Design systems that survive their designers
The saddest artefact in our industry is the beautiful design system nobody uses. Four hundred meticulously named components, a token architecture of genuine elegance, and six months later, the client's team is hard-coding hex values again.
Systems don't fail because they're badly designed. They fail because they're designed for their authors instead of their inheritors.
Design for the person who wasn't in the meeting
The test of every component we ship: can a developer who joined last Tuesday, who never met us, compose a correct page with it? That means defaults that are right 90% of the time, names that describe purpose rather than appearance, and guardrails that make the wrong thing harder than the right thing.
- Ship the system as code, not just canvases, coded components are the source of truth.
- Write documentation as recipes ('build a pricing page') rather than API dumps.
- Record a 20-minute walkthrough video. It outlives every meeting.
- Schedule a 90-day check-in and budget for it up front.
A design system is judged by the quality of pages built by people who never met its designers.
The goal is a client team that can build dozens of pages without opening a support ticket. That matters more than any component count.
