A rough model is a question made visible
A low-fidelity prototype is a deliberately simple representation of an idea. It might be a hand-drawn app screen, a cardboard version of a household object, a set of paper cards showing a service journey or a conversation acted out by two people. It does not need to look finished. Its job is to make an assumption concrete enough that someone can react to it.
That distinction matters because an idea can sound clear in a meeting while meaning different things to different people. Once a team draws the first screen or lays out the steps of a service, missing choices become visible. What happens first? What information does a person need? Where might they hesitate? A rough model gives those questions a shared reference point without requiring the team to settle every detail.
What early prototypes can reveal
Rough prototypes are useful for exploring structure and sequence. Paper screens can show whether people understand where to begin and what they expect to happen after an action. A cardboard object can expose an awkward grip or an inconvenient size. A role-play can uncover a confusing handoff between staff and customers. These observations are often more useful early on than opinions about colors, finishes or branding.
They can also reveal mismatches between a creator’s intentions and another person’s expectations. Someone may look for a feature in an unexpected place, interpret a label differently or assume that a step is optional. Such responses are not proof that the person is wrong. They are clues about what the design communicates. Because a rough prototype is easy to change, a team can explore several approaches rather than defending its first idea.
Choose the simplest form that fits the question
Start by writing down one question the prototype should help answer. If the question is whether a process makes sense, sketch its steps on separate cards and ask someone to arrange or walk through them. If it concerns the placement of controls, draw a screen or panel. If it concerns how an object is held or stored, make a basic physical model. The form should make the relevant decision visible; extra detail can distract from it.
It helps to mark what is not being tested. A paper checkout screen, for example, may be suitable for discussing the order of tasks but not for judging how fast a working system would feel. A cardboard package may help explore opening and storage but not durability. Naming these boundaries keeps a rough model from being treated as evidence for questions it cannot answer.
Watch behavior as well as listen to opinions
When showing a prototype to someone, offer a realistic task instead of a long explanation. You might ask, “How would you find the return instructions?” or “Where would you put this after using it?” Then allow the person time to respond. If they pause, take a different route or ask a question, note what happened before explaining your intended design. The goal is to learn what the model communicates on its own.
Ask open follow-up questions, such as what the person expected at a particular step. Avoid treating a single reaction as a verdict. A prototype session offers a small view of how one person encounters one version of an idea. Look for recurring points of confusion across sessions, while also paying attention to surprising reactions that expose an assumption worth checking. Separate what people did from your interpretation of why they did it.
Turn findings into the next useful version
After a session, group observations around decisions the team can make. Perhaps a label needs clearer wording, two steps could be combined or an object needs another way to be held. Decide which uncertainty matters most, change the prototype and try again. Keeping earlier versions can help the team see which trade-offs each change introduced, rather than assuming every revision is an improvement.
Low fidelity has limits. People may behave differently with a working product, and a sketch cannot establish technical feasibility, long-term usefulness or performance in varied conditions. As an idea becomes clearer, later prototypes can test those questions with greater realism. The early rough version earns its place by making it inexpensive to discover what the team has not yet understood.
