Skill Maps

What is a design system

A design system is a shared set of standards, artifacts, and processes that connects design and engineering. The goal is simple: interfaces look and behave predictably, and the team spends less time reinventing buttons, forms, and patterns.

It is not “a Figma folder of components” and not “an npm package of buttons.” A full system brings together visual language, code, documentation, and rules for how the system evolves.

What a design system is made of

  1. Design Tokens — atomic values: colors, typography, spacing, radii, shadows, motion.
  2. Components — reusable UI building blocks with a clear API (Button, Input, Modal).
  3. Patterns — recurring scenarios: forms, navigation, empty states, confirmations.
  4. Documentation — living guidelines: when to use, which variants, accessibility constraints.
  5. Governance — who decides, how components are added, how versions ship and roll out.

Without tokens, the system drifts into “similar but different” styles. Without docs, components get misused. Without governance, the library goes stale within a quarter.

Examples of mature systems

Material Design (Google)

A shared language for Android, Web, and cross-platform products. Strengths: motion, depth, responsiveness, detailed guidelines.

Human Interface Guidelines (Apple)

The standard for Apple’s ecosystem. Focus on gestures, native ergonomics, and restraint. Important: HIG is more of a brand and platform guide than an npm library.

Carbon Design System (IBM)

An enterprise-oriented system with a strong focus on data visualization and accessibility. A solid reference if you ship dense tables, forms, and internal tools.

Ant Design (Alibaba)

A rich set of enterprise components and patterns. Popular for dense interfaces and many CRUD screens.

When you study other design systems, look beyond buttons: tokens, semantics, accessibility, documentation structure, and contribution process.

When you need a system — and when it is overkill

Signals it is time to build a DS:

  • the same elements look different across screens;
  • buttons and inputs are copied “with a small tweak”;
  • every new screen starts almost from scratch;
  • designers and engineers argue about the “correct” blue;
  • the number of products or teams is growing;
  • the brand frays across apps.

When a full DS can be excessive:

  • a team of 1–2 people and one small product;
  • you are building an MVP/prototype on a short horizon;
  • you lack capacity to maintain a library;
  • the product has not yet stabilized its UI language.
Important

A design system is an investment. If the team cannot maintain it, start with a light component library and a short style guide rather than promising an “enterprise platform” and abandoning it a month later.

System types: from library to brand platform

1. Component Library

Focus on reusable components. Examples: Bootstrap, Material UI. Good for a fast start and small teams.

2. Full Design System

Tokens + components + patterns + documentation. Examples: Carbon, Ant Design. Fits mid-size and large teams with multiple products.

3. Brand / Design Platform

A full ecosystem: tools, guidelines, governance, sometimes internal platforms. Examples: Salesforce Lightning, Shopify Polaris. For large organizations.

Practical takeaway for this course: we aim for a full design system at the “tokens + components + Storybook” level — not a giant enterprise platform on day one.

Maturity evolution

Chaos → Style Guide → Pattern Library → Design System → Design Platform

Most teams get stuck between style guide and pattern library: Figma looks polished, code is chaos. A design system closes that gap with living code and shared tokens.

Practical mini-checklist before you start

Answer honestly for your product:

  1. How many screens and teams already diverge in UI?
  2. Are buttons/forms being reinvented repeatedly?
  3. Who will own the system after launch?
  4. Are you ready to maintain documentation for at least one release cycle?

If questions 3–4 have no answer, start with a component library and a short style guide — that is a valid maturity stage, not a failure.

Takeaways

  • A DS is standards + artifacts + processes, not only a UI kit.
  • Key layers: tokens, components, patterns, docs, governance.
  • Compare Material, HIG, Carbon, and Ant by goals, not by “looks.”
  • First decide: do you need a full DS, a library, or just a style guide right now.
  • Next in the course: audit the current project — not jump straight into component code.