User-centred research methods

Their needs (what the product must achieve), their wants (what they would prefer) and their limitations (what they cannot do).

By understanding users' needs and by carrying out their tasks in the specified environment — doing the task where it is really done, not imagining it from a desk.

Products that meet a need but ignore a want get abandoned. A medication reminder that works perfectly but looks medical ends up in a drawer.

A design process that pays particular attention to the needs of potential users of a product through the involvement of users at ALL stages of the design process.

Specify the context of use; specify the requirements; produce design solutions; evaluate against the requirements; iterate.

The product fits a diverse range of user needs and capabilities, and expensive mistakes are found while they are still cheap to fix rather than after tooling.

It takes longer and costs more up front, and a poor user sample lets a vocal minority pull the design away from the wider population.

The user, the task and the environment.

Because no single discipline covers the user, the task and the environment. Each specialist notices a kind of failure the others are not equipped to see.

An understanding of how users perceive information, make decisions and make errors — especially under stress or time pressure. It informs the USER side.

An understanding of how the setting, the culture and the daily routine shape the way a product is actually used. It informs the ENVIRONMENT side.

Field research, task analysis, user observation, interviews, surveys and focus groups.

Watching methods (field research, observation, task analysis) show what users DO. Asking methods (interviews, focus groups, surveys) report what users SAY. The gap between them is where design opportunities hide.

When you need to measure how COMMON something is across a population — after a deeper method has told you what to ask about.

One confident participant can pull the whole room, so the result reflects the loudest voice rather than the user population.

One named user built from research data who represents the attributes of a user population — with goals, context and constraints specific enough to force a design decision.

A written account of the persona performing a task in a specific situation. It surfaces constraints a persona alone does not — the time of day, the lighting, whether a hand is free.

An expectation a whole population shares about how something behaves: red means stop, clockwise means more. Designing against one causes errors under pressure, however logical the alternative.

Advantage: the team shares one concrete user instead of arguing about an abstraction. Disadvantage: a persona built on thin data gives the designer's assumptions false authority.