This is a three-month framework for design systems that have drifted: understand and diagnose, simplify and streamline, empower and embed. One month for each of those problems.
I developed the approach while working on Lantern’s Lux 4.0. It’s a framework I’d use again when the problem fits.
Month one: understand and diagnose
Identify what’s broken and why it’s hard to use.
- Stakeholder interviews. Designers, developers and PMs. Surface the pain points and what actually gets used.
- Usage audit. Compare the system with real products. The gaps reveal unused components, duplication and missing patterns.
- System review. Bloated components, inconsistent naming, missing documentation, accessibility gaps.
- Define success with the team. What does good look like for them: lightweight, easy to adapt, accessible by default? Imposing external standards that don’t fit the context is how audits get shelved.
The principle underneath: don’t prescribe before diagnosing. Most failed design-system efforts start with someone deciding the answer before understanding the problem.
Month two: simplify and streamline
Make what’s left worth trusting.
- Prioritise core components. A minimum viable set: buttons, forms, layout primitives. Clean those up first. Don’t try to fix everything.
- Refactor the bloat. Break down overly complex components, merge redundant ones, clarify naming and structure.
- Documentation pass. Usage guidance, dos and don’ts, accessibility notes. Clear and brief, without trying to cover everything.
Month three: empower and embed
Make the system stick.
- Onboarding. Short workshops, plus recorded walkthroughs people can come back to.
- Templates and examples. Common layouts and Figma templates people can copy and build from.
- Handover and roadmap. A short-term roadmap and a how-to-maintain-it checklist that the team owns.
The third month is the point of the whole framework. Many design-system projects fail at handover: the consultant leaves, the team can’t maintain what was built, and the system drifts again. The last month invests in the team’s capability, not just the system.
How I work
- Focus on usage over theory. Practical beats perfect.
- Create before-and-after examples. Show the impact rather than just describing it.
- Work in the open. Show progress and encourage early feedback.
- Build internal capability. Partner with one or two designers or developers who can carry the system forward after I’ve gone.
When this fits
- You already have a design system and it’s struggling: drift, bloat, low adoption, accessibility debt.
- There’s appetite for change but the scope is unclear.
- A few products and a team small enough to move quickly.
- Roughly three months of capacity, full-time or equivalent.
When it doesn’t
- Starting from scratch. There’s nothing to audit yet. That’s a different kind of project.
- Enterprise-wide consolidation. Competing systems and stakeholders need more than three months to untangle.
- No access to the people who use the system. If I can’t talk to them, the audit loses most of its value.
If you think the framework sounds like it could be useful, take it and make it your own.