Loading
Product Design
A design is finished when an engineer can build it, an operator can run it, and a first-time user can complete the task without being taught.
01Why it matters
We design digital products for organisations where the work is genuinely complicated — where a screen has to hold a scheduling conflict, a regulatory constraint and a customer’s expectation at the same time. Simplifying that is not a matter of removing elements. It is a matter of understanding the domain well enough to know which complexity belongs to the user and which belongs to the system.
Our design work is done in the open. Prototypes go in front of real users early, engineers are in the room while decisions are being made, and interface work is specified against a component system rather than delivered as a set of flat images that somebody else has to interpret.
We measure a design by how well it holds up under the boring cases: the record with missing data, the user with fourteen open jobs, the second Tuesday of the month when volume triples.
02What we do
The work inside the engagement.
- 01
Research with the people who do the work
Contextual sessions with operators and customers, run where the work happens rather than in a usability lab.
- 02
Interaction and interface design
End-to-end flows designed against real data shapes, including the states most projects discover late — empty, partial, failed, and far too full.
- 03
Prototyping and validation
Working prototypes put in front of the intended users, revised, and put back. We run this until the flow stops surprising people.
- 04
Accessibility from the first sketch
Contrast, focus order, keyboard paths and screen-reader behaviour designed in, then verified against WCAG 2.2 AA before handover.
03A typical engagement
A designer and a researcher, with an engineer embedded from the first week so feasibility is a conversation rather than a rejection.
- Typical duration
- Eight to sixteen weeks
- What you receive
- Research findings and the decisions they changed
- Designed end-to-end flows, including edge and failure states
- A tested, interactive prototype
- Interface specifications written against a component system
04Proof
All workWhere this work has been done.
Halden Maritime
Replacing forty spreadsheets with one operations platform
A port services operator running its entire scheduling function on shared spreadsheets, rebuilt as a single system its planners actually wanted to use.
Read the case study
Nordvik Energy
Making a wind portfolio legible to the people who finance it
An operator whose asset data was accurate, complete, and impossible for anyone outside engineering to interpret.
Read the case studyNext step
Tell us what is not working. We will tell you what we think.
A first conversation is an hour, costs nothing, and usually ends with a straight answer about whether we are the right studio for the problem.