User Centered Design

User Centered Design, the principles

In many development projects in one or the other way users play a role. In meetings design decisions are based upon an idea that the user is going to be happy with these decisions. And if there is any doubt you can always do an usability test. In how far the design decisions are really based on users expectations and needs and not on say, technical possibilities or the design teams preferences, is not really an issue. If there is an usability test before the publishing of the website, due to time pressure often only quick wins are implemented. In the next releases hopefully all the other findings from the test will be implemented.
This summary of a standard development process leaves two questions open: 1. How do you know that what the development team has in mind about their users has any real connection to the users? and 2. How do you know you have chosen the right concept/design? In an usability test you only test that particular concept, with the risk of improving the wrong concept.
The frustration of many designers who listen carefully to the requirements of the development team is bad results from the usability tests. They did meet all the requirements in the concept they designed and the development team was probably cheering when the designer presented the design.
Wouldn’t it be nice and logic to have user data ready before the development starts? Making sure you chose the best concept for the user needs? And the usability test would improve this best design to even higher standards.

If you look at user centered design which in short means, putting the focus on the needs, wishes and capabilities of end users or customers during every part of the design process, wouldn’t a lot of development teams think that is what they are doing? They talk about the users and they (sometimes fight to) have an usability test done. What is wrong with that? The thing that is really missing here is the user himself. User centered design means talking to actual users about their work in the work place. This will take about one hour per user and even talking to only one user is better than none at all. You talk about their work, because that is what you are going to support. Or you talk about the decision process in their daily or professional live, because that is what you are going to support. Talking to users about content and/or functionalities won’t get you the user data you really want and can support your design decisions. It is hard for users to pinpoint how their work can be supported by what functionality. Besides that is not their job, it is the development teams job. As a development team you want an overview that covers all your users, not one or two ‘super’ users who have knowledge about ICT development. Interviews and observations of users during the execution of activities in the offline world will identify common patterns and mental similarities. This gives a clear picture of all the users, in an early stage.
Summarizing, UCD focuses on three important things about designing with the focus on ease of use:

Your users: what roles they play regarding the system.

Their work: what tasks they are trying to achieve in their roles.

Their needs: what instruments/tools and materials are needed for the tasks.

UCD as a process will lead to discovering new targets. The method is goal directed but not static. It contains a set of principles which can support any form of development process. Using UCD will support and promote innovation and the results are desired by real users. It creates the ability to radically transform by having user data available at the beginning of the development process.

Characteristics of User Centered Design

The roots of the UCD process lie in the Grounded Theory (2010), a method of qualitative research. In (Boeije, 2006) the following list of the characteristics of qualitative research are mentioned:

• Experience of those investigated, interpretative.
• Research in the everyday environment, naturalistic.
• Open investigation procedure.
• Researcher as an instrument.
• Working with texts (transcript), which include extensive and detailed descriptions.
• Statements by stakeholders and from a theoretical and / or social backgrounds.
• Experience of those investigated, interpretative.
• Research in the everyday environment, naturalistic.
• Open investigation procedure.
• Researcher as an instrument.

Both end users and domain experts are needed to provide input. Users live with the product, closely linked to their daily work, but are relatively unaware of important issues outside their scope. Domain experts hover above the product, they know the whole landscape, but see less of the practical details. Easy access to users and domain experts promotes fast switching between design and development.
Designing for users is to connect to their expectations and creating a positive acceptance. The interaction with an interface is part of every computer and determines how people use and manage that system. If the interaction is well designed, it is understandable, predictable and manageable. As a result, users feel happy and involved with their tasks.
Within the UCD process the design is tested early in the design process. In this way the solution is checked whether it fits the logic of the user. Several iterations are possible. Both, parts or the whole product, can be tested. Participants can be the same as the interviewed users or a new selection is made based on personas.
The greater the pressure to develop systems, the greater the need for thoughtful and comprehensive use of models. That is easier said than done. There is a need for making shortcuts, but creating shortcuts will ultimately cost money because reverse development always takes longer. But still it is better to interview one user or customer than none at all (Beyer and Holtzblatt, 1998).

Summarizing, UCD has the following advantages:
• Everybody in the organization will have access to user data.
• Putting the focus on the needs, wishes and capabilities of end users or customers during
every part of the design process.
• Seeing the ‘big picture’.
• Preventing behavioural preference of one or two (super) users.
• Less need for (expensive) usability testing.
• Preventing the pitfall to build what the user asks instead what people actually will use.
• Saving time because the discussions within a development team are focused on the big
picture and real user data.

User Centered Design techniques

The method of UCD consists of a few techniques which you can use in a way that fits the development team and deadline for the project. One thing is critical though, you have to collect user data and talk to the actual users in their work place. You are free to chose the amount of users you interview, which work models you create, whether you want to use personas, even if you want to design a product or instead use the data for communication, brainstorm sessions or other organizational processes.

These primary and basic stages will lead to a complete design that will connect to users expectations and create a positive acceptance:

• Collecting and analysing user data
• Create work models
• Write personas
• Create information analyses schemes
• Designing wireframes with navigation panels
• Early usability testing using paper prototypes and improving the design

Collecting and analyzing user data

Interviewing users is the main activity for collecting user data. The intention of the interviews is to visualize the work of the user. The interviews are semi-structured and master-apprentice in approach. Semi-structured means that a set of questions are pre-prepared that need answering and keeps the focus on the research question(s). The master-apprentice approach means that the interviewer leads the interview process but not the information that is given.
During the interviews artefacts are collected. Artefacts are tools used during the work- or decision process by users and tell how people work and what they might lack in support. An example of this are e-mails that people send to themselves to remember certain things.
The difference in questioning when using qualitative or quantitative methods is best shown with these example questions about the use of a digital board by a teacher. In UCD the main focus is on answering ‘why’ and ‘how a problem gets solved’ questions. (In Boeije, 2006)

• Question in quantitative method: How often do teachers use a digital board and in what frequency?
Explain the answers by checking these numbers in relation to school type, age, background, gender, region.

• Question in qualitative method: What variations are there in meaning and methods of using a digital board?

Explain the answers by looking at patterns in use:
- Do teachers have existing digital course material available?
- Does different usage of a digital board depend on certain topics?
- Does different usage of a digital board depend on the level of students?
- Do teachers develop digital materials themselves?
- Are teachers dependent on the available classrooms that have a digital board?
- Do teachers use the digital board all the time during a lesson or partially?
- Has the usage of a digital board increased or decreased the work load?
All questions are followed by the ‘And why?’ question.

Create work models

After interviewing the users, transcripts are made for analyses of the interviews. To be able to work with the data and spread the knowledge into an organization work models are created. There are several models to chose from, all models representing the user. For example a flow model that shows the relationship between the different roles of users and a mental model or affinity diagram which shows the relationship between the tasks of users. Without work models critical functions are discovered late in the development process, which leads to high costs because of redesign.
There are few other advantages creating and using work models. Because they are simplified forms they focus on the big pictures, details are kept for later when they do matter. This will accelerate realization. Work models are real data and accessible throughout the wholeorganization, they allow reliable design decisions. It promotes research and innovation based on real user intentions and needs, not gadgets, desires and fantasies functions (Beyer and Holtzblatt, 1998).

Mental model, a clear picture of the ‘market’.

The mental model describes the work from the standpoint of the users in their own words. It tells how people think and cope with their tasks and goals. A representation of the way users do things, such as how to solve a problem or complete a process.In addition, common issues and themes within large groups of people become clear and
whether they deal with things in the same way as another person. This overview inspires to find new solutions,
bottom-up. For Wikiwijs it means to finding out how Wikiwijs can support teachers, not only by automation but also by the things like training. The role of the solutions is always to
unburden peoples workload.

Create a mental model

In a mental model a large amount of concrete user information is organized.
The structure of a mental model has the form of a narrative, the story of the work processes. Information is
arranged bottom-up, this means without pre-defined categories.

The structure of a mental model can directly matched onto the structure of software. One of the big advantages is that the structure of a online service will not be sorted by keywords but is supported by the natural
work flow.
User activities are divided in so-called mental spaces. A mental space is a group of task
towers that share the same user goal. For example working on a letter and decide to go and check e-mail messages is a switch of attention and therefore are different mental spaces. The relation between tasks is based upon steps a participant describes and similarity in tasks.
Visually every task box shows how many people mentioned this activity.
Mental models can grow in response to a new group of users or new activities or roles.

In the example Movie mental model from Indy Young (2008), the mental spaces are:

• Decide to watch a film
• Encounter a film I haven’t heard of
• Choose film
• Learn more about a film
• Choose a theatre
• Choose a time
• Go to the movies
• Watch a film at home
• Eat dinner
• Attend a film event
• Watch the film
• Identify with a film
• Interact with people about film
• Follow the industry.

To put it simple, when a mental model matches the structure of a tool or content this software
will be easy to use. People recognize their own workflow in the system, minimizing the
learning curve and they can predict what and where everything is placed.
If there is an existing system making a content analysis happens by placing the model of the
users on top and beneath it the model of the system. Checking the mental model with the
content and functionalities of the system gives insight in whether all task towers are
supported by content or functionalities. Any gaps show possibilities for automation, any
overload on the systems side will tell what to delete.
When a new system is developed every mental space or task tower shows if this activity is
important enough to support because a lot of users talked about it or when it is an important
part in the whole user work process. Under the model of the user all possible content and
functionalities (or trainings) are placed, following the exact flow mentioned by users (Young, 2008)

Write personas

A good way of telling what personas are is quoting the design company Adaptive Path (2010): “Personas are fictitious people who represent the archetypal qualities of your audience. They provide targets for design and are generally very effective for communicating design and research activities throughout an organization.”
Personas are a tool that help communicate the results of the interviews to the development team or through all levels of an organization. From the interviews archetypes are created for the major groups of users. Using these fictitious persons, the focus during the development process stays on the target groups. Personas give concrete direction by asking questions like:

• How can we best support persona X during his/her work?
• Do we help persona X in providing this functionality?
• Persona X wants this, how can we design it?

It helps the development team to make choices and decisions. Because there are often large groups of users, making multiple personas who represent these groups the patterns (similarities and differences) can be seen throughout the large amount of users. Any misconceptions about the user can be tackled at an early stage. And ultimately this leads to improving the quality of a product or service. It also saves time because the discussions within a development team are focused on real users.
In summary a persona is based on realistic behaviour, motivation, attitude, skills and needs. The behavioural patterns, belonging to a persona group, are described as concretely as possible from the various interviews. The typical characteristics of users are presented as a lively, narrative description. Aim of the personas is that they are challenging and will tell new things. One persona represents thousands of users.
One of the ways to use personas is a scenario where the personas ‘walk’ through and use the product. It gives an overview of tasks and functions and helps to design a logical and user oriented flow of all activities in a process. This provides an easy way to check the design decisions before testing the whole product.
The personas and the different models that are created have a life span of about five years. That means that during this time the models and the personas can serve as a starting point for development and extension of the system. After that period they need revision (Cooper, 1995).

Number of interviews

When selecting the number of participants for interviews keep in mind the goal of these interviews: knowing how people organize their work process and whether they deal with things in the same way as another person’s do. How tasks are divided into activities, goals, strategies and several individual steps.
One way to select participants is to define roles. We all have different roles and these roles tell what we do and where our responsibilities lie. During the interviews finding out how someone performs this role, what their approach is and where this approach has similarities with other approaches is the main focus. We are all unique, but only in details. Looking at the structure of any approach shows that three different ways of doing things are the maximum. (Beyer and Holtzblatt, 1998). This was confirmed during the Wikiwijs user research.
If you ensure that the roles defined are at least three times discussed then you have enough participants.

Karen Holtzblatt (2001 and 2004) states about the relatively small number of interviews:
‘…years ago, while testing for usability, people in the industry were not comfortable with test results from small numbers of users. However, after 15 years of collecting data, the industry has found through experience that small numbers add up to a detailed picture of work practice that supports design. And we’re not just looking at usability anymore; we’re engaged in market characterization at the level of work practice.’
‘A small, quick-iteration project only needs a small amount of planning. We have completed field studies of 5-8 users, quickly consolidated and brainstormed solutions, all within a week or two.’

Onderdeel uit Paper geschreven door Karin van den Driesche (www.filterdesign.nl) en Robert Schuwer (www.ou.nl).