What Makes Software Successful? (part II)

Yesterday I asked the question What makes software successful? and concluded that it’s mainly to do with whether or not your software is eminently liked, at a deep level, by its users.

This isn’t just the case for shrink-wrapped products such as MS Office or WinAmp. The same is often also true of custom-made business software; or highly configurable platforms, e.g. CRM systems like PeopleSoft. There might be a corporate mandate that “package X shall be used in call center Y”. But the rollout of “package X” can still fail abysmally if the users hate it, and therefore don’t have the motivation to really make the system work for them. This all translates into productivity, staff turnover and so on.

On the other hand, if users really buy into “package X”, they’ll be more willing to forgive it its warts and wrinkles, and to work (probably harder than they realize) to make the system work.

Liking or disliking something is highly emotive. There’s very little cognition going on when users decide, at a fundamental “gut feeling” level, whether or not they like your product. This is why the product’s appearance matters so much (something which Apple understands incredibly well), even when the product fulfills a not-especially-glamorous business function. This is one reason why, in the past, I’ve harped on about why Swing should by default look cool and behave swankily, and not make the programmers have to *think* in order to create cool results (and that, even though progress is being made, it can’t happen soon enough).

Of course there are exceptions; some clunky software has done undeservingly well; but we’re talking long-term success here, which means fostering loyalty in your users and nurturing a preference in your product even if a competitor releases a superior (on paper) product with more features.

This is a subject which Don Norman discusses in his book Emotional Design. He provides an example of a kettle which looks so cute and curvy on the stove that its owners are willing to forgive the occasional scalding from its poor functional design.

In the software world, users are less forgiving though. However cool you make your UI, try not to forget that you’re still building a tool, and people will judge it by whether or not it allows them to get their job done.

Rule of thumb: if your software looks cute and shiny, your users will love it. But if the software gets in their way or is even slightly awkward to use, you may as well cut out the middleman and feed that big pile of VC money to your pet hamster.

About the Author

Matt Stephens is a senior architect, programmer and project leader based in Central London. He co-wrote Agile Development with ICONIX Process, Extreme Programming Refactored, and Use Case Driven Object Modeling with UML - Theory and Practice.