A design system a small team can actually maintain
Design systems fail when they are built as a product rather than as a tool. A small team needs maybe forty decisions documented, not four hundred components.
Start with tokens
Colour, type scale, spacing, radius and elevation. Defining these once removes most of the inconsistency that makes interfaces feel improvised, and it makes redesigns a configuration change rather than a rewrite.
Four states, not four variants
Every interactive component needs default, hover, focus and disabled. Missing focus states are both an accessibility failure and the most common sign of an unfinished system.
Documentation in the repo
Keep usage notes next to the components, with the reason a component exists and when not to use it. Documentation that lives in a separate tool drifts within a quarter.
Common questions
- Do we need a component library tool?
- Not initially. A folder of components with clear names and states covers most teams until several products share the system.
- How do we stop components drifting?
- Review new components against existing ones before building, and delete duplicates rather than deprecating them politely.
Next step
If this question is live in your business right now, describe the situation and you will get a written view on the options, including whether you should build at all.
Discuss your projectRelated notes
All insightsCustom software or off-the-shelf: how to decide
A practical framework for choosing between configuring an existing product and commissioning custom software, based on where your process actually differs.
ReadAI and automationPractical AI automation, and where it should stop
Where language models genuinely reduce work in a business workflow, where deterministic code is cheaper and safer, and how to tell the difference.
ReadWebsitesCore Web Vitals: what actually moves the needle
A prioritised list of fixes for LCP, CLS and INP on business websites, ordered by how much each one typically gains per hour of work.
Read