When does a UI kit need to become a design system?
A polished button library is not automatically a system. Across Corevia’s Operations Console, Fleet Manager portal, Driver, and Customer apps, the challenge is to preserve meaning, states, and reuse rules as the surface changes.
A UI kit lists parts; a system defines their use
Corevia’s foundations include navy #0D2B5E, teal #00B2A9, IBM Plex Sans/Condensed/Mono, and a 4px spacing rhythm. Those values alone do not say why a blocked assignment must stand out in Dispatch but become an expectation in the Customer App.
I organised Global tokens as source values and Alias tokens as roles in the UI. Components then use semantic roles instead of copied colour codes. This is a maintenance approach; no time-saving metric has been measured.
A library is only useful when screens use it
During Figma review, recurring problems included lookalike buttons and status labels not using component instances, missing Auto Layout, text without text styles, and icons not linked to the MingCute/component source. A list template can look consistent while breaking when content or states change.
My approach is to inventory repeated patterns, build purposeful variants, replace lookalikes with instances, apply type and icon rules, and review short/long content, empty/error states, and responsive layouts. The component is a contract only if the team uses it.
Handoff joins product logic to implementation
Developers need permissions, required data, loading/empty/error states, responsive thresholds, failure paths, and acceptance criteria—not just padding. Design QA checks whether built screens preserve the logic, not only the pixels.
Operations needs exception signals; Fleet Manager needs readiness; Driver records milestones; Customer follows booking. A mismatched status meaning across these surfaces is a product issue, even if all four badges use the same teal.
- Foundation: type, colours, and spacing.
- Global → Alias: values to semantic roles.
- Components: variants, states, and reuse rules.
- Real screens + handoff: roles, edge cases, and Design QA.
Know when to make the transition
A single concept screen may only need a lean UI kit. When patterns span surfaces, teams edit and build in parallel, one state change affects many screens, or handoff exceptions go undocumented, a lightweight governed system becomes valuable.
Start with components used in real screens and expand as needed. A huge library nobody maintains is merely a museum of buttons.
A system is not defined by its token count. It carries the same design decision across different screens without losing meaning.Explore Corevia’s four surfaces