SaaS Platform Design System — Selinay İblikci

Segment	ARR	Status
Enterprise	$840k	Active
Mid-market	$410k	Review
SMB	$120k	Active

Overview

Context

RoleLead Product Designer

Timeline10 months

Team5 designers, 8 engineers, 3 PMs

ToolsFigma, Storybook, Chart.js

A Series B healthcare analytics company with 200+ hospital clients needed to unify their rapidly growing dashboard product. Multiple teams were building features independently, resulting in inconsistent data visualizations, conflicting interaction patterns, and a fragmented user experience that was showing up in customer churn feedback. I led the design system initiative to bring coherence to the platform while supporting fast-paced feature development.

Research approach

Module audit

Mapped every component across 5 dashboard modules — identified 32 chart variations, 3 different table patterns, and 4 conflicting filter styles.

User observation

Shadowed 4 clinical analysts using the dashboards. Noticed they opened multiple modules side by side — inconsistent layouts forced them to re-learn each view.

Engineering interviews

Talked with 3 frontend engineers about pain points. Maintaining duplicate component code was eating ~20% of their sprint capacity.

System map

What’s inside

Foundations and components documented with the same precision as product UI—tokens first, then patterns.

Color system

Consistent color tokens and palettes for scalable themes

Inter

Typography

A flexible type system with predefined roles and scales

Spacing and radius

Structured spacing, sizing, and corner rules

Icons

An icon set designed to stay clear and meaningful

Grid system

Responsive grids for consistent layouts

Shadows and blurs

Depth and elevation styles that add clarity

Process

Design decisions

Key choices that shaped the system

One design system or separate per module?

Each dashboard module keeps its own component set vs. one shared system across all 5 modules

Shared system. Teams were already duplicating work — 32 chart variations existed because each module built its own. A single source of truth meant fixes and improvements reached all modules at once.

Teal as primary or neutral brand color?

Using the existing brand blue as the primary UI color vs. introducing teal as a dedicated data/UI accent

Teal. The brand blue was too saturated for dense dashboard interfaces — it competed with status colors (red/amber/green). Teal provided enough contrast for interactive elements while staying calm at high density.

Light-only or light + dark from day one?

Ship light theme first and add dark later vs. build both themes into the token architecture from the start

Both from day one. Setting up semantic tokens with day/night mapping added ~2 weeks upfront but saved months later. When a client requested dark mode for their NOC screens, we shipped it in 3 days.

Foundations

Color system

Semantic tokens map to primitive scales so light and dark themes stay aligned while dashboards keep accessible contrast for dense data.

Color palette

Mono

11 colors

Brand

11 colors

Error

11 colors

Success

11 colors

Warning

11 colors

Info

11 colors

Primitive colors

Brand (teal)

#ccfbf1

#99f6e4

#5eead4

#2dd4bf

#14b8a6

#0d9488

#0f766e

#115e59

#134e4a

Mono

#fafaf9

#e7e5e4

#d6d3d1

#a8a29e

#78716c

#57534e

#44403c

#292524

#1c1917

Semantic ramps (excerpt)

Error

Success

Warning

Semantic variables

Variable name	Day theme	Night theme
FG/Brand/Primary	Colors/Day/Brand/600	Colors/Night/Brand/400
FG/Brand/Secondary	Colors/Day/Brand/500	Colors/Night/Brand/300
FG/Brand/Hover	Colors/Day/Brand/700	Colors/Night/Brand/500
BG/Surface/Default	Colors/Day/Mono/White	Colors/Night/Mono/900
Border/Subtle	Colors/Day/Mono/200	Colors/Night/Mono/700
Status/Success	Colors/Day/Success/600	Colors/Night/Success/400

Color contrast check

Text on surface

17.51

Contrast ratio · Brand on white

AAA Pass

Normal text · Large text

Automated checks against WCAG 2.1 are embedded in the token documentation so designers can ship accessible pairings without manual spreadsheet work.

Foundations

Typography

Inter for every surface—one family, explicit roles, so dense dashboards and long-form docs stay readable.

Type scale

H1 32px · 700

Analytics overview

H2 24px · 600

Cohort performance

H3 20px · 600

Module summary

H4 18px · 600

Card title

Body 16px · 400

Dense UI stays readable with calm spacing and clear hierarchy.

Small 14px · 400

Helper text for labels and metadata

Caption 12px · 500

Last updated · 2m ago

Heading scale

Role	Size	Line	Weight
H1	32px	40px	700
H2	24px	32px	600
H3	20px	28px	600
H4	18px	26px	600
H5	16px	24px	600
H6	14px	20px	600

Body styles

Role	Size	Line	Weight
Subtitle 1	16px	24px	500
Subtitle 2	14px	20px	500
Body 1	16px	24px	400
Body 2	14px	20px	400
Caption 1	12px	16px	500

Foundations

Spacing and radius

A consistent scale creates rhythm across dense tables and marketing surfaces alike.

Spacing

Token names follow #spacing-* mapped to pixel values.

0spacing-0

4spacing-1

8spacing-2

12spacing-3

16spacing-4

24spacing-6

32spacing-8

48spacing-12

64spacing-16

96spacing-24

128spacing-32

160spacing-40

Applied spacing

Padding and gaps use the same token scale—this strip shows common increments as proportional widths.

8px

12px

16px

24px

32px

48px

Border radius

radius-0

radius-0.5

radius-xs

radius-sm

radius-md

radius-lg

radius-xl

Scale	Variable name	Value	Representative UI
# 0	radius-0	0px	Sharp data cells
# 0.5	radius-0.5	2px	Micro chips
# 1	radius-xs	4px	Tags
# 2	radius-sm	6px	Inputs
# 3	radius-md	8px	Buttons
# 4	radius-lg	12px	Cards
# 5	radius-xl	16px	Modals

Foundations

Shadows & blurs

Elevation is subtle. Shadows use low blur and tight opacity to keep focus on data.

Elevation

XSmall

Small

Medium

Large

XLarge

XXLarge

Shadow types

Drop shadow

Button-shadow

Focus-shadow

Input active

Background blur

S

M

L

XL

XXL

Effect styles

☑ Shadow / elevation / sm
☑ Shadow / elevation / md
☑ Shadow / focus / brand
☐ Shadow / inner / input

Foundations

Grid system

Breakpoints share a single gutter language while column counts adapt to viewport width.

Desktop · 12 columns

Column width: 72px · Gutter: 24px · Margin: 24px

Tablet · 8 columns

Gutter: 24px · Margin: 32px

Mobile · 4 columns

Gutter: 16px · Margin: 16px

Foundations

Icons

24×24 default canvas, 1.5px stroke on outline icons, filled variants for emphasis.

Outline

Line stroke 1.5 · 24×24

Solid

Components

Simple components

Core building blocks shared across navigation, forms, and data views.

Buttons

Input fields

ChipsChip

Avatars

BreadcrumbsHome / … / Label

BadgesActive

Pagination1 2 3 … 100 ›

Checkbox✓

Switch

TooltipPlain tooltip

Components

Buttons

Anatomy, sizing, and interaction states documented for handoff parity with Figma.

Anatomy

8px 8px 16px Button

Padding is symmetric on the horizontal axis; vertical padding matches touch targets per size token.

Sizes

States × styles

Same label in every cell—read rows by state, columns by style.

Filled

Tonal

Outline

Bare

Enabled

Hover

Active

Focus

Disabled

Components

Input fields

Labels, inputs, and helper text follow one vertical rhythm; variants cover dense admin flows.

Anatomy

Label (optional) Help text for validation and hints.

Input types

Long text…

States matrix

Variant	Default	Hover	Typing	Focus	Error	Disabled
Outlined
Outlined filled
Lined

Components

Status badges

Five visual treatments across semantic palettes—used in tables, filters, and timeline headers.

Filled

Tonal

Bare

Tonal-outline

Outline

Brand

Badge

Mono

Badge

Success

Badge

Error

Badge

Warning

Badge

Patterns

Complex components

Composable modules for analytics workflows—tables, charts, and scheduling surfaces.

TablesRows, filters, badges

StatisticsStats & trends

Pie chartsDonut metrics

MenuActions & shortcuts

CalendarsRange pickers

MessagesThreads & media

File uploaderStates & progress

+ moreMaps, filters…

Patterns

Data table

Toolbar, filters, and dense rows with consistent cell primitives.

User	Status	Location	Email	Tags
Sam Lee Admin	Active	SF	sam@acme.io	OpsBeta	⋮
Ava Chen Viewer	Pending	NYC	ava@acme.io	Sales	⋮
Jon Rivera Editor	Terminated	ATL	jon@acme.io	HR	⋮
Mia Park Admin	Active	SEA	mia@acme.io	Ops	⋮
Leo Kim Viewer	Onboarding	CHI	leo@acme.io	CX	⋮
Nina Shah Editor	Active	SF	nina@acme.io	OpsPilot	⋮
Omar Ali Viewer	Pending	BOS	omar@acme.io	Rev	⋮
Pia Gomez Admin	Active	LA	pia@acme.io	Ops	⋮

Showing 1–8 of 384 results 1 2 3 … 30 ›

Cell variants

Default

Title

Description

User

Name
Role

Badge

Active Pending

Functional

Patterns

Statistics

KPI tiles and chart modules share one framework for headers, filters, and footnotes.

KPI tiles

Net revenue

$128k

vs last month

Encounters

12,480

WoW +3.2%

Completion

62%

Rolling 30d

CSAT

4.8

Risk score

74

Target 80

Bar chart widget

Foundations

Dark mode

The same semantic tokens drive both themes: surfaces, text, borders, and interactive colors remap at the system level so components stay consistent without one-off dark-mode hex values in product code.

Light theme

Actions

Form field

Cohort name

Stat card

Net pipeline

$2.1M

vs last quarter

Data table

Name	Role	Status
Sam Lee	Admin	Active
Ava Chen	Viewer	Pending
Jon Rivera	Editor	Critical

Status badges

Active Pending Critical Inactive

Dark theme

Actions

Form field

Cohort name

Stat card

Net pipeline

$2.1M

vs last quarter

Data table

Name	Role	Status
Sam Lee	Admin	Active
Ava Chen	Viewer	Pending
Jon Rivera	Editor	Critical

Status badges

Active Pending Critical Inactive

Token mapping

Semantic tokens resolve to different primitives per theme—documentation and code reference the same names.

Token name	Light value	Dark value
surface-primary	#FFFFFF	#1C1917
text-primary	#1C1917	#F5F5F5
border-default	#E5E7EB	#374151
interactive-primary	#0D9488	#14B8A6
surface-elevated	#F8F9FA	#262626

Outcome

Results

Measurable outcomes after the system reached production coverage.

5

Dashboard modules unified

All 5 modules now pull from one shared Figma library and codebase

~50%

Reduction in UI-related bugs

Tracked via Jira — UI inconsistency tickets dropped from ~12/sprint to ~6/sprint

60%

Faster new feature development

New dashboard views built in 2 days average vs. 5 days before the system

100%

Accessible color contrast

All color pairings validated against WCAG 2.1 AA — automated checks in token docs

Reflection

Key learnings

Principles I carry into the next systems-heavy product.

Data-heavy products need extra attention to information hierarchy — the design system must enforce visual clarity, not just consistency.

Involving engineers early in token naming and structure decisions led to much smoother adoption.