Case Studies · Design Systems

Design cases: from specification to a live product

Four cases, each with a live surface

Every case here rests on a live surface or a real capture from the project — never a mockup. Where there is an open link, it is on the card.

Case 01 · The document is what worked

A children's learning platform

  • Handoff
  • RTL
  • Six weeks? Six hours

A team we had never worked with executed the spec correctly, over a weekend, with nobody to ask.

The client called on the last working day before the weekend: "our product looks AI-generated — make it look like a platform that has existed for years." They were presenting to the Ministry of Education on Monday. We did not deliver mockups; we delivered a specification — users, constraints, product principles, an accessibility floor, and an explicit list of facts we refused to invent. That is what lets a team of strangers execute correctly with nobody in the loop.

A colour-token board in two modes, student and staff, each swatch labelled with its token name
The colour layer of the system built on the Monday — two modes, the same token names, one place to change them
  1. Thu 13:00last working dayThe client calls. Urgent.The product reads as machine-generated. On Monday they present to the Ministry of Education.
  2. 13:00–19:00six hoursWe write the handoff.Not mockups. A specification: users, constraints, principles, an accessibility floor — and a list of facts we refused to invent.
  3. Thu 19:00deliveredSix hours from a cold call to a document.Then the country closes for the weekend and we go offline.
  4. Fri–Sunwe are not thereTheir own team redesigns off the document.A team we had never worked with. No designer of ours in the loop. Nobody to ask.
  5. Mondaypresentation dayWe build the full system on top.Design directions across four screens, a governed token system, an automated review pass — and a facelift of the live product, published the same day.
13:00 → 19:00From a cold call to an executable document
Fri–SunTheir team redesigns off it, with no designer of ours
MondayA token system and a facelift of the live product, same day

Case 02 · A whole product, not a screen

RenoRange

  • Lead funnel
  • AI render
  • Live in production

The user uploads a photo and sees their own room renovated — and the whole funnel is built from one system.

A renovation cost-estimate funnel: pick the job, upload a photo, get a price range — and a render of the room after the work. No developer measures by hand and no designer exports images: it is all built from the same system, and the cost pages are generated from a single source of truth, so a price cannot drift between the page and the calculation.

Server-sideThe render runs on the server — no API key sits in the browser
Every stepof the funnel is measured — from first click to lead
One source of truthCost pages are generated from the rate table, never typed
Open the live funnel
A before-and-after comparison of a renovated room inside the cost-estimate funnelAI-generated example
A before/after slider inside the funnel — the user drags and continues. The render is labelled an AI-generated example, both inside the image and on it

Case 03 · Data story

PISA

  • Ten chapters
  • Full Hebrew
  • RTL

A lot of data, one visual language — and it reads as a single piece, not a collection of screens.

Ten chapters in full Hebrew, from the opening through the conclusions. Every chart is built from the same components and the same tokens, so a new chapter is an assembly rather than a redesign. The real gain is not the polish — it is that the reader understands without explanation, because the same colour coding and the same scale recur in every chapter.

Tenchapters in one visual language, from the opening to the conclusions
The opening screen of a Hebrew data story, with a large headline and a chapter index down the side
The opening screen — full Hebrew, RTL, a chapter index down the side; the same visual language carries through all ten

Case 04 · Annotated handoff

Lexus

  • Component library
  • Handoff annotations
  • Automotive

Every edge is annotated inside the file, so no developer measures by hand and nobody sends questions.

A complete library: logo, icons, buttons, cards, header and footer — each with its states. The annotations live inside the file rather than in a separate document, so they cannot go stale the moment the design moves. That is what turns handoff from a conversation into a read.

In the fileHandoff lives in the design file, not in a document beside it
Every stateFor each component, so no state gets invented in development
My LEXUS Israel in the portfolio
Hebrew card components on a design-file artboard, grouped inside dashed frames
Card components on the artboard — document upload, vouchers and an empty state, each its own group

Want to see what this looks like on your product?

Stage 01 with us is a specification, not a quote. Tell us about the product and we will get back to you, usually within one business day.

Talk to us

Tell us about your project and we'll get back to you, usually within one business day.

We respect your privacy. Your details are safe with us.