Lantern Design System

Introduction

Lantern had four teams building the same components slightly differently. The audit found nine card variants and eleven shades of the same grey.

Auditing Four Codebases

The audit covered what was in production, not what was in the design files. Those two had drifted far enough apart that starting from the files would have produced a library nobody was actually using.

Deriving the Library From What Shipped

We derived the library from what was already shipping rather than designing an ideal set, which meant adoption cost teams almost nothing.

• Where two teams had built the same component, the more accessible implementation won.
• Variants that only one team used stayed local until a second team needed them.
• Tokens were named for their role, so a palette change does not mean renaming anything.

Governing the Additions

The part that mattered most was the contribution model: a documented path for adding to the system, so teams extend it instead of routing around it.

• Any team can propose a component; the review is on the interface, not on taste.
• Additions ship behind their originating team first and are promoted once a second team adopts them.
• Deprecations carry a migration note, so removing something is as documented as adding it.

Conclusion

Nine card variants became two, the greys became four tokens, and — more usefully — the additions since handover have all come through the contribution path rather than around it.