Compare interface options before building the product
Use small disposable prototypes to answer a specific interaction or layout question. Compare alternatives with stakeholders and preserve the decisions that should guide production work.
How this works
Use small disposable prototypes to answer a specific interaction or layout question. Compare alternatives with stakeholders and preserve the decisions that should guide production work. Use this when a team must resolve a particular interaction or layout question before investing in production work. The prototypes should make contrasting options comparable, not grow into an unplanned application.
Define the uncertainty and comparison criteria, then build small isolated variants with the same representative data and states. Record what stakeholders observed and why an option was selected. Preserve the decision and useful interaction evidence; discard or clearly label the experimental implementation.
Before you start
Decision question
State the specific interaction uncertainty and who will decide.
Representative content
Provide realistic synthetic data covering normal and awkward states.
Prototype environment
Use an isolated local workspace with available UI tooling.
Prepare the inputs
- comparison_brief
- Required
question, alternatives and decision criteria
Keep the experiment narrow enough to answer one decision.
- sample_data
- Required
synthetic records and edge cases
Use identical data across variants.
- state_matrix
- Required
normal, empty, loading and error states
Include the states that could change the choice.
- technical_bounds
- Required
allowed components and time or scope limits
Do not add production services to make a visual comparison.
Implementation, step by step
Frame the experiment
- Write the question and observable differences between alternatives.
- Choose criteria such as task clarity, density or recovery behavior rather than general taste.
Checkpoint: The comparison has a clear purpose.
Build contrasting variants
- Implement the minimum interaction needed to expose each option.
- Use shared content and avoid polishing one alternative disproportionately.
Checkpoint: Variants are comparable.
Exercise relevant states
- Show empty, long-content, loading and error cases where they affect the decision.
- Check the intended viewport and basic keyboard interaction.
Checkpoint: The comparison covers realistic constraints.
Gather review evidence
- Ask stakeholders to perform the same task in each variant.
- Record observations separately from preferences and avoid presenting them as broad usability proof.
Checkpoint: A decision record captures the actual feedback.
Preserve the outcome
- Summarize chosen behavior, rejected tradeoffs and unresolved questions.
- Label code as prototype and hand production requirements to the responsible team.
Checkpoint: The experiment ends with an actionable decision.
Decisions along the way
Alternatives answer different questions
Narrow them to a common task before comparing.
Reviewers disagree
Document the tradeoff and identify the deciding criterion or further test.
Prototype requires real customer data
Replace it with representative synthetic records unless access is explicitly necessary and authorized.
What you will produce
prototype-variants
Local interactive filesDisposable implementations for a controlled comparison.
Include: variant_id · states · sample_data · limitations
interface-decision.md
MarkdownA durable decision record independent of prototype code.
Include: question · criteria · observations · choice · tradeoffs · next_steps
Check the result
- Verify each variant uses the same task and sample content.
- Exercise relevant failure and empty states.
- Check the prototype actually exposes the intended difference.
- Confirm findings are limited to the observed review.
When something goes wrong
One variant is broken
Repair it before comparison or mark the experiment inconclusive.
Scope expands into unrelated features
Return to the decision question and defer extra work.
Prototype code is mistaken for production
Add clear status and a handoff checklist identifying missing engineering work.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: compare filters in a side panel versus a top bar.
Inputs
Both variants use 30 synthetic records, six filters and a no-results state. The decision is whether users can see active filters while reviewing results.
Expected result
Synthetic result: present both layouts with identical tasks and record visibility and correction observations. A stakeholder preference alone is not evidence of improved conversion.
Run a small pilot
Start small
Run one interface question with a small stakeholder review.
Record the baseline
Record time spent reaching a decision and questions still unresolved.
Agree success criteria
Agree whether the prototype exposed the relevant tradeoff before further development.
Stop or revise
Stop when the experiment cannot answer its question without production integration.
Keep the scope clear
- Prototype acceptance does not establish production readiness or customer usability.
- Keep experimental changes isolated from the live product.
Check before using
Stakeholders assess whether the prototype answers the question. It is not a production-ready application or evidence of customer usability.
Business activities
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: A clearly defined interaction question · Relevant user tasks and interface states
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow