What’s the minimal design system you ship first (colors, type, spacing, buttons, inputs) and how do you keep it consistent?

My usual design system consists of

1. Setting up Figma colour variables

5 core groups (background, border, icon, text)
example: background-error-light, text-heading-primary

2. Setting up typography styles
(H1, H2, H3....p, caption, label, etc.) - across a variety of font weights

3. Define what iconography set will be used

4. Setup components - created as component sets (with different options of variables such as "button-primary" or "button-outline" with icon or without etc.

Components I usually do are: Buttons, Input fields, Text area, Checkbox, Radio button, Toggle, Navigation block and tooltips. Other components are updated/added during the project progress

Minimal Design System We Ship First — and How We Keep It Consistent

(Experience from E-Sutra — https://e-sutra.com)

1) What We Ship First (Starter Set)

We start small and opinionated to avoid over-designing.

Foundations (must-have):

• Colors:

  • Brand primary (1)

  • Neutrals (text, background, border)

  • Semantic colors (success, warning, error)

• Typography:

  • 1 font family

  • 3–4 text styles (body, heading, caption, button)

• Spacing:

  • Single scale (e.g., 4 or 8 based)

  • Used everywhere for padding, margins, gaps

• Buttons:

  • Primary, secondary

  • States: default, hover, disabled, loading

• Inputs:

  • Text input, select

  • States: default, focus, error, disabled

Why this first:
These cover ~80% of UI needs and unblock teams fast.

2) Tokens & Naming Approach

We use design tokens, not raw values.

Examples:

• color.primary.main

• space.2 / space.4 / space.8

• font.size.body

• radius.sm

Rules:

• No hex codes or pixel values in components

• Only tokens are allowed

This keeps design and code aligned.

3) Where It Lives

• Design: Figma shared library (foundations + components)

• Code: Token file (JSON or similar) consumed by UI components

• Source of truth: Tokens, not screenshots

Design and engineering update tokens together.

4) Usage Rules We Document

Short and practical docs:

• When to use primary vs secondary buttons

• Which text style is allowed per component

• Spacing rules (no custom spacing)

• Accessibility basics (contrast, focus states)

Docs are lightweight and live next to the system.

5) How We Prevent Drift

This is critical.

Process controls we use:

• Design reviews check token usage

• PR checks block hard-coded values

• Component-only reuse (no custom UI per screen)

• Versioned updates to the design system

• Clear ownership for approving changes

If it’s not in the system, it doesn’t ship.

6) What We Add Later (Not Day One)

• Advanced components

• Motion rules

• Theming

• Data-heavy patterns

These come after real usage proves the need.

Key Principle

Start minimal, enforce strictly, evolve slowly.

This approach has helped us at E-Sutra maintain consistency across teams, products, and audits while shipping fast and safely.

Happy to share more examples if useful.