Product discovery and UX/UI design

Before development, we help define the problem, the users, and the smallest useful first release. Discovery turns assumptions into a product direction the team can design, estimate and build.

This is Phase 1 of how we deliver every project. It is also something we do on its own, for teams who have a build ahead of them and want the thinking done properly first, whoever ends up writing the code.

Why this is the phase worth paying for

Most development goes wrong before anyone writes code. A brief gets taken at face value, a team starts building, and the expensive discovery happens in month four when it turns out the thing being built solves a problem nobody has.

Phase 1 is roughly fifteen per cent of a project budget and it is the only portion that pays itself back before the project ends. Changing the product here costs a conversation. Changing it in development costs a sprint. Changing it after launch costs the launch.

When this is the right choice

When you have a product idea and several opinions about what it should do. When an existing product is technically fine and people still struggle to use it. When you need a scope somebody can actually quote against instead of a wish list. And when there is a build coming and you would rather decide what it is before you commit the budget.

When something else fits better

If the product decisions are genuinely already made and you have a scope somebody can quote against, you do not need this as a separate piece of work. Go straight to the build and we will pick up the design inside it, whether that is a mobile app or a web app.

If what you need is a logo, a brand identity or a visual system, that is brand work rather than product design, and it is not what we do. Ask us anyway and we will point you at people who do it well.

And if you are not sure which of those you are, that is the most common position to be in and it is exactly what the first conversation is for.

What we do

Discovery workshops that surface what is actually being solved and for whom. User journeys and flows. Functional and technical requirements written so a developer can estimate them. Information architecture and data model. Wireframes, then interface design. Prototypes tested with the people who will actually use the product, before the build rather than after it.

What you end up with

A clear first release, design foundations the build can work from, and a scope the team can estimate with far less rework. If we build it, Phase 2 starts from something decided. If somebody else builds it, they start from the same place, and the work stands on its own.