IGNITE EXTENDED / LESSON 05
How can reframing a need lead to a more useful prototype?
A problem frame, prototype sketch and test question.
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.
This cycle connects customer evidence to a testable response. It is iterative: a prototype can reveal that the original problem was framed incorrectly.
Investigate a real situation through observation and recent episodes. For a hospital handoff, watch how staff find the current instruction and record where uncertainty or repeated work occurs.
State the user, need and evidence-backed insight. Example: a shift supervisor needs confidence that the next team has the current instruction because updates arrive through several conflicting channels.
Explore more than one response to that need. Compare a shared record, a confirmation routine and a change to who owns updates. Avoid assuming a notification feature is the only solution.
Make the uncertain part inspectable. Let another person complete a realistic handoff using a rough version. Observe errors and clarification requests, then revise the frame or solution.
The cycle is a learning process. A polished prototype can still answer the wrong question if the user and need remain vague.
Example: a shift supervisor needs confidence in the current instructions because changes occur after the formal handoff.
A frame determines which solutions appear relevant. Reframing changes the question when evidence suggests that the first formulation assumes a solution too early.
“How can we add a message notification?”
“How can the next person know which instructions are current?”
Illustrative application: “add a message notification” already chooses an interface intervention. “Help the next shift identify the current instruction” admits notifications, a shared authoritative record and a new handoff routine. Test which obstacle actually causes the confusion before selecting among them.
A broader frame is useful when it preserves the concrete user and task while opening plausible responses.
A U-shaped curve. It starts at Research and Observe, which are concrete, then dips into an abstract zone for Synthesis. There the team works through insights, design principles, a strategic framework and opportunity areas. It climbs back to concrete work through Ideation, Prototyping and Test + Iterate, and ends at Solutions.
To find a better frame, you have to leave the concrete details for a while and come back with a new abstraction. That is why the reframe from "send reminders" to "match open slots to available patients" feels unclear before it feels obvious. Teams that skip the dip tend to go straight from observations to the first solution they thought of.
The elevator scene, now captioned "The problem is that the wait for our elevator feels longer."
The evidence is the same complaint. Moving from "speed" to "perceived wait" changes which interventions count as solutions. Like the lesson's DEEP slide says, the new frame is a hypothesis. Measure actual wait times before you assume perception is the only issue.
A large circle of "less obvious solutions," including mirrors around the doors, contains a small circle of "obvious solutions": new motor, new control algorithm, new elevator.
The obvious solutions sit inside the larger set. Reframing adds options and keeps the old ones, so the team can still choose the motor if the evidence calls for it. For Relay, "reminders" belongs in the small circle. "Matching" opens the larger one.
A quotation, "Rise didn't have a data visualization problem. They had a user experience problem," beside two phone screens. Before: dense charts of heart rate and sleep trends. After: a simple nightly sleep target with one coaching prompt.
The team first framed the problem around its strength, data, and responded with more charts. Fieldwork with athletes showed that they needed to know what to do tonight. Relay faces the same temptation, since Daniel's strength is automation, and a full SMS engine is the obvious response whether or not automation is the bottleneck.
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.
“Users liked it” gives little direction for the next version. Analyze an observable attempt against a prediction made before the test.
Describe the task and behavior. A supervisor finds the latest instruction but sends a separate message to confirm that it is authoritative. Record the extra step and the reason given.
State what you expected. The prototype was intended to make the current instruction unambiguous. Completion with a confirmation call therefore provides weaker evidence than an unaided handoff.
Identify the assumption challenged by the attempt. Perhaps staff understand the screen but do not trust who can update it. That points to authority and process, rather than screen readability.
Change the next test accordingly. Add a visible owner and update history, then test whether the supervisor can accept the instruction without contacting another person.
One test narrows a question. It does not validate every part of adoption, willingness to pay or delivery at scale.
Fidelity is how closely a prototype resembles the eventual experience. Choose the detail required to expose the uncertain mechanism.
Useful when appearance, interaction timing or realistic constraints are the question.
Useful when a cheap sketch can expose a misunderstanding before the team invests heavily.
Illustrative application: paper screens can reveal whether a customer understands the order of a booking process. They cannot show whether a payment integration will complete reliably. A working integration answers that second question but costs more and may be unnecessary for the first.
Specify the question first, then select the representation and the result that would change the next design decision.
A test teaches you something only if you could have been wrong.
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."
Two filled templates side by side. Strong: a 14-year-old girl at a new school (vivid user) needs to feel socially accepted when she eats healthy food (her need, not yours), because at her school a social risk is more dangerous than a health risk (surprising learning). Weak: a teenager (super vague) needs a healthy diet (your need, not hers), because diet matters for growth (obviously).
Each part of the weak frame fails a different test. The user is too vague to design for, the need belongs to the designer, and the insight tells no one anything new. Only the strong frame suggests solutions the team wouldn't otherwise consider, such as changing what healthy food looks like in a cafeteria. Apply the same three tests to Relay's frame.
The complete list of four challenges: groups dwell on shared knowledge, high-status comments are overvalued, low-status members are ignored and speak less, and a few extraverts dominate. The slide says that in teams of 8, 3 people speak 67% of the time.
In a Relay brainstorm, the person whose information matters most is a front-desk coordinator or a junior hire, not a founder. Collect ideas in writing before discussion. The exact figure is uncertain: Thompson is quoted elsewhere as saying that in a four-person group two people do 62% of the talking, and in a six-person group three people do 70%. Cite the direction of the effect, not the slide's number.
A list of reasons to prototype: to answer a question, to get an idea out of your head by "building to think," to start a conversation, to communicate an idea, to allow new insight from the user and to build deeper empathy.
Only the first purpose, answering a question, produces evidence you can act on. The others help you think and communicate. Before you build, write down which purpose the prototype serves. If it is the first, write the question and the result that would change your plan.
A hand-drawn emotion line runs from Beginning to End above and below a neutral axis, with deep dips early and recovery later. A caption reads "User journey map as a prototype: trace emotions over the course of the experience."
A prototype doesn't have to be a product. A journey map can test whether you've understood the experience if you show it to users and ask where it is wrong. For Relay, map the patient's side, from the text arriving to the decision to the trip to the clinic. The lowest point may be the 90-minute notice, not the message itself.
Five versions of a login screen side by side: a pencil sketch on lined paper, a gray wireframe, a simple black-and-white mock-up and two polished, colored screens.
Each step adds cost and makes the idea look more finished, and the more finished it looks, the less people criticize it. Raise fidelity only when the next question needs it. A paper sketch can show whether coordinators understand a waitlist flow. It can't show whether patients reply to a text at 7:45 a.m.
A woman working at a table covered in prototype materials, with the text: your mindset should be that of an anthropologist in the field, watching how users interact with a prototype to judge whether its concept and design fit their needs.
The anthropologist watches what people do with the prototype. The salesperson (scan 82) and the protective parent (scan 81) try to win approval. For Relay's pilot, that means recording which patients replied and came in, and not asking clinics whether they like the service.
Selected reading: PDF pages 2, 3, 4, 5
The selected pages describe innovation as a human-centered process that connects observed needs with a feasible and viable response. Rough prototypes make an emerging idea concrete enough to learn from.
The Kaiser example begins with how nurses exchange information and what patients experience during shift changes.
Edison’s example connects an invention to the infrastructure that makes it useful. Service delivery and surrounding activities belong in the design problem.
A simple assembled surgical-tool mockup helps practitioners specify what the device must do. The representation supports a more precise conversation.
Teams try alternatives, observe feedback and revise. The reading emphasizes learning from attempts rather than protecting a finished-looking idea.
Selected reading: PDF pages 2, 3, 4, 5
A repeated handoff failure can support several explanations. Preserve the observed episode while examining which need or constraint best explains it.
A rough service enactment can test a sequence or interpretation. Different evidence is needed for reliability, adoption and operational performance over time.
The reported improvements illustrate a particular intervention. Transferring the approach requires understanding the new setting and its constraints.
The fictional delivery handoff from L04 might be addressed with another alert. It might also be addressed by a shared current record, a clear owner or a process that requires acknowledgement. These responses solve different parts of the situation.
Which uncertainty should the first prototype examine?
Prompt-to-prototype tools turn a sentence or a design file into a working, coded prototype. Figma launched Figma Make in beta at Config in May 2025 and released it to all users on July 24, 2025. The cost difference between a paper sketch and a clickable app, a key reason to start low-fidelity, has become much smaller.
Cheap polish doesn't change how people react to it. A finished-looking prototype still draws compliments instead of criticism, and it hides which part is uncertain. Decide the fidelity from the question you are testing, even if a polished version costs almost nothing to make.
Use generated working prototypes for questions that need real interaction, such as whether a coordinator can find the open-slot list during check-in. Keep paper, scripts or a human "wizard" for value questions. A realistic interface can't tell you whether patients will come in on 90 minutes' notice.
Sources: CMSWire (May 2025): Figma Make beta launches to turn designs into apps and prototypes · Figma: Figma Make is now available to all users · CMSWire (July 2025): Figma Make AI prototyping tool exits beta for all users
Known packet: delivery instructions change during the day; email and text can disagree; the driver and office need the current destination. No evidence yet shows that people will check another application.
Write two problem frames, sketch two different responses and choose a prototype that tests the riskiest assumption. State a task and an observable learning signal.
Lesson 4 interviews keep coming back to one episode. A slot opens at 7:50 a.m., the coordinator calls the waitlist and the slot stays empty. Daniel's first idea is better automated reminders. Most clinics already send reminders through their EHR, though, and the gaps remain. Maya has 3 pilot clinics willing to try something. At about 42 empty slots per clinic per week, that is roughly 126 slots a week. Phone calls fill an estimated 10–15% of them (illustrative). No software exists yet.
Write two problem frames, "reminders" and "matching," as user–need–insight statements. Then specify a 4-week Wizard-of-Oz pilot: what Maya does by hand, the single learning metric and its denominator, the prediction made in advance, and the results that would mean continue, revise or stop.
Like Rise Science's team at first, Relay can frame the problem around what the team is good at, which here is automation and SMS. Check whether interviews show automation to be the bottleneck. The real constraint may be the waitlist itself: who is on it and how much notice they need.
"We filled 40 slots" means nothing until you know how many slots opened, how much notice each one had and what the phone method would have filled. Define the metric and its denominator before the pilot starts, not after the results come in.
If Maya hand-picks which patients to text and uses her personal relationships with the clinics, the pilot measures Maya and not Relay. Write down the rules she follows so that software could repeat them, and log every exception.
Two Relay problem frames, reminders and matching, as user–need–insight statements, plus a Wizard-of-Oz pilot specification: manual procedure, fill-rate metric and denominator, prediction, decision thresholds and open questions.
Next lesson: Systematic ideation: thinking inside the box
Check your understanding
Question 1
A building manager hears complaints about a slow elevator. After reframing the problem as "the wait feels longer," what should the manager do before installing mirrors?
A reframe is a hypothesis. If waits have grown because of real capacity limits at peak hours, mirrors won't fix it. Measuring separates the perception explanation from the capacity explanation. Asking tenants whether they like mirrors gets an opinion about a solution, not evidence about the cause.
Question 2
Lesson 4 interviews showed coordinators failing to fill 7:50 a.m. gaps from the waitlist. Which problem frame for Relay best meets the user–need–insight standard?
The third option names a specific user in a specific situation, a need from their point of view and a non-obvious insight that explains why current methods fail. The first is a solution. The second and fourth are generic and obvious, like the "teenager needs a healthy diet" example.
Question 3
Relay's 4-week Wizard-of-Oz pilot logs 300 fillable cancellations and 96 rebookings. The phone baseline is 10–15%. What is the fill rate, and what does the illustrative decision rule (≥30% build, 15–30% revise, <15% reconsider) imply?
96 ÷ 300 = 32%, above the 30% threshold and more than twice the phone baseline. A control group would strengthen the causal claim (lesson 12), but the rule was set in advance so a result like this leads to a decision. Refusing to decide defeats the reason for the pilot.
Question 4
A team shows clinic owners a polished, clickable Relay dashboard. Every owner says it looks great. What is the main weakness of this evidence?
Compliments on a polished artifact predict little. The test had no task, no prediction made beforehand and no commitment asked for, and high fidelity makes people hold back criticism. Sample size and user role also matter, but they aren't the main problem. With more owners, or with coordinators, the same test would still produce only reactions.
Question 5
Maya plans to run Relay v0 by texting waitlisted patients herself from a shared phone. Which statement about this kind of Wizard-of-Oz prototype is a misconception?
A Wizard-of-Oz pilot tests whether the service creates value under hand-run conditions. It says nothing about automated reliability, unit costs or performance at scale. A founder may also add judgment that software won't copy. For example, Maya might pick the patients most likely to accept, which raises fill rate in a way the automated product can't reproduce.
Question 6
A meal-kit startup sees subscribers cancel after three weeks. The team's frame is "our recipes are too complicated." Exit interviews show customers often skipped cooking on busy nights and let ingredients spoil. Which reframe best opens the solution space while staying anchored in evidence?
The third option comes from the observed behavior: skipped nights and spoiled food. It allows flexible skipping, longer-lasting ingredients, quicker meals and simpler recipes too. The first keeps the original frame, the second is a retention tactic that ignores the cause, and the fourth is a solution.
Workbook
Module output: An evidence log, problem frame, prototype, segment choice, positioning and route to market.
Sources
Original pages and full documents are in the Library edition.