Introduction

1         Introduction

This is an overview of the standard user-centred interaction design process based on ‘BS EN ISO 9241-210:2010 Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems’ (hereafter referred to as ‘the HCD standard’). It contains my suggestions for methods and techniques with their documentation to be produced during the design process. These are based in large part on the GUIDE methodology [Redmond-Pyle & Moore, 1995] and not specified in the HCD standard. This is just an outline; additional information and training are required to carry out this process.

Why should you take account of this ‘standard process’ when plenty of successful interaction designers have never even heard of it! Well, if someone really is a successful interaction designer, the elements of this process will almost certainly be respected in their work, even if they are not aware of it.  I think that there are at least four reasons to use it consciously.

  1. An international bunch of bright and experienced interaction design professionals worked for years to put this standard together. You might just learn something from it.
  2. Seeing a formal description of a process with which you are familiar often gives insight that will improve your performance; even (especially) if you think they have it wrong.
  3. Being able to describe what you are doing as complying with an international standard, may be a useful card to have up your sleeve when negotiating with clients or management.
  4. An indication of developing maturity in an industry or profession is an acknowledgement of standards, both de facto and de jure. They provide a framework for assessing performance and competence. Professional practice requires knowledge of standards.

2        The formal process

The HCD standard is a concise document of 32 pages. I recommend getting hold of a copy, though it is expensive. (Students may be able to access it through university libraries.) It sets out the major human-centred design activities that are carried out in designing an interactive system:

  1. Understand and specify context of use
  2. Specify user requirements
  3. Produce design solutions to meet these requirements
  4. Evaluate design against requirements

These can be summarised as analysis, specification, design and evaluation. However, it is important to note that these are not presented as ‘waterfall’ steps. The standard acknowledges that in real life, these activities must be carried out iteratively; a two steps forward, one step back progression (sometimes more than one step back), where an understanding of what is really needed is negotiated between the designer, the commissioner and the eventual users. Sometimes it is even more complicated, as elements of the process occur simultaneously. The process is summarised in the simple diagram below, based on that in the standard.

In the standard, each HCD activity is defined by the information that should be acquired during it and the quality criteria that should be met. This implies a collection of sub-activities to be carried out to elicit and produce information. These are not specified in detail, but may be focused around the production of intermediate documentation. The formality with which any documentation is produced and maintained will vary between projects. There is no point in doing it more formally than will suffice. For a small one-person project it may amount to no more than notes and sketches. For a large multi-person project a rigorous document management system may be needed.

Where standards for documentation exist I recommend using them: those that I am aware of are referenced in this document. However I suggest that these standards be used as guides rather than rigid templates. They really constitute check-lists compiled out of the collective experience of many designers. You don’t necessarily have to complete them in full, but at least scanning them for relevance to the current project will help you avoid naive mistakes. There is a difference between not using something out of ignorance and an informed decision that it is not relevant.

Production of each element of the documentation set is initiated in an obvious sequence. However the overall process is iterative, with new discoveries requiring addition and amendment to initial documentation occurring throughout.

The precise documentation set is not specified in the standard. The formats of some intermediate documents have been specified in other standards to integrate with ISO 9241. I recommend using these along with other appropriate document templates drawn from various methodologies, in particular GUIDE [Redmond-Pile & Moore]. The status of this recommendation is slightly more than mere personal preference. This set explicitly allows a principled flow of rationale from the input analysis data to the design. It is listed in the table below. The production of intermediate documentation helps focus and guide the development. It also assists in supporting user input into the design process by presenting key elements in a form that they can understand and critique.

HCD Activity 1: Understand and specify the context of use
  • For all tasks
    • Task Scenarios (of key tasks)
    • Abstract Task Models (for each user group)
  • Glossary of specialised terms
  • For each user group
    • User Profiles
    • User Personae (based on profiles)
    • Conceptual models (based on task scenarios)
HCD Activity 2: Specify the user requirements
  • Usability requirements (NISTIR 7432 Common Industry Specification for Usability-Requirements)
HCD Activity 3: Produce design solutions to meet user requirements
  • Wire-frames
    • Initial pencil sketches
    • Wire-frames cleaned up (possibly using software presentation tools)
  • Lo-Fi Prototype
  • Application Style-Guide
HCD Activity 4: Evaluate the designs against requirements
  • Prototyping Session Report (for feedback to Activity 3)
  • Evaluation Report (for completed implementation, ISO/IEC 25062 Common Industry Format for Usability Test Reports)

The requirements of each intermediate product are described in the following sections.

3          History of the standard

This document covers the latest version of the international standard for human-centred design. It was preceded by ‘ISO 13407:1999 The human centred design process for interactive systems’. It retains the gross structure of the preceding standard (the four activities, presented as an iterative process) but is slightly less prescriptive of the details in these activities, making it more flexible in application. The changes are described as: [ISO 9241-210, p.iv]

  • clarifying the role of iteration in the whole design process (not just evaluation);
  • emphasising that human-centred methods can be used throughout the system life-cycle;
  • explaining design activities;
  • clarifying the principles of human-centred design.”

In addition it has been renumbered as a part of a larger collection of standards dealing with ergonomics of human-system interaction (and an earlier set addressing office work with visual display terminals). Familiarity with the complete set of standards is advantageous.

4         References

BS EN ISO 13407:1999 The Human-centred design process for interactive systems.

ISO/IEC 25062 Common Industry Format for Usability Test Reports.

NASA (1991). NASA-STD-2100-91 Software Documentation Standard. [online] Available at: <http://www.profinit.eu/uploads/souvisejici-obsah/dokumenty/cz/academy/sweng-materialy/documentation/reading/NASA_SwDocumentationStandard.pdf> [Accessed 21 September 2011].

NISTIR (2007). NISTIR 7432 Common Industry Specification for Usability-Requirements. [online] Available at: <http://zing.ncsl.nist.gov/iusr/documents/CISU-R-IR7432.pdf> [Accessed 21 September 2011].

Redmond-Pyle, D. & Moore, A. (1995). Graphical User Interface Design and Evaluation (GUIDE): A Practical Process. Prentice Hall PTR

The Atlantic Systems Guild Ltd. (1995) Volere Requirements Specification Template. [online] Available at: <http://www.volere.co.uk/> [Accessed 21 September 2011].

One thought on “Introduction

  1. Pingback: What’s In a Name | Paul Daly

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s