Four environments
A month in, I put the plan on the table: four repositories, ordered so each one pays for itself before the next begins. I have watched design system programmes die for want of that ordering.
Posted the plan today. Four environments, in order:
- A design tokens repository.
- Making the legacy product look new, using those tokens.
- A decoupled component library, versioned and published as packages.
- A next-generation boilerplate repository.
The order is the part I will defend hardest, and it comes from having watched this go wrong elsewhere. Design system programmes do not usually fail on craft. They fail because they are a two-year argument with no deliverable in month two, and somewhere around month seven the people funding it quietly stop believing.
So each step has to be useful to somebody on its own. One is small and immediately useful. Two puts a visible change in front of real customers quickly, reusing the work from one. Three is what lets other teams build without waiting on my team, which is the point at which a design system stops being a service desk.
Four is the one I actually want. Its specification: decoupled from the backend, testable accessible layouts and patterns, mock data instead of a real API, and something a person can install locally and run without IIS, without .NET framework, without any of it.
That last line is September's constraint, written as a deliverable.
My argument in the thread was blunt — if we do not decouple the presentation layer, we cannot lift off. What I have learned to attach to that kind of statement is the smaller version: here is what ships first, here is who it helps, here is how we will know within weeks whether it worked. An architecture argument on its own moves nobody. An architecture argument with a delivery in thirty days moves everybody.
Tokens first, and we will know inside a month.
Where this goes: by the end of next year I want a product engineer to be able to build a correct, accessible, on-brand screen without talking to a designer first — not because designers are a bottleneck to be removed, but because the team's taste should be in the materials rather than in a review queue. That is what a design system is for. Everything above is scaffolding to get there.