EN 
DE An introduction to the User-Centered Design Process
Author: Jonas Zimmermann, Mixed Mode GmbH
Contribution – Embedded Software Engineering Congress 2017
The UCDP (User-Centered Design Process) uses a systematic approach to acquire the necessary knowledge, condense it to the essentials, and create a product with the best possible customer benefit. The user and close collaboration with them are central to the User-Centered Design Process (UCDP). The four phases are defined by the UCDP, but the team is free to choose its own methods.
„"Software with great features is useless to me if I can't find or use those features." Most people would probably agree with this statement immediately – and yet there is still far too much software where it quickly becomes apparent that usability was not a focus during development.
High usability, as defined in ISO 9241-210, is achieved when a specific user can use a product in a specific context of use in such a way that their defined goals are achieved effectively, efficiently, and satisfactorily. Effectiveness is derived from the accuracy and completeness with which this user achieves these goals. Efficiency is described by the ratio of resources used (e.g., effort, costs, materials) to the results achieved. Perceptions and reactions arising from the use of the product determine the degree of user satisfaction.
The reasons for user problems with a particular product can be manifold. These range from features that are difficult to find, to those that cannot fulfill all tasks, to features that are completely missing. Everyone understands that this was not the development team's intention, but rather that they worked to the best of their knowledge and ability. In most cases, the real cause lies in an (unconscious) lack of knowledge. So what could be more logical than acquiring this knowledge directly at the source – from the user?
As early as the late 1980s, Don Norman (along with Jakob Nielsen, one of the pioneers in the fields of usability and user experience) was working on user-centered design. Even then, he pointed out that product development needed to focus much more on the user and their needs. Over the years, these initial recommendations evolved into an independent methodology: the User-Centered Design Process (UCDP). It uses a systematic approach to acquire the necessary knowledge about users and tasks, condense it to the essential points, and create a product with the best possible customer benefit. (See Figure 1 in the...) PDF, The User Centered Design Process with its four phases).
The UCDP strikes a balance between flexibility on the one hand and clear structure on the other. Although there are four clearly defined phases with specific objectives, the development team has considerable freedom in choosing both the software development process and the methods used within each phase.
The focus is on the user. Although different tasks need to be solved in each of the four phases, the team always focuses on the users and their very specific situation.
A key aspect of the User-Centered Design Process is its iterative approach, meaning the four phases are typically repeated more than once. After the evaluation, one of the three remaining phases is addressed based on the identified shortcomings. This process is repeated until the evaluation yields a satisfactory result.
Phase 1: Understanding the context of use
In the first phase, the team focuses on the different user groups of its future product. Using various techniques (e.g., observation, contextual interviews, the student-master model, etc.), the team gathers insights into the usage context in order to answer at least the following questions:
- Who are the stakeholders, i.e., who uses the system or is affected by the results of its use?
- What types of users are there, and what are their goals and tasks?
- What data is processed during use?
- What equipment do the users have?
- In what kind of environment (from a technical, physical, and social point of view) do they work?
The answers to these questions should be found at the end of this phase in a description of the usage context as well as collections of scenarios and personas.
One might be tempted to go through this phase without direct user interaction, but that would mean missing out on a large portion of the information to be discovered. Beware, however: users can quickly become blind to their own shortcomings and often formulate needs as concrete extensions of the existing solution. The far more valuable insight is the problem the user wants to solve with their suggestion. Once the development team is aware of all the problems and tasks, it can develop suitable solutions and processes that often go far beyond the users' expressed wishes.
Two excellent approaches, which can be simplified as "looking over the shoulder," are observation and the master-apprentice model. In both cases, information gathering should take place at the user's workstation and be carried out by a team member. With observation, the team member's main task is to record the tasks and processes. Communication with the user should be kept to a minimum, so that clarifying questions are only asked rarely if the user's behavior is not understood. The major advantage is that the user truly follows their daily workflow without interference, giving the observer a very realistic impression of the work. The master-apprentice model goes a step further: Here, the team member attempts to learn the user's craft, as if in a crash course.
Phase 2: Specification of usage requirements
The goal of the second phase is to translate the findings into user requirements. A systematic approach involves first examining the usage context for user needs and then converting them into user requirements. A need, in this context, is a prerequisite for achieving a goal within a specific usage context and can be derived from the scenarios developed in the first phase.
The oft-cited prime example is the presenter, who needs to know at all times how much time they have left to finish their presentation within the allotted time. A requirement that can be derived from this need is the constant visibility of the remaining time in the presenter view of presentation software.
Phase 3: Developing design solutions
The "creative phase" then focuses on translating the requirements into a prototype. There's no set level of detail required at this stage. Especially at the beginning, it's usually advisable to work with simpler versions: basic sketches, wireframes, or even designs made from sticky notes can be created quickly and are perfectly adequate for initial discussions.
This isn't just about defining the user interface's appearance, but primarily about the software's structure and behavior. The first step, therefore, is to consider which interactions will be used to solve the tasks and how they relate to one another. A simple technique for structuring (e.g., for a menu structure) is card sorting. In this method, a test subject is given a stack of cards containing the available terms and asked to group them in a way that makes sense to them.
The user-centered design process, of course, doesn't offer a magic bullet that automatically produces outstanding-looking and perfectly usable interfaces. However, there are certainly some principles that should always be kept in mind during the design process. These include, in particular, the principles of dialogue design according to ISO 9241-110 (aptitude for the task, self-descriptiveness, conformity to expectations, learnability, controllability, error tolerance, and customizability) and the Nielsen heuristics [1]. Simplified examples of heuristics include "Respect the conventions of the platform used," "Help users identify errors, understand them, and suggest a solution to the problem," and "Inform the user about the current state through appropriate feedback.".
Phase 4: Evaluating design solutions
Depending on the situation, there are different techniques for evaluating the created designs. Thanks to the significant differences in time, effort, and costs, a suitable option should always be found: the range extends from heuristic inspection and user surveys to usability testing.
In heuristic inspection (also called heuristic review), the design proposal is compared against a list of heuristics. Ideally, the inspection is conducted by one or more usability experts and thus primarily serves to verify usability (and not so much usefulness). The advantages of this technique lie in its ease of implementation and relatively low effort – but at the cost of a limited range of potential insights.
User surveys using questionnaires are significantly more complex in both preparation and interpretation, but they also promise a much greater gain in information. This is due not only to the wider reach but also to the direct communication with the user. In this regard, it's important to note that the questionnaire itself should be optimized for usability. If users have difficulty completing the questionnaire and misinterpret questions or answers, this can easily lead to erroneous conclusions during the analysis.
The ultimate discipline in evaluation is arguably usability testing. In each test session, a participant attempts to solve predefined tasks with the system (or a prototype), ideally while "thinking aloud," i.e., verbalizing their thoughts. A moderator guides the participant through the test session without providing assistance. In the background, observers and a note-taker can directly identify which tasks are intuitively solvable and which are not. To avoid unnecessarily distracting the participant, no one other than the moderator should be visible. The possibilities for "covert" observation are numerous: for example, an observation room separated from the test room by a semi-transparent mirror, or a webcam combined with a mirrored feed of the participant's monitor. An additional eye tracker can even provide information that the participant isn't consciously aware of—namely, the elements that first catch their eye.
Misunderstandings: Only agile and far too expensive?
The User-Centered Design Process may at first glance seem to be usable only in an agile environment – but in fact, it can also be integrated into a classic waterfall model. An example of this can be found on the website of the US Department of Health & Human Services [2].
Development costs don't automatically explode when focusing on the user. Firstly, costs can be scaled by choosing the right technologies, and secondly, there are many tangible benefits – from identifying previously undiscovered user needs and addressing usability issues to creating a significantly better product and thus a stronger competitive position.
Further links
[1] Jakob Nielsen, Ten Usability Heuristics
https://www.nngroup.com/articles/ten-usability-heuristics/
[2] User-Centered Design Process Map
https://www.usability.gov/how-to-and-tools/resources/ucd-map.html
author
Mr. Zimmermann (B.Sc. Computer Science and Multimedia) has experience in software development for graphical user interfaces since 2009. Since the beginning of his career, he has focused intensively on requirements engineering and the usability of software systems. Mr. Zimmermann is both an “IREB Certified Professional for Requirements Engineering” and a “Certified Professional for Usability and UX”.
Contact
E-mail: jonas.zimmermann@mixed-mode.de
Mixed Mode GmbH, Lochhamer Schlag 17, 82166 Gräfelfing near Munich
Software Engineering Management – our training courses & coaching sessions
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Software Engineering Management / process, project and product management.
Training & coaching on the other topics in our portfolio can be found here. here.
Software Engineering Management – Expertise
Valuable expertise in software engineering management / process, project and product management is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
