Synthesis groups observations into patterns and proposes an explanation for them. The explanation remains a hypothesis. A useful problem frame identifies a specific user, a need and the insight that makes the need consequential in that situation.

The user–need–insight structure prevents a team from presenting an interface idea as though it were a discovered need. A frame should be narrow enough to guide a test while leaving room for several solutions. Keep the observations that support it visible so that another person can challenge the interpretation.

The design material contrasts a slow elevator with the experience of waiting for an elevator. If the problem is defined as motor speed, the solution set centers on engineering and capital investment. If the problem concerns the waiting experience, information and the surrounding environment also become possible interventions.

Reframing does not prove that the cheaper alternative is sufficient. The team must test whether the new explanation fits the complaints. A genuine capacity constraint at peak hours or a persistent accessibility issue cannot be resolved simply by making waiting feel shorter.

A prototype is a tool for learning. A rough representation can test whether a sequence makes sense, while a functional prototype may be necessary to test performance or reliability. More polish increases cost and can make participants reluctant to criticize the idea.

Choose the smallest representation that exposes the uncertain part of the experience. Tell the participant what task to attempt without demonstrating the answer. Observe the attempt, then ask about confusing points. A successful task with extensive coaching provides weaker evidence of usability than an unaided completion.

A test rarely validates an entire business. It supplies evidence about the conditions represented in that test. A participant may understand the prototype but lack authority to buy, or may want the benefit without accepting the price.

After each test, state what became more credible, what became less credible and what remains unresolved. Distinguish a problem with the implementation from a problem with the underlying need. The next iteration should target the uncertainty that matters most to the next commitment of resources.

In a Wizard-of-Oz test, a person performs the work behind an interface that looks automated, and the customer experiences the intended service. In a concierge test, the customer knows a person is doing the work. Both test whether the outcome matters to customers, and both are cheap enough to run before writing code.

Both share one limitation: the human operator adds judgment, care and relationships that software won't copy. Write the operator's rules down in advance and log every exception. Otherwise you'll learn about the founder, not the product.

Before the test, write down the uncertainty, the metric, the denominator, the expected result and the threshold for each decision: continue, revise or stop. After the test, compare the result with the prediction and say which assumption the result challenged.

Relay example (illustrative): "Of fillable cancellations reported by 3 pilot clinics over 4 weeks, we expect 30–40% to be rebooked by text, against an estimated 10–15% by phone. At or above 30% we build v1 automation. Between 15% and 30% we change lead-time cutoffs and message wording and rerun. Below 15% we reconsider the matching frame."