All-Risks Insurance Brokers 路 Design System
Designing the system behind the product
I created a scalable design system for All-Risks' digital insurance products, defining the foundations, components, interaction patterns, and insurance-specific workflows used across quoting, onboarding, policy management, and self-service.
The challenge
A growing product needed shared rules
Quote, onboarding, policy, payments, documents, and self-service were each solving the same interactions in their own way. A date field, an error message, or a progress indicator could look and behave differently depending on which team built it.
- Inconsistent UI patterns across product areas
- The same design decisions made again for each feature
- Complex forms with no shared approach to validation
- Unclear behavior for engineers to implement
My role
From audit to shipped components
Audited existing patterns
Collected how quote, onboarding, policy, and payment screens handled the same interactions, and where they differed.
Defined the tokens
Set semantic color, type, spacing, radius, and elevation roles so decisions were made once.
Built components and variants
Designed reusable components with every state they needed, from focus and loading to error and disabled.
Designed insurance patterns
Turned recurring insurance tasks, like comparing coverage or tracking a quote, into documented patterns.
Documented states and usage
Wrote when to use each component, what each state means, and what to avoid.
Partnered through delivery
Worked with Product and Engineering through implementation and QA so the coded system matched the design.
System architecture
Four layers, each built on the one before
Tokens feed components, components combine into insurance patterns, and patterns become the screens customers use.
- Layer 1FoundationsColor, type, spacing, shape, icons
- Layer 2ComponentsButtons, forms, navigation, feedback
- Layer 3PatternsQuote progress, coverage, comparison
- Layer 4Product experiencesQuoting, onboarding, policy, self-service
Foundations
Start with the rules, not the screens
Every token is named by its role, not its value. Changing a brand color or tightening spacing happens in one place and carries through every product.
- Eight core roles
- Brand, text, surfaces, status, and focus colors cover nearly every screen.
- Contrast is part of the token
- Each foreground and background pairing is tested to WCAG 2.2 AA, so approved pairs are safe to use.
Components
Reusable behavior, not just reusable UI
Each component defines how it behaves in every state, not only how it looks at rest.
- Forms are the product
- Most insurance tasks are forms, so form controls got the most detail: eight controls in six states.
- Labels are never placeholders
- Labels stay visible, and helper and error text are linked to the field.
- Errors explain recovery
- Messages say what is wrong and how to fix it, not just that something failed.
Insurance-specific patterns
A design system shaped around insurance
Generic components were not enough. These patterns capture tasks that only exist in insurance and come up across every product.
Quote & onboarding progress
Quotes are long and often finished later. The pattern shows completed, current, and remaining steps, confirms that work is saved, and marks only the affected step when something needs fixing.
Coverage selection
Coverage cards lead with protection and trade-offs before price. A recommended plan must explain why it is recommended, and the selected state uses a border, checkmark, and label rather than color alone.
Documents, policy summary & empty states
Uploads keep the file name, progress, and retry visible. Policy summaries answer status, cost, renewal, and documents at a glance. Empty states explain why a region is empty and offer one next action.
Accessibility
Accessibility built into the system
- Contrast
- 4.5:1 for body text and 3:1 for large text and UI boundaries.
- Visible focus
- A 3px focus indicator surrounds the whole interactive target.
- Error guidance
- Errors name the problem and explain how to fix it.
- Touch targets
- Interactive areas are at least 44 by 44 pixels.
- More than color
- Every state pairs color with text, shape, or an icon.
Design to development
A shared language between design and development
Semantic naming
Tokens are named by role, like color/status/destructive, so design and code refer to the same thing.
Reusable states and variants
Each component ships with defined states, so engineers do not have to guess what hover, error, or loading look like.
Documented behavior
Usage notes say when a pattern applies and what it should never do.
Consistent validation
Forms share one approach to labels, helper text, and error recovery across every flow.
QA collaboration
Built screens were reviewed against the system with Engineering before release.
Impact
Designing rules that scale beyond one feature
- 250+
- Reusable components and variants
- Shared rules
- One set of foundations and components across quoting, onboarding, policy, and self-service
- Faster starting points
- New workflows begin from existing components and patterns instead of a blank screen
- Accessibility by default
- Contrast, focus, targets, and labels are built into components, not checked at the end
Reflection
From screens to rules
The biggest shift was moving from designing individual screens to defining the rules behind them. The system had to be flexible enough for different insurance workflows while still being opinionated enough to create consistency.