Blog
How to Validate a Feature Before Building It
A feature can receive enthusiastic feedback and still be the wrong thing to build. People may recognize the problem yet reject the proposed workflow. They may like the concept but struggle to use the prototype. Or a polished design may be easy to operate while addressing a problem that matters little to the customers the product serves.
Feature validation reduces these different uncertainties before development becomes expensive. It is not a single test that certifies an idea. It is a sequence of evidence-informed decisions about the problem, the proposed solution, and the usability of that solution. The aim is to learn enough to choose a responsible next step, while keeping the limits of the evidence visible.
Feature validation is three separate decisions
Treating validation as one question hides important failure modes. A problem interview cannot show that a prototype is usable. A usability test cannot establish how widespread a problem is. A favorable concept reaction does not show that a feature fits the participant's real workflow. Separate the questions so each study has a clear job.
| Validation type | Core question | Useful evidence | Possible decision |
|---|---|---|---|
| Validation typeProblem | Core questionIs there a meaningful problem for the intended users? | Useful evidenceRecent examples, observed work, constraints, consequences | Possible decisionContinue, reframe, or stop |
| Validation typeSolution | Core questionDoes the proposed approach fit the user's goal and workflow? | Useful evidenceConcept reactions, workflow walkthroughs, tradeoffs, expectations | Possible decisionAdvance, revise, compare, or stop |
| Validation typeUsability | Core questionCan representative users complete realistic tasks? | Useful evidenceObserved behavior, errors, hesitation, recovery, task outcomes | Possible decisionBuild, fix and retest, or reconsider |
The three decisions inform one another, but they are not always linear. A usability session may reveal that the team misunderstood the underlying job, sending it back to problem research. A solution walkthrough may expose a constraint that changes who should be recruited next. Validation is strongest when the team can change direction as evidence changes.
Validate the problem before the feature
Begin with what people are trying to accomplish, how they do it today, where the work breaks down, and what happens when it does. GOV.UK guidance on user needs distinguishes a need from a proposed feature: a useful need describes the outcome or problem rather than prescribing an email, dashboard, button, or automation.
Use recent, concrete accounts instead of asking whether someone would use an imagined feature. In interviews, ask participants to reconstruct the last time the situation occurred: what triggered it, which tools and people were involved, what they tried, and where time, risk, or frustration appeared. Observation, support records, product data, and earlier research can provide complementary views. GOV.UK's discovery research guidance recommends examining the current experience end to end, including tools, transactions, support, and offline steps.
Qualitative examples can explain a problem's shape and consequences, but they do not by themselves estimate prevalence or prove causality. Combine methods when the decision requires frequency, segment, or behavioral evidence. The preceding guide explains how to prioritize customer feedback using evidence rather than treating request volume as validation.
Validate whether the solution fits the workflow
Once the problem is sufficiently understood, represent the smallest version of the proposed approach that participants can react to meaningfully. That might be a storyboard, a workflow diagram, a rough prototype, or a deliberately limited interactive design. Fidelity should match the question. A sketch can expose a mistaken sequence; it cannot support detailed claims about interaction behavior.
GitLab's solution-validation guidance frames this work as assessing whether a product, feature, or design addresses the problem it was intended to solve. Ask participants to place the proposal in their current process. What would happen immediately before and after it? Who needs access or approval? Which data, integrations, policies, or exceptions matter? What would they have to give up or change?
Avoid turning the session into a sales pitch. Explain only enough for the participant to engage, use neutral prompts, and ask them to compare the proposal with how they work now. Record objections and mismatches alongside positive reactions. A strong solution decision depends less on applause than on whether the approach survives the constraints of the intended context.
Validate usability with realistic tasks
Usability validation observes behavior. Give representative participants a believable goal and enough context to attempt it, then watch what they understand, choose, miss, and recover from. GOV.UK's moderated usability-testing guidance recommends tasks with a clear, relevant goal that do not reveal the answer or hint at the path.
For a proposed bulk-editing feature, a weak prompt is, “Use bulk edit to change these records.” A more useful scenario gives the participant a credible set of records, a policy change, and a deadline, then asks them to make the required updates. The team can observe whether the participant finds the entry point, understands the selection state, predicts the scope of the change, notices exceptions, and verifies the result.
Note task outcomes, critical errors, confusion, hesitation, workarounds, and comments, while preserving the context around each observation. Success in a prototype remains evidence about that prototype under those conditions. It does not demonstrate market demand, production reliability, accessibility across untested configurations, or business impact. Those questions need their own evidence.
Write the decision rules before the study
Before recruiting, write down the decision, the assumptions that matter most, and what evidence would change the team's course. This reduces the temptation to reinterpret every result as support for a favored idea. GOV.UK's research-planning guidance recommends agreeing what the team needs to know now to make an informed next decision.
- Build or advance. Define the problem evidence, workflow fit, and task behavior that would justify investing further.
- Revise and retest. Name which mismatches or usability barriers can be changed without invalidating the overall approach.
- Stop. Identify evidence that would undermine the problem, reveal an unacceptable constraint, or show that the approach creates more harm than value.
- Investigate. Describe which conflicting or missing evidence would require another method, participant group, or prototype.
These are not universal numeric thresholds. The appropriate bar depends on the consequence of being wrong, the maturity of the idea, the diversity of intended users, and the evidence already available. Record disagreements and exceptions rather than forcing ambiguous material into a pass or fail score.
Run the smallest useful validation cycle
A small cycle should be narrow enough to complete and rich enough to inform the decision. Small does not mean choosing an arbitrary participant count or recruiting whoever is easiest to reach. It means focusing the research question, selecting people with relevant experience, using an artifact suited to the question, and analyzing soon enough to adapt the next round.
- State one decision and the assumptions that could overturn it.
- Choose problem, solution, or usability methods for those assumptions.
- Recruit participants whose role, context, and recent experience can answer the question.
- Pilot the guide, tasks, prototype, recording setup, and accessibility arrangements.
- Run a focused round, review evidence between sessions, and document limitations.
- Choose build, revise, stop, or investigate, then preserve the reasoning.
Repeat this cycle as part of a continuous user research rhythm. Each round should narrow uncertainty or reveal that the team is asking the wrong question.
How Palette can support feature validation
Palette's research workflow can support a validation cycle by keeping user studies, usability studies, connected feedback, product-usage evidence, and the resulting synthesis in the same decision context. A team can use that record to see which observations support an assumption, which evidence conflicts, and which questions remain open.
For example, a team could connect reports about bulk editing to a problem study, test a bounded workflow with relevant participants, and preserve task evidence with the proposed direction. This is an illustrative workflow, not a customer result. Palette does not make the decision or remove the need for sound recruitment, safe research practice, analysis, and human review.
When the direction is ready, the evidence can inform Palette Build rather than being reduced to an unsupported feature request. Teams interested in trying the workflow can join the waitlist.
Build, revise, or stop
Validation is useful when every outcome is legitimate. Build when the evidence supports a meaningful problem, a workable approach, and an interaction the team understands well enough to specify. Revise when the problem remains sound but the workflow or interface needs another round. Stop when the evidence weakens the problem or exposes a constraint that makes the proposal irresponsible. Investigate when the evidence is too limited or contradictory for the consequence of the decision.
Record what was decided, the evidence considered, the limits of that evidence, rejected alternatives, and the questions development still needs to answer. That trail helps engineering challenge hidden assumptions and helps future research revisit the decision when conditions change.
The next step is to turn the supported direction into bounded scope, testable requirements, acceptance criteria, risks, and open questions. Continue with the guide to turn user research into a build-ready product specification.