A prototype becomes easier to evaluate when you can state what it is supposed to help you learn. A beautiful object, a clickable screen and a rough arrangement of paper can all be useful, but they do not answer the same question. Before choosing a tool or polishing an interaction, describe the uncertainty that matters. Then decide what someone would need to encounter for that uncertainty to become observable. This guide proposes a practical planning method for a small design exercise, not a report of testing performed on the projects in this portfolio.
Stanford d.school's No-Build Hack treats prototyping as an exploration of questions and context, including ways to learn without constructing an elaborate artifact. The worksheet described here is an independent editorial approach. It does not reproduce that exercise or claim that a particular fidelity level is always best. The useful starting point is to connect the thing you build with a decision you actually need to make.
Replace a vague goal with an observable question
Make the question narrow enough that a session could provide relevant evidence. Improve the experience is a direction, but it does not tell you what to observe. Can a person identify the next step after selecting a delivery option is more specific. It names a situation and a behavior that can be described. You may still need to refine the task and the participant context, but the question now gives the prototype a purpose beyond looking finished.
Avoid writing the desired answer into the question. Asking whether someone loves a cleaner layout invites a judgment about your preferred solution. Asking what information they use to choose an option leaves room for unexpected behavior. A useful question can survive a result you did not hope for. If every plausible observation would be interpreted as support for your design, reconsider whether you have framed a question or merely written a justification for a decision already made.
Identify the decision the evidence could change
Write one sentence describing the decision that depends on the question. You might be deciding whether to show a comparison before a selection, whether to separate two actions or whether to explain a term at the point of use. Keep this sentence beside the question. It helps prevent the session from becoming a general tour in which every comment is collected but no one knows what action the evidence could support.
Also record what the exercise will not decide. A short interaction prototype may be useful for examining a sequence while offering no evidence about long-term adoption, operational reliability or business results. Those boundaries are not defects to hide. They make the output easier to interpret and help you plan a later exercise if a different uncertainty remains. A small, well-bounded question is often more useful than a broad claim that the entire concept has been validated.
Choose the minimum representation that preserves the question
List the parts of the experience that must be present for the question to make sense. If you are examining terminology, readable language and realistic choices may matter more than animation. If you are examining how an object is held, a screen mockup may leave out the essential physical interaction. Match the representation to the uncertainty. Do not use fidelity as a status label or assume that adding detail automatically creates better evidence.
Mark deliberately omitted behavior. A paper prototype may require a facilitator to change screens; a digital prototype may have inactive routes. Plan how those limitations will be explained without leading the participant toward the intended action. If an omission would make the target behavior impossible or confusing for reasons unrelated to the question, revise the representation. The aim is not to make the artifact look real at every cost, but to make the relevant interaction interpretable.
Prepare a task with a believable starting point
Describe a situation that gives the participant a reason to act. Include only the context necessary for the question and avoid using the interface's exact labels as instructions. If the task says click the compare button, it cannot reveal whether the participant would discover comparison as the next step. A better prompt describes the decision to be made and leaves the route open. Review the wording with someone who has not been immersed in the design.
Use fictional details where personal information is unnecessary, and tell participants when the scenario is fictional. Do not ask them to enter real payment details, passwords or private records into a prototype. The task should allow observation without creating an avoidable privacy problem. If realism depends on sensitive context, plan an appropriate research process instead of improvising with live data. Record which parts of the scenario were supplied so they do not later get mistaken for participant-generated behavior.
Decide what you will record before the session
Create separate spaces for observation, participant comment and interpretation. An observation might describe a pause, an action or the order in which information was inspected. A comment records what the participant said, with an exact quotation only when you have a reliable record and permission to use it. Interpretation is your explanation of what the behavior might mean. Keeping these apart makes it easier to revisit an initial conclusion without rewriting the evidence itself.
Do not invent a numerical success score merely to make a small exercise look rigorous. If you use a measure, define it before observing and explain its limits. A task completion count from a small exploratory session does not by itself establish how an entire population will behave. Preserve the context of interruptions, facilitator assistance and prototype limitations. These details may explain an apparent failure more accurately than a single red mark in a results table.
Use a fictional comparison to examine the plan
Imagine two versions of a collection page for a fictional furniture project. One places dimensions beside each item; the other puts them behind a detail link. The question is whether a participant can find the dimensions needed to compare two items, not which version looks more elegant. Both versions need comparable content and a task that requires those dimensions. Otherwise, a difference in behavior may reflect missing information rather than the placement being examined.
The exercise could reveal where a participant looks, which terms they recognize and whether they notice the detail link. It would not establish real purchase conversion or prove that one arrangement works for every furniture shopper. This distinction should appear in the resulting note. A useful report states what was represented, what was observed and what decision is proposed next. It does not turn a small hypothetical comparison into a sweeping claim about customer behavior.
Revise the artifact and the question separately
After a session, decide whether the evidence suggests a design change, a question change or both. If participants never reached the relevant step because the starting context was unclear, polishing the final screen may not address the problem. If the question was useful but the representation lacked a necessary state, improve that state and record the change. Version the artifact so that later observations can be connected with the actual experience shown.
Keep a short change log explaining why a revision was made. A sequence of screenshots alone does not reveal the reasoning behind it. For each meaningful change, identify the observation or constraint that prompted it and the uncertainty that remains. This produces a more useful design record than a retrospective story in which every step appears inevitable. It also helps collaborators avoid repeating an exercise whose limitations have already been understood.
Turn the exercise into a readable design note
A concise design note can include the question, decision, scenario, representation, observations, limitations and next step. Show only the artifacts needed to understand those points. If you publish the note, remove private information and distinguish actual research from a speculative concept. The examples in this article are fictional; they are not evidence that any portfolio project was tested in this way. Clear attribution protects both the reader and the people whose work you are discussing.
The portfolio presents the site's original work, while the blog contains separately authored editorial guides. Our editorial policy explains that distinction. For your next prototype, start with a question that could change a decision, build only what the question needs and keep observation separate from interpretation. The result should be an artifact you can learn from and a record that explains what you actually learned.