Product strategy & design / Capability
Design systems.
Shared components, tokens and rules that keep screens consistent as more people work on the product.
Talk through your idea
When to bring us in
Sound familiar?
- We have five slightly different versions of the same table.
- Every new screen starts with a debate about spacing and colour.
- Our design files and our code describe two different products.
The cost of leaving it
Each new screen restarts the argument about spacing and colour. The differences pile up until users notice, and a later clean-up has to touch every page at once.
Why us
What we bring to design systems.
Designers who stay for the build
Design and engineering sit in one team, so the people who drew a screen are still there when it is built and tested.
Decisions in working prototypes
We settle the important journeys in prototypes people can click through, before anyone writes code that depends on them.
A view for every role
SoulCare gives coordinators, carers and families each the screens their job needs. We design client products the same way.
What the work includes
Decide it once, then reuse it.
We audit the screens you have, find the patterns worth keeping and turn them into named components with clear rules. Colour, type and spacing become tokens that design and code share. Each component covers its states and accessibility, so teams stop rebuilding the same button.
Interface audit
An inventory of the components and patterns already in use, and where they conflict.
Design tokens
Colour, type, spacing and other values named once and used by both design and code.
Component library
Reusable components with variants, states and accessibility behaviour defined.
Usage guidance
Short rules on when to use each component, so new screens follow the same logic.
Use cases
Projects we take on.
Aligning admin and customer apps
Two products built separately that need to look and behave as if they came from the same company.
Tokens for a growing web product
Colour, type and spacing pulled out of scattered stylesheets into named values before more teams start building.
A shared mobile component set
Buttons, form fields and lists built once in React Native, so new app screens stop drifting apart.
What you get
Outputs you can review.
- Audit of existing interface patterns
- Token set for colour, type and spacing
- Component library in design files
- Coded components for web or mobile
- Usage and contribution guidelines
Technologies we use for this
Where it matters
- Health & social care Carers record visits on a phone between homes, so we test task flows for speed and one-handed use with the carers themselves.
- Fintech & professional services We design onboarding and approval screens with the later review in mind: what a compliance officer or auditor will need to see, and in what order.
Where AI helps
Useful, on a short leash.
Finding inconsistencies
Scan existing screens for near-duplicate colours, spacing and components, so the audit starts with a list.
AI evaluation & testing ↗Answering usage questions
Let designers and developers ask how a component should be used, with answers drawn from the system’s own documentation.
Knowledge assistants ↗
Where it stops: Which components exist, and the rules for using them, are design decisions. AI can find the mess but not decide the system.
What’s changing
Shifts to plan for.
October 2025
WCAG 2.2 becomes an ISO standard
WCAG 2.2 was approved as ISO/IEC 40500:2025, which makes it easier for governments and buyers to require it by name.
June 2025
European Accessibility Act applies
Many consumer products and services sold in the EU, including online shops, banking services and e-books, must now meet accessibility requirements. Microenterprises providing services are exempt.
October 2024
UK public sector checks against WCAG 2.2
The government began monitoring public sector websites and apps against WCAG 2.2 AA, which adds criteria on focus, dragging and target size.
Process
How the work runs.
Collect what exists
Screens are captured and grouped, so every variant of a button, table or field sits side by side.
Choose the keepers
For each group we pick one pattern, note why, and list the variants it replaces.
Build tokens, then components
Tokens come first, then components in design files and code, with states and keyboard behaviour defined.
Hand over the rules
Your team gets short usage notes and a way to propose new components, so the system can change without splintering.
Cost
What shapes the estimate.
Platforms covered
A system serving web and mobile needs its components built and tested on each.
Amount of inconsistency
The more competing versions exist today, the longer the audit and migration take.
Code or design files only
A coded component library is a larger piece of work than design files on their own.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Common questions
Before you get in touch.
Do we need a design system for a new product?
Not a full one. A small set of tokens and core components is usually enough at first, and it can grow as the product does.
Can you build it on top of our existing components?
Yes. We start from what you have, keep what works and change what causes inconsistency, so teams don’t have to rewrite everything at once.
What affects the scope?
The number of products and platforms it must serve, how many components exist today and whether the coded library is part of the work.