Design

UI/UX Design

Interfaces designed with the awkward states drawn, not cropped out

How this is usually engaged

Usually four to eight weeks as a discrete piece of work, or an embedded designer alongside a build team. Access to your users is the single biggest determinant of quality — if we cannot speak to them, we will say what that costs the work rather than substituting our own assumptions and calling it research.

Start a project brief

Practice: Product & Interface Design
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Research, task flows, wireframes and interface design produced against your real content and real permissions, with prototypes tested by the people who will use them.

01What this solves

The problem this addresses

Two failures account for most disappointing interfaces. The first is design without research: screens shaped around what the organisation wants to say rather than the task someone arrived to complete. The second is design that never leaves the happy path — a portfolio-ready set of screens with three tidy rows in every table, which falls apart the first time a developer asks what happens when the list is empty, the upload fails, or the user only has read access. Both produce work that is signed off enthusiastically and argued about for the rest of the build.

02Capabilities

What is included

Discovery research

Interviews and observed sessions with the people who do the work, plus a review of support tickets and analytics. The output is what people are trying to achieve and where they currently give up, not a set of invented personas.

Task flows and information architecture

The routes through the product, mapped with the decisions and dead ends included. Navigation and labelling are tested against the tasks people arrive with, using card sorting or tree testing where the structure is contested.

Wireframes at working density

Structure decided before styling, at the information density the job requires. An interface someone uses forty times a day is designed differently from one they visit twice a year, and we agree which this is early.

Interface design against real content

Screens drawn with your actual product names, actual field lengths and actual permission levels, including empty, loading, partial, error and read-only states for every view that has them.

Prototyping and usability testing

Clickable or coded prototypes put in front of a small number of real users, with the sessions observed by your team. A small number of sessions finds most of what is seriously wrong, and finding it before the build is where the money is saved.

Accessibility-led design decisions

Colour contrast, focus order, target size, form labelling, error association and reduced-motion alternatives decided at design time. Retrofitting these after build is consistently the most expensive way to arrive at the same place.

03Use cases

Where this work usually starts

An internal tool people work around

Staff maintaining a private spreadsheet next to the system they were given, which is a reliable signal that the system does not match the job.

Professional Services

Losing people during sign-up or application

A multi-step form with a drop-off cliff at one particular step. The work is diagnostic first: what people are being asked for, and why they stop being willing to give it.

Finance

Deciding what to keep before a rebuild

A product due for replacement, where the important question is which parts people rely on and which parts they have simply tolerated for years.

Healthcare

04Approach

How we approach it

We start by watching the task being performed, including the workarounds people have quietly invented, then map the flows before drawing anything. Wireframes are made at the density the work actually needs rather than the density that photographs well. High-fidelity screens are designed against your longest names, your real permissions and your genuine error conditions, and we prototype and test the routes that carry the most traffic before they are built. Everything is handed over with the states, the rules and the reasoning, so the build does not become a series of guesses.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Understand the task
Interviews, observed sessions, ticket and analytics review. We look for the workarounds first.
02
Map the flows
Routes, decisions and failure points agreed on paper before any screen is drawn.
03
Structure before style
Wireframes at real density, reviewed with people who do the work rather than only with stakeholders.
04
Design and prototype
High-fidelity screens against real content, assembled into a prototype for testing.
05
Test, revise and hand over
Sessions with real users, revisions made, then handover with states and accessibility annotations for build.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Research findingsWhat was observed, from how many people, and what it does not tell us.
Task flows and information architecture
Wireframes and interface designs with all statesEmpty, loading, partial, error, read-only and permission-limited views.
Interactive prototype and usability test results
Accessibility annotations for buildFocus order, labels, roles, contrast values and motion alternatives.
Design rationale documentThe decisions made and the options rejected, so future changes are informed rather than re-argued.

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Languages & Runtimes

TypeScript

Frontend

React
Next.js
Tailwind CSS

Testing & Quality

Playwright
axe-core

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Design decisions carry security consequences, so we make them deliberately: sign-in, recovery and multi-factor flows designed to be completed by ordinary people without writing passwords down, session expiry that warns before it discards work, and screens that show only the data the acting role is entitled to see rather than hiding it with a style rule. Consent and permission requests are written plainly with a genuine decline path, and any research recordings or screenshots containing personal data are anonymised and deleted on the schedule we agree with you.

Our full security and quality approach

09Questions

Asked before we start

Can you just make our existing product look better?

Sometimes that genuinely is the right job, and it is cheaper than a redesign — updated type, spacing, contrast and component consistency can lift a product considerably without touching its structure. We will tell you which you need after looking at it. Where the problem is that the flow does not match the work, styling it will not help and we will say so.

Do we need research if we already know our users well?

Usually yes, and it can be small. Teams tend to know their users well in aggregate and less well in detail, and it is the detail — the field people skip, the step where they open a spreadsheet instead — that changes a design. If budget is tight, a handful of observed sessions is a far better use of it than a large survey.

Will the designs be buildable?

That is a large part of why we design and build in the same organisation. Designs are made against the constraints of the platform being used, reviewed with the engineers who will implement them, and handed over with the states and rules they need. Where an idea would be disproportionately expensive to build, we would rather know at the wireframe stage.

Can you certify our product as accessible?

No. We design and test to WCAG 2.2 AA, using keyboard and screen reader alongside automated tooling, and we document conformance honestly including anything not met. Nobody can self-certify accessibility, and a supplier offering you a certificate is selling you something that does not exist. If you need an independent statement, we will work with an external auditor and fix what they find.

START HERE

Talk to us about UI/UX Design

The project brief takes about five minutes and gives us enough to have a useful first conversation about UI/UX Design rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.