User Centred Design
User centred design (UCD) is a well-tried methodology that puts users at the heart of the design process, and is highly recommended for developing ITS products and services that must be simple and straightforward to use. It is a multi-stage problem-solving process whereby designers of ITS analyse how users are likely to use a product or service – but also tests their assumptions through analysing actual user behaviour in the real world.
A key part of UCD is the identification and analysis of users’ needs. These have to be completely and clearly identified (even if they are conflicting) in order to help identify the trade-offs that often need to happen in the design process.
User-centred design (UCD) aims to optimise a product or service around how users can, want, or need to use the product or service – rather than forcing users to change their behaviour in order to meet their needs.
The ISO 9241-210 (2010) standard describes six key principles of UCD:
- the design is based upon an explicit understanding of users, tasks and environments
- users are 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
As shown in the figure below the main, but iterative, steps in UCD are Plan, Research, Design, Adapt, and Measure.
A key part of the research stage for UCD is collecting and analysing user needs. Quality models such as ISO/IEC 25010 provide a framework for this activity.
Users include the following:
- primary users who interact with the ITS to achieve the primary goals
- secondary users who provide support (for example data providers and system managers or administrators)
- indirect users who are affected by the ITS
Some important questions related to user needs are:
- who are the users?
- what are the users’ tasks and goals?
- what functions do the users need?
- what are the users’ experience levels with similar systems?
- what information might the users need, and in what form do they need it?
- how do users think the system should work?
- what are the extreme environments?
- is the user multitasking?
- does the user have particular requirements of the interface?
User needs can also be defined according to the following list of attributes for an ITS:
- effectiveness
- efficiency
- satisfaction (usefulness, trust, pleasure, comfort)
- freedom from risk (safety, health, environmental, economic)
- reliability
- security
- coverage of a range of contexts (coverage, flexibility)
- learnability
- accessibility
Advice to Practitioners
The main advice is to adopt a user-centred design (UCD) process that begins with collecting and analysing user needs. The design of the ITS product or service can then be undertaken making use of all the advice and guidance provided below. The product or service should then be trialled and developed with actual users, taking account of their feedback. (See Piloting, feedback and monitoring)
Techniques for Collecting User Needs
Assistance from human factors professionals should be sought where necessary as there are many techniques available to collect user needs. Some of the main techniques include:
- observation/analysis – this requires an external observer to note what activities users actually undertake – and to infer their needs from this
- walk-throughs – these are deliberate executions of an activity, noting all the steps and documenting exactly the circumstances, for later analysis and derivation of user needs at each stage
- questionnaires and surveys – these can be written or use other forms of information gathering to engage users directly or indirectly about their needs. Some use scales and optional choices and some have free-form areas for user response – but the design depends on the requirements of the user needs collection process
- Delphi - this method helps to reach a consensus amongst users engaging the same group in several rounds of surveys. The first round generates initial needs. Subsequent rounds enable participants to see and comment on all ideas – until a general consensus emerges
- focus groups – these comprise semi-structured discussions with a trained facilitator and a group of users – where a second observer makes notes of the sessions
- group techniques - various structured techniques can be used to help explore needs and activities including, for example, “5W+H” (asking who, why, what, when, where and how) [Link to 2422, Context of ITS Use @ THE5W+H CHECKLIST] and “Progressive Why” which explores a particular activity or need in increasing depth
- use of persona – development of a fictional character with all the characteristics of the users, from which user need may be created
- scenarios – development of a fictional story about the "daily life of", or a sequence of events, with the primary user group as the main characters
- use cases – these are constructed to describe a specific event or unfolding situation and may include very fine details and interactions between the users and the ITS
Undertaking User Needs Analysis
Assistance from human factors professionals should be sought where necessary. The following general guidelines are useful in compiling user needs and undertaking analysis for use in ITS design:
- always express findings from the user’s perspective
- cross-relate user needs to each other (there may be conflicting needs)
- allocate sufficient time during the development process to check and validate the user’s needs
- compile all the user needs into a single set of user requirements
- word the requirements precisely and ensure that all categories of human-related requirements are covered
- create test statements to validate the user requirements, the concept and the implementation
- ensure that all user requirements are developed before being transposed into system requirements
- prior to finalising the ITS design, validate the user requirements with actual users
- accept that there still may be contradictory requirements
- try to understand the nuances of the requirements and ensure that these are reflected in the precise wording of the requirements
- keep asking the users until there is a clear picture of their actual requirements
Print