A product experiment card turns “we should try this” into a test the team can interpret. It states the assumption, the activity that will examine it, the evidence to collect, and the decision that evidence could change. The difficult part is not fitting those fields onto a card. It is making sure the test actually examines the claim.
Keep the claim and the proposed decision together in a shared product-planning workspace. The worked example below follows a booking team testing a reminder with a self-service change link. The team wants to know whether people can use that link when their plans change, before investing in a broader rollout.
Choose one claim the test can actually examine
Imagine a service where customers book an appointment and receive a reminder. Today, people who need another time must contact the team. The proposed reminder would let them change the booking themselves.
“Better reminders will reduce missed appointments” is too broad for a first prototype test. A missed appointment may reflect a forgotten booking, unavailable transport, an unsuitable time, or a change the customer could not communicate. A clickable prototype cannot reproduce all of those conditions.
Start with a smaller claim: when customers need to change a booking, they can recognize the reminder's change option and select a suitable alternative without contacting the service. That claim concerns comprehension and task completion. Whether the feature reduces missed appointments remains a separate question for a later live evaluation.
If the team has not chosen which uncertainty matters most, use an assumption mapping workshop first. This card starts after that choice; it is not a substitute for deciding which problem deserves attention.
Complete the booking-reminder experiment card
Strategyzer's Test Card asks teams to state the hypothesis, test, measurement, and success threshold. For a product task, add enough context that another researcher can understand what participants will encounter and what the team will do with the result.
| Card field | Booking-reminder example |
|---|---|
| Decision | Is the reminder's self-service change route understandable enough to take into a limited live pilot? |
| Claim | Customers who need another time can find the change option and choose an alternative without staff guidance. |
| Participants and context | Recruit people who use comparable appointment services. Include relevant access needs and devices. Use fictional booking details, not another customer's information. |
| Activity | Show the reminder in a realistic message context. Explain that the booked time no longer works and ask what the participant would do. |
| Evidence | Record the first action, unprompted route, requests for help, interpretation of the confirmation, and any critical misunderstanding. |
| Decision rule | Revise the route if recurring confusion prevents independent completion or anyone encounters an unresolved critical misunderstanding. Consider a limited pilot only if the intended route is understood across the relevant cases studied. |
| Unresolved question | This test does not establish attendance improvement, production reliability, or whether enough alternative appointments will be available. |
The rule is not a universal numerical benchmark. Before recruiting, agree on what counts as a critical misunderstanding, which user situations must be represented, and what evidence would be sufficient for this next decision. A small qualitative study should not be turned into a precise population success rate.
Give the task without teaching the answer
“Click the reschedule link and choose another time” tells the participant where to go. It tests whether the instructed clicks are possible, not whether the reminder communicates the option. A more useful prompt is: “You can no longer attend at this time. Show me what you would do next.”
Keep the starting point consistent enough to interpret differences. Someone who begins on the booking page has already passed the discovery problem facing someone who begins in an inbox. Record the actual start, device, message context, and any moderator intervention.
When a participant hesitates, allow the hesitation to remain visible. If help is necessary, note what happened before and after it. Finishing after “try the link at the bottom” is a different observation from finding the route independently. Both can inform the design, but combining them into one completion count hides the problem.
The prototype also needs a credible end state. If the test stops after choosing a slot, the team cannot learn whether people understand that the original appointment has changed. Include the proposed confirmation and ask what booking they now believe they hold.
Separate what happened from why you think it happened
Put raw observations beside interpretations rather than replacing them with a verdict. The table shows how different observations would change the next step.
| Possible observation | Interpretation to investigate | Design consequence |
|---|---|---|
| A participant opens the message, looks for a phone number, and does not notice the change link. | The message may look informational rather than actionable. | Reconsider link wording and placement, then observe the revised reminder. |
| A participant finds the link but thinks selecting a new time creates a second appointment. | The relationship between the original and replacement booking is unclear. | Clarify the change and confirmation before any live pilot. |
| A participant understands the route, but none of the offered times works. | Availability, not navigation, prevents completion. | Do not count this as proof that the interface is confusing; examine the service constraint separately. |
| The prototype link fails before the participant sees the options. | The intended task was not exposed. | Repair the test material; mark that attempt uninterpretable for the navigation claim. |
A positive comment such as “that looks useful” does not answer the same question as an unprompted action. Equally, a failed task does not automatically identify its cause. Keep the sequence visible so the team can distinguish a wording issue from unavailable appointments or a broken prototype.
Organize the test and evidence in Boardmix
On a Boardmix board, place the decision above a compact experiment card. To its right, show the reminder and proposed change flow. Below it, create separate areas for observations, interpretations, and the next decision. Use plain text labels as well as color so the meaning survives a screenshot or a different reader's display.
For this example, connect “understands the change option” to the reminder, and “knows which booking remains” to the confirmation. Those links show which part of the design supplies the relevant evidence. Keep the attendance question outside the card's result area; otherwise a successful prototype session can quietly become a claim about business impact.
Open a Boardmix board and build the card around the next decision your team actually faces. Use anonymized excerpts or fictional task details on a shared board; link to appropriately controlled research records when the underlying material needs restricted access.
Decide what the result allows you to do next
Strategyzer's Learning Card separates the tested hypothesis, observations, interpretation, and resulting action. In this case, the outcome may be a revised reminder, a different confirmation, a live pilot, or another study because an important situation was missing.
Suppose the change route is understood but people cannot find an acceptable alternative slot. Rewriting the link again would address the wrong constraint. The next investigation belongs with availability and service operations. If the route works in the prototype, a live pilot can examine what customers do when a real booking changes. That later evaluation needs its own measures and safeguards; the first card has answered a narrower, useful question.
