Prototyping Services: Desktop Walkthroughs to Wizard-of-Oz

Think in a prototyping spectrum, not a single mockup

When a team says, “We need a prototype,” I immediately ask, “Prototype of what risk?” That question changes everything. If the uncertainty is basic comprehension, I want a storyboard or paper flow. If the uncertainty is spatial sequencing, I want a desktop walkthrough. If the uncertainty is emotional tone and staff ergonomics, I want roleplay. If the uncertainty is whether the service promise can survive real customer behavior without full automation, I want Wizard-of-Oz. If the uncertainty is unit economics, staffing load, or operational repeatability, I want a bounded concierge pilot. Different risks require different fidelities.

This is why I talk about a spectrum instead of a ladder you climb mindlessly. Higher fidelity is not inherently better. It is more expensive, more politically visible, and easier to over-believe. I have seen teams rush to a polished front-end because they wanted the prototype to look impressive. That move often hides the service question under interface gloss. A paper storyboard can answer a crucial learning question in two hours. A medium-fidelity roleplay can expose a broken backstage dependency before a single developer opens a branch. Cheap prototypes are not amateur work. They are sharp tools when aimed at the right uncertainty.

ASD helps because the methods make the intended learning explicit. storyboard-authoring returns a storyboard artifact. desktop-walkthrough returns a walkthrough script. wizard-of-oz returns a prototype plan. concierge-pilot does the same at higher fidelity. The artifacts force me to state the hypothesis, the touchpoints to simulate, the fallback rules, and the pass or fail criteria. That keeps a prototype from mutating into a demo whose only real job is to reassure the sponsor.

Ember Hospitality illustrates the value of this framing. Leadership originally wanted a substantial software build for “occasion management” inside the booking flow. That would have answered the wrong question first. Before software mattered, the team needed to learn whether guests wanted to disclose special-occasion intent in a structured way, whether floor staff could trust a shared celebration brief, whether dietary and deposit promises could travel intact, and whether a human concierge layer was economically viable. Those were service questions. The prototype spectrum let us ask them in the right order.

Start with storyboard-authoring and desktop walkthroughs

The storyboard-authoring method looks simple. It is not. The method requires a minimum of four nodes and rejects any frame with no action in the scene field. I love that gate because it prevents one of the oldest service-design sins: making mood boards and calling them experience prototypes. A service storyboard needs a protagonist, a sequence, an observable move, and a consequence. Otherwise the team is only projecting its intentions.

For Ember, the first storyboard had six panels: booking intent, occasion disclosure, dietary capture, arrival cue, table moment, and payment follow-through. Every frame had two layers: what the guest believes is happening and what the staff need backstage for the next moment to hold. That second layer is where the service prototype becomes serious. The guest sees a simple prompt asking whether the dinner is for a special occasion. The backstage layer asks harder questions. Who needs to know this? When? In what level of detail? Does the floor runner need the emotional context, or only the timing cue?

{
  "id": "ember-spectrum-01",
  "method": "storyboard-authoring",
  "hypothesis": "Guests will disclose special-occasion intent when the prompt is specific and discreet.",
  "fidelity": "low",
  "targetSubjects": ["repeat diners", "group bookers", "floor-staff champions"],
  "successCriteria": [
    "at least 80 percent of participants understand what the prompt is asking",
    "staff can state which role sees which occasion detail"
  ],
  "failureCriteria": [
    "guests perceive the prompt as intrusive",
    "staff say the service would expose sensitive context too broadly"
  ]
}

Once the storyboard is coherent, I move the service onto a table. Desktop walkthroughs sound almost childish until you see how brutally they expose broken logic. I map the environment with paper, printed interface states, table markers, shift notes, kitchen tickets, or route cards. Then I move tokens through the sequence and narrate every state change aloud. In Ember’s case, a simple walkthrough exposed the service fracture instantly. Occasion information sat in one place, dietary nuance in another, and group-deposit promises somewhere else. On the screen, that looked manageable. On the table, it became obvious that the host would be forced to reconstruct the service from fragments under real dinner-service pressure.

Desktop walkthroughs are also where I start hunting for hidden backstage work. If somebody has to invent a note, remember an exception, text a manager, or run to the kitchen, I want to see that labor immediately. The future bug often appears first as a compensating behavior in a fake environment. A person leans over and whispers, “I would probably tell the manager here just in case.” That is gold. It means the designed process is not trustworthy enough on its own yet.

At Ember, this stage killed one early idea elegantly. A first concept assumed any special occasion should be broadly visible to staff to ensure enthusiasm. The bodystorming and walkthrough sessions proved the opposite. Some occasions needed celebration. Others needed discretion. A proposal dinner, a fertility-anniversary meal, or a quiet reunion after bereavement should not be broadcast on the floor. The prototype taught us to separate emotional context from operational cueing. That is the kind of learning a software build would have obscured until it became an embarrassing live-service problem.

Use wizard-of-oz when the frontstage matters more than the code

The wizard-of-oz method is where service prototyping gets interesting. ASD defines it clearly: the user sees a believable frontstage while hidden humans run the manual process behind it. The method’s gate is load-bearing. A Wizard-of-Oz plan without a fallback script fails. Good. If the hidden operator has no defined response when the customer behaves unexpectedly, the prototype is testing improvisation rather than the service design.

I use Wizard-of-Oz when I need to test whether the promise and pacing of a service feel credible before building the heavy machinery underneath. Ember was a perfect fit. We could build a lightweight booking flow and a staff tablet mock quickly. The real uncertainty sat backstage. Could a hidden operator review occasion notes, dietary nuance, group size, surprise constraints, and timing windows fast enough to produce a useful celebration brief? Which bookings really needed human review? Which could route cleanly with rules alone? Those are manual-operability questions. Wizard-of-Oz is built for them.

prototype_id: ember-woz-01
frontstage:
  - booking flow with occasion, dietary, and group prompts
  - confirmation screen promising follow-up only when coordination is required
backstage:
  - hidden operator reviews each booking in a shared queue
  - operator assigns one of: no action, staff brief only, concierge follow-up
  - operator writes celebration brief and routes it to the site tablet
fallbacks:
  unexpected_surprise_request: "A team member will confirm whether we can support that detail before your visit."
  unsupported_allergen_complexity: "We need a manager to review this request before we confirm the booking."
  deposit_confusion: "We will send the exact payment and timing terms in writing today."
metrics:
  - guest completion rate
  - manual minutes per booking
  - staff trust score in the brief
  - promise-kept rate at table

The phrase I use with teams is agent backstage. The customer does not need to know which parts are manual and which parts are partially automated. The operators do. ASD is excellent here because I can let lightweight agents parse the incoming request, normalize it, and tee up a recommendation for the hidden human without pretending the system is already ready for production autonomy. That hybrid mode matters. A pure manual Wizard-of-Oz test can become too slow for anything beyond a handful of sessions. An agent-assisted backstage lets the prototype stretch into a more realistic volume while preserving human judgment on safety, discretion, or commercial exceptions.

There is one ethical boundary I keep tight. I will fake automation. I will not fake capability in safety-critical scenarios. Ember’s Wizard-of-Oz path excluded highly sensitive occasions, severe multi-allergen cases, and anything where a partial backstage script could create harm or false reassurance. The prototype must respect the domain. Hospitality feels light compared with healthcare or banking, yet it still contains safety, privacy, and consent edges that deserve caution.

That is exactly what happened at Ember. The first live Wizard-of-Oz rounds showed that a universal concierge model would be absurdly expensive. Hidden operators could manage the queue for a while, but manual effort spiked on a small cluster of complex bookings: large groups, layered dietary notes, surprise choreography, and high-value tables. The winning insight was not “build more automation.” The winning insight was that only a minority of bookings needed human concierge work at all. The backstage service model changed before the software did.

Instrument the pilot like a service, not a product demo

Once a concept survives storyboarding, walkthroughs, roleplay, and Wizard-of-Oz, I still do not call it validated. I call it ready for a bounded live trial. This is where teams often relapse into startup folklore. They say things like, “Let’s launch a beta and see what happens.” I refuse that language. A service pilot needs entry criteria, exit criteria, and explicit measures across both customer value and operational load. Otherwise the organization learns the wrong lesson from a lucky week.

For Ember, the bounded concierge pilot focused on one service proposition: Celebration Concierge. Structured capture at booking. Rules that route only risky bookings to a human concierge. One concise celebration brief visible to the right staff at the right time. That is specific enough to pilot. We then instrumented the live run around four families of evidence: guest completion and confidence, staff scramble minutes, promise-kept performance on dietary and surprise details, and attach revenue on celebratory covers. The goal was not to prove the concept was perfect. The goal was to learn whether the service economics and execution standards could hold across multiple restaurants.

{
  "prototype_id": "ember-concierge-pilot",
  "cohort_size": 84,
  "sites": 12,
  "metrics": {
    "special_occasion_nps": 54,
    "staff_scramble_minutes_per_table": 6.2,
    "attach_revenue_per_cover_eur": 10.7,
    "dietary_promise_kept_rate": 0.96
  },
  "guardrails": {
    "manual_minutes_per_routed_booking": 8.4,
    "recovery_comps_per_100_bookings": 5,
    "unsupported_request_escalation_within_hours": 4
  },
  "decision": "stage for rollout beta"
}

I also instrument the decision boundary. If routed manual work exceeds a defined threshold, the model fails. If staff distrust the brief and rebuild it from scratch at the site, the model fails. If the guest experience improves but the margin story collapses, the model fails. A pilot is supposed to be demanding. Its purpose is to discover where the service cannot scale yet.

ASD’s measurement stack is useful in this phase because I can keep the evidence tied to the method artifacts. The prototype plan points to the learning question. The daily notes and structured observations become evidence. The pilot-test-report and any follow-on decision matrix cite those inputs explicitly. That traceability prevents a familiar executive move: treating the happy anecdotes as proof while ignoring the cost curve and the hidden work that made those anecdotes possible.

Ember Hospitality: from vague occasion notes to a bounded concierge service

Ember is a fictional composite, but the operational pattern is very real. Occasion dining creates outsized emotional stakes with relatively small windows for recovery. A missed surprise, a dropped dietary note, or a broken deposit promise can erase trust faster than it does in an ordinary booking. That is why I like this case for teaching service prototyping. The difference between a screen feature and a whole service becomes visible fast.

We began with weak signal capture. Only a minority of celebratory visits were identifiable in structured form at booking. Most arrived as vague notes such as “birthday maybe cake.” Floor staff carried a huge share of the recovery burden because they reconstructed the service manually at the site. During discovery, the team found five structural failures: weak signal capture, backstage fragmentation, promise failure, frontline improvisation cost, and no testable operating model. Those failures became the hypothesis bank for the prototype spectrum.

The first two weeks were cheap and revealing. Storyboards and bodystorming showed that public celebration behavior was culturally brittle and privacy-sensitive. Desktop walkthroughs exposed the fragmentation between occasion notes, dietary details, and deposit handling. We rewrote the brief around a single service object rather than three disconnected note systems. By week three, the service was coherent enough to fake.

Weeks four and five ran the Wizard-of-Oz test across six restaurants. Guests used a believable booking flow. Hidden operators reviewed each request, triaged risk, and routed a celebration brief to the site. Every evening ended with a same-day debrief. We watched completion rates, guest confusion, staff effort, and manual minutes per routed booking. The biggest learning was economic. A universal concierge service was overkill. The high-value operational move was selective routing: only large groups, multi-part dietary notes, surprise coordination, and higher-spend bookings needed the human layer consistently.

Week six turned that learning into a bounded live pilot across twelve restaurants and eighty-four guests. The resulting service, Celebration Concierge, proved its worth precisely because it was narrow. Structured capture became mandatory for occasion, dietary, and group contexts. Rule-based routing decided which bookings required concierge intervention. The celebration brief respected discretion: hosts, managers, and kitchen saw different slices of the same service object depending on what they needed to act on. The metrics moved in the right direction because the service design had been pressure-tested before software scale entered the conversation.

The final decision was not “ship the prototype.” It was “fund the right service model.” That difference matters. The pilot validated a rollout-beta path with explicit staffing assumptions, rule thresholds, and measurement. It also preserved several manual edges intentionally because the team now knew which parts of the experience deserved human judgment. Prototyping did not simply reduce risk. It improved strategy.

That is the deeper lesson of service prototyping. I am not trying to mimic production perfectly. I am trying to reveal where the service promise depends on human discretion, where the backstage model cannot carry the frontstage script, and where the business case only works after the scope is narrowed intelligently. The more invisible the service, the more valuable this discipline becomes.

So I keep the sequence tight. Storyboard the promise. Walk the logic. Roleplay the handoffs. Fake the automation. Measure the bounded live run. Then decide what deserves real build investment. Teams that skip these steps do not move faster. They simply postpone the moment when reality argues back.