MSc-IT Study Material
June 2010 Edition

Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |

Why designing for usability is sound economic practice

Given the evidence for the need for improved usability on a ‘macro' economic level we now look at the actual design of interactive systems. What motivates developers, and how that may bring them gains in the short-term, but trouble in the long term.

Deadlines

Software developers are very conscious of deadlines. The software market is very fluid and developers feel they must get products out into the marketplace on time above everything else. A fear of being usurped by competitors who get their product out before you and corner the market is ever felt and real.

However Cooper argues that this determination to get a product out, no matter what the quality, on time distorts priorities. In the long run, he argues, it is better to get a high quality product out behind schedule, than to get a bad product out on time.

Missing deadlines and failure to ship on time are not as dramatic as often held in the computer industry. He cites as an example the hand-held ‘palm top' market. In 1990 the Penpoint computer from GO was released and it was supposed to herald the dawn of hand held computers. It did not and two years later Apple released the Newton to universal apathy. The in 1994 the General Magic ‘Magic Link' brought out a hand held computer that failed to kindle any dramatic interest. Finally in 1996 the PalmPilot was released, was acclaimed, captured the market and still sells well. The point being that even though it was six years too late, it is a well designed and researched product that satisfies its users.

Features

A typical measure of how good a product is, are the number of features that the product offers.

I am using a now out of date version of Microsoft World to prepare most of these notes. By a quick count I can see one hundred and five options from the menu system alone, each of which relates to some feature or other. Let us say that some of the menu options relate to the same feature, so at a guess I should think there are about seventy or so features. Of these features I use at most ten and I should say I do not know how to use half of the other features, and do not even know what the other features are for. More up to date versions of Word come bundled with even more features, none of which I would use.

I have, in fact, been using Microsoft Word since 1990, and the only new feature that has in any way changed the way I do my word processing is real time spell checking. All other features, buried away in menus, toolbar buttons and other dialogues, stay there, unused.

Adding features does not improve usability unless firstly those features are useful, and secondly those feature are usable.

Furthermore an explosion of features in a system is not neutral. You may think that throwing extra features into a system at worst does not effect usability and may improve it, by offering the user extra things to do. However extra features clutter an interface and may make it more difficult to find useful features. Also the product becomes more intimidating to novice users.

Features can be expensive to develop, but if they are not used then that effort is wasted in the long run.

Throwing mud against a wall

The fluidity of the software market means that there is little emphasis on analysing why a product fails. It is better just to chalk a failure to bad fortune and move on to another venture. The availability of venture capital means that it is easy to do this: venture capitalist will put a little money into a wide range of investments and hope that one at least will be successful enough to make a profit over all the other failures.

A little analysis of why a product fails, and it is typically because a product is simply not a useful tool, or if it is useful it is too difficult to use, will prevent failures in future. A lot of venture capitalists believe that there is no way to predict what will or will not fail (the ‘unpredictable market') and are therefore just as likely to fund bad products as well researched and target ones.

A random activity is light-heartedly called ‘throwing mud against a wall to see what sticks'. The funding of many high tech capital ventures follows very much this idea.

Releasing versions

Software products tend to go through several phases while out in the market place. Successful products iterate through many releases, typically as more and more features are piled in, but sometimes as genuine improvements are made too.

Cooper argues that the real cost in the information age, is not what you are building, but what you are not. If it takes four releases to get your product right then this means you did not release three good products on the first release.

The solution

The solution to all the problems we have outlined above is design, where design is an activity that takes place before anyone actually gets around to writing code. It is important to find and understand the problems that users have and then to design a system that will overcome those problems. It is then important to design that system to be easy enough to use such that the effort of using it does not outweigh the problem it was trying to solve in the first place.

The reason that this does not happen is because of the invisibility of the negative consequences. Recall the London Eye booking system. Its benefit to its owners are a reduction in staffing costs which is easily quantifiable. Its cost is lost revenue, which is invisible and difficult to quantify. Hence a system that is not built with what users actually want in mind. Deadlines and feature lists are all tangible and quantifiable. Management can point with pride to a product that ships on time and has a certain number of features and success has been measured this way because it is easy to do so. Measuring the success of a product in terms of how many useful and usable features it offers is much less easy.

Long term thinking is the key. Rushing out a badly designed product to meet an apparent need may have readily apparent short term benefits. Spending time researching a product requires long term thinking and financing and this may be problematic to justify, particularly if your competitors are rushing out products. Sometimes when you throw mud against a wall some of it sticks, but you are much more likely to get some to stick if you investigate the wall first and design your mud to stick to it.