Abstract
Laboratory automation and instrumentation vendors frequently claim usability among their long lists of features and benefits—but can they justify that claim? What makes a product usable and how do you design for usability?
This article outlines an approach used to create usable products in other application areas, such as eCommerce and medical device development, and suggests that a similar approach could provide benefits for users and developers alike in the field of laboratory automation. The user-centered design process is summarized, together with a set of usability heuristics that can be applied during the design process and used to evaluate usability during development.
Keywords
Introduction
In the laboratory, product features and performance are quite understandably of paramount importance and usability has perhaps not been so high on the agenda. Yet the consequences of poor usability can include days lost in training courses, time spent poring over user guides, expensive user errors, equipment lying gathering dust at the back of the lab, complex features left unused, and time wasted using an inefficient user interface or an instrument that does not integrate well with existing systems and working practices. Quite simply, poor usability increases the total cost of ownership of a product.
It is not just product users and their managers who can benefit from improving the usability of laboratory products and systems; vendors stand to gain too. A usable product will require fewer support calls, less documentation and will ultimately be better accepted and more successful. As the market becomes more competitive, usability can be a key product differentiator and a crucial factor in the purchase decision in a world where evaluations and ‘try before you buy’ are becoming very common. For in-house solution developers improved usability will speed up buy-in and compliance with new systems as they are introduced.
We frequently see ‘user friendly’, ‘usable’, or ‘intuitive’ mentioned in the list of features of a new product, but what do these terms really mean and can they be justified? As developers of laboratory automation equipment, instrumentation, and informatics software, how do we go about achieving usability in our products? There may be lessons to be learnt from the eCommerce and Web development world where usability is taken very seriously. Usability engineering as a profession has grown out of this industry because of the huge business impact poor usability can have in this domain; if customers cannot use a website, they will not buy the product it is trying to sell and may well be lost to a competitor. This has acted as a great motivator for the website developers to improve and formalize their usability engineering techniques.
This article introduces the principles of user-centered design (UCD), which is used widely in the Web development domain and increasingly in other areas where usability important, such as medical and consumer product development. It covers aspects such as gaining insight into the user requirements by establishing the context of use for a product, designing for usability, and using prototypes to evaluate usability and iterate the design during development.
User-centered design
Unfortunately, usability generally cannot be bolted onto a product as an afterthought; it needs to be built in from day one of development and this requires some changes in the way product development is approached. UCD is a widely recognized philosophy and design process for developing usable products and systems. Although it is best known for its application in website development it can be applied in any context, and is particularly suited to complex applications such as those encountered in laboratory automation and informatics. The UCD process aims to ensure that the right product is designed to meet the user needs and that it is designed right, that is, to be usable. In fact, it is becoming so mainstream, that the Food and Drug Administration (FDA) in the US has a human factors program 1 to educate developers and encourage the use of ‘human factors engineering’ (another term for UCD) in medical product development, and is increasingly looking for evidence that a UCD approach has been applied to medical product developments as part of its approval process, with the aim of reducing the number of product recalls and use errors.
As the name suggests, UCD involves thinking about the user experience first and foremost, then designing the technical solution to fit, compared to a technology-centred development where a technical solution is designed first and then a user interface is fitted on top. 2 Laboratory automation products are typically technology-centred and new products are frequently evolved from earlier products, with perhaps little opportunity to stand back and look at what the users really need. Spotfire Inc., developer of data visualization software, is a notable exception; the company's starting point was a consideration of the interaction between user and computer and this focus on the user experience with an interactive and visual approach to data analysis remains a strong selling point.
An important feature of UCD is a multidisciplinary development team, which includes usability or human factors specialists in addition to the technical and domain experts appropriate to the product. This is supported by the FDA whose recommended design process for medical devices 3 advocates the involvement of human factors professionals from the earliest stages of product development. In contrast, products in the laboratory automation industry are often developed by teams of engineers or chemists-turned-software developers, with little or no specialist input from the human factors field.
The UCD approach to product development is characterized by three main themes:
Establishing the context of use Designing for usability Evaluating usability
The emphasis is on iteration. Having established what the users need and want from the product, concepts and prototypes are continuously evaluated during development for usability and their fit to those needs. A typical UCD process is illustrated in Figure 1.
UCD process.
Context of use
Defining the context of use involves identifying the intended users of a product, the tasks they will perform and the environment in which they will use the product.
It is important to establish who the users are, their goals in using the product and their characteristics such as skills, experience, training, and priorities. There may be different user groups looking for different things from the product. For example, is the product intended to be used by expert users who will be provided with appropriate training, or is the product aimed at a broader user base for whom training is not practical? It can be useful to develop profiles of the key user groups for the product, suchas expert and novice, or users from different disciplines or backgrounds.
In identifying the tasks users will need to perform with the product to achieve their goals, considerations should include how users currently perform the task and their mental model of how the product might achieve it, task frequency and duration, the risk resulting from error etc.
Environment considerations will include the physical and social environments in which the product is used as well as other aspects such as the information technology (IT) or regulatory environment. Physical environment factors might include lighting or ambient noise, space and location, user posture, and health and safety factors such as protective clothing. For example, will the user be wearing gloves, will there be space for a mouse and/or keyboard or other product accessories, will the user typically need to access the user interface with one hand while carrying labware, what cleaning procedures are acceptable? Social environment factors might include work practices such as shift working, support for group working or shared access, and the need to provide metric collection and reporting for management. Other environment considerations relevant to laboratory products might include networking, security, and integration with other systems. The need to be 21 CFR Part 11 compliant is a regulatory environment factor particular to this industry that can cause considerable usability issues if the implications of authentication on user interaction are not addressed early in development.
The context of use analysis is an additional user-focused step in gathering product requirements, which are traditionally defined by internal stakeholders such as product managers in the developer company. The analysis moves the requirements gathering exercise out into the lab, typically involving observation of and interviews with representative end users, and may identify new, previously unexpressed user requirements or serve to modify and prioritize existing requirements. It also provides valuable information for the user interface designers and provides a framework for evaluating usability as the product is developed.
Design for usability
In designing for usability, we need to understand what makes a system or product usable. Usability is officially defined in EN ISO 9241, ‘The ergonomics of human system interaction’, as the ‘extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use’. This is useful in terms of measuring how usable a product might be, but does not help much with understanding how to design it to be usable in the first place. There have been numerous attempts at capturing the essence of usability as a set of good practice guidelines or ‘heuristics’ for user interface designers to follow. The heuristics presented here are based on those derived by Nielsen 4 and are generally applicable to any user interface:
1. Visibility of system status
The user should be kept informed of what is going on through appropriate feedback within a reasonable time. The user should never be left in any doubt as to the state of the system or the results of their actions.
2. Match between system and the real world
The interface should use terminology and concepts that are familiar to the user, also referred to as ‘speaking the users’ language’. There should be a match between the interface and real world conventions so that information appears in a natural and logical order.
3. User control and freedom
The user should be able to navigate and explore the interface without penalty, such as loss of entered information. There should be clearly marked exits from all screens or dialogues and the user should be able to undo unwanted actions and redo them if desired. This is an important factor in allowing users to feel confident in learning how to use a product by exploration rather than referring to the user manuals (often a resented last resort as far as the user is concerned). At any time the user should be able to answer the questions: Where am I? How did I get here? Where can I go from here?
4. Consistency
Language and structures should be consistent; both internally within the interface, and externally with any recognized standards and industry conventions.
5. Error Prevention
Where possible the interface design should prevent users from making errors and the consequences of user error should be minimized. This extends from simple validity checking on data entry to, for example, preventing robot moves that could cause damage or injury. Of course it is not possible to prevent all user errors, but designing a system with this in mind, rather than trying to prevent errors as an afterthought, makes it more achievable.
6. Minimize user memory load
The user should be presented with available options and required data entry formats and should not need to remember information from one part of the interface to another. It should be possible to recognize what needs to be done in any given situation rather than have to remember this.
7. Flexibility and efficiency
The interface should support both novice and experienced users. Mechanisms designed to guide the novice, such as setup wizards, should not frustrate and slow down the experienced user. It may be appropriate to make shortcuts available to experienced users and allow them to configure the interface and tailor frequent actions.
8. Aesthetic and minimalist design
The interface should not present irrelevant or rarely needed information as this diminishes the visibility of the relevant information. Layout and color should be used to group related information and attract attention. Color should be used sparingly and consistently, and should not be used as the sole means of conveying key information (around 8% of males have some degree of color blindness). Aesthetics also contribute to the satisfaction element of the definition of usability. Users tend to expect an attractive user interface to be more usable than an unattractive interface and may be more forgiving of problems in an interface that they feel more warmly towards.
9. Help users recognize, diagnose, and recover from errors
Error messages should be in plain, straightforward language (no error codes or system jargon), indicate the problem as precisely as possible, and suggest a recovery route. Error messages are a frequent target for gripes about user-unfriendliness, perhaps because they can sound accusatory (implying that the user has done something wrong) or because they often emanate directly from a software developer's code rather than being a designed part of the user interface. Error messages should be treated as an important part of the dialogue with the user.
10. Help and documentation
Most laboratory systems will have sufficient features to warrant the provision of user documentation and a help system. These should be easily accessible, searchable, and presented in a task-oriented format.
While these usability heuristics can be very helpful, there is more to developing a usable product than simply applying a set of rules to the design. It is also important that the user interface is structured in a task-oriented way. The user interface design activity should start by considering the users’ goals in using the product and the tasks they will need to perform to achieve them. The navigational structure of the interface can then be designed to support these tasks. For a software application this would involve defining the main screens/windows, their basic contents and how the user moves between them, before worrying about design details. A classic problem with many user interfaces is that they are structured around the functions available in the application (or worse the software architecture) without regard to how they are used in the context of the user tasks.
Figure 2 is a screenshot of the very successful Google search site. Google is totally oriented to the users’ prime task of searching the Web and is an excellent example of the usability heuristics in practice. It provides a simple and clean interface for the basic search, without complicating the main screen with the more complex features for advanced users. It provides clear feedback on the search that has been performed, and makes it easy to modify and repeat the search. Minimal use of color is made so that the user is not bombarded with advertisements and a riot of confusing color, and the simple layout makes it clear which are the sponsored results. Accepted conventions are followed, both for defining search strings and in the use of underlined blue text to represent links, which change color when visited. If the user misspells a search term, the interface offers help in the form of a link to a search with the correct spelling. Of course, the search engine performs well too, but the provision of a simple usable interface that meets the users’ needs is recognized as having been fundamental to Google's success.
Google - usability heuristics in practice.
Evaluating usability
A key aspect of the user-centered process is evaluation of usability during development and feedback into the product design. Prototypes of the product being developed are usually produced so that this activity can start as early as possible, often when the product is just a concept.
In the early stages of development, low fidelity prototypes such as paper or PowerPoint slides can be tested with users to improve and validate the concepts. Paper prototyping 5 can be a very effective technique to get early feedback from users without investing too much development effort. Users can be very receptive to working with paper prototypes and are often more comfortable with criticizing and contributing to a design that is still obviously very much in progress. Paper prototypes are particularly helpful in exploring aspects such as user interface structure, navigation, and grouping of related information without getting distracted by the cosmetic details of the interface. However, as development progresses it is important to test the user interaction with prototypes of increasing fidelity (closeness to the final product) so that issues associated with the more detailed look and feel can be addressed. It is important to bear in mind when planning prototyping activities that evaluation of functional prototypes can uncover issues relating to response time and error recovery that may have a dramatic impact on the user experience which may not be apparent with earlier low fidelity prototypes. Of course, prototyping in itself is nothing new and many development teams produce prototypes during development; these are demonstrated to sales teams, customers, and managers, but rarely in this industry are they subjected to testing with real end users or independently reviewed for usability.
Usability evaluation generally takes the form of an expert review or user testing. In an expert review, one or more experts review the design to look for usability problems, usually by considering a set of usability heuristics such as those described above. The experts will ideally include someone from the usability or human factors field, and should also include a domain expert for the product; this is particularly important for the specialized and complex applications in laboratory automation and informatics.
User testing is the best way to determine any real user problems. It involves representative users using the product or prototype to perform a defined task in controlled experimental conditions. There are various ways of conducting a user test, but useful results can be obtained without specialized equipment or usability labs using a simple ‘think-aloud’ protocol. This involves defining a scenario for the users and a task for them to perform, and asking them to give a running commentary of their thoughts as they try to complete the task. The test facilitator notes user comments, behavior, and problems in using the interface. It can be useful to video record sessions so that issues can be demonstrated to the development team. The skill in performing an effective user test is in the selection of the scenario and tasks so that they are realistic, achievable, and not presented to the user in a way that biases the outcome. A user test can also be a great opportunity to get subjective feedback from the participants, either by means of a structured interview or questionnaire.
A combination of techniques is usually the most cost effective and practical approach to usability evaluation. Expert review is quicker, cheaper, and generally better at achieving broad coverage of a whole user interface but typically misses some complex issues. User testing is good for rooting out detailed problems, but is best applied to testing one or two specific aspects of an interface, as it is generally too expensive and time consuming to run user tests on every feature. Whereas it can be expensive to carry out extensive user testing, valuable results can be obtained from just a few users and, unless some form of statistical analysis of the results is required, studies have shown that testing with more than five users gives diminishing returns. 6,7 It is generally better to test frequently during development with fewer users than less often with many users.
The problems uncovered during usability evaluations should be logged, assessed (for severity and recommended action), and tracked in a comparable way to bugs uncovered in functional testing.
Putting it into practice
Incorporating UCD within a typical product development process need not be difficult; most modern development processes are iterative in some way and this is conducive to user involvement and feedback into the design. Nevertheless, it does require a shift in focus and some extra activities such as usability evaluation that can fall prey to tight budgets and slipping project schedules. It does not have to be all or nothing though, and any investment in usability work is likely to pay off. In fact, following a UCD process can often reduce development time by focusing on features users really need (avoiding the ‘feature bloat’ which often compromises usability) and spotting requirements and usability problems early in the process, before they become expensive to fix.
This article provides just a short introduction to the subjects of usability and UCD. Ideally the user-centered development team would include a human factors or usability engineer who will contribute an understanding of human characteristics and abilities as well as skills in user research, user interface design, and techniques for effective usability evaluation. However, there is a wealth of information available to support developers, project leaders, and managers wishing to know more; perhaps not surprisingly, many books on the subject of usability are highly usable themselves. In particular, Nielsen's ‘Usability Engineering’ 6 is a very accessible description of usability engineering methods, ‘e-Commerce Usability’ by Travis 8 is a great practical guide which describes tools and techniques that can easily be transferred to product development, and Schaffer's ‘Institutionalization of Usability’ 2 is an excellent guide to introducing UCD into a product development company. Finally, the FDA recognized standard, “Human Factors Design Process for Medical Devices”, 3 provides a concise description of a UCD process and associated design and analysis techniques.