05 · What I do
Token architecture, component contracts, and the six weeks after handover.
One page, read two ways, and the page is this one. On the left is the top of what you are reading, rendered normally. On the right is what it is actually made of: an 8pt grid, a named step behind every gap, and a class you could go and look up.
A design system is not a look. It is a finite vocabulary and the rules for combining it, and the only honest demonstration is a page built out of the thing it describes. Every label on the right names a real class in the stylesheet this page is running.
Home / Services / Design systems
05 · What I do
Token architecture, component contracts, and the six weeks after handover.A design system is the shared kit a product is built from: the buttons, the spacing, the type, the colours, and the written rules for using them. One set, used by every team, so six teams do not build six slightly different buttons and then argue about which is correct.
Tokens are the named values underneath it. A colour is called accent rather than #2f6b60, so changing what accent points at reaches every screen at once, and the same components can carry a different brand without being rebuilt.
The first question, and it is not about components
Which model are you hiring for? They are three different jobs.
A brief that says "design system" without saying this is a brief nobody can quote against. The failure modes are completely different, and so is the person you need.
One team owns it, everyone else consumes. Consistent, and it becomes a bottleneck: the queue for a new component is measured in sprints and teams start forking quietly.
The job here is throughput and saying no well.
A core team owns the foundations, product teams contribute upward. Scales better and lives or dies on governance: without a contribution route and a decision-maker it degrades into a shared folder within a year.
The job is the contract between core and consumers.
The same components have to be correct under someone else's identity. Nothing may be hard-coded and every colour pair has to stay legible whatever brand is applied, which makes contrast a runtime property rather than a design-time check.
The architecture underneath
Three layers, and skipping the middle one is why systems rot.
A palette is not a design system. The layer that makes it maintainable is the one nobody enjoys naming: what a value is for, rather than what it is.
Every swatch above is read from the running stylesheet, not typed into this page. If a token were renamed, this demonstration would break rather than quietly lie, which is the same property a component library needs.
What the work looks like day to day
Nine things a library needs before anyone else can use it.
If your spec lists requirements, these are probably them. The picture is the easy half; almost none of this is drawing.
Three emphases against three sizes. Nine cells, not the twenty-seven a full property matrix would generate, because a library that offers every combination has pushed the decision back onto whoever is drawing the screen.
Detaching is the beginning of drift, and it is nearly always caused by a missing slot rather than by a designer being careless. The same card takes a button, a status chip, or nothing at all, and stays one component.
More than a drawing
A component is an agreement, and most of it is not visual.
Written so an engineer implements it once and nobody reopens the question.
- Variants and sizes, named, with the reason each one exists
- Every state: default, hover, focus, active, disabled, loading, error, empty
- Which properties a consumer may override, and which are closed
- What it does with content longer than the design assumed
Built in rather than audited at the end and argued about in a spreadsheet.
- Contrast checked at the token pair, so no failing combination can be assembled
- A designed focus state, not the browser default nobody looked at
- Target size, keyboard order and role specified alongside the visuals
- Reduced-motion handled at the component, not as a global afterthought
The most-read part of any component page, and usually the missing one.
- What it is for, in one sentence
- The neighbouring component people confuse it with, and how to choose
- Do and do not, with a real example of each rather than a principle
How it stays alive after the person who built it has gone.
- How a team proposes a change, and who decides
- Versioning and deprecation, so a rename does not silently break four products
- A route for the exception, because a system with no escape hatch gets forked
Default and hover get designed. Focus, disabled, loading and error are the ones that reach production undesigned, and they are the four a user meets on the worst day they will have with your product.
These ratios are calculated as the page renders, from the same tokens the site uses. A colour is never accessible on its own, only a pair is, which is why the check belongs on the semantic mapping rather than in a palette review.
How you know it is working
Component count is a vanity number. These are not.
"We have 84 components" tells you nothing about whether anyone uses them. Every measure below is about adoption or about drift, because those are the two ways a system dies.
Checkout is the finding, not Onboarding. A product sitting at 41% coverage with 60 detached instances is not ignoring the system, it is telling you the system does not answer its questions. That backlog is where the next three components come from.
The six weeks after handover
Where design actually fails, and the reason the studio exists.
Almost never in the design. It fails when the thing gets built by people who were not in the room, against constraints nobody drew.
In the tool your team already uses, not a PDF of a design file.
- Tokens named as they will appear in code, so nothing needs translating
- Behaviour written down, including failure and slow networks
- The states that actually occur in production: empty, partial, too much, wrong
On the real thing, at real widths, against the specification rather than the mockup.
- Reviewed at the breakpoints the product is genuinely used at
- The spec changes when the constraint turns out to be real, rather than the build being wrong
- Findings raised as issues in your tracker, not comments on a design file
What I have not done, so the rest of this page is worth trusting.
I have not run a central design system for a large organisation. At Ericsson I was on the consuming side of one owned in Sweden, which taught me the contract from the direction most people never see it from, but it is not the same as owning the queue.
Where my depth is: token architecture, multi-brand theming, component contracts, accessibility built into the component, and the delivery half nobody staffs. If you are hiring somebody to run a fifty-person federation I would say so on the first call. If you are hiring somebody to build the system, or to fix one that has quietly become a folder, that is exactly the work.
Where this has actually happened
A central team in Sweden, a white-label platform, three products of my own.
Owned by a team in Sweden, with my product as one of its consumers. That is the normal enterprise situation and it is a negotiation, not a download: what the system already answers, what it does not, and what goes back upstream.
The hardest version of the problem. Nothing hard-coded, and contrast had to hold for brands nobody had seen yet, which makes legibility a property the system enforces rather than a check a designer performs.
Routina, ParrotB and Saveri each keep their own token file as the source of truth, and the mockups on this site are drawn from those real values rather than from an impression of them.
The other five