Find a story.

Explore Neeed, Vividish, or WGTakt.

Vividish journal

The design system had to reach the actual screens.

A blueprint and an implementation can both exist while still speaking different visual languages.

The application did not look like its blueprint. Typography was one visible symptom, but the request was about the shared design language underneath the screens.

A blueprint is useful only if it survives implementation. Otherwise every new view becomes a fresh interpretation, and consistency depends on whoever happens to be editing that page.

See the original request

Inside the screen

One workspace, two reading contexts.

A design system has to work in the dense restaurant workspace and in the guest view being previewed inside it.

The guest view, inside the workspace
Actual application capture · 21 May 2026

Select a detail

The sidebar gathers operations into labelled groups. I would review spacing, active state, and hierarchy across these repeated items, not just in a token file.

May application capture. It shows the resulting interface, not proof that every April token or component was migrated.

The original request23 Apr 2026 · excerpt
I saw the font and everything looks different from the blueprint, make sure it is EXACTLY as blueprint.

Excerpted from the development conversation. Punctuation is lightly edited; the surrounding story is an edited retrospective.

01

A font mismatch can be a dependency problem.

My request sounded visual because that was how I encountered it. The font looked wrong. Underneath, the recorded work found older global styling and a font bridge competing with the intended blueprint foundations. Fixing the heading on one route would have been a tempting response. It would also have left the next generated screen open to the same conflicting inputs.

I used the blueprint as a constraint on the shared layer: typography, colour tokens, and the primitives that ordinary components inherit. The compatibility mappings for existing components mattered too. A new foundation is only useful if the application actually reaches it. This is a part of AI development that rarely appears in a hero image. The quality of the next screen depends on whether the codebase gives the tool one coherent visual vocabulary.

02

Use real routes as the test

The work continued into public directory routes, with build, language, and file size checks. Browser screenshots covered design system and directory views. That moves the discussion beyond whether an isolated component looks correct.

There was a specific verification gap: live directory cards could not be confirmed because the data fetch failed in the local browser check. A route rendering and its real data loading are separate results. The record did not blur them together.

03

The browser can disagree with the component library.

A typeface changes more than the mood of a headline. It changes where a label wraps, how much fits in a row, and the relationship between a number and its explanation. The guest menu and the workspace are a useful pair to inspect because they put different pressure on the same foundations. One needs a quick scan on a phone. The other carries navigation and operational context around the content.

The route checks moved the review into that real environment. I still keep the failed directory fetch visible in the account because a beautiful empty shell does not answer whether the actual cards fit. A useful next review would populate short names, long names, and both languages, then compare the same routes. The April change established shared foundations. It did not make every future composition correct automatically.

Shared styling has to survive real screen constraints. I return to that question in Making the navigation smaller made the collision worse.

Where this chapter landed

What changed.

Shared visual foundations were updated and checked on real routes. The local record retained a live directory data verification gap.

Added while revisiting this story · September 2026

The thinking behind the detail.

Research notes to take these decisions further. These sources were reviewed for this retrospective.

The foundation must support real content

W3C’s internationalisation guidance favours flexible text layouts over tight fixed containers. This gives the blueprint review another concrete input: the same primitives should accommodate the application’s actual English and German content.