From screenshot
to recipe, instantly.

Two users, one tension.

Research surfaced two distinct user modes: the impulsive saver who needs frictionless capture above all else, and the deliberate cook who wants to review before committing. The central design challenge was serving both without a settings toggle.

The tension resolved into a confidence-routing system — the AI agent silently routes based on extraction confidence. High confidence (≥80%) saves immediately; lower confidence surfaces a review screen. Neither user has to manage this explicitly.

This decision is the spine of the entire product. Every subsequent design choice either protects Priya's capture speed or gives Tom the accuracy signals he needs.

Editorial with warmth.

The visual system is built on one principle from NYT Cooking: serif for recipe content, sans-serif for UI chrome. Playfair Display handles every piece of recipe content — titles, descriptions, step instructions, metadata values. DM Sans handles all navigation, labels, buttons, and tags.

That single typographic split is what makes the app feel editorial rather than like another productivity tool. Recipe content reads like a cookbook. UI reads like an interface. The two never blur.

Avocado green is the only action colour. It appears on primary buttons, checked ingredients, active steps, progress fills, and nowhere else. Every green element is interactive or confirmed.

Avocado — 7 stops

Warm neutrals

Tag colours — WCAG AA verified

Icons — Tabler Icons (MIT)

Exclusively Tabler Icons throughout. Consistent 1.5px stroke, rounded caps, 24×24 grid. Zero mixed icon sources — a deliberate constraint to maintain visual coherence across all 8 screens.

Sprint to shipped product.

The sprint produced a research foundation, design system, and 8-screen prototype with every decision traceable to a user insight. Then the app was built and deployed — validating that the design logic held up in production.

The three decisions that mattered most — confidence-based routing, named pipeline steps, and per-field uncertainty flags — all shipped without modification. Designing the logic precisely enough to prototype it made the implementation spec unusually clear.

Six findings.
Three validated, three to build.

After the sprint prototype was complete, I ran a round of user testing to stress-test the core flows. The sessions surfaced clear signal: users connected strongly with the multi-source upload and the confirmation screen, and called out three gaps that would shape the next iteration.

The findings split cleanly into two categories — things that landed as designed, and things that revealed scope gaps. Both are equally useful. The validated items reinforce the core design decisions; the gaps define what v1.1 needs to solve.

The design spec became the build spec.

Documenting every design decision — not just the outcome, but the rationale and the rejected alternatives — meant the implementation had unusually clear requirements to work from. The confidence threshold, the pipeline step names, the per-field flag logic: all of it was written down precisely enough to implement directly.

The gap between prototype and product was narrow by design. When you can explain exactly why a UI behaves the way it does, building it becomes a translation problem rather than a interpretation problem.

Three things held up without change from design to production:

• The confidence-based routing model — no user configuration needed in the live product
• The named pipeline steps on the saving screen — users respond to seeing the AI's work made legible
• The per-field uncertainty flags — showing only what's wrong, not a global warning

The live app is at souschef-sepia.vercel.app — every screen in this case study corresponds to a live, working feature.