← Go Back

Component Libraries

What is a component library?

A component library is a collection of reusable, implemented UI components (buttons, inputs, cards, navigation, etc.) that developers use to build interfaces. It’s the code counterpart of a design system: the same components and patterns, built so they’re consistent, accessible, and fast to use. Components usually include props, variants, and documentation.

Use it when: you have (or want) a design system and need developers to ship UI that matches it without rebuilding from scratch. A library speeds build and keeps accessibility and behaviour consistent.

Copy/paste checklist (minimum library)

  • [ ] Core components – Button, link, text input, checkbox, radio, select (or dropdown), label; at least one layout primitive (e.g. stack, grid).
  • [ ] Documented – Props, variants, and when to use each; link to design system or design standards.
  • [ ] Accessible – Keyboard, focus, ARIA where needed; colour contrast and WCAG considered.
  • [ ] Consistent API – Naming and props follow a pattern (e.g. size, variant, disabled); same approach across components.
  • [ ] Versioned – So products can adopt and upgrade; changelog for breaking changes.

Why component libraries matter

  • Consistency – Same look and behaviour across products and teams.
  • Speed – Reuse instead of rebuilding; focus on product logic, not button variants.
  • Quality – Components are tested once (including accessibility) and improved for everyone.
  • Alignment with design – Design system and library stay in sync so design and code match.

What a good component library includes

Checklist

  • [ ] Design-system aligned – Implements the design system (tokens, components, patterns); design and code don’t drift.
  • [ ] Accessible by default – Keyboard, focus, ARIA where needed; WCAG AA where applicable.
  • [ ] Documented – Usage, props, examples, and “do/don’t”; accessibility notes.
  • [ ] Tested – Unit and/or integration tests; optional accessibility tests (e.g. axe).
  • [ ] Maintained – Owner or team; process for contributions and releases; versioning and changelog.
  • [ ] Used – Adopted by product teams; feedback loop so the library improves.

Common formats

  • Framework-specific: React, Vue, Angular, etc. Use when your stack is fixed.
  • Web components: Framework-agnostic; use when you need to share across stacks.
  • Storybook (or similar): Isolated examples and docs; use for development and documentation.
  • Design + code: Figma (or similar) components and code components owned together so they stay in sync.

Examples

Example (the realistic one)

Library: “UI Kit v1.” Components: Button (primary, secondary, danger; small, medium, large), TextInput, Checkbox, Select, Card, Stack, Grid. Docs: Storybook with props table, examples, and “When to use.” Accessibility: Buttons and inputs are keyboard accessible and focusable; Select uses ARIA pattern; colours meet contrast. Process: Design system tokens in code; components consume them. One team owns the library; product teams depend on it and log issues. You add components when the design system adds patterns.

Common pitfalls

  • Design and code out of sync: Figma has one button set, code has another. → Do this instead: Single source of truth (tokens, specs); design and dev review changes together.
  • No accessibility: Components aren’t keyboard friendly or don’t use ARIA for custom widgets. → Do this instead: Build accessibility into every component; document it.
  • No documentation: Developers don’t know when to use which variant or which props. → Do this instead: Document usage, props, and examples; link to design system or design standards.
  • Nobody maintains it: Library drifts and teams fork or stop using it. → Do this instead: Assign ownership; version and release; take feedback and iterate.
  • Too many components too soon: Huge first release that’s hard to maintain. → Do this instead: Start with 5–10 core components; grow based on real use.
  • Component library vs design system: Design system is the full set (tokens, guidelines, patterns); the component library is the implemented, coded part of it.
  • Component library vs pattern library: A pattern library can be design-only (Figma, docs); a component library is the code. They often go together.
  • Component library vs atomic design: Atomic design is a way to structure components (atoms, molecules, organisms); a component library is the deliverable. You can structure the library using atomic levels.

Next step

If you don’t have a library, start with 3–5 components (e.g. Button, TextInput, Card) and document them in Storybook with props and accessibility notes. If you have one, audit one component for keyboard and ARIA and add the result to the docs. Align with your design system so design and code stay in sync.

Related Terms