Anyone can generate a working screen now. Keeping a hundred of them consistent, accessible and on-brand is the hard part. I take raw AI output and sharpen it into a real design system — tokens, components and standards — and put AI to work inside the process to get there faster.
“It runs — but it won’t scale, and it’s off-brand.”
AI gets you to a working screen in minutes. It does not give you a system. I sharpen those outputs into consistent, reusable components — and use AI inside the work to move faster, while the judgment on what is right, accessible and on-brand stays human.
The order is deliberate. AI produces working screens faster than any process can; the design work is what comes next, not what comes before.
Let AI generate quickly, then inventory what came out — every spacing, every shade, every button variant — and agree the tokens and the one true version of each component.
Rebuild the generated output against the system, with contrast, focus order and keyboard operation designed in rather than audited afterwards.
Hand over documented components in the framework your team uses, together with the rules that keep the drift from returning the week after.
We start from what AI and your team already produced. I audit the screens, surface every inconsistency — the fourteen shades of grey, the five button styles — and define the foundation underneath: design tokens, a component inventory and the patterns that repeat. AI helps extract and cluster; I decide what is right.
Then the system gets built for real: a Figma library and matching coded components, every state covered — default, hover, focus, disabled, error — responsive and accessible to WCAG. AI accelerates the boilerplate and the variants; I make sure each one is correct, tokenised and on-brand.
Finally the system goes out into the product. Screens get built from the library — by your team and by AI — and they stay consistent because they draw from one source. You get documentation, hand-off and light governance so the brand holds at ten screens or a thousand.
AI makes screens cheap. This makes them coherent. You get a design system that keeps every screen consistent, accessible and on-brand, however fast they are produced.
Project or ongoing retainer
This is for teams that can already produce screens quickly — and are paying for it in inconsistency, rework and accessibility debt.
Every generated view invents its own spacing, its own button and its own shade of the brand colour. The speed you gained comes back as cleanup.
You get tokens and components the generated output has to conform to.
Two or three teams, three interpretations of the same brand. Every new feature widens the gap, and nobody owns the difference.
You get one system all of them build from.
Developers making design decisions under time pressure, and accessibility discovered during the audit rather than during the build.
You get a documented component library with WCAG built in.
The work between a design and a working interface: turning design decisions into tokens, components and documented rules that developers build from. It is design expressed in the material the product is actually made of, rather than in a picture of it.
Start from what you already ship, not from a blank file. Inventory the existing screens, find where the same thing is done five different ways, agree on one version of each, and express it as tokens and components. A system designed before the product exists tends to describe a product nobody went on to build.
AI is fast at producing components and slow at deciding which ones should exist. It will cheerfully generate a fourth button variant rather than reuse the third. With a defined token set and human review it removes most of the repetitive work; without one it multiplies exactly the inconsistency you were trying to remove.
As components with named tokens, documented states and accessibility notes, in the framework your team already uses — I have handed over to Angular and Flutter teams. The handover says what each component is for and when not to use it, because that is what prevents the next variant from appearing.
Yes, built into the components rather than audited afterwards. Contrast, focus order, keyboard operation and labelling are decided when a component is defined, following WCAG 2.1 AA and, for public-sector work, BITV.
A free 30-minute call. No pitch, no pressure — just an honest look at your product, your system and where design engineering would pay off.