INTRODUCTION

This chapter explains what user-centred design is. We start by considering design itself, and looking at some of the ways in which design is commonly neglected or marginalised. We then move on to look at the principles and processes of the human-centred design cycle as defined in ISO 9241-210 (2019). We identify what is special about user-centred design, and review the concepts of inclusive design, user experience, usability and user acceptance testing.

LEARNING OBJECTIVES

After reading this chapter you will be able to:

THE PLACE OF DESIGN IN THE PROJECT PROCESS

Many products and systems are hard to use, or are not found to be useful. Consequently they cause their users frustration or worse, and in a business context, they waste money. How can we design systems that are usable and useful? This book is about a particular approach to designing products, systems and services which aims to achieve just that. As a first step, we need to be clear what ‘design’ means. There are two specific traps to avoid here.

First, anyone who is familiar with the ‘system development life cycle’ concept – see, for example, Cadle (2014) – will be familiar with the notion of design as one stage or component in the overall project process, whose exact nature depends on the type of life cycle being used, but which generally is logically or chronologically consequent upon requirements analysis. In this book, we use ‘design’ in a different sense: to refer to the entire project process (as in, for example, Beyer and Holtzblatt, 1997; Newman and Lamming, 1995).

Second, in colloquial speech we often talk about ‘design’ when referring to the cosmetic aspects of a product. The scope of user-centred design is, however, certainly not restricted to cosmetic elements. Design is the whole project.

Inescapably, all products and systems are designed. Design is nothing more or less than the cumulative effect of all the decisions, large and small, which have an influence on the nature of the final product. If we want to create better products and services, we need to ensure that we take the right decisions, from the beginning to the end of the project. We need a process that will take into account, as far as possible, all the factors that could affect the quality of the solution.

The quality of the solution is very largely determined, not by the functional properties of the product, but by the user experience associated with it. Recall from Chapter 2 that usability is one component of user experience. It is objectively measurable, as we will see in Chapter 6.

ALTERNATIVE APPROACHES TO DESIGN

User experience consultant Jared Spool (2009) has identified several different types of design decision-making that are used in the real world. We look at two of them here.

Unintended design

One commonly used style of decision-making in design is ‘unintended design’. Unintended design happens when the people making decisions that affect the nature of the product do not properly consider the effect that their decisions will have. They might do this to save resources such as money or time, by doing whatever is easiest to implement. Just as frequently, they do it because they do not understand the scope or nature of the effects produced by their decision.

Usability and accessibility are particularly vulnerable to this problem: as we saw in the last chapter, software systems are often designed primarily on the basis of functional requirements, that is, what the software can do, with usability and accessibility relegated to the unimpressive-sounding category of ‘non-functional’ requirements. The underlying problem is that the system boundary has been drawn too narrowly: the product’s designers have focused only on the software’s inherent properties, rather than taking responsibility for ensuring that the overall socio-technical system works properly. There are often commercial reasons for this: a purely product-focused approach often appears less risky and easier to control.

Self-oriented design

Sometimes an individual designer or a design team will design a product for their own purposes, in order to meet a need that they have themselves, without reference to any existing or prospective external customers. Spool (2009) calls this ‘self design’. In some cases, a product designed like this may succeed in making the transition from being used exclusively by its makers to a wider circle of customers; this is unusual, however. When a product is designed in this way, its design will tend to include assumptions about the users and their needs that are not transferable outside the original environment for which it was created.

Almost all human beings have the ability to imagine themselves in someone else’s situation. We are always happy to give others the benefit of the opinions we generate by doing this (‘If I were you ...’). We can use this ability to draw conclusions about how something should work. What we often fail to consider is that the ability to imagine ourselves in the other person’s position is not the same as sharing or understanding the other person’s experience. The conclusions based on our own experience may not be applicable to others.

INCLUSIVE DESIGN

Historically, a particularly common type of unwarranted assumption has been that the user will have the same set of physical and cognitive abilities as the designer. This will normally result in a design that is difficult or impossible to use for people who have various types of disability.

Fortunately, progress is being made towards a greater awareness of this problem; however, it is still common to find organisations taking an attitude towards accessibility that sees it as a box-ticking exercise. While it is true that a failure to comply with legal or regulatory accessibility requirements may expose a business to risks such as legal action, financial penalties and reputational damage, there are better arguments to be made in favour of inclusive design. Inclusive design is an approach which ensures that people with the widest possible range of abilities are explicitly taken into account during the project. This is particularly essential in the early stages. Benefits of inclusive design are listed below:

• Some of the difficulties with access that are all too familiar to people with disabilities are also encountered on an occasional basis by other users in particular circumstances. Thinking about these problems will result in a more robust and usable product.
• Users with disabilities may have goals that other users do not have. Including them at the early stages ensures that those needs will be considered before the project goes in a direction that makes it impossible.
• Users with disabilities may be engaging in the relevant activities in an environment which differs from that of other users. Again, including these users means that the design of the solution will be able to take this into account.
• If the particular needs of users with disabilities are considered at an early stage, it will often be relatively easy to include them. Retrofitting such requirements can be extremely expensive.
• Thinking carefully about how to support users with disabilities introduces an extra degree of rigour and clarity into the process, which is likely to result in a product that works better for everyone.

THE PRINCIPLES OF USER-CENTRED DESIGN

User-centred design (UCD), also known as human-centred design (HCD), avoids the problems associated with unintended design and self-oriented design (for almost any statement about UX, some practitioners can be found who disagree with it; according to one school of thought, ‘human-centred’ and ‘user-centred’ have different connotations). The international standard ISO 9241-210 (2019), ‘Human-Centred Design for Interactive Systems’, identifies six principles and five processes that underpin HCD/UCD. These are the central concepts in this book. We will examine each of these in turn.

Understanding users, tasks and environments

The most important factor in designing usable systems is understanding users and their needs. This understanding needs to be made explicit – in other words, it needs to be documented in a visible form so that project participants can share it. It will not be possible to plan a reliable and repeatable evaluation of the system’s ability to meet the users’ needs if they are not documented. Explicitly documenting the users’ characteristics, tasks and environment helps to ensure that the design team does not forget the principle, ‘you are not your user’.

It is only by taking the user’s perspective that we can ensure their needs are met. Individuals vary greatly from each other and therefore, we need to ensure that we study the widest possible range of relevant potential users and environments.

A key word here is ‘relevant’. An important aspect of understanding users is being clear who is not included in our user population. We must not cast the net too wide by trying to satisfy the needs of irrelevant user groups, or meet unimportant requirements.

As discussed in the last chapter, our understanding of the users and their needs can only be considered adequate if it includes an understanding of the tasks they are carrying out and the environment in which they are doing it.

Involving users

The design team needs to ensure that users are involved throughout the project. This principle should not be taken to mean that the involvement of users is required only during certain fixed periods of time that are allocated to design and development of the product in the up-front plan. On the contrary: ISO 9241-210 (2019) states, ‘Human-centred design shall be planned and integrated into all phases of the product life cycle.’ As mentioned earlier, the heading ‘design’ covers the whole project. Users must be involved for the whole duration.

It is quite common to ‘involve users’ in a project without really taking their participation seriously. Examples of ineffective approaches to user involvement include:

• Asking potential users what feature they would like to see in a product, without seeking empirical proof that these features would really be useful.
• Inviting users to meetings but not treating what they say as fundamentally important and acting on it.
• Giving demos or presentations to users and treating the resulting feedback as an interesting sidelight on the requirements, rather than using it to guide the project.

Effective user involvement is based on the thorough application of the first and third (see below) principles. It is not achieved through focus groups, meetings or demos. It is achieved by basing the product on an understanding of needs gained from observing people in action, and by evaluating successive prototypes the same way.

It is vitally important to involve the right individuals. We will see how to do this in the next chapter.

Employing user-centred evaluation to drive the design

One of the most significant risks on any project is that the resulting product does not successfully meet the needs of the people for whom it is intended. There is only one way of reliably making sure this does not happen: as the system evolves, have those very people try to use it in realistic ways, observe how well it performs, and use the resulting information to guide the ongoing development.

To get the most of out of using this approach, the design team will need to pay careful attention to shaping each stage of the development process so that it will result in an artefact that can be used effectively for this kind of testing, while building on the knowledge gained from previous stages.

Iterating

User-centred design can only work if it is carried out in a series of iterations, where each iteration carries out a similar series of steps to the others. Each iteration improves upon and extends the results of the preceding ones, and must therefore be consciously designed as a learning exercise.

Iterative development is now the norm in software development (see for example Measey, 2015). It also fits in with contemporary thinking on marketing and strategy (Ries, 2011). It is a risk reduction technique, which takes into account that opportunities to gain new information are constantly arising during the development of a product. In developing iteratively, we are seeking to maximise and structure the new information as it becomes available, and to minimise the length of the feedback loop, that is, the time it takes to exploit that information by optimising the design trajectory of the product.

Addressing the whole user experience

User-centred design is partly concerned with ensuring the product’s usability; in other words, we need to make sure that the intended users can achieve their goals effectively and efficiently. However, usability is not the only factor in achieving a good user experience. A user’s experience with a product includes their emotional response to their interaction with it too.

Someone’s experience of a product does not only consist of how they feel at a particular moment when they are using it, which can be referred to as momentary experience. There are other aspects to be considered with regard to the time dimension:

• Anticipatory experience refers to the user’s state of mind before they start interacting with the product. They will already have feelings about the product deriving from their existing knowledge and their perception of the product’s significance to them.
• Episodic experience refers to the user’s feelings and responses as they interact with the product over a short period.
• Cumulative experience is the sum of the user’s experience with the product up to a certain point.

At the most general level, we need to consider how using the system affects the user’s life. If this is a work system, does it make their job more interesting and meaningful, or less so? Does it contribute to factors of wellbeing such as the following?

• Mastery: the feeling of being in control of one’s environment and having an opportunity to exercise skill.
• Autonomy: the ability to use one’s discretion and take decisions without needing to refer to others.
• Purpose: the sense that one’s work has a meaning and is directed towards identifiable goals that one can influence.

Working in multidisciplinary teams

Bringing any product from an initial brief to a finished article requires a wide range of skills. The number of different individuals who are required will, of course, depend on the scope and nature of the project. It is important however that the core project personnel should be thought of as a single team. As far as possible, they should work together in one location and communicate with each other continually. The project team should not be so large as to make communication difficult, but it should be as diverse as possible, both in terms of the skills contributed by each member and also the personal characteristics and experience that each brings to bear. Roles in the team might include, but not be limited to, user researchers, interaction designers, content authors and developers.

THE USER-CENTRED DESIGN CYCLE

ISO 9241-210 (2019) identifies five areas of activity that take place in human-centred design. These are not necessarily stages to be undertaken one after the other; each of them is an ongoing process with links to the others. The processes are described below.

Figure 3.1 shows the cycle of processes required for user-centred design. The arrows show the logical dependencies between the processes.

Another helpful way of visualising the five processes is to imagine the project as a rope or helix with five strands, as illustrated in Figure 3.2. The planning strand runs through the middle like a core. The other four strands wind around it in a spiral.

Plan the work

Figure 3.1 The user-centred design cycle (Source: Adapted from ISO 9241-210, 2019)

Planning is shown in Figure 3.1 as a one-off activity standing outside the main flow of the iterative sequence. In fact, planning needs to be done continually. This is a ‘planning-driven’ rather than ‘plan-driven’ approach. In other words, it is the act of planning itself that is considered valuable, rather than having activities and tasks scheduled a long way in advance and codified into a plan. ‘The plans that result have a short half-life, not because they are bad plans, but because their underlying assumptions have a short half-life’ (Kent Beck, quoted in Boehm and Turner, 2003).

Time spent on planning is an opportunity to configure a version of the design cycle that makes sense for the particular project or product under consideration. We need to consider:

Figure 3.2 The user-centred design helix

• What is the nature of the project?
• What does usability mean for this project?
• What are the types of risk that would result from poor usability?

Understanding these factors will make it possible to customise the generic UX approach for this individual project, emphasising those factors that are important and de-emphasising those that are not relevant.

Re-planning takes place at the beginning and end of every iteration through the cycle. At the beginning of each iteration the team must consider:

What are the objectives and focus of this iteration?

At the end of each iteration the team must consider:

What have we learned in this iteration, and how will we use this information in the next one?

Through this continual re-setting and re-examination of learning objectives, the team can converge on a solution that meets user needs.

Understand the context

Planning aside, the keystone and starting point for UCD activities is user research. The objective of user research is for the design team to understand everything they need to know about the users and their characteristics, their goals, tasks and environment, in order to create a successful product or service for them.

The critical factor in user research is that it must be done by observing real users in the actual environment where they will be interacting with the system. This is indicated by the highlighted area in Figure 3.1, which shows the two processes that must be driven by user engagement.

In the early iterations, user research will be aimed at acquiring a thorough general understanding of the context, trying not to draw premature conclusions about potential solutions to specific problems. In later stages, specific areas of interest or uncertainty will be explored.

This process is discussed in Chapter 4, ‘User Research’.

Specify the requirements

Specifying the requirements is about first understanding users’ needs, and then defining what attributes and behaviours a product or service should provide in order to meet those needs.

The specification of requirements by describing user needs and developing user stories is discussed in Chapter 5, ‘Illustrating the Context of Use’.

Make designs

The core activity in design is, of course, making designs. This process includes an extremely wide range of types of activity. This is not just because different projects will be aimed at producing different types of eventual product or service, it is also because each iteration in any given project will be focused on producing one or more different types of output, each of which can be considered the object of a design activity. For example, all the following are designs:

• A user journey map
• A paper-based mockup of a physical interface
• A computerised workflow simulation
• A role-playing exercise
• A hierarchy of categories for a website’s navigation
• A high-fidelity interactive system prototype

There are two possible reasons for producing a design; these are not mutually exclusive, but it is important to understand which are relevant at each point. Firstly, the design may represent a set of ideas proposed for the final product or part of it. Secondly, the design may be deliberately created as an experiment, to help the design team explore issues or answer questions so as to aid progress towards the final product. Typically, designs produced in the early iterations will be mainly intended as experiments. Proposals will become more prevalent over the course of the project.

Producing design solutions is discussed further in Chapters 7–10.

Evaluate the designs

Every design idea, whether embodied in a throwaway experiment or a high-fidelity prototype, needs to be evaluated. Design evaluation is the second of the two processes highlighted in Figure 3.1 as being necessarily driven by user engagement.

It would be an exaggeration to say that all design evaluation must be done by testing the design with end users. There are analytical techniques, such as heuristic evaluation, which allow alternative designs to be evaluated at the usability analyst’s desk. However, even if we do this, we are still focusing on how suitable the design is for the user, rather than on any intrinsic properties of the design itself.

Evaluation is discussed in Chapter 6, ‘Measuring Usability’ and Chapter 11, ‘Usability Evaluation’.

A note on testing

A key user experience technique is usability testing (see Chapter 11). This sometimes makes people think that UX is closely connected with user acceptance testing or system testing. While all these activities are concerned with trying to create a successful product, they have fundamentally different approaches.

Systems testing and user acceptance testing both originated as stages in a type of software quality process that is based on a full documented specification of requirements, allowing the development team to create the technical solution without reference to users (often referred to as a waterfall process; see Chapter 12 for more details). System testing is carried out on the finished technical solution and aims to ensure that it meets the functional and non-functional requirements specified in the documentation. User acceptance testing follows system testing, and is carried out by end users. Traditionally, this is the first opportunity that the end users have had to try using the system in a real-world situation. It is a very necessary step, because it is surprisingly easy for a solution to comply with the requirements as specified without actually meeting the users’ needs.

UX, on the other hand, as described in this book, is based on user-centred design. In user-centred design, the entire process of developing a solution is driven by user-centred evaluation – in other words, if the process is carried out properly, it is not possible to end up with a solution that does not meet the users’ needs. Testing becomes an iterative activity carried out over the development life cycle, and the likelihood of unpleasant surprises during final user acceptance testing is greatly diminished.

SUMMARY

Usability is part of user experience and is objectively measurable. Accessibility refers to the usability of a system by people with the widest possible range of capabilities. Inclusive design supports accessibility and usability.

User-centred design is described in the international standard ISO 9241-210 (2019), ‘Human-Centred Design for Interactive Systems’. The six principles of user-centred design are:

1. The design is based upon an explicit understanding of users, tasks and environments.
2. Users are involved throughout design and development.
3. The design is driven and refined by user-centred evaluation.
4. The process is iterative.
5. The design addresses the whole user experience.
6. The design team includes multidisciplinary skills and perspectives.

The five processes of user-centred design are:

1. Plan the human-centred design process.
2. Understand and specify the context of use.
3. Specify the user requirements.
4. Produce design solutions to meet user requirements.
5. Evaluate the designs against requirements.

User experience work includes usability testing, but it is not essentially a testing discipline. Using the user-centred design approach will lead to better quality products because it focuses continually on ensuring that the product meets user needs.

REFERENCES

Beyer, H. and Holtzblatt, K. (1997) Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, San Francisco, CA.

Boehm, B. and Turner, R. (2003) Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley Professional, Boston, MA.

Cadle, J. (ed.) (2014) Developing Information Systems: Practical Guidance for IT Professionals. BCS, Swindon.

ISO 9241-210:2019 (2019) Ergonomics of Human-System Interaction – Part 210: Human-Centred Design for Interactive Systems. International Organization for Standardization (ISO), Geneva.

Measey, P. (2015) Agile Foundations: Principles, Practices and Frameworks. BCS, Swindon.

Newman, W.M. and Lamming, M.G. (1995) Interactive System Design. Addison-Wesley, Reading, MA.

Ries, E. (2011) The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Penguin, London.

Shaw, G.B. (1903) Man and Superman: A Comedy and a Philosophy. Archibald Constable & Co, Westminster.

Spool, J. (2009) 5 Design Decision Styles. What’s Yours? Available from: https://articles.uie.com/five_design_decision_styles/

FURTHER READING

Cooper, A. (2004) The Inmates are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS, Indianapolis, IN.

Gould, J.D. and Lewis, C. (1985) Designing for Usability: Key Principles and What Designers Think. Communications of the ACM, 28(3), 300–311.

Hassell, J. (2019) Inclusive Design for Organisations: Including your Missing 20% by Embedding Web and Mobile Accessibility. Rethink Press, Great Yarmouth.

IEEE Standards Coordinating Committee (1990) IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990). IEEE Computer Society, Los Alamitos, CA.

Norman, D.A. (2013) The Design of Everyday Things: Revised and Expanded Edition. MIT Press, Cambridge, MA.

EXAMPLE EXAMINATION QUESTIONS

1. Which of the following has the MOST significant impact on determining the usability of a system?

a. Creating a user interface that is visually attractive

b. Understanding users and their needs

c. Ensuring the design is responsive on different platforms

d. Creating comprehensive help and documentation

2. Which standard published by the International Organization for Standardization addresses the usability of systems?

a. ISO 9241

b. ISO 9001

c. ISO 2491

d. ISO 1009

ANSWERS TO EXAMPLE QUESTIONS

1. The correct answer is (b).

One of the six key principles in ISO 9241-210 is ‘The design is based upon an explicit understanding of users, tasks and environments’. This is summarised in answer (b). Answer (a) is an important way to improve user satisfaction with a system, but there is no point having an attractive UI if you do not understand users and their needs. (c) is a technology-based answer that will apply only to certain situations (unlike answer (a), which will always apply). Answer (d) will apply only in a situation where the system needs comprehensive help: an appropriately designed system may not need any documentation.

2. The correct answer is (a).

(a) is a multi-part standard that addresses usability and is the correct answer. (b) is incorrect because ISO 9001 is a quality standard. (c) refers to a withdrawn standard on ‘Thin parallel keys and their corresponding keyways’ and is nothing to do with usability. (d) refers to a standard to do with paper dimensions.