There’s no excuse in this day and age for a nonuser-friendly interface and often the only source of reliable insight into this area is the user. Dave Tait* puts the case for the user as invaluable testing tool.

Gaining maximum market share with a software product means selling to inexperienced as well as experienced users and making both of these types of user feel like it was designed with them in mind. The ‘Windows 7 was my idea’ campaign appears to demonstrate that Microsoft have taken this on board, in a move reminiscent of Nintendo’s creation of the Wii, a games console even non-gamers can use.

Software developers themselves can be hamstrung by their own expertise when it comes to testing since by definition they only represent expert users. That is why it is important to get end users involved in the design process as early as possible. Not only can they find bugs in software by interacting with it in unexpected ways, but they can also reveal fundamental problems with its usability.

In the past, users accepted the blame for their inability to use technology. It was seen as the domain of people with knowhow and if you were struggling with a piece of technology it was either because you were too lazy to read the manual or just plain stupid. Oddly, this acceptance of blame extended even to devices such as VCRs and central heating controllers, devices which, on the face of it, should not need specialist knowledge to operate.

Designers, manufacturers and even suppliers all seemed happy to go along with blaming users. However, with the increasing ubiquity of electronic devices and electronic interfaces in general, including web pages, it is becoming evident that this belief is increasingly untenable. There are just too many interfaces to learn and not enough time to consult the manuals for all of them.

Of course, many of the usability problems of older technology were associated with the cost and size of components, yet others were plainly down to a lack of user testing. Even now parking ticket machine manufacturers, for example, come up with some of the most baffling designs; designs that suggest that their machines are never used hurriedly or in a rainstorm, by non-native speakers, visually impaired people, or by people who are simply carrying something.

Software interface and website design can be just as baffling for the same reason – that testing was limited to making sure the product did not fail. While catching bugs is a crucial part of software development, the fact that software works is something that users have come to expect as standard. They are now evaluating software based on whether they had a positive or negative experience of using it, not just whether it worked at all. Building the product right is not the same as building the right product.

Why should this concern developers? Because customers are being presented with an increasing number of products to choose from and those that are easy and even pleasurable to use will win out. Customers implicitly blame the developers of those products they cannot use by choosing products that they can use instead. Gone are the days of struggling manfully with technology solely because it has superior technical specifications to its rivals.

Even large companies purchasing bespoke software are coming to realise that simple-to-use systems reduce the costs associated with training their personnel to use them, as well as the costs of onsite helpdesk provision. Simple systems can also increase productivity due to fewer errors in user-system interaction.

Software focussed on users’ needs is also cheaper to develop and maintain. According to a 2003 review of surveys on software effort estimation, the respondents (typically project managers) in one survey believed that half of cost or schedule overruns were due to changes in design and implementation. Another survey suggested overruns were caused by frequent requests for changes from users, overlooked tasks, users’ lack of understanding of their own requirements, and poor communication and understanding between users and analysts. Fixing a problem after a product has been released is far more expensive than identifying it at the design stage. This is where a user-centred approach to software design comes into its own.

User-centred design (UCD) involves users in the development process right from the start. Users’ tasks and goals are the driving force of UCD and it establishes what these are with questionnaires, interviews, focus groups and so on. Users’ current behaviour and the context of the product’s use (for example whether it is to be used in a noisy environment) are also studied to see if this will affect the design. The combination of this information establishes the user requirements. Getting these right is crucial as it is not only failing to meet all the users’ requirements that makes software unusable for the target user group, but also the extra complexity and cost of unnecessary functionality.

In UCD, prototypes are developed and presented to users only after the user requirements have been established. In the early stages there may be many prototypes and they will probably be lo-fi, perhaps consisting of sketches or storyboards. The most appropriate prototype may go through many design iterations, depending on the responses of users, as it progresses towards a hi-fi prototype.

Users are consulted throughout the whole design process from early concept phases to the final product, with each design iteration being traceable back to user goals. Where possible, users are studied interacting with the prototypes in order to highlight any usability issues.

Historically, system design and testing has tended to focus on functional requirements – what the system should do. UCD expands this focus to users as well. It takes into account their varying attitudes towards and abilities with computers. Systems are designed to be helpful, memorable and clear for novices and infrequent users, while retaining power, flexibility and speed for expert users.

By taking the UCD approach developers get access to two very valuable resources – expertise in the process that the software product seeks to streamline, and a sense of what the solution looks like from the point of view of someone who has no idea what is going on behind the user interface. In addition, involving users early on in the design process means that developers can make sure they are building the product their customers need, and instil a sense of ownership of the product in the users. This can drastically reduce the cost of the product since the maintenance phase is often the most expensive phase of the software lifecycle. This in turn is good for customer satisfaction and that has a positive effect in terms of customer loyalty.

* Dave Tait is a recent graduate of the University of Sussex where he studied Human-Computer Interaction as part of a Music Informatics BSc.

Dave Tait

davidatait@googlemail.com