Product design that removes friction rather than adding polish

UX, UI and product design: what each word is doing

These terms get used interchangeably in proposals, which is convenient for the seller and unhelpful for the buyer, so it is worth being precise about what we mean.

UX design decides what the product does and in what sequence. Structure, flows, vocabulary, defaults, permissions, what happens when something fails, and whether a proposed feature should exist. It is mostly thinking, and its artefacts are cheap: diagrams, sketches, a written argument.

UI design decides how all of that is presented. Layout, typography, colour, spacing, motion, the behaviour of an individual control, the difference between a button that feels pressable and one that does not.

Product design is the term for doing both with commercial context attached — which is what most engagements actually require, because a beautifully resolved screen that solves the wrong problem is still a wasted month.

The distinction matters when you are buying. A firm proposing “UI design” for a product with a broken signup flow is proposing to repaint a room with a structural problem. A firm proposing six weeks of research for a five-screen internal tool is proposing something equally disproportionate in the other direction.

When a product needs design help

The symptoms are usually operational before they are visual.

Support answers the same question repeatedly and everyone privately agrees the answer should be in the interface. Onboarding requires a call from your team, which was manageable at forty customers and is now a growth ceiling. Sales demos skip a particular screen. Analytics shows a clean drop at one step and nobody can explain it. New features make the product harder to use because there is no longer an obvious place to put anything. Or the product is genuinely more capable than a competitor and loses the evaluation anyway, which is almost always a legibility problem rather than a capability one.

None of those get fixed by a visual refresh. They get fixed by working out what people are trying to do and where the product stops them.

Research in proportion to the decision

Research has a bad reputation in some companies, generally because someone once commissioned six weeks of it and received a deck that changed nothing. The corrective is not to skip research; it is to size it to the decision it informs.

We start with evidence you already own, because most organisations are sitting on far more than they think. Support tickets and their categories. Sales call recordings. Churn and cancellation reasons. Session recordings and heatmaps from a tool such as Hotjar. Search logs, which are the most underrated source in the list — what people type into your own search box is a direct statement of what they expected to find and did not. Analytics tells you where people stop; it will never tell you why, and treating a funnel chart as an explanation is the most common analytical error in product work.

Then we close the specific gaps. Usually that means a small number of task-based interviews: watching someone attempt a real job in the real product, rather than asking them what they would like. People are unreliable narrators of their own behaviour and entirely reliable demonstrators of it. Where the question is about structure rather than behaviour, card sorting generates candidate groupings and tree testing evaluates whether a proposed hierarchy actually lets people find things — two methods that are frequently confused and do opposite jobs.

A heuristic review runs alongside all of this: an expert pass over the interface against Nielsen’s ten usability heuristics — visibility of system status, match with the real world, user control, consistency, error prevention, recognition over recall, and the rest. It is cheap, it finds a great deal, and it is not a substitute for watching a real user, because an expert knows too much to get lost.

Defining the problem before designing anything

The step teams skip is the one between research and design: writing down, in plain language, what problem is being solved.

We prefer to frame this as the job the user is trying to get done rather than as a feature request, because feature requests arrive pre-solutioned. “Add a bulk export button” is a solution. “Finance needs last month’s numbers in their own spreadsheet before the fifth working day” is a problem, and it has several possible answers, one of which might be that the report should have been emailed automatically and nobody should be exporting anything.

Personas are useful here and frequently misused. A persona that records real differences in goals, context and constraint is a working tool. A persona with a stock photograph, an invented name and a paragraph about weekend hobbies is set dressing, and teams are right to ignore it.

Structure, flows, then screens

Information architecture is where most large products go wrong, and it goes wrong slowly. Each feature is added in a reasonable place given what existed at the time, and after three years the navigation reflects the order things were built rather than how anyone thinks about them.

Restructuring is uncomfortable because it changes something users have already learned, so it needs evidence rather than opinion — which is precisely what tree testing provides. It is also cheap to test: participants attempt to locate things in a text-only hierarchy with no visual design to compensate for a bad label.

Flows come next, and the part that matters is the part usually left undrawn. Every flow has a happy path that gets designed and a set of failure paths that do not: the payment declined, the session expired mid-form, the file too large, the invitation to an account that already exists, the permission the user does not have. Those moments are where trust is won or lost, and they are cheaper to design than to discover.

Only then do wireframes get made — deliberately rough, because their job is to settle hierarchy and content priority while the artefacts are still cheap to throw away. Arguing about a layout in low fidelity takes an hour. Arguing about it after the visual design exists takes a fortnight and someone’s pride.

Interface design and the states nobody draws

When the structure is settled, the visual work has something to be good at.

The parts we spend disproportionate time on are the ones that decide whether a product feels solid: a type scale that stays readable at the sizes real content demands, spacing rhythm that survives a translated string, focus states that are visible against every background they appear on, and motion that clarifies what just happened rather than decorating it.

And states. Every screen has more of them than a design file usually contains: default, loading, empty on first use, empty because a filter matched nothing, partial data, error, permission denied, offline, and content that is far longer than anyone anticipated. The empty state at first use is arguably the most important screen in any product, because it is the one every new user sees and the one most often left as a blank panel with a grey icon.

If a state is not designed, engineering will invent it under time pressure, and it will be the state your user encounters on the day something goes wrong. That is when they decide whether your product is trustworthy.

Prototyping and usability testing

A clickable prototype settles arguments that a static file cannot. It is also the cheapest way to find out that a flow which reads perfectly well is confusing to operate.

On sample size, the practical answer is smaller than most people expect. Nielsen Norman Group’s finding, which has held up across decades of practice, is that about five participants reveal roughly 85 per cent of usability problems, and that three rounds of five will improve a design more than a single round of fifteen — because the improvement comes from redesigning between rounds, not from the report. The important caveat: that applies to one user group doing comparable tasks. Two genuinely distinct audiences need a small round each.

Sessions are task-based. We ask people to do something and watch what happens, rather than showing them a design and asking what they think. Opinions about interfaces are cheap and unreliable; failures are neither.

Accessibility as a design requirement

Accessibility is a design decision long before it is a development task, and treating it as a pre-launch audit is how it becomes expensive.

The measurable floor is WCAG 2.2 at level AA. In design terms that means contrast of at least 4.5:1 for body text and 3:1 for large text and interface components, with large text defined as 18pt, or 14pt bold. It means pointer targets of at least 24 by 24 CSS pixels unless the spacing exception applies. It means a visible focus indicator on everything interactive, no meaning carried by colour alone, and a heading structure that describes the page rather than sizing the text.

For anything custom — a combobox, a tab set, a date picker, a tree view — we specify behaviour against the ARIA Authoring Practices Guide, which defines the expected keyboard interaction and semantics for each pattern. This is the difference between a component that is technically labelled and one that a screen-reader user can actually operate.

The economics are simple. Changing a contrast-failing colour in a token takes a minute. Changing it after two hundred screens exist takes a sprint and a regression cycle. The same principle applies across the whole build, which is why we would rather constrain the palette early than negotiate it late.

Design systems, tokens and component libraries

A design system is what stops a product drifting. Without one, the next screen is designed from scratch by whoever is available, and consistency decays at a rate proportional to team size.

At minimum a system is: tokens for colour, type, spacing, radius and elevation; components with every state documented; content rules for labels, errors and empty states; and a short set of decisions about when to use which. We export tokens in the Design Tokens Community Group format so the same values can drive Figma, a Storybook library and the production code without three people maintaining three copies of the same hex value.

The common failure is not the absence of a system but an over-built one: hundreds of components, elaborate documentation, and a team that quietly ignores it because it does not match what they need to build. Start with what is being used repeatedly, document that properly, and grow the system from real demand rather than from an inventory exercise.

Working with engineering

Handover as a file transfer produces implementations that are subtly wrong everywhere. Handover as a conversation produces the product you designed.

Practically: a walkthrough with the people building it, specifications that answer the questions they will actually have — what happens on a slow connection, what the maximum content length is, which spacing value is intentional and which is incidental — and a design QA pass against the running build before release, not after. That pass includes keyboard traversal and a screen reader on the real interface, because a Figma file cannot tell you what gets announced.

Where we are also building the product, this is simply how the project runs. Where an in-house team is implementing, the handover pack is written for exactly that, and we would rather answer questions for a month than have the system abandoned quietly in the third sprint.

Measuring whether the design worked

The measure has to be agreed before the work starts, or every result becomes debatable afterwards.

What to measure depends on the product: task success rate in a moderated test, completion through a defined funnel, time to first successful action, support contacts about a specific flow, activation, or retention at a set interval. For perceived usability, the System Usability Scale produces a comparable 0–100 score from ten questions and has enough published benchmark data behind it to mean something when compared across studies — Nielsen Norman Group cites an average of 68 across 500 studies, which is a useful reference point precisely because it is not flattering.

Where traffic supports it, an A/B test answers the question outright and should be preferred to inference. Where it does not — most B2B products, most internal tools — a small moderated benchmark before and after is honest, provided you say plainly that it is directional. What we will not do is show a before-and-after screenshot next to a number that moved and imply the two are related.

Where this sits next to our other work

Design rarely arrives on its own. If the thing being designed is a marketing site whose job is to persuade rather than to be used repeatedly, web design is the right discipline and the definition of success is different. If the product is an application people sign into, the design work usually runs alongside application development so that flows, states and permissions are settled once rather than twice. If it is a phone app, platform conventions do a lot of the work and mobile development brings its own constraints on gestures, notifications and store review. And if you need the brand assets that sit around the product — identity, collateral, decks — that is graphic design, a related craft with a genuinely different method.

If you are not sure which of those you are actually buying, describe the problem and we will tell you, including when the answer is that you do not need us yet.