Digital Product Design Services
Product design is the work that happens before anyone draws a screen. What the product is for, who it is for, what it has to do first, and what can wait.
It is also where most of a project's cost is decided. By the time something is in development, the expensive choices have already been made — usually implicitly, often by whoever spoke loudest in the first week.
We do this work as a team that has to estimate the build afterwards. When we propose a feature for version one, we know roughly what it costs to make, and we say so while the scope is still a conversation rather than a contract.
How We Can Help
Not every project needs all of this. These are the parts we go deep on when a product calls for them.
-
Discovery
Goals, users, constraints and the things everyone assumes but nobody has written down. Short, structured, and ending in something you can act on rather than a deck.
-
Flows and journeys
What the user is trying to do, in what order, and what happens when it goes wrong. Mapped before any screen exists, because a beautiful screen in the wrong place is the more expensive mistake.
-
Information architecture
How the product is organised, what lives where, and what the words are. Most products that feel confusing have an architecture problem wearing a visual-design costume.
-
Wireframing and prototyping
Low fidelity while decisions are cheap to change, higher fidelity once they are settled. Prototypes at the level the decision actually requires, not the level that looks most impressive.
-
MVP scoping
Deciding what version one is. We break the product into modules, give each one a rough cost, and work with you on where the line goes. This is the part most design engagements hand off and most development quotes assume was already done.
-
Pitch and investor material
Where a prototype has to communicate the product to people who will never use it. Different job from designing the product, and we treat it as one.
When Teams
Come to Us
-
An idea, and no idea what it costs
You know what you want to build and have no way to size it. We shape it into something estimable and tell you what each part would take.
-
A product about to scale
It worked for the first hundred users and the structure will not hold for the next ten thousand. Usually an architecture problem, sometimes a product-definition one.
-
Too much scope and not enough budget
Everything is essential and the number is three times what you have. We have this conversation often and it is a design problem, not a negotiation.
-
A rebuild that needs rethinking first
SeeYou are replacing an existing system and carrying its assumptions into the new one is the most common way that goes wrong.
-
Raising, and the product has to be legible
A prototype and a story that makes sense to someone outside the company.
Send Us the Product
Send us what you have — a brief, a deck, a half-built product, or a conversation. We will tell you what we would change and why, before anyone signs anything.
How We Work
Goals, users, constraints. Short and structured.
What the product does, what it does not, and what version one is.
The journeys through it, agreed before screens.
At the fidelity the decision requires, tested with people where that is possible.
The product broken into modules, each with a cost, so the line can be drawn with real numbers.
Either into UI/UX Design or straight into development.
Stack
- Design and prototyping: Figma
- Flows and architecture: documented, not whiteboard photographs
- Estimation: module-level, matched to how the build is actually quoted
- Research: interviews and usability testing where the question warrants it
Selected Work
- Planit. Construction planning and scheduling platform. A product where the hard design problem was making an inherently complex domain navigable rather than making it attractive.
- Compliance Auditing Tool. Multi-role auditing platform built around a configurable rule set, where the product definition was most of the work.
Industries We Design For
We design for construction and PropTech, healthcare platforms, booking and scheduling systems, and travel and mobility.
How We
Work Together
-
Discovery engagement
A short, fixed piece of work ending in a defined scope and a module-level estimate. Useful whether or not you build with us. -
Product design through to handover
Discovery, definition, flows and prototype, handed to your team or into our own build. -
Design and build
One team from discovery to release.We price every project individually. There are no packages, because the work does not arrive in packages.
Questions We
Get Asked
-
This is what the product should be. UI/UX design is what it looks like and how it behaves. On a new product they run together; if you already know what you are building, you probably only need the other one. See UI/UX design.
-
Yes, and the output is written to make that possible. A scope and a module-level estimate are useful to whoever builds it, including a team that is not us.
-
We break the product into modules, price each one roughly, and then have an honest conversation about which of them version one genuinely needs. The useful part is not the list — it is seeing what each item costs while you can still change your mind about it.
-
Less than the feature you would otherwise have built and removed. We give you a rough estimate once we understand the shape of it, and discovery engagements are usually fixed price because their scope is knowable in advance.
-
Where the question warrants it. We will tell you when a decision needs research and when it needs someone to make a call. See UX research & audit.