Skip to content
APDD
See my library

Test whether something works

To check a design, whether a product, a space, a piece, or a service, before launching or improving it. In each step, choose one or more entries; open “How it’s used” to decide without leaving this page.

  1. Step 1

    Review it with expert judgment

    A quick expert review finds many problems.

    How it’s used

    A short set of rules, drawn from research and the project's values, that guide design decisions so they are consistent.

    How it’s done

    1. They are drawn from insights and from the project's values.
    2. Write only a few, clear and easy to apply.
    3. They are used to decide and to review the work.
    Avoid
    Writing principles so general that anyone would agree (“be easy to use”).
    Full entry, with sources
    How it’s used

    The extent to which specific people achieve their goals with a product, in a specific context, with effectiveness, efficiency, and satisfaction.

    Why it happens

    1. Set who and what for, because usability depends on people, their goals, and their context.
    2. Check whether they succeed (effectiveness) and with how much effort (efficiency).
    3. And how they feel doing it (satisfaction).
    Avoid
    Saying something is “usable” without saying for whom or for what.
    Full entry, with sources
    How it’s used

    Designs digital products that people with disabilities can use, following guidelines that can be checked, such as WCAG.

    When to use it
    Check contrast, keyboard use and alt text from the start.
    Avoid
    Relying only on automated tools: they find some of the problems, not all.
    Full entry, with sources
    How it’s used

    The W3C guidelines for making digital content accessible, organized into four principles, with testable criteria at three levels: A, AA and AAA.

    How it works

    1. Four principles state what content must achieve.
    2. Each guideline has concrete criteria that can be tested.
    3. Each criterion has a level: A, AA or AAA.
    Avoid
    Relying only on automated checkers: many barriers only show up when testing with a keyboard or a screen reader.
    Full entry, with sources
    How it’s used

    Ten general rules that evaluators use to review an interface and spot usability problems before testing it with users.

    How it works

    1. Several people review the interface separately.
    2. Each problem is noted next to the heuristic it breaks.
    3. The lists are combined and the problems are ranked by severity.
    Avoid
    Letting a single person review the interface and call it done.
    Full entry, with sources
  2. Step 2

    Test it with people

    See where they hesitate or make mistakes.

    How it’s used

    A method in which real people try to do specific tasks with a product while being observed, to find out where they get stuck and why.

    How it’s done

    1. Prepare realistic tasks, without saying how to do them.
    2. Observe each person as they try and think aloud.
    3. Note where they get stuck and decide what to fix first.
    Output
    A list of usability problems, with where they appear and why
    Avoid
    Asking “do you like it?”: measure what people do, not what they think.
    Full entry, with sources
    How it’s used

    A trained person poses as a customer to experience a service and evaluate it against defined criteria, without the staff knowing they are being observed.

    How it’s done

    1. Define. The journey and the evaluation criteria.
    2. Visit. Experience the service as a customer and write it down right after.
    3. Compare. Contrast visits, locations and channels.
    Output
    An evaluation of the service against set criteria, seen as a customer
    Avoid
    Using it to monitor or punish specific employees.
    Full entry, with sources
    How it’s used

    A scale prototype, made with cardboard, building pieces, or figures, on which the team moves the characters step by step to rehearse a service from start to finish.

    How it’s done

    1. Set up the space and the characters on the table.
    2. Walk through the service step by step, out loud.
    3. Note questions and failures, change things, and play again.
    Output
    A model of the service and a list of changes
    Avoid
    Polishing the model: it takes time away from playing.
    Full entry, with sources
  3. Step 3

    Understand the problems

    Go to the cause, not the symptom.

    How it’s used

    A technique for finding the root cause of a problem by asking “why?” several times in a row, each time about the previous answer.

    How it’s done

    1. Describe the problem with concrete facts.
    2. Ask “why?” about each answer.
    3. Stop when you reach a cause that can be corrected.
    Output
    A chain of causes that reaches the root cause of the problem
    Avoid
    Following a single chain of causes when the problem has several.
    Full entry, with sources
    How it’s used

    The often incomplete idea a person forms of how something works, and uses to predict what will happen when they act.

    Why it happens

    1. We can't see how a system works on the inside.
    2. We form an idea from what we see and what we already know.
    3. If the idea doesn't match the system, we make mistakes.
    Avoid
    Assuming people understand the system the way the team does.
    Full entry, with sources
    How it’s used

    The mental effort a task demands from working memory, which can only handle a few things at once.

    Why it happens

    1. Working memory holds few things at once.
    2. Everything you have to remember or look for takes up part of that space.
    3. If it fills up, we make mistakes or give up.
    Avoid
    Asking people to copy a code from one screen to type it into another.
    Full entry, with sources
  4. Step 4

    Decide what to change

    Organize what you found so you can act.

    How it’s used

    Writing each research observation on a note and grouping the notes by affinity, bottom-up, until the themes that connect them emerge.

    How it’s done

    1. Write one observation on each note.
    2. Group the notes that are alike, without prior categories.
    3. Give a title to each group and arrange the groups.
    Output
    Observations grouped into themes
    Avoid
    Starting with categories already decided: that way you only confirm what you believed.
    Full entry, with sources
    How it’s used

    The process of organizing, grouping, and interpreting what has been researched until patterns, insights, and design opportunities emerge.

    Why it happens

    1. Get all the information out while it is fresh.
    2. Group and regroup it, looking for patterns and differences.
    3. Interpret it until insights and opportunities are formulated.
    Avoid
    Jumping from data to solutions without going through interpretation.
    Full entry, with sources
    How it’s used

    A method that sorts requirements or ideas into four groups for a specific release: what must be in (Must), what should (Should), what could (Could) and what won’t this time (Won’t).

    How it’s done

    1. List everything that could be done.
    2. Sort each item into one of the four groups.
    3. Agree on what stays out with whoever decides.
    Output
    A prioritized list in four groups
    Avoid
    Marking almost everything as a must.
    Full entry, with sources
  5. Step 5

    Measure after the change

    Check with data whether the experience improved.

    How it’s used

    A questionnaire with the same questions for many people, designed to measure in numbers how many think, do or prefer something.

    How it’s done

    1. Define what to measure. Which decision depends on the answer.
    2. Write and test. Test the questionnaire with a few people before sending it.
    3. Send and analyze. Count, compare groups and read carefully.
    Output
    Numerical data on what many people think, do or prefer
    Avoid
    Asking about what they will do in the future (“would you use it?”): what people say they will do isn’t what they later do.
    Full entry, with sources
    How it’s used

    An experiment in which people are randomly split between two or more versions of a product and a metric is compared to see which version works better.

    How it’s done

    1. Define the change, the metric and how many people you need.
    2. Assign people at random to the versions.
    3. Compare the metric and decide.
    Output
    Which version works better on a metric chosen in advance, with its margin of error
    Avoid
    Stopping the experiment as soon as you like the numbers: the result may be chance.
    Full entry, with sources
    How it’s used

    A model that explains service quality as the distance between what customers expect and what they perceive, and looks inside the organization for where it arises.

    How it works

    1. Customer expectations set the bar.
    2. Four gaps appear when understanding, specifying, delivering and communicating the service.
    3. The fifth is the one the customer experiences.
    Avoid
    Measuring only satisfaction without asking what the person expected.
    Full entry, with sources
    How it’s used

    A framework for choosing what to measure in a digital product (happiness, engagement, adoption, retention and task success), starting from goals rather than available data.

    How it works

    1. Goals what the product should achieve.
    2. Signals what behavior or response would show it.
    3. Metrics how to count it to track it over time.
    Avoid
    Always using all five categories; choose the ones that make sense for your product.
    Full entry, with sources