Prototyping and Usability Testing
Build the smallest credible representation needed to test a product decision, then record what the evidence does and does not establish.
- Product design
- Prototyping
- Usability testing
Match the prototype to the evidence
A prototype is an instrument for learning or alignment. Its fidelity should match the question. A clickable flow may test comprehension. A coded prototype may be necessary for data, AI behaviour, responsive interaction or technical feasibility.
Each row matches a product question with an appropriate representation and names what that representation cannot prove alone.
| Question | Appropriate representation | What it cannot prove alone |
|---|---|---|
Can people understand the sequence? | Clickable flow | Runtime performance or integration |
Does the product model hold across states? | State-rich interactive prototype | Production reliability |
Can this AI interaction support review? | Coded prototype with representative model output | Live model quality at scale |
Can design intent survive the frontend? | Coded responsive slice | Backend or operational readiness |
Prototype evidence contract
- 01
Entities
Hypothesis, participant or reviewer, representative data, task, observed behaviour, interpretation, technical constraint, decision and unresolved risk.
- 02
Relationships
Every prototype state maps to a hypothesis; observations remain separate from interpretation; the decision names what may proceed.
- 03
Review behaviour
Prototype and evidence record are reviewed side by side on desktop and sequentially on mobile. The task and representative-data label appear before interaction. Keyboard and assistive-technology behaviour are part of the prototype when relevant to the hypothesis.
The Auxentios case shows a product made concrete enough to align stakeholders and implementation. It does not claim that prototype approval established market success.
Observe the evidence, then decide what may advance
Usability testing records behaviour, questions, errors, workarounds and participant explanation. The interpretation remains separate from the observation. A small study can expose a serious failure without estimating how common it is, and task completion can coexist with confusion or unsafe recovery.
The decision record states:
- which hypothesis was supported, challenged or left unresolved;
- which design or product change follows;
- which finding requires more research or technical investigation;
- which risk remains before build or release;
- what the prototype could not represent.
Code can make the uncertain part real
ConnectX used a coded demonstration because the product decision depended on intent, data, modules and a digital-twin state working together. Benchmark Gensuite used HTML, CSS and JavaScript prototypes to bring interaction effort and dependency questions into review.
These cases support coded evidence and feasibility review. They do not establish production readiness or user outcomes.
AI can accelerate prototype production and organise approved research material. Participants, product owners and practitioners still determine what the evidence means and whether the product may advance.
Bring the riskiest product assumption
Use the prototype to test the part of the product decision that needs evidence before build or release.