Expertise / 01 of 04
Product strategy & design.
Find the right problem, map the work, and design an interface people can use with confidence.
Talk through your idea
When to bring us in
Sound familiar?
- You have an idea, but not yet a clear first release.
- People work around your product instead of through it.
- Your team needs designs that engineering can actually build.
Why us
What we bring to product strategy & design.
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.
Benefits
What changes for you.
Fewer late surprises
Weak assumptions surface in a prototype session, before anyone has written code that depends on them.
A defensible first release
Everyone involved knows what the first version must do, and what has been left out on purpose.
Engineering starts with answers
Developers get resolved layouts, states and components, so fewer decisions are made mid-build by whoever happens to be coding.
Software that fits the work
Screens follow how people actually do the task, which gives staff less reason to keep a side spreadsheet.
Capabilities
Start with the part you need.
- 01.1Product discoveryWork out who the product is for, what they need first and which assumptions to test before you build.Explore ↗
- 01.2UX & UI designInterfaces designed around real tasks, with every state, error and edge case resolved before build.Explore ↗
- 01.3Prototyping & validationTest the key task with the people who do it, using a prototype, before committing engineering time.Explore ↗
- 01.4Design systemsShared components, tokens and rules that keep screens consistent as more people work on the product.Explore ↗
What the work includes
Test the idea before you build it.
We map the people, tasks and constraints around a product before committing to screens. Prototypes let your team test the key journey; interface design resolves the states and details engineering will need to build it.
Discovery & product direction
Agree the problem worth solving, who it is for and what the first release has to do.
User journeys & prototypes
Put the key journey in front of the people who know the work before any code is written.
Interface & design systems
Design the screens, states and components engineering needs to build it well.
Use cases
Projects we take on.
Coordinator dashboard redesign
Reworking a care provider’s scheduling screens so a coordinator can see the day’s gaps, clashes and changes without switching tabs.
Discovery for a new platform
Mapping roles, workflows and constraints for a new business idea. The work ends in a defined first release and a clickable prototype.
One design system, many teams
Pulling screens built by several teams over the years into one set of tokens, components and usage notes.
Where AI helps
Useful, on a short leash.
Bounded jobs a model can take on inside product strategy & design work, with a person checking the result.
- Product discoveryAI workflow automation ↗
Sorting interview notes
Group quotes from interview transcripts by theme, so the team starts synthesis from a draft rather than a blank wall.
- UX & UI designAI workflow automation ↗
Realistic content for states
Draft sample data and error messages for every screen state, so layouts are tested against long names and awkward cases.
- Prototyping & validationAI workflow automation ↗
Faster throwaway prototypes
Generate rough variants of a screen to test an idea in hours, knowing none of it is production code.
- Design systemsAI evaluation & testing ↗
Finding inconsistencies
Scan existing screens for near-duplicate colours, spacing and components, so the audit starts with a list.
Where it stops: permissions, releases and decisions that matter stay with ordinary tested code and a named person, not a model’s output.
A practical sequence
How the work runs.
Understand the job
Review existing workflows, user roles, business goals and the assumptions that need testing.
Prototype the path
Make the core journey tangible and refine it with the people who know the work.
Prepare the build
Resolve responsive layouts, interaction states, components and the scope of a useful first release.
Relevant product work
See it in practice.
Home care operations / Our product
SoulCare
One visit record sits behind a care dashboard, a carer app and a family app, each designed around a different person’s job.
Explore SoulCare ↗
Industries
Product strategy & design by sector.
- 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.
- Medical education Educators change a scenario while learners watch, so we design the control screen and the learner’s view together and test them as a pair.
- Property & field services A repair moves between customer, inspector, worker and office; we map each hand-off before designing the screens for any one role.
- 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.
What’s changing
Shifts to plan for.
Dates that affect product strategy & design work, checked against the official sources.
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.
Technologies we use
Tools chosen for the product.
Cost
What shapes the estimate.
Number of user roles
Each role, such as a coordinator, a customer or an administrator, needs its own tasks, views and permissions designed.
Access to real users
Busy staff and customers are hard to schedule for interviews and test sessions, and some groups take far more effort to reach.
Depth of design
A tested prototype of one key task is a different size of job from fully specified screens across the whole product.
What already exists
An existing brand, component library or live product can speed things up, or add work if it needs untangling first.
Engagement
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.
Choosing a partner
Questions to ask any provider.
Including us. The answers tell you more than a portfolio does.
Who will you speak to before designing anything?
Designs drawn only from management opinion tend to miss how the work is really done by the people doing it.
What exactly do we receive at the end?
Prototypes, specified screens and component files are different deliverables. A vague answer now becomes a dispute at handover.
How will you test the design, and with whom?
Testing with colleagues feels quick, but it rarely finds the problems your real users will hit on their first day.
How do your designs reach the engineers?
If designers and developers have never worked from the same files, expect gaps in states, spacing and edge cases.
Common questions
Before you get in touch.
Can we start with design only?
Yes. Discovery and design can be a focused engagement with an agreed handover, or the first stage of a build. We define the outputs before the work begins.
Can you work with an existing brand or design system?
Yes. Share your current guidelines, components and product. We can work within them and identify the gaps that matter for the project.
How do you decide what to build first?
We look at the most important user journey, the business goal and technical dependencies. The first release should be a useful, coherent workflow with a scope you can review.
What affects the estimate?
The number of user roles, the complexity of the journeys, the research needed and the depth of the design system. An existing product and a clear brief help us identify those variables.