Before commissioning a prototype, finish this sentence: “We need to find out whether…” The answer determines how much to build. A rough drawing can answer a layout question, while a working browser experience may be needed to expose a difficult interaction. Extra polish has a cost, especially when it makes an unfinished idea look approved.
Use a wireframe to discuss content and order
A wireframe strips a page down to its main parts. For an imagined food subscription service, it might show the meal options, delivery area, dietary information, and order action. The discussion becomes whether those pieces are present and in a sensible order.
Write representative headings and use realistic content lengths. Empty grey boxes hide disagreements about the message. If the important question is whether customers understand the offer, a carefully written rough page is more useful than decorative detail.
- Best question
- Is the content in the right order?
- Effort
- Can’t tell you
- How it feels to use
Go only as far as the question needs. Every step up costs more to change.
Use a clickable prototype to explore a journey
Connect screens when you need to see how people interpret choices and move between steps. For the food service, that could be selecting a plan, changing portions, and reviewing a delivery date. Include a way to go back so the test does not quietly assume everyone makes the right choice first.
Make a list of what is simulated. A clickable calendar may show available dates without checking capacity. A successful payment screen may be only an image. Explain these boundaries to stakeholders so a convincing demonstration does not become an accidental promise about the finished system.
Use code when behaviour is the question
A browser prototype is useful when you need to examine text wrapping, keyboard focus, validation, or interactions that depend on changing input. A meal total that updates with quantity can reveal details a fixed set of screens may miss. Try long names, unexpected values, and a narrow phone viewport.
Use disposable test data and clearly separate the prototype from production services. Working interface code still needs a review for security, accessibility, maintainability, and backend behaviour before launch. The ability to click a button is not evidence that an order is safely stored.
Agree on what happens after the test
Define the prototype’s lifetime. Will it be thrown away, kept as a reference, or reviewed for reuse? Record the choices the team accepted, the issues participants encountered, and the assumptions that remain untested. This makes the handover useful even if the prototype itself is discarded.
For a small project, one wireframe and one focused browser demo may be enough. For a complex application, several rounds may be justified. Choose the smallest experiment that can change a decision, then stop when it has answered that question.
Before you build
- Write the learning question first.
- Use representative content and reversible journeys.
- Label simulated data and unavailable integrations.
- Review any reused prototype code before production.