Every other doc in this corpus starts at "design a feature." This one is the step before: figuring out who the feature is for, what their real day looks like, and what you actually know versus what you're guessing. Skipping it is the most expensive mistake in product design, because it ships the wrong thing beautifully. A flawless interface for a user who doesn't exist is still a failure.
Understanding users is not a phase you complete and leave behind. It's a discipline of honesty: separating what's been observed from what's been assumed, and refusing to let a confident-sounding guess masquerade as a fact. The goal is not certainty, which no amount of research fully delivers. The goal is to know exactly how much you don't know, so the gaps are visible instead of hidden.
Confidence Traceability
Every claim about the user carries a confidence level, and you mark it. There is no grey zone where a hunch quietly becomes a requirement.
- Tag each user claim as
[ASSUMPTION]or[VALIDATED — source]. "Users abandon at checkout[ASSUMPTION]" and "Users abandon at checkout[VALIDATED — funnel analytics, Q2]" lead to very different decisions, and the tag is what keeps them honest. - An assumption is not a sin; an unlabeled assumption is. The label is what lets the team weigh the claim correctly and prioritize what to test.
- Don't pretend to replace field research. No amount of reasoning substitutes for talking to real users. When you're inferring, say so; never dress a guess as a finding.
[ASSUMPTION] Power users want keyboard shortcuts for everything.
[VALIDATED — 8 user interviews, May] Users keep the dashboard open all day in a pinned tab.
[VALIDATED — support tickets] "Export" is the most-requested missing feature.
The discipline is binary on purpose: assumed or validated, with a source. Anything softer reintroduces the false certainty it exists to prevent.
Anchored Personas, Not Archetypes
A useful persona is anchored in observation, not assembled from demographics. "Marketing Mary, 34, likes coffee" tells you nothing actionable; it's an archetype, and archetypes lead to designs for nobody in particular.
An anchored persona describes:
- Observed frustrations with the current way of doing things, not invented pain points.
- Current tools the person actually uses for this job: Excel, email, paper, a competitor, a Slack channel. What you're really replacing is their current workaround.
- A day-in-the-life showing when and how the job fits into their real routine (see The Day-in-the-Life Lens below).
- At least one emotional goal, not just a functional one. "Feel in control," "look competent to my boss," "stop worrying about missing something." Function tells you what to build; emotion tells you how it should feel.
If a persona could describe any user of any product, it's an archetype. Anchor it in specifics until it could only be this user.
The Day-in-the-Life Lens
Walking through the user's actual day reveals what a feature list never will: the context the product drops into.
- Timing and frequency: is this a thing they do once a quarter or forty times an hour? The two demand opposite designs (one teaches, one gets out of the way, echoing the frequency-of-use principle in
ui/animation-and-motion.md— Duration Guidelines). - Emotional context: are they calm and focused, or stressed and interrupted? A tool used under pressure needs more forgiveness and fewer decisions.
- Real integration: where does your product sit among the others they're juggling? It's rarely the only window open, and almost never the center of their attention.
The day-in-the-life is where you discover that the "main screen" you obsessed over is glanced at for three seconds between two other tasks.
Reconstruct a Customer Story
When a team is guessing what customers want, reconstruct a recent attempt before discussing solutions. Look for three kinds of evidence:
- Hope: the better outcome the customer was trying to create.
- Pain: what felt difficult, risky, or emotionally costly.
- Barrier: what stopped the customer from making progress.
Ask what happened the last time, not what the customer might do in an imagined future. A recent story exposes context, workarounds, triggers, and constraints that preference questions hide. Treat a pattern as validated only after it repeats across customers or is supported by behavioral data.
Reduce the story to six moments with the customer as the protagonist. Record the context, action, emotion, and thought at each moment. The sequence should show the customer's changing state, not merely six product screens. Use it to expose gaps between moments and to give the team one compact account of the experience.
Anti-Personas
Knowing who should not use the product sharpens who should. An anti-persona is an explicit description of a user you are choosing not to serve.
- Naming the anti-persona prevents scope creep: when a feature request clearly serves someone you've decided not to build for, the decision is already made.
- It clarifies trade-offs. A tool optimized for the daily power user is correctly worse for the once-a-year novice, and that's a choice, not a bug.
- "Everyone" is not a user. A product that refuses to exclude anyone usually serves no one well (see
jobs-product-design.md— Say No to 1,000 Things).
Understand the Domain First
Before proposing a solution, understand the territory: the terminology, the current process, the constraints, the surrounding ecosystem. Designing in ignorance of the domain produces interfaces that are confidently wrong.
- Learn the real vocabulary practitioners use, and use it in the UI (see
microcopy.md— Plain & Inclusive Language: plain to outsiders, precise to insiders). - Map the current process honestly, including the parts that are annoying but load-bearing. The ugly step is often there for a reason you don't see yet.
- Context feeds the brainstorm; it does not filter it. Knowing the constraints should inform ideas, not pre-emptively kill them. Understand the box thoroughly, then decide consciously what to keep inside it and what to challenge.
Separate Generation from Evaluation
Idea generation and idea judgment are different modes, and running them at once kills both. Critique during generation strangles the ideas; generation during evaluation muddies the sort.
- Generate with zero judgment. In the creative phase, no idea is too obvious or too wild to write down. Filtering happens later.
- Evaluate with structure. Once you have a field of ideas, sort, compare, and cut deliberately (see
design-process.md— Decide Between Options). - Trace the reasoning. For every idea kept, dropped, or parked, record why. A parked idea needs a resume condition ("revisit if we add teams") so it isn't silently lost or silently resurrected.
The two-mode discipline is what lets a team be both genuinely creative and genuinely rigorous, instead of mediocre at both.
Contradictions Are Signals
When two sources disagree about the user, that contradiction is information, not noise to be smoothed over. Hiding it to keep a tidy story is how teams build on sand.
- Mark the contradiction explicitly: sales says users want X, support tickets say users struggle with X. Both can't be the whole truth.
- Resolve it deliberately: get more data, segment the users (maybe two different groups want opposite things), or make a documented call about which signal to trust.
- Never average two incompatible findings into a mushy middle. "Users both love and hate the wizard" usually means there are two user segments, and the design should serve them differently, not split the difference.
Turn Repeated Questions into Product Knowledge
A feedback path should solve the user's immediate problem and improve the next person's experience.
- Keep a feedback action in a consistent, reachable surface so users can ask while the context is still fresh.
- Answer direct questions, then turn repeated answers into durable documentation or product changes.
- Offer a community path for peer help when it fits the audience, but never make it the only support route.
From Insight to Design
Understanding users is the front end of the design process, not a separate exercise. What you learn here feeds directly into how you start designing.
- The validated needs and emotional goals become the criteria for "is this the right feature" (see
design-process.md— Start with a Feature, Not a Layout). - The day-in-the-life and frequency data shape density, defaults, and how much the interface teaches versus stays out of the way.
- The anti-personas and parked ideas keep scope honest as the build proceeds.
Carry the [ASSUMPTION] / [VALIDATED] tags forward into the spec. A design built on unresolved assumptions is a design that hasn't earned its confidence yet, and the team should know which parts those are.
Uncommon Care
Care becomes visible where a team could reasonably have stopped. It appears in an edge case that still feels considered, a task that no longer requires contacting support, language that respects a difficult moment, or a transition that preserves the user’s sense of place.
More output is not the same as more care. Automation and AI can create time, but the useful question is where to reinvest that time. Often the answer is a humane operational detail—clear invoices, reversible actions, good recovery, or a thoughtful empty state—rather than another ornamental feature.
Ask periodically:
- Where are we accepting “good enough” without naming it?
- Which unresolved detail has become part of the furniture?
- What uncomfortable refinement are we avoiding because it crosses team boundaries?
- What could we remove or resolve that would make someone feel looked after?
Checklist
Confidence
- Every user claim tagged
[ASSUMPTION]or[VALIDATED — source] - No guess presented as a finding; research not faked or skipped
- Low-confidence, high-impact assumptions prioritized for validation
Personas & context
- Personas anchored in observed frustrations, real current tools, and ≥1 emotional goal
- Day-in-the-life captures timing, frequency, emotional context, real integration
- Recent attempts reveal the customer's hope, pain, barrier, triggers, and workarounds
- Six-moment story follows the customer's changing state rather than only product screens
- At least one anti-persona named (who you're not building for)
Domain & process
- Domain terminology, current process, and constraints understood before solutioning
- Context used to inform ideas, not pre-filter them
- Generation kept judgment-free; evaluation structured and reasoned
- Kept/dropped/parked ideas traced; parked ideas have a resume condition
Context & feedback
- Feedback stays reachable in context; repeated questions improve docs or the product
Honesty
- Contradictions marked and resolved, never averaged away
- Assumption/validation tags carried forward into the spec