A design system is what makes AI-models useful

Hacken sells blockchain security to a global market, and the marketing team’s output is the front of that: 40+ pages on the site, plus investor and sales presentations — typically 20–30 slides each, 15–20 of them a month.

The hard part was never the design. It was the timing. A serious prospect appears, a call is booked, and a deck is needed now — not next week. Before this work, that meant the team sitting late to get it out.

There was an existing design system, but it was large and years out of date. Reaching for it cost more than ignoring it, so people ignored it, and consistency drifted.

1 — Build a small new system instead of repairing the old one

The obvious move was to modernise what existed. I chose not to.

A large, outdated system has a specific failure: every component you touch has dependencies you have to verify, so the cost of a fix is unpredictable. I built a separate, deliberately simplified system instead — colours, type, the main components, the grid, and the principles behind them. Small enough to hold in your head, and small enough to describe completely.

That second property turned out to matter more than the first.

2 — Variables so one design produces three breakpoints

Type sizes and spacing are bound to Figma variables, with one value set for desktop and separate sets for tablet and mobile.

In practice I design a page once, at desktop, then switch the whole file to tablet or mobile in a single action. Three layouts come out of one pass, and the errors that normally come from re-laying-out by hand mostly disappear.

The developer benefits from the same structure: the design is expressed in the same terms the front end is built in, so there is less to interpret and less to ask about.

3 — Encode the system as files a model can read

This is the part that makes the rest work.

I converted the system into local CSS files and components, and wrote a CLAUDE.md next to them holding the detailed instructions for how they are meant to be used. Connect that folder to Claude Code, and the system stops being a Figma library that only a human can consult — it becomes something a model can apply.

From there it works in two directions: into Figma via the Figma MCP, where the model finds the right values and existing components and builds the deck directly on the canvas — or straight to PPTX, when the file needs to exist without going through Figma at all.

The general point, and the reason this case exists: a model that has no system to work from produces something generic. The design system is the constraint that makes the output usable. Which is an odd thing to notice — the more capable generation gets, the more valuable the person who defines the rules becomes.

4 — An intake interview, not a prompt

The first thing the tool does with any request is run a short onboarding: what is this deck for, who is it going to, what does it need to contain.

This is the difference between a tool other people can use and a prompt only I can use. A colleague does not have to know how to describe a design brief — the tool asks them, in the order the answers are needed. It is the same interview I would run if they walked over to my desk.

5 — Scope the tool to the part the model is actually good at

The obvious ambition is a finished deck out of one request. I tried that, and it does not hold up.

What the model reliably fails at is visual judgement: it fills every available space. Given room, it will put something in it. Left any latitude, it also improvises — rewriting copy it was told to place, inventing structure, drifting from the brief. The failure is not random noise; it is a consistent bias towards more.

So I cut that ambition out of the tool on purpose. Claude Code produces the basic design only. I finish it by hand — usually one to two hours on a 20–30 slide deck.

That split is not modesty about AI, it is where the actual economics are. A large share of what remains on a generated slide is simply faster to fix by hand than to re-prompt into place. The value is in skipping the blank canvas and the mechanical layout work, not in avoiding design work altogether.

The model fills space. Its consistent bias is towards more — more elements, more text, more decoration. A slide with room left in it will not stay that way. Every visual request has to specify the end state precisely, because anything unstated gets filled in.

Latitude produces drift. Leave it room to improvise and you get rewritten copy, invented structure, and output that no longer matches the brief. Constraint is not a limitation of this workflow, it is the workflow.

A finished result is not on the table. I tested it. What comes back needs a designer, so the tool is scoped to the part that holds up.

That third point is worth being blunt about, because the usual version of this story ends with the tool doing the whole job. This one does not. It removes the blank canvas and the mechanical layout pass — which, at 15–20 decks a month, is the part that was costing evenings.

And the review rule does not always survive contact with urgency. When a deck is needed today, a basic generated version sometimes goes to stakeholders as-is, because on that timeline something on-brand and structurally right beats nothing. I don’t think that’s fine in principle. I do think pretending it doesn’t happen would be worse.

The tool also outgrew me. Stakeholders asked for it, so I shared the files and the workflow, and they now generate basic decks for themselves without involving me at all. That is the adoption I wanted, and it is also how unreviewed output reaches an audience — the same property produces both. Success created a governance question the tool doesn’t currently answer.