Package A · interface audit

An interface audit of one product flow

We go through one flow of your product as a person would, screen by screen, and write down every place they could stall, misread or give up. You receive an annotated set of screens and one fix list, ranked.

Fixed price, one flow€1,200

Extra flows on the same audit: €450 each. Ten working days for the first flow.

Start a package

What we review

An audit covers one user flow: a path with a clear start and a clear finish, such as signing up, booking a slot, inviting a colleague or exporting a report. We agree the start and finish screens in the written scope so there is no dispute later about what was in.

Inside that flow we look at every screen and every state of every screen. That means the screen as designed, and also the screen when the list is empty, when the data is still arriving, when the request fails, and when the person comes back half-way through. A flow that looks tidy in its happy path is often confusing in its error state, and the error state is where people decide whether to trust the product.

We review against a short set of well-known usability heuristics — visibility of system status, match with the language people use, user control and freedom, consistency, error prevention, recognition over recall, and helpful error messages — plus the plain basics of layout: reading order, contrast of text against its background, target sizes on touch screens, and whether labels survive translation into longer languages.

We do not review your code, your server set-up, your search ranking or your advertising. The audit is about what a person sees and does on the screen.

How we capture the flow

We use the product as a new person would, on the devices you name in the scope: usually one desktop browser width and one phone width. Every screen is captured, numbered and placed on a single long board in the order it appears. States we cannot reach on our own — a payment that fails, an account that is locked — we ask your team to trigger on staging, or we describe them from the screen text and mark them as unobserved.

Close view of wireframe sketches and a sticky note covered in red handwritten notes and crossings-out — Red notes on the sketch: each one becomes a numbered finding.

How findings are written and ranked

Every finding is a pin on a screen with a short note beside it. The note follows the same four lines each time, so a developer can read twenty of them in a row without guessing what we mean:

Where: the screen number and the state (default, empty, loading, error, success).
What happens: what a person sees or does, described plainly, without adjectives.
Why it matters: the heuristic it breaks, or the point in the flow where people are likely to leave.
Suggested change: a specific change, often with a small redrawn sketch of the corrected screen.

Findings are then ranked into one list. The rank is set by harm, not by effort: a finding that stops someone finishing the flow ranks above one that merely slows them down, which ranks above one that looks untidy. Within each band we note which fixes are small enough for a single afternoon, so your team can pick a few quick ones without reshuffling the whole list.

Edge case, noted: if two findings share one cause — say, every error message is written by a different hand — we merge them into one finding with several pins, rather than padding the list.

We do not attach a number to the expected gain from any fix. Nobody can honestly promise that a changed button will lift sign-ups by a given amount, and we will not pretend otherwise. What we can say is which problems are most likely to stop people, and why.

What your team receives

An annotated board of every screen and state in the flow, pinned and numbered, shared as a design file you own.
The ranked fix list as a plain document, each line linked by number to its pin on the board.
Small redrawn sketches for the findings where a picture explains the change faster than words.
A recorded walk-through, usually twenty to thirty minutes, that goes through the list from the top and explains the reasoning.
One follow-up call within two weeks of hand-over to answer questions from the people doing the fixes.

Timeline

Ten working days for one flow, counted from the day the deposit arrives and we have working access to the product. Each extra flow adds three to four working days. The exact hand-over date is written in the scope before you pay anything.

Price

Item	What it covers	Price
Interface audit (one product flow)	Every screen and state of one flow, ranked fix list, recorded walk-through	€1,200
Extra flow on an audit	Another flow in the same product, merged into the same ranked list	€450

Payment is in two halves: a deposit of half the total when you accept the scope, the rest on hand-over. See payment and refunds for what happens if you cancel part-way.