Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu

Bootcamp - Medium，Bootcamp 是 Medium 上关于 UX、UI、产品设计与设计思维的出版物。关注

How product teams generate possibilities, test assumptions, and learn before committing expensive resources.

At a small restaurant in Bandung, Aditya watched a chef prepare three bowls of the same pasta sauce.

The first received roasted tomatoes. The second used fresh tomatoes with a little palm sugar. The third included a spoonful of fermented chili that the chef had bought from a local market.

None of the bowls was large enough for a customer. There were no decorative plates, printed menus, or carefully placed basil leaves. The chef tasted each version, asked two kitchen staff to compare them, changed the amount of salt, and tried again.

Aditya asked when the new dish would be ready.

The chef laughed. “Ready for what? Today I only need to know which direction deserves another hour.”

That sentence stayed with her.

Product teams often wait until an idea looks complete before showing it to anyone. We refine the interface, prepare the presentation, and protect the concept from uncomfortable questions. By the time real feedback arrives, the team has invested enough effort to hope the idea is right.

The Stanford d.school describes a different ability: Rapidly Experiment.

It is not simply about moving quickly. It is the ability to generate possibilities, make important assumptions testable, and learn through small cycles before the cost of change becomes high.

🍽️ The Team Had Already Chosen the Dish

Aditya’s team was building a feature for a grocery delivery app. Customers frequently forgot one or two items after placing an order, then created a second order or contacted support. The proposed solution was an “Add forgotten items” button available for ten minutes after checkout.

The concept felt obvious. The team discussed the button position, countdown behavior, and payment update. Engineering estimated several weeks because the feature affected inventory, routing, payment authorization, and warehouse picking.

Before development began, Aditya asked a simple question: “What must be true for this idea to help?”

The room became quieter.

Customers would need to notice the option. They would need to remember the missing item within the allowed time. The warehouse would need to receive the update before picking began. People would need to trust that the second charge was correct. Adding items must not create more confusion than placing a new order.

The team had discussed one solution as if it were the problem itself.

Rapid experimentation begins by reopening possibility. Instead of asking only, “How should this button work?” the team asked, “How might we help customers recover when they realize something is missing?”

That produced more directions: a final basket reminder before payment, a short post-checkout add window, suggested forgotten staples, easier order duplication, and a lightweight support path for time-sensitive cases.

The goal was not to build all of them. It was to avoid spending weeks perfecting the first idea that entered the room.

🧂 Name the Assumption Before Choosing the Experiment

An experiment is useful when it is connected to a learning question.

Without that connection, teams can produce prototypes, A/B tests, and workshops that create activity without reducing uncertainty.

Aditya listed the assumptions behind the leading concepts and sorted them by importance and uncertainty. One stood out: customers would recognize a forgotten item soon enough for the order to be updated.

The team did not need a functioning payment integration to investigate that assumption. They recruited recent customers, asked them to place a realistic grocery order using a prototype, and introduced a prompt at different moments. They also reviewed the timing of support messages that mentioned forgotten items.

The results were mixed. Some people remembered an item immediately after seeing the confirmation screen. Others realized only when cooking several hours later. A ten-minute window would help a meaningful group, but it was not the whole answer.

That learning cost two days, not six weeks.

The experiment did not prove that the final feature would succeed. It made one important assumption less uncertain.

🥄 Use the Smallest Portion That Can Produce Honest Feedback

Low fidelity does not automatically mean useful. A paper sketch may be enough to test whether people understand a sequence, but not enough to test whether they trust a payment update. A polished prototype may feel realistic, yet take too long if the question concerns a single label.

The right experimental form depends on what the team needs to learn.

Aditya’s team used several small experiments:

A paper flow to compare when reminders felt helpful or annoying.
A clickable prototype to test whether people understood that one order was being updated rather than a second order being created.
A fake operational simulation in which a staff member manually approved item additions, allowing the team to observe edge cases before automating them.
A limited release at one warehouse to understand timing and picking constraints.

Each experiment was intentionally incomplete. Each was complete enough for its question.

The chef in Bandung did not plate the sauce because visual presentation was not the uncertainty he was exploring. If the question later became whether customers would pay for the dish, the experiment would need to change.

🔁 Test to Learn, Not Only to Confirm

Teams sometimes use experiments as a courtroom where an idea must be declared successful or unsuccessful. That framing creates pressure to defend the concept.

Rapid experimentation works better when the team expects the idea to change.

During a usability session, one participant saw the “Add items” confirmation and asked, “Will the driver have to go back?” The prototype had explained the payment change but not the operational timing. Another participant tried to add a chilled product after the cold-storage bag had already been sealed.

These were not annoying exceptions. They were information about the system the team was designing.

Aditya changed the experiment. The next version showed whether the order was still editable and explained why the option might close earlier than expected. The team also explored an alternative reminder before checkout for items commonly forgotten together.

The concept became a set of connected interventions rather than one heroic button.

Learning happened because the team allowed feedback to redirect the idea.

🔥 Speed Is About the Learning Loop

Rapidly Experiment does not mean rushing people, lowering ethical standards, or testing carelessly. A badly framed experiment conducted quickly can create false confidence just as efficiently as a slow one.

The speed that matters is the distance between a question, a testable representation, evidence, and the next decision.

Aditya kept a simple record for each experiment:

What do we believe?
Why does it matter?
What evidence would challenge that belief?
What is the lightest responsible way to obtain that evidence?
What will we do differently depending on what we learn?

The final question prevented the team from running interesting tests that had no consequence. If no plausible result would change the decision, the experiment was not ready.

🍝 The Full Menu Came Later

Several weeks later, the product team released a limited version of post-checkout item addition. It did not look exactly like the original concept.

The editing window depended on warehouse status rather than a fixed universal timer. The confirmation made payment changes explicit. The checkout screen included a gentle reminder based on the basket, but customers could dismiss it. Operational teams had a clear exception path.

The solution was stronger not because the first idea had been brilliant, but because the team had been willing to treat it as material for learning.

Aditya returned to the Bandung restaurant months later. The experimental sauce was now on the menu, but the fermented chili version had disappeared. The chef had kept the roasted tomato base and borrowed one small technique from the second bowl.

“So none of the original versions won?” Aditya asked.

“The dish won,” the chef said. “The versions did their job.”

That is what good experiments do. They do not exist to preserve the dignity of an idea. They help the team discover what deserves to become real.

🧺 Takeaways to Bring Into Your Next Project

Rapid experimentation explores possibilities before the team commits heavily to one solution.
Begin with an important uncertain assumption, not with a prototype format.
Use the smallest responsible representation that can produce honest feedback.
Match fidelity and method to the learning question.
Treat surprising behavior and edge cases as evidence that can reshape the concept.
Measure speed by the learning loop, not by how quickly artifacts are produced.
Let experiments combine, transform, or retire ideas without framing that as failure.

P.S. Next up:

“Move Between Concrete and Abstract: Like a Doctor Connecting Symptoms to the Larger System” 👀

🔗 About This Series

This is article 4 of Designerly Thinking: Eight Core Design Abilities, followed by a reflection epilogue. The abilities come from the Stanford d.school and are not intended as a rigid sequence.

#ProductDesign #RapidExperimentation #Prototyping #ProductDiscovery #UXDesign #DesignAbility #DesignThinking #DigitalProductDesign #StanfordDschool

Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu 🍝 was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

添加评论

点踩

分享查看原文

参与讨论