Route · Public Design Atlas
Test whether something works
To check a design, whether a product, a space, a piece, or a service, before launching or improving it.
Review it with expert judgment
A quick expert review finds many problems.
Design principles
A short set of rules, drawn from research and the project's values, that guide design decisions so they are consistent.
How it’s used
How it’s done
- They are drawn from insights and from the project's values.
- Write only a few, clear and easy to apply.
- They are used to decide and to review the work.
- Avoid
- Writing principles so general that anyone would agree (“be easy to use”).
Usability
The extent to which specific people achieve their goals with a product, in a specific context, with effectiveness, efficiency, and satisfaction.
How it’s used
Why it happens
- Set who and what for, because usability depends on people, their goals, and their context.
- Check whether they succeed (effectiveness) and with how much effort (efficiency).
- And how they feel doing it (satisfaction).
- Avoid
- Saying something is “usable” without saying for whom or for what.
Accessible design
Designs digital products that people with disabilities can use, following guidelines that can be checked, such as WCAG.
How it’s used
- 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.
WCAG guidelines
The W3C guidelines for making digital content accessible, organized into four principles, with testable criteria at three levels: A, AA and AAA.
How it’s used
How it works
- Four principles state what content must achieve.
- Each guideline has concrete criteria that can be tested.
- 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.
Ten general rules that evaluators use to review an interface and spot usability problems before testing it with users.
How it’s used
How it works
- Several people review the interface separately.
- Each problem is noted next to the heuristic it breaks.
- The lists are combined and the problems are ranked by severity.
- Avoid
- Letting a single person review the interface and call it done.
Test it with people
See where they hesitate or make mistakes.
Usability testing
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 used
How it’s done
- Prepare realistic tasks, without saying how to do them.
- Observe each person as they try and think aloud.
- 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.
Mystery shopping
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 used
How it’s done
- Define. The journey and the evaluation criteria.
- Visit. Experience the service as a customer and write it down right after.
- 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.
Desktop walkthrough
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 used
How it’s done
- Set up the space and the characters on the table.
- Walk through the service step by step, out loud.
- 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.
Understand the problems
Go to the cause, not the symptom.
Five whys
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 used
How it’s done
- Describe the problem with concrete facts.
- Ask “why?” about each answer.
- 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.
Mental model
The often incomplete idea a person forms of how something works, and uses to predict what will happen when they act.
How it’s used
Why it happens
- We can't see how a system works on the inside.
- We form an idea from what we see and what we already know.
- If the idea doesn't match the system, we make mistakes.
- Avoid
- Assuming people understand the system the way the team does.
Cognitive load
The mental effort a task demands from working memory, which can only handle a few things at once.
How it’s used
Why it happens
- Working memory holds few things at once.
- Everything you have to remember or look for takes up part of that space.
- 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.
Decide what to change
Organize what you found so you can act.
Affinity diagram
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 used
How it’s done
- Write one observation on each note.
- Group the notes that are alike, without prior categories.
- 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.
Design synthesis
The process of organizing, grouping, and interpreting what has been researched until patterns, insights, and design opportunities emerge.
How it’s used
Why it happens
- Get all the information out while it is fresh.
- Group and regroup it, looking for patterns and differences.
- Interpret it until insights and opportunities are formulated.
- Avoid
- Jumping from data to solutions without going through interpretation.
MoSCoW method
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 used
How it’s done
- List everything that could be done.
- Sort each item into one of the four groups.
- Agree on what stays out with whoever decides.
- Output
- A prioritized list in four groups
- Avoid
- Marking almost everything as a must.
Measure after the change
Check with data whether the experience improved.
Survey
A questionnaire with the same questions for many people, designed to measure in numbers how many think, do or prefer something.
How it’s used
How it’s done
- Define what to measure. Which decision depends on the answer.
- Write and test. Test the questionnaire with a few people before sending it.
- 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.
A/B testing
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 used
How it’s done
- Define the change, the metric and how many people you need.
- Assign people at random to the versions.
- 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.
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’s used
How it works
- Customer expectations set the bar.
- Four gaps appear when understanding, specifying, delivering and communicating the service.
- The fifth is the one the customer experiences.
- Avoid
- Measuring only satisfaction without asking what the person expected.
HEART framework
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’s used
How it works
- Goals what the product should achieve.
- Signals what behavior or response would show it.
- 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.