How to Use SaaS UI Patterns When Building a Design System
9 pattern-based strategies for building a design system from real SaaS products — each illustrated with actual UI screenshots from Linear, Notion, Stripe, Figma, Shopify, and more.
Most design system guides start the same way: pick your colors, define your typography scale, build a button component. Repeat until you have a Figma library nobody uses.
The problem isn’t the process. It’s the starting point. Teams build design systems in a vacuum — inventing components from first principles instead of studying how the best products in the world have already solved the same problems.
This article takes a different approach. Instead of abstract theory, every section below is grounded in real UI patterns from production SaaS products — screenshots from the SaaSUI.Design library showing exactly how companies like Linear, Notion, Stripe, Figma, and Shopify have translated design decisions into systematic, scalable interfaces.
These aren’t conceptual frameworks. They’re patterns you can study, deconstruct, and adapt into your own design system today.
What you’ll find in this article
9 practical strategies for building a design system informed by real SaaS UI patterns, each illustrated with actual product screenshots from saasui.design — no abstract theory, no generic component lists.
Pattern 01: Start With a UI Audit, Not a Component List
The fastest path to a useful design system isn’t building components. It’s studying the ones that already work.
The most common design system failure is starting with an empty Figma file and a list of components to build: button, input, card, modal, table. You end up with a generic UI kit that doesn’t reflect how your product actually works.
The better approach — the one used by teams at Atlassian, IBM, and Shopify — is to start with an audit. Screenshot every screen in your product. Screenshot the products your users already love. Then categorize what you find: where are the patterns? Where are the inconsistencies? Where have other products solved a problem you’re still fighting?
Figma’s own blog recommends this exact workflow: gather screenshots across platforms, identify repeating patterns, and let those patterns become the foundation of your system. The same approach applies when benchmarking against best-in-class SaaS products. Linear’s interface, for example, reveals a remarkably tight system: consistent spacing, a restrained color palette, and typography that does the heavy lifting across every view.
How to run a pattern-first audit
- Screenshot 20–30 screens from your own product and 3–5 competitor/reference products
- Group screenshots by pattern type: navigation, forms, data tables, empty states, modals, settings
- Identify the 3–5 patterns that appear most frequently — those become your first design system components
- Note where reference products solve the same problem differently — these are design decision points
Linear’s interface reveals a tight, systematic design language — consistent spacing, restrained color, typography-driven hierarchy. This is what a pattern-first system looks like in production.
Notion’s sidebar navigation reuses the same component patterns across pages, databases, and workspaces — a masterclass in systematic reuse.
The key insight: your design system should document decisions you’ve already validated through real-world usage, not decisions you’re making in theory. Start with what works, then systematize it.
Pattern 02: Extract Your Token System From Real Products
Design tokens aren’t abstract. Study how the best SaaS products use color, spacing, and typography — then build your token system from those patterns.
Design tokens are the atomic layer of any design system — the named values for colors, spacing, typography, radii, and shadows that every component references. But most teams define tokens in isolation, picking colors from a wheel and spacing from a modular scale without testing them against real interface patterns.
A better approach: extract your token system by studying how production products actually use these values. When you look at Stripe’s dashboard, you’ll notice their color system operates on a clear hierarchy — a neutral base palette for surfaces and text, a single primary accent for interactive elements, and semantic colors reserved exclusively for status communication (success, warning, error). There’s no decorative use of color. Every color token earns its place by conveying information.
Linear follows the same principle with spacing. Their interface uses a consistent 4px base grid with a limited set of spacing values: 4, 8, 12, 16, 24, 32, 48. You can verify this by studying their screens — the padding inside cards, the gap between list items, the margin around sections all snap to this scale. No arbitrary values.
Token categories to extract from reference products
- Color: surface, text, border, interactive, semantic (status), accent — study how products like Stripe and Linear limit their palette
- Spacing: base unit, scale (typically 4px or 8px), and how products apply it to padding, gaps, and margins
- Typography: font families, size scale (heading vs body), weight usage, and line-height ratios
- Radius: corner rounding values — most modern SaaS products use 2–3 radius tokens (small, medium, large)
- Shadow/Elevation: how products like Notion and Figma create depth without heavy drop shadows
Stripe’s dashboard demonstrates a rigorous token system in action — neutral surfaces, one primary accent, and semantic colors reserved for status. Zero decorative color.
Linear’s spacing system is visible across every view — consistent padding, predictable gaps, a tight base grid that holds the entire interface together.
Pattern 03: Build Navigation Components From Proven Architectures
Navigation is the skeleton of your product. Study how the best SaaS products structure it before building your own.
Navigation components — sidebars, top bars, breadcrumbs, tabs, command palettes — are the most structurally important elements in a design system. Get them wrong and every page in your product inherits the problem.
The dominant navigation pattern in SaaS in 2026 is the collapsible sidebar with contextual sub-navigation. Notion, Linear, Asana, and HubSpot all use variations of this pattern, but the details differ in ways that matter for design system decisions.
Notion’s sidebar is a hierarchical tree that expands infinitely — pages within pages within pages. This works because Notion’s content model is inherently nested. Linear’s sidebar is flat and task-oriented: teams, projects, views. No nesting. Both are excellent navigation systems, but they encode completely different information architectures.
The command palette is the other navigation pattern that’s now essential in any design system serving a complex product. Linear’s Cmd+K implementation is the reference standard: every action and navigation path accessible through a single keyboard shortcut, with fuzzy search and recent items surfaced by default.
Navigation patterns to document in your design system
- Primary sidebar: collapsible, with sections, icons, and active states — study Notion and Linear for contrasting approaches
- Command palette: global search + action execution — Linear and Figma set the standard
- Breadcrumbs: critical for nested content — Airtable and HubSpot show different hierarchy approaches
- Tab navigation: for switching contexts within a view — Stripe and Amplitude handle this cleanly
Notion’s sidebar encodes a nested content model — pages within pages. A different system decision than flat, task-oriented navigation.
Linear’s command palette — every action in the product accessible via one keystroke. This pattern belongs in every modern design system.
Pattern 04: Design Your Form System From Real Input Patterns
Forms are the transactional backbone of SaaS. Your design system’s form components should reflect the complexity your product actually demands.
Every SaaS product is, at some level, a series of forms. Creating an issue in Linear is a form. Setting up a workflow in HubSpot is a form. Configuring billing in Stripe is a form. Yet most design systems treat forms as simple stacks of labeled inputs — missing the layout patterns, validation states, conditional logic, and progressive disclosure that real products require.
Stripe’s checkout and payment configuration flows are the gold standard for form design systems. Every input has clearly defined states: default, focused, filled, error, disabled. Validation messages appear inline, not in alert banners. Help text is contextual, not buried in documentation. And complex multi-step forms use progressive disclosure — showing only the relevant fields at each stage.
HubSpot’s CRM forms take a different but equally systematic approach. Their property editor handles dozens of field types — text, dropdowns, date pickers, multi-selects, currency inputs — all within a consistent visual framework. The design system behind this must account for each field type, its states, its responsive behavior, and how it composes with other fields.
Form patterns your design system needs
- Input states: default, hover, focused, filled, error, disabled, read-only — study Stripe for the clearest state definitions
- Validation: inline error messages, success confirmations, real-time vs on-submit patterns
- Multi-step forms: progress indicators, step navigation, conditional fields — Stripe’s onboarding is the reference
- Complex field types: date pickers, multi-selects, search-and-select, rich text — HubSpot and Airtable demonstrate the range
Stripe’s form design — clean input states, inline validation, contextual help text. The reference for transactional form UX.
HubSpot’s form system handles dozens of field types within a consistent visual framework — a design system that scales to complexity.
Pattern 05: Data Display Components — Tables, Cards, and Dashboards
Most SaaS products are data products. Your design system needs a robust data display layer, not just a basic table component.
Data tables, metric cards, charts, and dashboard layouts are where most design systems fall short. The default approach — build one table component and one card component — doesn’t account for the range of data display patterns that real products require.
Amplitude’s analytics interface demonstrates the complexity. Their dashboard uses metric cards with sparklines, full-width chart components with interactive tooltips, data tables with sortable columns and inline filters, and segmentation controls that reshape the entire view. A design system serving this product needs components for each of these patterns, not a generic “card” component.
Airtable takes a fundamentally different approach to data display — the same dataset rendered as a grid, kanban board, calendar, gallery, or form. Each view reuses the same underlying data components (cells, field headers, filter badges) but composes them differently. This is the hallmark of a well-architected design system: components that compose flexibly rather than requiring custom builds for each new layout.
Data display patterns to systematize
- Tables: sortable columns, inline editing, row selection, pagination, empty states — study Airtable and HubSpot
- Metric cards: KPI value, trend indicator, sparkline, comparison period — Amplitude and Stripe do this well
- Charts: line, bar, pie, funnel — with consistent axis styling, tooltips, and legend patterns
- Dashboard layouts: grid systems for arranging cards and charts — study Vercel and Amplitude for responsive data grids
Amplitude’s dashboard demonstrates the full range of data display components a design system needs — metric cards, charts, tables, and filters working together.
Airtable’s table interface — the same data components compose into grid, kanban, calendar, and gallery views. Composability over custom builds.
Vercel’s deployment dashboard — minimal data cards that surface exactly the right information. Strategic restraint in data display.
Pattern 06: Define Empty States and Loading Patterns as First-Class Components
Empty states aren’t edge cases. They’re the first thing every new user sees. Your design system should treat them accordingly.
Most design systems include components for the happy path — buttons, forms, tables filled with data. But the states users encounter most frequently during onboarding and first-run experiences are empty states, loading states, and error states. If your design system doesn’t have documented patterns for these, your product will handle them inconsistently.
Notion has turned empty states into a signature design moment. A blank page shows a warm prompt with the slash-command shortcut, template suggestions, and one clear action. The copy is human-voiced, the layout is intentional, and the empty state itself functions as onboarding. This isn’t an afterthought — it’s a designed component.
Stripe takes a different approach to empty states in their developer dashboard. An empty integration page doesn’t just acknowledge the absence of data — it walks the developer through the first integration step-by-step, with inline code snippets. The empty state is the tutorial.
State patterns your design system needs
- Empty states: illustration + headline + description + primary CTA + optional secondary action — Notion and Stripe show contrasting approaches
- Loading states: skeleton screens (not spinners) that match the layout of the content being loaded — study how Slack and Linear handle this
- Error states: inline errors, page-level errors, connection failures — each needs a documented pattern
- Zero-data states: what dashboards and analytics views show before data exists — Amplitude and Mixpanel handle this differently
Notion’s empty state is a designed component, not an afterthought — warm copy, a clear action, and zero overwhelm.
Stripe turns empty states into step-by-step tutorials — the empty state is the onboarding surface.
Pattern 07: Onboarding and Activation Flows as System Patterns
Onboarding isn’t a standalone feature. It’s a composition of your design system’s core components — and it should be documented as such.
The best onboarding flows aren’t built as one-off features. They’re composed from existing design system components: progress indicators, checklists, tooltips, modals, empty states, and form steps. When your design system includes these patterns with onboarding use cases documented, building activation flows becomes assembly, not invention.
Asana’s onboarding checklist is a clear example. It combines a progress bar component, a checklist component with auto-detection of completed steps, contextual tooltip components, and empty state components for each section of the product. Each of these should exist as a documented, reusable pattern in the design system — not as bespoke onboarding code.
Slack’s first-run experience demonstrates action-first composition: the channel creation form, the invite flow, the message composer — all standard design system components used in an onboarding-specific sequence. The design system doesn’t need a special “onboarding component.” It needs its existing components to be flexible enough to compose into onboarding flows.
Onboarding-adjacent patterns for your design system
- Progress indicators: step counts, percentage bars, checklist completion — study Asana and ClickUp
- Tooltip/coach marks: contextual pointers with dismiss + next actions — Linear and Notion use subtle variants
- Setup wizards: multi-step modal flows with validation per step — HubSpot’s signup survey is the reference
- Celebration moments: success states, confetti animations, milestone acknowledgments — Asana’s flying unicorn is the famous example
Asana’s onboarding checklist is composed from standard design system components — progress bar, checklist, tooltips, empty states — not built as a one-off.
Slack’s first-run experience uses existing product components in an onboarding sequence — the design system enables the flow without custom builds.
Pattern 08: Settings and Configuration Surfaces
Settings pages are the most under-designed screens in SaaS. They’re also where your design system’s compositional flexibility gets stress-tested.
Settings pages expose the true scalability of a design system. They combine form inputs, toggle switches, section headers, permission matrices, billing components, notification preferences, and integration cards — often on a single page. If your system can’t compose these cleanly, your settings UI will become a graveyard of one-off components.
Linear’s settings are a model of restraint. Each settings section uses the same layout pattern: a section header, a description line, and then the relevant controls. Whether it’s notification preferences, workspace configuration, or API settings, the pattern holds. The design system behind this clearly defines a “settings section” pattern that all teams can reuse.
Shopify’s admin settings handle significantly more complexity — payment providers, shipping zones, tax configurations, checkout customization — but still maintain consistency through a shared settings layout component with contextual help panels and progressive disclosure of advanced options.
Settings patterns for your design system
- Settings section: header + description + controls group — Linear’s approach is the cleanest reference
- Toggle rows: label + description + switch, with dependent fields that appear/collapse — standard in Slack and Notion
- Permission matrices: role-based access grids — HubSpot and Asana handle multi-role complexity
- Integration cards: connected service status, configure/disconnect actions — study Slack and Zapier patterns
Linear’s settings use a single, repeating layout pattern — section header, description, controls. Systematic simplicity.
Pattern 09: Document Patterns, Not Just Components
Components are the atoms. Patterns are the molecules. The best design systems document both.
The most common mistake in design system development is stopping at components. You build a button, an input, a card, a modal — and call it done. But components alone don’t tell designers or developers how to compose a settings page, a data table with inline editing, or an onboarding wizard.
IBM’s Carbon design system is the gold standard here. Beyond individual components, Carbon documents UI patterns — complete solutions for common interface problems like login flows, forms with validation, data filtering, and content creation. Each pattern shows how multiple components compose together, with usage guidelines and accessibility notes.
Atlassian’s design system takes a similar approach, documenting patterns like “empty states,” “forms,” and “tables” as compositions of their core components. The pattern documentation explains when to use each composition, what accessibility requirements apply, and how the pattern adapts across screen sizes.
For your own design system, this means going beyond a component library. For every common interface pattern in your product, document: which components compose to create it, the layout rules, the responsive behavior, the state variations, and the accessibility requirements. When a designer opens your system looking for “how do I build a settings page,” they should find an answer — not just a list of parts.
Patterns to document beyond components
- Login and signup flows: social auth + email options + error handling + redirect logic
- Dashboard layouts: responsive grid with metric cards, charts, and filter bars
- Settings pages: section-based layout with forms, toggles, and permission controls
- Data management: table views with sorting, filtering, bulk actions, and empty states
- Modals and dialogs: confirmation, creation, detail view — each with documented size, content, and dismissal patterns
Clerk’s auth interface is a complete pattern — social login, email fallback, error states — not just individual components. Your design system should document flows like this.
Intercom’s messenger composes input fields, message bubbles, quick replies, and attachment handling into a documented pattern that scales across use cases.
The Common Thread
Look across all nine strategies and one principle emerges: the best design systems are built by studying real products, not by inventing in a vacuum.
Pattern audits ground your system in validated solutions. Token extraction from reference products gives you values that work in real interfaces. Navigation, form, data display, and settings patterns give you compositional recipes, not just isolated parts. Documenting patterns alongside components gives teams the guidance to actually ship consistent, high-quality interfaces.
The underlying formula is: study first, systematize second, build third. A design system informed by real-world patterns will always outperform one built from theory alone.
Explore the products featured in this article
Every product shown here is available in the SaaSUI.Design screenshot library. Browse real UI patterns — hand-picked screenshots from 150+ SaaS applications, updated regularly.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →