Governance and ownership

Choose the system namespace

For icare, the namespace is simply icare-: the stable ownership prefix placed before names exported by the design system. Everything after it belongs to a separate token or class naming convention. For example, in icare-colour-background-primary, the namespace is icare- and the token name is colour-background-primary.

The prefix gives designers and engineers a quick ownership signal and reduces collisions with Bootstrap, product-specific CSS and older local patterns. It should remain short and stable even when the token taxonomy, component API or implementation changes.

Apply the same boundary to CSS classes. In .icare-button--primary, the full stop is CSS selector syntax, icare- is the namespace, and button--primary follows the class naming convention. The namespace does not describe the component, property, variant or state.

Name an owner, not a committee

One named person should be accountable for the health of the design system. In practice this is often the lead designer or design system designer, working closely with engineering. The designer protects intent, usability and Figma quality; engineering protects implementation quality, accessibility, performance and release discipline.

A working group can advise, review and help prioritise, but it should not become the place where every component waits for approval. Ownership should make contribution easier, not slower.

Split decision rights clearly

A mature system makes an important distinction: design and code are different environments with different responsibilities. Figma can hold explorations, extra ramps and future themes, while production code should expose only reviewed and supported decisions. icare should name which environment is authoritative for each part of the system and how differences are reconciled.

Lesson learned

Declare production the source of truth

A practical model treats production SCSS tokens as the source of truth while allowing Figma to remain a deliberate superset for brand exploration. A read-only drift check can report disagreements without silently rewriting either side. Experimentation stays possible, but the boundary between an idea and a supported system decision remains visible.

The designer does not need to become an engineer, but should understand how tokens, CSS inheritance and component APIs work. Equally, engineering needs enough design context to protect intent rather than simply reproduce a screenshot. That collaboration is part of governance, not an optional handoff activity.

Use atomic design as the governance model

Brad Frost's atomic design approach is useful because it gives teams a practical language for scale. Atoms are the smallest reusable decisions, molecules combine those decisions into simple controls, organisms compose larger interface sections, templates define page structure, and pages show the system in real product contexts.

This matters for governance because every layer has a different review question. An atom asks whether the foundation is correct. A molecule asks whether the component behaviour is reusable. An organism asks whether a pattern should be shared. A page asks whether the system still works in the messiness of actual product work.

Make contribution a visible lifecycle

A contribution process should show where an idea sits, who decides next and what evidence is required. This prevents Figma experiments, local product fixes and production-ready system changes from being mistaken for one another.

Plan the build-up deliberately

The system should grow in planned releases rather than by collecting whatever each project happens to need. Start with foundations and high-use components, then add patterns where several teams repeat the same layout or interaction. Each release should include Figma assets, code, usage guidance and a migration note.

Fund the long-term maintenance

Maintenance, migration support and documentation are the work, not the overhead around it. Budget recurring capacity for dependency updates, accessibility checks, token changes, Figma library cleanup, contribution review and product-team support. A useful rule of thumb is to reserve roughly a third of system capacity for maintenance and adoption, then show that work on the roadmap by name.