Validation is evidence, not encouragement
Friends saying your idea sounds good is not validation. Useful evidence comes from past behaviour, observed difficulty, attempts to solve the problem, and actions taken with your prototype.
Your goal is not to prove that the idea is brilliant. Your goal is to reduce uncertainty before spending more time building.
- Does the problem happen repeatedly?
- Who experiences it most strongly?
- What do they do today?
- What does the current workaround cost in time or effort?
Interview five relevant people
Choose people who genuinely experience the problem. Ask them about the last time it occurred and let them describe the process in their own words.
Avoid leading questions such as would you use an app that solves this. People often say yes to be polite. Ask what they already tried and which part was hardest.
- Tell me about the last time this happened
- What did you do first?
- Where did you get stuck?
- How often does this happen?
- What have you tried to make it easier?
Test a small promise
You do not need a complete app to learn. A clickable prototype, simple form, manually managed service, or three-screen web app can test whether people understand and value the result.
Give the user a realistic task and observe silently. Note whether they begin correctly, complete the task, trust the output, and want to use it again.
- Task completion
- Time to understand the first screen
- Points of hesitation
- Errors or missing information
- Willingness to return or recommend it
Turn observations into decisions
After each test, separate evidence from interpretation. The user clicked the wrong button is evidence. The user does not care about the product is an interpretation that may be incorrect.
Group issues by severity. Fix blockers first, then unclear language, then convenience. Decorative preferences come last unless they affect trust or accessibility.
- Blocker: prevents task completion
- Confusion: creates hesitation or mistakes
- Friction: adds unnecessary effort
- Preference: personal taste without clear outcome impact
Document validation in your portfolio
Write down who you spoke with without exposing personal details, what task you tested, the patterns you observed, and the change you made. Include before-and-after screenshots when useful.
This evidence demonstrates communication, product judgement, and iteration. Those skills remain valuable regardless of which builder or programming language you used.
- Number and type of users
- Test task
- Main observation
- Decision made
- Result after the change