Information & Design
Designing for humans
Designing for humans
This was produced originally as an A5 booklet, and is available in PDF format (File size: 30 KB)
- Gerry Gaffney, 2004
This document is:
This document is based on personal experience and opinion, rather than a considered review of the literature.
Several formal and informal definitions of usability exist. The most widely recognised is probably the ISO definition:
The usability of an interface is a measure of the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in a particular environment with that interface.
Although the definition of usability may be the subject of some discussion, lack of usability is readily recognisable. Systems that lack usability are characterised by:
Because incorporating usability is a quality activity, it often occurs that systems with poor usability are also deficient in other areas. For example, they are likely to be crash-prone, poorly documented and difficult to maintain.
By contrast, usable systems:
Benefits deriving from usability include:
There are several specific activities that can be carried out to incorporate usability in product development.
During analysis, activities such as contextual enquiry, user profiling and requirements gathering activities can be conducted.
At the evaluation stage, expert usability review ('heuristic evaluation') and usability testing can be conducted.
The guiding principle for all these activities is that the user or customer is at the centre of the design. This is referred to as user-centred or customer-centred design. It should be noted that users include end-users, but also any other users (for example, support or administrative staff).
Technical communication and usability can be considered to share the common goal of enabling people to use systems to complete their tasks.
Unfortunately, some of the work of the technical communicator consists of 'fixing' user interface problems in the documentation. In theory, the application of usability techniques could reduce this requirement.
The two fields share many characteristics:
Very often, the technical communicator is the first real person to attempt to use a system. (For our purposes, a 'real person' is one who has to actually use a system.)
Many technical communicators are de-facto usability consultants. They are in a good position to provide feedback on design flaws to the development team. However, this role many only be available if there is sufficient time, and crucially, if the project team is open to such feedback.
In fact, technical communicators are often very well placed to provide such feedback. They are generally respected (or at least tolerated) by technical and design personnel, who perceive that there is a need for their services.
In ideal situations, technical communicators are engaged early in the product development, and are consequently in a position to have an influence on design decisions.
Technical communicators are therefore well placed to implement usability by stealth.
However, most projects are cost-driven, and engaging in usability commentary may be well outside the scope of the technical communicator's brief.
In the worst case scenario, technical communicators can be a force for evil, because if they have given a fixed-price commitment, they may be in a position to enforce design freezes even though significant usability flaws exist.
Technical communicators often have many of the skills required by usability professionals.
The ability to write should not be underestimated. Many usability professionals are poor writers, and therefore have difficulty in communicating their findings and recommendations.
Of necessity, technical communicators tend to have good analysis skills. They are used to approaching a new product or environment with little or no background knowledge, to absorbing large quantities of new information, and to identifying the salient information in large sets of data (such as user profiles, requirements documents, specifications and the like).
Technical communicators also tend to be familiar with applicable standards, such as style guides and interface design guidelines.
They are also generally comfortable dealing with both technical and non-technical people, since they gather data from the former in order to communicate with the latter.
They tend to have the diplomatic and political skills to be able to remain impartial, particularly when bearing bad news about an interface to the development team.
Over and above all these specific skills, the technical communicator has (or should have) and affinity with the eventual users of a product or system. The technical communicator is inherently user-centred.
It is unfortunately the case that on many projects, technical communicators are not afforded the opportunity to interact with real users.
There are several skills that technical communicators may not have, or may not have sufficiently developed.
During analysis, it's necessary to spend time with real people. The ability to listen to them, to learn about their work and their issues, and to distil this information for the benefit of the design team is crucial. Techniques for interviewing users and conducting contextual enquiries are described by Beyer and Holtzblatt in 'Contextual Design'. Refer to our one-page summary of the technique.
During evaluation, the ability to conduct expert usability reviews (heuristic evaluation) is important. This activity is fraught with the potential to be highly subjective, and it's necessary to have a good method for conducting such reviews. To some extent, this comes with experience; and particularly from experience observing real people use real systems. Most practitioners also use a checklist when conducting this activity. We have an example of such a checklist (for web evaluation). Jakob Nielsen has also written several articles on usability heuristics.
The ability to conduct usability testing is also important. At first, this may seem somewhat daunting. However, in practice it is quite straightforward, provided it is approached in a methodical fashion. Rubin's 'Handbook of Usability Testing' is an excellent and practical book on this subject. Refer to our one-page description of the technique.
It is perhaps in the design area that technical communicators are most likely to need to develop new skills. In my experience, many technical communicators are much stronger on verbal skills than on visual skills.
I have no magic formula for developing such visual skills. Mullet and Sano, in 'Designing Visual Interfaces' are excellent on the visual aspects of interface design, and Edwards' 'The New Drawing on the Right Side of the Brain' is an excellent resource for learning to draw.
In my experience, one of the most exciting and fun activities in usability is facilitating design workshops. This can be very daunting and challenging, but the benefits are usually very great. Refer to our one-page description of one technique.
Good presentation skills are also required, particularly when trying to sell projects on the benefits of usability, and when presenting results that my be unpalatable. One of the best ways to develop presentation skills is to have someone critique your performance.
Various techniques are described on our website.
Usability is gaining acceptance in the technical community.
In particular, the advent of the Web is forcing designers to build systems that can be used by ordinary people.
Computing power is cheap, and staff time is expensive, so organisations are seeing the benefits of providing their staff with efficient systems.
In addition, I believe there is a groundswell of opinion that technology is unacceptable if it is difficult to use. After all, technology is supposed to improve our lives, not make them harder.
A well-designed system requires less documentation than one that is poorly designed. In some ways, the move towards usability could be seen to present a threat to the technical communication community. However, I do not believe this is the case.
The terms 'interaction design' and 'customer experience design' are also becoming increasingly common, and there are factions and adherents in various camps.
Eventually, usability must become an inherent part of the design process. It is simply nonsensical to turn out systems that are unnecessarily difficult to use.
Technical communicators are well positioned to add a usability string to their bows, and this can benefit not only themselves, but society at large.