With the rapid development of new user interface technologies, it’s tempting to claim that there’s a lot more to good design than simply applying standards. Although this is certainly the case, international standards in usability still have an important role to play. This is because usability standards:
- Ensure consistency:
- Standards provide a consistent benchmark to help design teams avoid annoying user interface inconsistencies.
- Define good practice:
- There are many conflicting viewpoints about good practice in usability.
- Standards, especially International Standards, provide independent and authoritative guidance.
- Prioritise user interface issues:
- Standards are serious business and whereas many organisations pay little regard to research findings, few organisations can afford to ignore standards.
- Help organisations fulfil their legal obligations:
- Disability legislation and Health & Safety legislation puts a legal obligation on service providers and employers to ensure that systems provided for users are fit for purpose and meet minimum ergonomics requirements.
- These requirements are worded rather vaguely in the legislation and therefore meeting relevant standards is one of the best ways of demonstrating compliance.
Ergonomics of human-system interaction: Human Centered Design (HCD) for interactive systems
The standard used to be known as ISO 13407. But in 2010 it was updated and re-issued as ISO 9241-210 to bring it into line with other ISO usability standards.
The standard describes 6 key principles that will ensure your design is user (or as they reference it – ‘Human’) centred:
- The design is based upon an explicit understanding of users, tasks and environments.
- The user is represented or explicitly involved throughout design and development.
- The design is driven and refined by user-centred evaluation.
- The process is iterative.
- The design addresses the whole user experience.
- The design team includes multidisciplinary skills and perspectives.
If we explore each of these principles, you’ll see why I believe this standard serves as an ideal manifesto for the field of user experience (UX).
The design is based upon an explicit understanding of users, tasks and environments
This principle is about understanding your users’ ‘context of use’. I like to think of the context of use as the user experience trinity:
- understand your users,
- understand what they want to do with the system
- understand the environment in which the system is used
As an example, the standard contrasts an interface aimed at a teenager downloading music on a mobile phone with a business user accessing corporate information on a handheld device. What makes a great experience for one may not be an acceptable experience for the other. Anyone who works in the field of user experience must surely sign up to this principle.
The user is represented or explicitly involved throughout design and development
The purpose of this principle is to ensure design teams include the user at the heart of the design phases: not just by running a focus group at the start of design or by administering a survey at the end of design.
Moreover, the standard emphasizes that user involvement needs to be ‘active': in other words, you don’t simply demonstrate your design to users; you engage them in the design. You can achieve this through field studies early in design and usability testing once you have an artifact that people can use. Again, this principle is a shoo-in for anyone who works in the field of user experience.
The design is driven and refined by user-centred evaluation
If I were asked to name one important contribution that the field of user experience has made to the world of design, I’d immediately pick usability testing. As well as being the canonical method that almost defines the field, it truly helps design teams improve upon their products, software and services. But one mistake that’s often made is to run just one test, usually at the end of development. The standard points out that usability testing should be carried out throughout the design process. So you should also use it to test preliminary designs, such as paper prototypes and electronic mock-ups.
The process is iterative
The standard describes this principle unambiguously: ‘The most appropriate design for an interactive system cannot typically be achieved without iteration.’ The idea behind this principle is that it’s extremely difficult, if not impossible, for users to explain what they want from a system. So to find out what people want, you have to show them something that they probably don’t want (your first design) and then discover how to improve it. This means that if you’re using a waterfall methodology where you have to nail down requirements before starting on design, your design process will struggle to be user centred. The standard doesn’t proscribe any particular development methodology, but if you’re using Agile then it’s much more likely you’ll be following this principle.
The design addresses the whole user experience
This principle wasn’t mentioned in the standard’s previous incarnation as ISO 13407. It’s probably been included in this new version to make sure people realise that usability isn’t just about the hygiene factor of making things easy (or at least, not making things difficult). ‘Easy’ is a good place to start, but usability (and a good user experience) is about a lot more than making things simple. The standard makes this explicit by writing, ‘the concept of usability used in ISO 9241 is broader and… can include the kind of perceptual and emotional aspects typically associated with user experience.’
The design team includes multidisciplinary skills and perspectives
I’ve often worked with design teams where everyone seems to have been cast from the same mould. For example, the design team contains predominantly graphic designers, or predominantly programmers, or predominantly usability experts. With this principle, the standard is pointing out that a siloed design team is the wrong way to approach user centred design. You need to include a range of views, including the voices of accessibility experts, end users, domain experts, marketing, tech support, technical writers and business analysts, as well as the roles just mentioned.
Even as an RFP response to a companies UX capability (or claimed capability) that’s a pretty compelling set of guidelines I think. Every company should ask themselves “do we do these things?” and if the answer is “Yes” then you’re a UX player… if the answer is “No” then you’re a design firm (which is nothing to be ashamed of BTW) who does some IA and Usbility type stuff.