Services / UI/UX design
Intuitive on day one, still pleasant in year three.
Interfaces that let people do the thing without being taught. Design here is scoped, estimated and reviewed like engineering — because delight is a requirement, not a coat of paint applied at the end.
Proof: designed and built by one team, so the awkward states get found while they are still cheap.
What we design
The screens, the system behind them, and the states that decide whether software feels trustworthy.
Product & app design
The screens people use every day, designed for the tenth time they see them rather than the first.
Design systems
Components and tokens with the rules written down, so the fifth screen someone else builds still looks like yours.
The states nobody designs
Empty, loading, error, permission-denied, first-run. These decide whether software feels solid, and they are usually an afterthought.
Usability testing
Real people attempting the real task. Cheaper than a debate, and it settles arguments that would otherwise run for weeks.
Redesign & simplification
Interfaces that grew a feature at a time until nobody could find anything. Often the work is removal, not addition.
Accessibility
Keyboard paths, contrast, semantic markup and focus behaviour — built in from the start, where it is close to free.
Do you need design, or something else?
When design is the lever
People abandon a flow partway, support answers the same question every week, or your team avoids part of your own product. Those are design problems and they respond quickly to design work.
When it isn’t
If the product is slow, or it does not yet do the thing people need, no interface will rescue it — fix the substance first. A beautiful screen over a broken process just makes the disappointment arrive faster.
An engagement like this
An operations tool has everything on one screen because every request added a field. We watch four people use it, find that three tasks account for most of the day, and rebuild around those — the rest moves behind a clear secondary path. Training time for a new hire drops from a week to an afternoon.
Questions we hear a lot
Do you do design without the build?
Yes, and we hand over something a developer can actually implement — components, states, and the rules behind them, not a flat picture of a happy path. That said, design and build in one team is where this works best, because the awkward states get found while they are still cheap to fix.
What do you actually deliver?
Interactive designs of the real screens, the empty and error and loading states, a component set with the tokens behind it, and the reasoning written down. The reasoning is the part most handovers skip and the part that stops the design drifting six months later.
How do you know a design is good?
A design is good when someone can do the thing without being taught. We test that with real people on the real task rather than asking whether they like the colours. Where a claim can be measured — completion, time on task, support tickets — we measure it.
Can you work with our brand guidelines?
Yes. We build inside an existing brand routinely, and where guidelines are thin we extend them consistently rather than inventing a parallel style. If something in the guidelines fails a contrast or accessibility check, we will flag it rather than ship it quietly.
Is accessibility extra?
No. Keyboard parity, sensible contrast and semantic structure are part of designing it properly. Retrofitting them later costs several times more than doing them at the start, which is the real argument.
Where do people get stuck?
Point at the screen or the step. We’ll tell you what we’d change and why — free, in plain English.