Nobody Has Time to Build a Complete Design System. That Was Never the Real Problem.
Across the small, early-stage product teams I've designed for, I keep running into some version of the same design system: colors, type, a handful of components, built exactly as fast as someone needed them at the time. Accessibility states were an afterthought everywhere. Nobody had time to do more, and I don't think that's actually the problem.
The real problem is whether the person building the system was thinking about anyone besides themselves in the moment they built it: the next designer who inherits it, the engineer who has to implement against it, the version of the product that exists after they've moved on.
Here's what that looks like in practice. I inherited a button component on one team where the icon was baked in as a flat, fixed image instead of a swappable slot. Every time a screen needed a different icon, the whole button had to be detached from its source and rebuilt by hand, instead of just swapped in place. Multiply that across a growing product and it adds up to real time, spent quietly, off anyone's radar.
None of this shows up in a roadmap review, not right away. It shows up later: as a new hire who takes twice as long to ramp up because the system fights them at every turn, a timeline that slips for reasons nobody can quite name, or a rebuild that becomes unavoidable once enough of these shortcuts stack up. By the time it's visible enough for a manager to notice, it's already the expensive version of the problem. An engineer implementing against the spec might not trace the slowdown back to this. A user definitely wouldn't. The only person who feels it immediately is another designer working inside the system every day, absorbing the cost quietly long before it becomes something anyone else has to explain.
That's the actual test I'd apply to any design system, complete or not: not how many components it has, but whether I could hand it to someone else tomorrow and have them build on it without quietly fixing it first.
Speed and structure aren't actually in tension. A system built fast can still be built with enough foresight that the next person isn't paying for the shortcuts later. That's not extra work bolted onto shipping quickly. It's the same job, done with slightly more imagination for who comes after you.
Across the small, early-stage product teams I've designed for, I keep running into some version of the same design system: colors, type, a handful of components, built exactly as fast as someone needed them at the time. Accessibility states were an afterthought everywhere. Nobody had time to do more, and I don't think that's actually the problem.
The real problem is whether the person building the system was thinking about anyone besides themselves in the moment they built it: the next designer who inherits it, the engineer who has to implement against it, the version of the product that exists after they've moved on.
Here's what that looks like in practice. I inherited a button component on one team where the icon was baked in as a flat, fixed image instead of a swappable slot. Every time a screen needed a different icon, the whole button had to be detached from its source and rebuilt by hand, instead of just swapped in place. Multiply that across a growing product and it adds up to real time, spent quietly, off anyone's radar.
None of this shows up in a roadmap review, not right away. It shows up later: as a new hire who takes twice as long to ramp up because the system fights them at every turn, a timeline that slips for reasons nobody can quite name, or a rebuild that becomes unavoidable once enough of these shortcuts stack up. By the time it's visible enough for a manager to notice, it's already the expensive version of the problem. An engineer implementing against the spec might not trace the slowdown back to this. A user definitely wouldn't. The only person who feels it immediately is another designer working inside the system every day, absorbing the cost quietly long before it becomes something anyone else has to explain.
That's the actual test I'd apply to any design system, complete or not: not how many components it has, but whether I could hand it to someone else tomorrow and have them build on it without quietly fixing it first.
Speed and structure aren't actually in tension. A system built fast can still be built with enough foresight that the next person isn't paying for the shortcuts later. That's not extra work bolted onto shipping quickly. It's the same job, done with slightly more imagination for who comes after you.
