VANKPA
Use customer feedback, everyday tasks, and real constraints to guide your design decisions.
Every design makes assumptions about what people need and how they work. Research helps you check those assumptions before committing to page structures, forms, features, or development work.
Collect observations before solutions
Early conversations often contain proposed features alongside real experiences: a customer could not find proof, an operator rebuilt the same record, or a decision-maker lacked confidence in the available measure. Preserve the observation before translating it into a requirement.
Observations can come from interviews, analytics, support patterns, workflow review, accessibility testing, competitive context, and direct use. No single source needs to carry more certainty than it deserves.
Evidence narrows the space responsibly; it does not remove the need for judgment.
Separate facts from assumptions
A useful synthesis shows what was directly observed, how the team interprets it, and what remains an assumption. Combining those layers too early makes a plausible story look like a verified conclusion.
The distinction is especially important when records are incomplete, participants are few, or the operating environment has recently changed. Visible limitations help stakeholders decide what to act on and what to test next.
- Observation: what the source actually shows
- Interpretation: what the pattern may mean
- Assumption: what still needs validation
- Constraint: what shapes the available response
Translate evidence into interface decisions
Research becomes useful when it changes priority. A repeated trust question may move proof closer to a claim. An operational handoff may require a visible state and owner. A mobile observation may reduce the amount of information requested at the first step.
Each important interface decision should be traceable to the evidence or constraint that shaped it. That does not make the design mechanically determined; it makes the reasoning reviewable.
Preserve traceability after launch
A design rationale should not disappear when implementation begins. Requirements, components, analytics events, and acceptance criteria can retain the original question so the team knows what a later change is meant to improve.
Post-launch evidence can then challenge the original assumption without erasing history. Teams learn faster when they can see what they believed, what they changed, and what happened next.
- Link decisions to their source context
- Record unresolved questions
- Define what evidence would change the direction
- Review outcomes against the original problem
