I design against a token set and component rules rather than screen by screen. That’s what makes the hundredth screen look like the first, and what lets generated code come back on-brand instead of off-piste.
Screens are inconsistent because each was designed on its own. The product looks dated next to competitors. Engineering rebuilds similar components repeatedly because nothing is defined. Or AI-generated code keeps coming back off-brand, because there's nothing for it to be on-brand against.
I design against a token set and component rules rather than screen by screen. That's what makes the hundredth screen look like the first.
Layout comes from a grid with a stated module, so spacing decisions stop being individually negotiated. Type follows a scale with a defined measure. Colour comes from a small set of tokens with defined jobs, not from picking what looks right in the moment.
The constraint is the point. A system with fewer options produces more consistent work and makes the decisions that remain more considered.
I also write the rules where the build can read them, which is what lets generated code come back on-brand instead of off-piste. This site runs on exactly that, and the rules file is published.
Varies with surface area. Usually a focused block of three to six weeks, then lighter ongoing support as the team builds against the system.
Do you work in our existing design system?
Yes, and I'd rather extend one than replace it. Replacing a system is expensive and rarely the actual problem.
Can you hand off to engineers?
Handoff as a separate stage has largely gone. I work in the same repo where I can, and write specs only for what code can't express.
What about accessibility?
Contrast and hierarchy are built in as a matter of course. Formal WCAG auditing isn't something I offer.