Back

Forkast

Usability test report.

Two connected studies tested whether diners could make a safer menu decision and whether that decision could survive the handoff into a working kitchen.

Forkast customer safety screens showing Safe, Caution, Avoid, and substitution states
Ownership
Independent, end to end
Customer test
11 participants
Restaurant test
3 participants
Evidence
Confirmed project record
  • Comparative Testing
  • Service Prototyping
  • Usability Testing
  • Design Iteration

Testing had to work on both sides of the table.

A customer-facing filter could look clear and still fail if the restaurant could not receive, verify, and act on the same allergy decision. I tested the two sides separately, then used the point of failure between them to reshape the service flow.

About this reportThis is a concise reconstruction from the confirmed project record. The participant totals and customer results below are real. Formal session notes, recordings, SUS scores, exact scripts, and per-participant timing logs were not retained, so they are not recreated here.

The customer comparison.

Eleven people used Forkast and a traditional menu to find a suitable dish and inspect the information behind that decision.

Under 2 min

All 11 participants found a suitable dish with Forkast.

About 2x longer

The same participants took about twice as long with a traditional menu.

10 of 11

Found the full dish details without guidance.

Forkast personalized menu showing dishes marked safe for the diner's allergy profile
Find a suitable dish
Forkast safe dish detail showing the evidence behind its safety state
Inspect the evidence behind the decision

Two tests, one handoff.

The customer comparison measured clarity at the menu. The restaurant-side walkthrough tested whether the same decision fit the people and pressure behind the menu.

Customer-side comparison

11 customer participants worked through the decision in Forkast and in a traditional menu condition. The surviving results show what the study evaluated, not the wording of the original task script.

  • Whether people could find a suitable dish.
  • How decision time compared with a traditional menu.
  • Whether people discovered full dish details without prompting.

Restaurant-side first iteration

A waiter, chef, and junior chef tested the kitchen workflow in a simulated service flow. The retained account documents the behavior that was evaluated, not an exact facilitator script.

  • Whether direct-to-chef routing fit existing service roles.
  • How allergy questions moved under service pressure.
  • Where responsibility returned when the first flow broke.

The first kitchen flow broke under pressure.

The uncomfortable conversation at the end of the first test exposed a system problem: sending every diner question directly to the chef interrupted the kitchen and eventually pushed the question back through the waiter anyway.

First iteration

DinerChefWaiter

Direct access looked faster on screen, but it bypassed the person already responsible for the table and added pressure to the kitchen.

Design response

DinerWaiterChef when needed

The waiter handles known answers first. Only unresolved safety questions reach the chef, and the answer returns through a visible shared record.

Forkast waiter dashboard showing guest questions and table context
The revised service flow keeps question ownership visible before escalation

What testing changed.

Each observed problem was translated into a specific interface or workflow response. These findings are retained in the original project record.

ObservedDesign responseWhy it matters

Allergen labels felt detached from the dish

Move the allergen indicator onto the dish card

Faster confirmation

“Ask the kitchen” felt like an end state

Turn it into a persistent pending action

Clear next step

Question ownership was unclear

Show a visible waiter → chef route

Shared accountability

Caution and Avoid looked too similar

Separate amber substitution from red rejection

Safer scanning

Chef actions were hard to find

Prioritize approve, substitute, reject

Faster resolution

What the evidence can support.

A useful case study is precise about both its findings and its limits.

Confirmed and included

  • 11 customer participants and three restaurant-side participants.
  • The three customer comparison results shown above.
  • The five observed usability issues and their design responses.
  • The failed direct-to-chef route and the waiter-first redesign.

Not available, so not claimed

  • Participant demographics or individual profiles.
  • Verbatim participant quotations or session recordings.
  • Per-participant task times, error counts, or assistance levels.
  • A System Usability Scale score or statistical significance.

What I would validate next.

A future round would turn the surviving evidence into a repeatable study and test the redesigned handoff in a real restaurant environment.

  1. Write one task protocol.Use the same menu-finding, detail-checking, and question-routing prompts with every participant.
  2. Record behavior consistently.Capture completion, assistance, errors, time, and short post-task confidence ratings.
  3. Retest the handoff.Compare the waiter-first escalation model with the rejected direct-to-chef route during realistic service pressure.
  4. Run a live pilot.Validate answer ownership, kitchen capacity, and whether the shared safety record stays current across a shift.

Testing changed the system, not just the screens.

The strongest result was the point where the first concept failed. Listening to the people inside the restaurant changed who owns the question, when the chef gets involved, and how one safety decision travels from table to kitchen.