Services / Design / Product design

Software people work out on their own, no manual, no training day

Confusion has a price, and it arrives as support tickets, abandoned sign-ups and features nobody ever finds. We interview the people who will actually use the thing, prototype it before anyone writes code, and keep testing until the confusion is gone.

Start the conversation →See the technology

Why it matters

The cost is the wait

Nobody reads the manual. People open your product, form an opinion in a few seconds, and either work it out or give up and email you. Every hour your team spends explaining where a button is, walking a customer through a form, or answering the same question about what a screen means is the running cost of a design decision somebody made quickly and never tested.

Product design is not a coat of paint applied at the end of a build. It is the part of the project where you decide what the software is for, in what order it asks for things, and what it does when the person using it is confused, in a hurry, or wrong. Those decisions are cheap to change in a prototype and expensive to change once they are set into a database schema and six weeks of front-end work.

We do the whole arc: interviews with your customers and your own staff, journey maps that include the emails and phone calls around the software, wireframes, a clickable prototype, usability sessions with real people, then production-ready screens with every state drawn (loading, empty, error, permission-denied) and a component kit your developers build from. The files are organised, documented and yours.

What you actually get

Built to be trusted

What separates a set of attractive screens from a product that survives contact with real users is mostly this list.

Research before pixels

Structured conversations with the people who will use it and the people who pay for it, distilled into findings you can argue with. It regularly turns out the requested feature was not the real problem, and the cheapest possible moment to discover that is before anyone has built it.

Every state, not just the happy one

Loading, empty, error, no-permission, first-run, too-much-data. Most of the confusion in software lives in the states nobody bothered to draw, so we draw them and write down exactly what each one says.

Flows, not screens

Sign-up, onboarding, checkout, invitation, cancellation: designed end to end, including what happens when someone abandons halfway and comes back two days later on a different device.

Accessible by default, not as a phase

Keyboard operation, focus order, screen-reader labels, readable contrast and forms that explain their own errors, designed in from the start, then checked with the assistive tools people actually use rather than an automated scan alone.

Tested with real users, recorded

We put representative people in front of the prototype with real tasks and record what happens, clipped to the exact moment someone hesitated. Watching a customer struggle settles an internal argument faster than any deck.

A handover developers can build from

Components with all their states, colour, type and spacing defined once as tokens, behaviour written down beside the design, and a live reference your engineers work against, which removes the entire category of "that's not what the design showed".

Where it earns its keep

Same pattern, different desks

The symptom is usually the same: a product that works, that people cannot work out. What changes is who is stuck and what it costs you.

01 · SaaS & B2B software

The trial nobody finishes

The problem: Sign-ups look healthy and activation does not. People reach an empty dashboard, cannot see how to get their own data into it, and quietly never come back, so sales spends its week running demos that the product should be running itself.
What we build: We watch new users attempt the first run, rebuild onboarding around the first moment the product becomes genuinely useful to them, and design the empty and half-configured states properly instead of leaving a blank screen and a hope.
What changes: Trials that reach the point of value without a human walking alongside, and a sales team demonstrating to buyers rather than nursing set-ups.

02 · Logistics & field operations

A screen used with one hand, in the rain

The problem: Drivers and engineers use the app standing up, wearing gloves, on a patchy connection. It was designed on a large monitor by people sitting down, so taps miss, forms lose everything when signal drops, and the office receives phone calls instead of updates.
What we build: Time spent watching the work happen, then a redesign around one-handed use: large targets, one decision per screen, forms that survive going offline and keep what was typed, and status a person can read at a glance in daylight.
What changes: Jobs recorded on the spot rather than remembered back at the depot, and an office that stops re-keying phone calls into the system.

03 · Financial services & fintech

The application people abandon at step four

The problem: An onboarding flow that asks for everything at once, explains none of it, and then rejects the whole submission over one badly formatted field. Drop-off concentrates at precisely the point where the customer had already decided to buy.
What we build: The flow is broken into steps that follow how the customer thinks rather than how the database is arranged, questions are asked only when they become relevant, errors are explained where they happen, and progress is saved so a return visit resumes instead of restarting.
What changes: More applications finished on the first attempt, and fewer abandoned half-records for the operations team to chase by phone.

The technology

The tools behind it, named

Tooling matters here for one reason: it is what makes the handover exact. These are the tools we can defend for the job, not a list of everything on the market.

6 layers · 28 technologies

Where the design lives

One source of truth rather than a folder of loose screens: organised, versioned, and readable by the people who have to build from it.

Figma
Miro
Notion
Loom

Research & evidence

Where the findings come from and where they are kept, so a decision made in month one can still be explained in month nine.

Dovetail
Maze
Hotjar
Optimal Workshop
UserTesting

Prototypes & motion

Making it clickable early, and specifying movement precisely enough that developers build the animation rather than interpret it.

Framer
Rive
Lottie
ProtoPie

Accessibility tooling

Automated checks catch a fraction of real problems, so the screen readers and keyboards do the rest of the work.

axe DevTools
NVDA
VoiceOver
Polypane
Lighthouse
WCAG 2.2

Handover to engineering

Design tokens and a live component reference, so what your developers build is what you approved, and stays that way.

Storybook
React
TypeScript
Tailwind CSS
Next.js

Platform conventions

An app should feel native to the place it runs. We design to the platform's own rules rather than forcing one layout onto every device.

Apple Human Interface Guidelines
Material Design
Flutter
Responsive web

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Typically six to twelve weeks from the first workshop to a build-ready design system, depending on how many flows the product has.

We agree what success looks like

One workshop to write down what the product must do, for whom, and how you will know it worked. Vague goals produce beautiful screens nobody can judge, so we make them specific before anything gets drawn.

We talk to the people who use it

Interviews with your customers and your own staff, plus a session watching people use whatever exists today. Findings come back as a short document with the uncomfortable parts left in.

We map the journey and sketch the structure

The end-to-end path, including the emails, phone calls and internal handoffs around the software. Then low-fidelity structure (what goes on which screen, in what order) while moving things still costs minutes.

We prototype and put it in front of people

A clickable version, tested with representative users on real tasks and recorded. A handful of sessions surfaces most of the usability problems, which is why we run them before the visual design is finished rather than after.

We design it properly, every state

High-fidelity screens built on tokens for colour, type and spacing, light and dark themes with contrast checked in both, motion specified, and each component drawn with its full set of states.

We hand over and stay for the build

A documented component library, a walkthrough with your engineers, and design review during development, because the gap between an approved design and what actually ships is where quality usually leaks away.

Before you commit

The questions worth asking

Design is subjective. How do we avoid endless rounds of opinion?

We cannot make taste objective, and anyone promising otherwise is selling something. What we can do is shrink the area where opinion applies. Research and usability testing settle the questions that have a right answer. Whether people understand the label, whether they can complete the task. For everything left over, we need one named person with authority to decide. Design by committee is the single most reliable way to make a project slow and expensive, and we will ask you to nominate a decision-maker before we start rather than discover there isn't one in week five.

Do we really need the research, or can you just design it?

We can just design it, and sometimes that is the right call: a small marketing page, or a product in a domain you know inside out where the flows are already proven. Be clear about the trade-off: skipping research saves time and money up front and moves the risk to the build, where being wrong costs far more. For anything where the workflow itself is uncertain, the interviews and a few usability sessions are cheaper than one rebuilt feature.

Will better design fix our retention problem?

Not on its own. If people leave because the product does not do something they need, because it is unreliable, or because it costs more than the value they get from it, no amount of interface work will hold them. Design fixes the losses caused by confusion, friction and distrust, which are usually a real share of the problem, but rarely all of it. During research we will tell you which part we think you have, even when that means recommending less design work than you asked for.

Can you work within our existing brand?

Yes, and often that is the sensible scope. We take your brand's colour, type and voice as fixed inputs and build the product system on top, filling in the parts brand guidelines almost never cover, like form states, data density, error messages and dark mode. If something in the brand genuinely breaks usability, most often colour contrast, we will show you the specific problem and propose the smallest change that fixes it.

We already have developers. How does this work with them?

Well, usually. It is the arrangement we prefer. Your engineers join the kick-off and the reviews, we agree early which component library and framework the design targets so we are not drawing things that will be painful to build, and the handover is a live component reference rather than a folder of images. We stay available through the build for the questions that always come up, and review what ships against what was approved.

What do we actually own at the end?

The design files, the component library, the tokens, the research recordings and notes, and the documentation. No proprietary format you can only open through us, and no licence you have to keep paying to keep your own designs. If you later move to another agency or hire in-house, they can pick it up.

Show us the screen people get stuck on

Send a link or a screenshot of the flow that generates the most support tickets. We will tell you what we think is going wrong and what we would test first: free, no strings.

Start the conversation →

Explore more

The rest of Product & Brand Design

Brand identity Prototypes Design refresh ← All of Design