Three Design Org Patterns by Stage
When production was the constraint, headcount scaled with surface area. More screens meant more designers, and the ratio conversation was about capacity.
The template
Three Design Org Patterns by Stage
Ratios, roles, and what a design organization looks like when generation is free. Three patterns, the tripwires that tell you to move to the next one, and the two roles that change the most. Pick the pattern that matches your stage, not the one that matches your ambition.
What changed about org design
When production was the constraint, headcount scaled with surface area. More screens meant more designers, and the ratio conversation was about capacity.
Production is no longer the constraint, so the ratio conversation is about decision coverage: how many independent product decisions can one person hold judgment over, and how much of that judgment has been written down so it operates without them.
That second half is why a team with good rubrics and constraints covers more surface than a larger team without them. Written judgment is the multiplier, not headcount.
Pattern A: The embedded pair (early stage)
Shape. One or two designers, embedded in product teams, no design management layer, no systems team.
Ratios. One designer across two to three product surfaces. The ratio to engineers matters less than the ratio to decision streams.
What they own. Everything. Constraints, ranges, rubrics, wrong paths, and the craft. In practice they will underinvest in the rubric because everything is urgent, and that is the specific trap of this stage.
The move that pays. Write the constraint set for the two highest-traffic surfaces even though it feels premature. At this size the founder or the first PM is generating half the interface anyway, and constraints are the only thing that makes that survivable.
Tripwire to Pattern B: the same quality argument happens three times in a month with three different people. That is not a people problem, that is the signal that judgment needs to be written down rather than re-litigated.
Pattern B: The spine (growth stage)
Shape. Designers embedded in teams, plus a small central function, two or three people, owning the rules rather than the components.
Ratios. One designer per product team. One central person per five to eight embedded designers.
The central function owns:
- The constraint layer and its enforcement.
- The rubrics, their versioning, and the calibration cadence.
- The primitives, which is a much smaller set than a traditional design system.
- The evidence register.
The central function does not own: approval. The moment the central team becomes an approval gate, embedded designers route around it and the rules decay.
The move that pays. A standing calibration slot across all embedded designers. Thirty minutes, everyone scores the same five outputs, disagreements discussed. This is the single practice that keeps quality consistent across teams without a review bottleneck.
Tripwire to Pattern C: two teams ship contradictory behavior on the same class of problem, and neither is wrong by their own team's rules. That is a system-level gap and it does not get fixed at team level.
Pattern C: The federated practice (scale)
Shape. Design distributed across many teams, a real central practice, and design leadership with a seat where product bets get made.
Ratios. Ratios stop being the useful measure. Track instead:
- Percentage of surfaces with a current constraint set.
- Percentage with a calibrated rubric.
- Time from a quality complaint to a rubric change.
Those three numbers describe a design organization's health far better than headcount ratios, and they are hard to game.
What is centralized: the rules, the calibration, the evidence, the research cadence, the primitives, and the standards for the wrong path.
What is federated: every product decision.
The move that pays. A cross-team failure inventory, quarterly. The failures that cross team boundaries are the ones nobody owns, and they are where a large product's quality actually erodes.
The two roles that change most
The design engineer
Not a bridge role and not a designer who codes a bit. This is the person who turns constraints into things that execute: checks in the pipeline, components that cannot be assembled wrongly, evals that score interface quality.
Where they sit: with the central function, working with teams. Reporting into design rather than engineering, because their output is enforcement of design decisions and that reporting line determines whose priorities they serve on a busy week.
One of these is worth more than two more embedded designers at Pattern B, and most orgs hire the two designers.
The design systems team
Becomes the design rules team. Their output shifts from components to constraints, checks, and primitives. Same people, mostly, and a real identity shift that takes a quarter and deserves to be named out loud rather than announced as a rename.
The trap: keeping the component catalogue growing alongside the new work, because the catalogue is what the team is known for. Something has to be actively retired, or the team is doing two jobs and the new one loses.
Choosing your pattern
| Question | If yes |
|---|---|
| Are quality arguments repeating with different people? | Move to B |
| Are two teams solving the same class of problem differently? | Move to C |
| Is your central team approving work rather than writing rules? | Fix before scaling |
| Can you say what percentage of surfaces have a current constraint set? | You are running B or C properly |
| Are you adding designers to cover surfaces? | Check whether written judgment would cover them instead |
The one thing to do this week
Count two numbers: how many surfaces your product has, and how many have a written constraint set. The gap between those numbers is your actual coverage problem, and it is usually solved with writing rather than hiring.
From "Team Shape", chapter 23 of The Design Operating Model. falkster.com/design/team-shape