A prototype should answer a question.

An idea can become more convincing every time you add detail. The screens look better. The name starts to feel familiar. You can picture someone using it. Then a person outside the project tries it, and the part you thought was obvious needs explaining.

That moment is useful. A prototype gives you a way to encounter it while the idea is still easy to change. Before building one, decide what you need to learn and what you will do with the answer.

Choose the uncertainty that matters

A new product can contain several unanswered questions. People may experience the problem differently from how you describe it. They may already have an acceptable workaround. Your proposed solution might make sense but require information they cannot easily provide.

Choose one uncertainty that could change your next decision. For a booking tool, that might be whether customers can describe what they need without calling someone. For an internal application, it might be whether a team can find the right record without assistance.

Write the question in ordinary language. Then describe what you would need to observe to feel more confident. “People like the idea” leaves too much room for interpretation. “People can complete this task and explain what happens next” gives the session a clearer purpose.

Build the part that makes the question testable

The question should determine how much you build. A rough sequence of screens can help you explore navigation or terminology. A small working application can help you test behavior that depends on real inputs. If the uncertainty is whether someone wants the service at all, a conversation about their current problem may be more useful than another screen.

Give the prototype enough detail for the task to make sense. Use recognizable labels and believable sample information. A screen full of placeholder text can leave you testing people's ability to guess what you intended.

Be clear about its limits. Explain which actions are simulated and where information is fictional. Use sample records when real customer information is unnecessary. A convincing demonstration should not leave someone believing they have booked, purchased, or changed something when they have only tried a concept.

Give someone a recognizable task

Take a hypothetical founder building an estimate-request tool for small service businesses. The first version could include a customer form, a request summary, and a simple view for the person preparing the estimate. Payments, scheduling, and a complete customer account can wait until the team understands whether this first interaction is useful.

Ask a potential customer to request an estimate for a situation they recognize. Then ask someone who handles those requests to work from the resulting summary. Observe whether they have enough information to take the next step and where they still need a phone call.

This connects both sides of the experience. A form can feel easy to complete while collecting information that is too vague to use. The prototype needs to help you see that gap before it becomes part of a larger system.

Watch before you explain

When you know the design, it is tempting to help someone through it. You know which button they missed and why the label makes sense. Give them a little room before stepping in, then ask what they expected to happen.

Keep observations separate from interpretations. “She opened the pricing page twice” records behavior. “She thought the service was too expensive” is an explanation that needs more evidence. A follow-up conversation may reveal that she was trying to understand what was included.

Treat enthusiasm with the same care. Someone enjoying a demonstration is encouraging, but it does not establish that they will change how they work or pay for the product. Depending on the question, the next useful signal might be another trial, a conversation with the person who controls the budget, or a return visit without prompting. Describe the evidence you have without stretching it into a bigger claim.

Let the finding change the plan

After the session, return to the original question. Record what you observed, what remains uncertain, and the decision it supports. You might improve a label, reconsider the proposed workflow, investigate a different customer need, or build the next part.

A prototype does not have to become the first production version. Code, shortcuts, and sample data chosen for learning may need to change before people depend on the result. Keep that distinction clear when planning what comes next.

The useful outcome is a better reason for the next investment of time and attention. Make that reason clear before the prototype grows into a product by momentum alone.

If you have an idea you want to make tangible, Work with me. We can shape a prototype around the decision you need to make next.