Services / Product Design
Before we build, we make sure we're building the right thing.
Most software fails not because it was built badly, but because it was built. The wrong thing, beautifully engineered, is still the wrong thing. Product design is where we work out what's worth building — and what isn't.
What we mean by Product Design
Before we build, we make sure we're building the right thing.
- Discovery and product strategy
- User research and synthesis
- UI design and prototyping
- Design systems that survive into production
- Validation against real users, not just stakeholders
What you get
Outcomes, not deliverables.
A validated direction before a line of production code is written
Designs that survive contact with engineering — not deck-only fictions
A research synthesis the whole team trusts, in days not weeks
How we approach it
4 stages, in this order.
- 01
Listen
Talk to the people whose job your software is going to change. Read the room before designing for it.
- 02
Frame
Turn what we heard into a small set of decisions about what to build, what to leave out, and what to test first.
- 03
Prototype
Clickable, testable, throwaway. Real enough to get honest feedback; cheap enough to throw away when it's wrong.
- 04
Validate
Put the prototype in front of real users. Watch what happens. Adjust before the build, not after.
The AI angle
AI accelerates the team. Senior experience still decides what to build.
AI has changed product design in two ways that matter. First, prototyping is faster — we can put a credible interactive prototype in front of users in days, not weeks. Second, research synthesis is a different exercise — we can analyse hours of user interviews in an afternoon and spend the rest of the time on the experience that AI can't replace.
- AI-accelerated prototyping — validated direction in days rather than weeks
- Research synthesis at scale, with human experience on the conclusions
- Faster iteration cycles, so we can afford to be wrong more cheaply
Questions we hear a lot
FAQs.
- Do you do design without the build?
- Yes. Many of our engagements start as design-only — sometimes that's all a client needs. If a build follows, we keep the team continuous so nothing gets translated through a handover.
- What about Figma — do we get the files?
- Yes, fully. We work in your Figma workspace if you have one, otherwise in ours and we hand the files over at the end.
- How does this fit with our existing design system?
- We use it where it's working, extend it where it isn't, and flag the gaps clearly. We don't rebuild design systems for sport.
- How long is a typical design engagement?
- Anywhere from two weeks (focused problem, narrow scope) to twelve (new product, deep research). The discovery call is where we work out which.
- Will the design survive the build?
- That's the bar. We design with the engineering team in the room, so the gap between "designed" and "buildable" is closed before the file ever ships.
Got a build in mind? Let's have a conversation.
Liverpool, UK. Available across the UK and remote.