Saad Pervaiz

A design system built to scale

A personal design system in Figma, from tokens to components to real screens, so new interfaces get assembled rather than redrawn.

Components from the design system: alerts, menus, buttons in every state, inputs, accordions, a variables panel and the type scale
Type
Personal project
Scope
Tokens & variablesComponent library
Focus
ScalabilityAccessibilityDocumentation
Tool
Figma
← Work

Overview

Tokens first, then components, then screens

Most design systems break in the same place: a colour or spacing value gets hard-coded once, then copied a hundred times. I built this system to work the other way round. Every decision lives in one place and flows down into components and screens.

151Variables in 5 collections
14Component sets
60Colour tokens across 6 scales

Foundations

One source of truth

Everything starts with variables. Primitives hold the raw values, like brand/500 = #366FED. Mapped tokens give them a job, like Action/primary/default or Text/secondary. Components only ever use the mapped tokens, so changing the brand colour or adding a dark mode means editing one layer, not every component.

5 variable collections. Here, the Brand primitives from 50 to 900.

Colour

Six scales of 10 steps each: neutral, brand, and green, orange, blue and red for feedback states like success, warning, info and error.

Type, radius and elevation

An 11-step type scale in Inter, from Display to Label, plus shared tokens for corner radius and shadows so every card, button and menu feels like part of the same family.

Type scale with Display, Headline, Body and Label styles and their sizes
Corner radius tokens from none to round
Radius: none to round.
Shadow tokens from extra small to large
Elevation: shadow levels from Xs to Lg.

Components

Every state, designed up front

14 component sets, each built with variants and properties instead of separate copies: buttons, icon buttons, button groups, inputs, checkboxes, radios, switches, text areas, menus, navigation, tags, alerts, accordions, avatars, cards and tables.

Each one covers the states real products need, so nobody has to invent a disabled or error look later.

Button variants: primary, outline and transparent across default, hover, focus and disabled, plus destructive, icon buttons and button groups
Buttons: 3 styles × 4 states, plus destructive, icon and grouped versions.
Inputs, checkboxes, radio buttons, switches and text areas in default, hover, focus, disabled and error states
Form controls with default, hover, focus, disabled and error states.

Accessible by default

Accessibility is part of every component, not an afterthought: visible focus states, a label on every field, error messages that don't rely on colour alone, and annotated reading and keyboard focus order for screen reader and keyboard users.

In context

From parts to real screens

The real test is putting components together. Every screen below is built only from system parts: fields, toggles, accordions, cards and a consistent button hierarchy. No one-off styles needed.

Profile form with first name, last name, a username field showing an error, email, bio and Save and Discard buttons
Profile: inline validation and a clear primary action.
Settings page with tabs, toggles, radio buttons, checkboxes and active sessions
Settings: tabs, toggles, radios and checkboxes working together.
Create account form on mobile with name, email, password, bio, role select, checkboxes and a Start Free Trial button
Sign up on mobile: the same parts at a small screen size.
FAQ built from accordion components, one expanded
FAQ built from the accordion.
Product card grid with filter tags, prices and Add to cart buttons
Product cards with filter tags.

Why it scales

What makes it scale

  1. 01

    Change once, update everywhere

    Components read from mapped tokens, so a new brand colour, theme or spacing change ripples through the whole system automatically.

  2. 02

    No surprises in edge cases

    Hover, focus, disabled and error states exist for every component before a screen ever needs them.

  3. 03

    Easy to hand off

    Clear naming, usage notes on every page and accessibility annotations mean developers can build it without a meeting.

  4. 04

    Fast to build with

    New screens come together from existing parts, as the example screens show, instead of being drawn from scratch.