Design System for a SaaS Website and Product

Solution design

Reusable patterns that hold up in production

The design system connects the SaaS website, signup journey and working product through shared typography, colour, language and interaction rules. Tokens and reusable code preserve those decisions across screens. Component guidance includes errors, focus, content variation and accessibility. Contribution and exception routes give teams a maintained way to address needs that the existing library does not cover.

Designers and developers work from the same component names, states and usage guidance. Marketing pages retain room for expression while product screens support dense work. Changes to shared patterns have a release record and a planned route into existing features.

• Brand decisions carried into working components
• Loading, error and recovery states included
• Documented changes and contributions

Business context

A SaaS company maintaining a marketing website, customer onboarding and a subscription application

Core capability

Design

The brand changes after signup

The website may use clear, confident typography while the application has a different button style, spacing scale and tone. Onboarding emails introduce another set of colours. These differences become especially noticeable when a customer moves from an explanation of the product into the first task they need to complete.

The problem also reaches delivery teams. Similar forms receive different validation behaviour, and routine changes reopen debates about spacing or labels. Shared foundations resolve recurring decisions while leaving room for the task: a campaign page needs to explain an offer, and an account table needs to support accurate, repeated work.

Screens viewed as part of a journey

The audit follows discovery, signup, the first useful product task and recovery from an error. Screens, emails and help material are reviewed together. The inventory records repeated controls, competing variants, missing states and design decisions that make information harder to understand.

Designers and developers explain why the variants exist. Some are accidental copies; others support a genuine constraint. A compact table action may need a different treatment from a prominent marketing button. The audit distinguishes those cases before consolidation, avoiding a library that looks consistent in isolation but fits actual screens poorly.

Names that explain how a token is used

Typography, colour, spacing, layout and motion rules describe their role in the interface. A colour named for critical feedback carries a clearer instruction than a bare palette value. Designers and developers can trace which product decisions a token change will affect before releasing it.

Brand character comes from proportion, contrast, language and pacing as much as individual colours. Focus visibility, readable text and reduced-motion behaviour are included in the same foundations. Guidance shows how these choices apply in both an open marketing layout and a denser working screen, including where variation is intentional.

Components and the tasks they form

A text input is a component. A form that validates entries, saves progress and explains completion is a pattern. The library includes both. Teams can find the smaller control and understand the behaviour expected when it becomes part of a larger task.

Each component covers relevant loading, empty, selected, disabled, error and focus states. Responsive behaviour is explicit. Design files and code use matching names, with reference examples that expose those states. Review takes place in the implemented interface, where content length, timing and browser behaviour can reveal gaps hidden by a static design.

A shared pattern with a route for exceptions

A new workflow starts with an existing pattern and a record of any unmet need. The designer and developer review the task together before adding a variant. Usage guidance explains the intended behaviour, restrictions and suitable alternatives, so adoption does not depend on finding the person who originally designed the component.

Exceptions have a concrete reason. A data-entry screen may need higher density; a new customer task may need a state the library lacks. The contribution process evaluates whether to extend a shared component, add a distinct pattern or retain a local exception. Those choices remain visible to the next team facing the same problem.

What happens after an error

Validation identifies the affected field and explains the correction. Forms retain appropriate work when a submission fails. Destructive actions describe what will be removed and offer recovery where the product supports it. The language is direct enough to help at a frustrating moment, without turning every error into a branded performance.

Testing includes long names, translated content, enlarged text, narrow screens, keyboard navigation and assistive technology. Motion is checked during rapid content changes and with reduced motion enabled. These conditions become part of the shared component's behaviour, so product teams do not repeatedly discover and repair the same weaknesses.

Onboarding as the first complete application

The first implementation follows signup through the first useful product task. It exercises transitions between pages, confirmation language, data loading and error recovery. The working flow becomes a reference for later screens and exposes missing guidance before the component library expands.

Migration follows product priorities and shared dependencies. Frequently used controls move first when that supports planned work; complex screens receive a separate migration plan. Releases describe component changes, compatibility concerns and required updates. Teams can adopt the new version deliberately instead of discovering a changed interaction after a routine dependency upgrade.

A contribution has a problem to solve

Design and engineering jointly review contributions, with product involvement when a pattern changes the task itself. Requests describe the unmet need, where it occurs, accessibility considerations and implementation cost. This keeps the backlog focused on components people need rather than an ambition to catalogue every possible interface.

Release notes identify changed behaviour and migration work. Deprecated patterns remain documented during adoption, then are retired. Periodic reviews compare the library with production use and investigate repeated overrides. Brand updates follow the same process so a new visual direction does not spread through unrelated local changes.

The library in actual use

Review follows representative journeys in the working product. Customers should encounter predictable controls and understandable feedback. Developers should be able to implement recurring tasks with supported patterns. Accessibility checks include the real content and interaction states used by those tasks.

Adoption is considered alongside overrides and rework. A widely used component that needs extensive local fixes may need redesign rather than promotion. Feedback from implementation identifies missing guidance and poorly chosen boundaries. The next library release addresses those specific problems, with an example that teams can inspect before migrating.

The choices behind the solution

How the solution is evaluated

These measures define the evaluation criteria for the workflow, its controls and the quality of completed tasks.