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. What's in the system against what's used in real products. The gap is the deadweight.
- Heuristic evaluation. Bloated components, inconsistent naming, missing documentation, accessibility gaps.
- Define success with the team. What does good look like for them: lightweight, extensible, 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 the system usable and intuitive.
- 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. Friendly and brief, not exhaustive reference docs.
Month three: empower and embed
Make the system stick.
- Onboarding. Short workshops or async walkthroughs showing how to use the system well.
- 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. Handover is where most freelance design-system engagements fail: the consultant leaves, the team can't maintain what was built, the system regresses. The last month invests in the team's capability, not just the artefact.
Speed and impact
- Focus on usage over theory. Practical beats perfect.
- Create before-and-after examples to show impact.
- Work in the open. Show progress where the team already talks, invite feedback early.
- Partner with one or two designers or developers as power users. They become the system's internal champions 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 contained team: a few products, dozens of designers and developers, not hundreds.
- Roughly three months of capacity, full-time or equivalent.
When it doesn't
- Greenfield builds. There's nothing to audit yet; that's a different scaffolding job.
- Enterprise-wide consolidation across competing systems. Three months is too tight for the political work.
- Engagements where I can't talk to the people who actually use the system. The interviews are non-negotiable.
Origin: Lantern, Lux 4.0, 2025. Generalised since.