Engagement 02 · The products need a system
Design System Foundation
The shared foundation for a growing product family, and the operating rules that keep it shared.
- The situation
- Four teams, four versions of the same table
- The team
- You and me, working with your product teams
- You leave with
- The shared foundation, in use, with rules
The situation
The suite grew a product at a time, and it shows. Four teams have built the same table four ways, nobody is sure which one is correct, and every new screen restarts an argument that was settled somewhere else last year.
Seen at enterprise scale: Making 40+ enterprise apps feel like one product.
How it works, step by step
Four steps, in order, each one something you can check off.
-
Inventory what already exists
Every component, in every product, including the four versions of the same one. This is unglamorous and it is the whole basis of the work: you cannot decide what should be shared until you can see what has already been built twice.
-
Decide what is shared and what stays local
Not everything belongs in a system. Over-sharing produces a foundation that every team fights, and the components that get fought become the components that get forked.
-
Build the foundation
The shared components, the patterns that use them, and the tokens underneath. Built to be used by the teams you actually have, not by an idealised team that reads documentation before starting.
From the SAP system: one dashboard, every part of it a shared component. -
Set the operating rules
Who can change what, how a team proposes an addition, how a change ships without breaking four products. A system without governance is a folder of components that slowly diverges again.
What you leave with
- The shared component set, in use
- The patterns and principles, written down
- Tokens as the single source of truth
- Contribution rules the teams agreed to
Working with one person
You talk to the person doing the work
No account layer, no juniors briefed second-hand, no rewriting of what you said before it reaches the designer. You explain the problem once, to the person who solves it.
The attention is undivided and it is finite
A one-person practice runs few engagements at once. That is the point: yours gets the whole of the attention. It is also the constraint, so start the conversation earlier than you need to.
Where this is not the right fit
You have one product, one team, and no scaling problem. A system is overhead until the coordination cost is real, and paying it early buys you nothing.
Shape, scope, and cost
Scoped to the problem in front of it, so length and price come out of a first conversation rather than a menu. That conversation is free and short. If the problem is still taking shape, we start with a smaller piece that produces clarity.
Is this the one?
Tell me what is happening with your product. If a different engagement fits better, or none of them do, I will say so.
Start a conversation