Productdesign
Interfaces people can pick up and use on day one.
We start by getting close to the problem ’ talking to users, reading the analytics, and mapping what the software actually needs to do. From there we design the flows, the interface and the interaction details, then prototype the risky parts early enough that changing course is still cheap.
What the engagement involves
Design work on a product is not a set of screens. It is deciding what the software is responsible for, what it delegates, and what happens when someone does something the happy path never considered. We map those decisions before opening a design tool, then prototype the parts most likely to be wrong ’ usually the flow that depends on other people’s data or a third-party system.
You get flows, interface and interaction detail as one reviewable set, plus the reasoning behind the choices written down. That reasoning is what lets your team extend the design without us, and it is the part most agencies leave out.
Who it suits
This fits teams who know what they are building but not how it should behave, and product managers who need something testable before committing engineering budget. It also suits products that have drifted into inconsistency and need a coherent model rather than another set of screens. It is the wrong fit when the problem is engineering rather than design: if the software is correct but slow, you want a performance engagement, not a redesign.
How we run it
Every engagement follows the same sequence. The steps below are in delivery order — each one is independently useful, so an engagement can stop after any of them with something finished.
01
Watch the work
We shadow the people who will use the software before designing anything.
The real workflow is visible only in what people do, never in what the process document says. A week of shadowing surfaces the exceptions and workarounds that determine whether the design survives.
02
Flows before screens
Information architecture and user flows precede any visual design.
If the flow is wrong, beautiful screens just help users get lost faster. We map every path — including errors, empty states and the back button — before pixels enter the picture.
03
Prototype the risky parts
The highest-uncertainty interactions get built and tested first.
A clickable prototype in week two answers the questions that would otherwise become expensive arguments in week ten. Changing course is cheap while it is still cardboard.
04
Test with real users
Five users, observed closely, beat fifty survey responses.
We test task completion, not opinions. If three out of five users stumble in the same place, the design is wrong — no matter how the stakeholder review went.
When product design is the wrong answer
You need a rebrand, not a product
Logo, palette and marketing site refreshes are brand design. We do product interfaces — if nobody completes a task in it, it is not our discipline.
Mockups are for approval, not learning
If screens exist to get sign-off rather than to test with users, our process will frustrate everyone. Design that cannot change is decoration.
The interface is genuinely trivial
Two buttons and a status page do not need discovery research. Save the budget for the hard parts and let an engineer lay out the simple ones.
Questions we get about this kind of work.
01Do you implement enterprise systems or just advise on them?
02Will you tell us not to buy something?
03How do you price enterprise work?
04Can you take over a project that has already gone wrong?
Ready to talk about product design?
Most enquiries get a reply within 2 working days. If it is not a fit we will say so rather than waste your time.