Product Design
Design debt does not show up as ugly screens. It shows up as support tickets, abandoned workflows, and a training document that exists because the interface could not explain itself.
Design that survives implementation
A design that ignores the constraints of the system behind it gets redesigned by whichever engineer is closest to the deadline. That is where consistency actually dies — not in the design review, but at five o'clock on the Thursday before release, when a screen needs an empty state nobody drew.
So we design the states that make software real: loading, empty, partial, error, too-much-data, permission-denied. They are most of the work and almost none of the portfolio, and getting them wrong is what makes an otherwise good product feel unreliable.
Where we work
Complex internal tools
Software operators use for hours a day, where keyboard efficiency and information density matter more than a first impression.
Design systems
Components, tokens and rules built alongside the code that implements them, so the library and the product do not drift apart within two releases.
Workflow and process design
Multi-step, multi-role flows with approvals and exceptions, where the hard part is the path that goes wrong rather than the happy one.
Data-heavy interfaces
Tables, filters, dashboards and reporting designed against realistic volumes, because a layout that works with twelve rows often fails with twelve thousand.
Accessibility remediation
Auditing an existing product against WCAG and fixing what is found, prioritised by who is actually blocked rather than by rule count.
Research when the answer is not obvious
Interviews and usability testing where a decision is expensive and genuinely contested. Not as a formality when everyone already agrees.
How an engagement runs
Watch the work happen
Sitting with the people who use the thing, in their environment, doing their real tasks. An hour of that reliably beats a month of stakeholder workshops.
Map the actual workflow
Including the spreadsheet on the side and the message to a colleague that the software forced them into. Those workarounds are the requirements nobody wrote down.
Prototype the hard screen first
Not the dashboard — the dense, awkward one where the real work happens. If that screen works, the rest of the product follows; if it does not, nothing else matters.
Test with eight people
Enough to find the problems that matter, few enough to run in a week. Sessions recorded, findings written as changes rather than as observations.
Hand over as components
Design and implementation together, states included, so the build does not quietly diverge from the design in the first sprint.
What you are left with
Component library
Design and code in step, with every interactive state specified: focus, hover, disabled, error, empty, loading.
Research record
What was tested, with whom, what failed, and what changed as a result.
Accessibility evidence
WCAG 2.2 AA checks with keyboard and screen-reader passes, recorded rather than asserted.
Written copy
Real words in the interface, not placeholder text hiding an unresolved question.
Accessibility is a requirement, not a phase
Treated as a late audit, accessibility becomes a list of contrast failures and missing labels bolted onto finished screens. Treated as a constraint from the first wireframe, it costs very little and produces better software for everyone — keyboard navigation and clear focus order help your power users as much as your screen-reader users.
We design to WCAG 2.2 AA and test with keyboard and screen reader before handover rather than after. Where a genuine tension exists between an accessible pattern and a visual intention, we will name it and let you decide, rather than quietly choosing the visual.
- WCAG 2.2 AA as the working standard, not the stretch goal
- Every interactive state designed: focus, hover, disabled, error, loading
- Keyboard and screen-reader testing before handover
- Components handed over as design and implementation together
- Copy written with the design — placeholder text hides real problems
When not to hire us
If you want a visual refresh of screens whose underlying workflow is broken, we will decline. Restyling a bad process makes it faster to encounter the same dead end.
We also do not run design as a phase that finishes before engineering starts. If the two are contractually separated, the design will be renegotiated by implementation reality anyway — better to have the designer in the room when that happens.
Common questions
Rarely, and it is not what we are best at. Our work is software people use repeatedly — internal tools, operator consoles, complex product surfaces. A brand site has different priorities and a specialist studio will serve you better.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.