Design system for SaaS website: tokens, components, scale

A design system for a SaaS website is a structured set of tokens, reusable components, and usage guidelines that enables product and marketing teams to build new pages and features consistently — without redesigning the same button or card every sprint. For SaaS companies growing beyond five to ten engineers, a design system is not a luxury; it is the infrastructure that prevents visual and functional debt from accumulating faster than teams can pay it down.

What a design system is and why SaaS teams need one

A design system is not a component library alone. It is the combination of three layers: design tokens (the raw values — colors, spacing, typography, border radii), components (the coded and designed building blocks assembled from those tokens), and documentation (the rules governing when and how to use each component).

For a SaaS business, the need arises at a predictable point: when the marketing site, the app UI, and the onboarding flows start diverging. A 50-employee B2B SaaS company in the growth stage will typically have a marketing team updating landing pages in one tool, a product team building in React or Vue, and no shared reference point. The result is visual inconsistency that erodes brand trust, and functional inconsistency that creates UX friction for users moving between surfaces.

The business case is straightforward: a shared design system reduces the time to produce new pages and features because designers are not starting from scratch and engineers are not re-implementing components. It also reduces review cycles because there is a defined standard to check against.

Design tokens: the foundation layer

Design tokens are the named variables that encode your visual decisions. Rather than hardcoding #1A56DB in a button component, you reference color.brand.primary. This means changing your primary brand color across every surface requires one token update, not a codebase search-and-replace.

A minimal token set for a SaaS website covers:

• Color tokens: brand palette (primary, secondary, accent), semantic tokens (success, warning, error, info), and neutral tones for text, borders, and backgrounds
• Spacing scale: a defined increment system (e.g., 4px base unit with multipliers) that governs padding, margin, and gap values
• Typography tokens: font families, size scale, line heights, and font weight variants
• Border and radius tokens: border widths and corner radius values that define how rounded or sharp your UI feels
• Shadow tokens: elevation levels for cards, modals, and dropdowns

Tokens can be stored as JSON or CSS custom properties. Tools like Figma Variables, Style Dictionary, or Theo allow tokens to be defined once and output to CSS, Sass, JavaScript, or Swift — keeping design tools and code in sync.

Component library: the building blocks

Components are the reusable, coded UI elements assembled from tokens. A minimal component library for a SaaS marketing site includes:

1. Button variants (primary, secondary, ghost, destructive) with size and state (hover, active, disabled, loading)
2. Form elements: input, select, checkbox, radio, textarea — with error, focused, and disabled states
3. Navigation: top nav, mobile nav, sidebar nav patterns
4. Cards: feature cards, pricing cards, testimonial cards
5. Badges and tags for status indicators
6. Alert and notification components
7. Modal and drawer shells
8. Data display: tables, stat cards, progress indicators

Each component should be built with accessibility in mind from the start: correct ARIA roles, keyboard navigability, and sufficient color contrast. Retrofitting accessibility into components after the fact is far more expensive than building it in.

Component documentation should include: the component name and purpose, when to use it vs. alternatives, all configurable props or variants, and code examples. Storybook is the de facto standard for hosting interactive component documentation.

Documentation and adoption

A design system without documentation and adoption is a component library that only the people who built it know how to use. Adoption requires two things: documentation that answers "how do I use this?" and organisational alignment that establishes the system as the canonical source rather than a suggestion.

Effective documentation for a SaaS design system includes usage guidelines (when to use a component and when not to), design principles (the opinionated decisions behind the system), token reference tables, and a changelog so teams know what has changed and when.

Adoption is partly a governance question. Who owns the design system? Who reviews and approves component additions? How are deprecations communicated? For a 50-person company, a single "design system owner" role — whether a dedicated person or a rotating responsibility — is sufficient to maintain quality and handle contribution requests.

When to build vs. adopt an existing system

| Approach | Best for | Trade-offs | |---|---|---| | Build from scratch | Established brand with strong visual identity | High initial investment; full control | | Extend an existing system (MUI, Radix, shadcn/ui) | Early-stage SaaS moving fast | Faster start; harder to fully brand | | Adopt a headless component library + custom tokens | Mid-stage SaaS with design resources | Good balance of speed and control | | License a premium system | Enterprise teams with compliance needs | Cost; may not match your stack |

Most SaaS teams at the 20–100 employee stage do best by starting with a headless or unstyled component library (Radix UI, Headless UI, or shadcn/ui) and applying custom tokens on top. This provides accessibility and interaction patterns out of the box, while leaving visual decisions entirely in your control.

The investment in a design system pays off most clearly during the phase when multiple teams are building independently — when consistency would otherwise require constant cross-team design review. If your team is still three people shipping fast, a lightweight token file and a shared Figma library may be all you need for now.

For SaaS companies evaluating a website rebuild that includes design system setup, [web design for B2B companies](/en/web-design-for-b2b) covers how Skylabs approaches component architecture on client projects. If you are planning a redesign and want to understand the full scope, [UX/UI redesign](/en/ux-ui-redesign) explains the audit-to-delivery workflow.