What Does UI/UX Design Actually Include?

The most expensive thing a design can do is be beautiful and wrong. Research exists to stop that: who are the actual users, what are they trying to complete, what do they already use, and where do they currently give up? That produces personas that constrain decisions and a mapped user journey — the route someone takes from arriving to finishing the thing they came for.

The journey map is the artefact that saves money, because it exposes the steps nobody scoped. A checkout looks like one screen until you map it and find you also need an address edit, a failed-payment retry, a receipt, and a way for a human to fix an order — none of which appeared in the brief. Finding those in a diagram costs an afternoon. Finding them in a built product costs a sprint each, which is one of the standard reasons software projects fail.

This is also the stage that decides what NOT to build. A well-mapped journey routinely removes a third of a wishlist because the steps turn out to serve nobody — and that removal is worth more than any visual polish you buy later.

Wireframes are deliberately ugly — grey boxes, real labels, no brand. That is the point: with no colour to react to, everyone argues about the right thing, which is whether the flow works. Reviewing a coloured screen reliably produces feedback about the shade of a button and silence about the missing step.

The prototype is the wireframe made clickable. It is the first honest test of the product, and it is where you discover that a flow reads fine as a diagram but feels like three steps too many in the hand. Getting a prototype in front of even five real users — not colleagues — is the highest-yield hour in the entire project.

A prototype is also the most precise brief a developer can receive. "Build this" against a clickable artefact removes an enormous amount of interpretation, and interpretation is where estimates go wrong.

The deliverable that matters is a system: a colour palette with defined roles, a type scale, a spacing grid, and components — buttons, inputs, cards, modals, empty states — each with every state defined. Default, hover, active, focus, disabled, loading. A design that specifies only the happy path guarantees a developer will invent the rest, and they will invent it differently on every screen.

The test for a system is simple: can a developer build a screen you never designed, and have it look like it belongs? If yes, you bought a system. If they have to come back for every new screen, you bought screens — and you will keep paying for screens forever.

This is also what keeps a product coherent after the designer leaves. A spacing grid and a token set survive handover; a Figma file of finished pages does not.

Accessibility retrofitted is expensive and always partial; designed in, it is nearly free. The decisions belong in the design stage because they are design decisions: contrast, target size, focus order, and whether meaning is ever carried by colour alone.

The concrete standards are unglamorous and checkable. Body text at a contrast ratio of at least 4.5:1 against its background, and large text at 3:1 — a WCAG AA baseline. Tap targets big enough to hit on a phone without precision. A visible focus state on every interactive element, because a keyboard user who cannot see where they are is simply locked out. And never using colour as the only signal: an error is red AND carries an icon AND says what went wrong, so it still reads for a colour-blind user and in a screenshot.

None of this is charity. It is the same work that makes an interface usable one-handed on a train, and it is increasingly the difference between passing and failing a procurement review.

Most screens in a product do not need optimising. Two or three do — the pricing page, the signup, the checkout, the quote request — and those deserve disproportionate attention, because a small improvement there pays for the whole engagement.

The work is unglamorous: reduce the number of decisions per screen, make the primary action obviously primary and everything else visually quieter, remove fields nobody reads, state the price and the commitment plainly, and answer the objection at the moment it occurs rather than on a separate FAQ page. Most conversion gains come from removing friction and ambiguity, not from adding persuasion.

Judge this with a stopwatch, not an opinion: can a stranger tell what this page is for, and what happens if they click, within a few seconds? If not, no amount of visual craft rescues it.

AI is real leverage in the exploratory half of design. It generates variations of a layout in minutes, drafts realistic placeholder content instead of lorem ipsum, produces imagery for concepts, and shortens the gap between an idea and something you can react to. Used well, it means more options explored before committing.

What it does not do is decide. It has no view on which of your users abandon at step three, it cannot tell you which feature to cut, and it will happily produce a confident, attractive layout for a flow that should not exist. Judgement — what to build, what to remove, what the interface is actually for — stays human, and that judgement is the part you are hiring.

That is the same balance we apply across the studio: AI absorbs the repetitive work so senior time goes to architecture, data modelling, and the decisions that are expensive to get wrong.

Ask what you will receive, in artefacts rather than adjectives. A proposal that says "modern, clean UI" is describing an aesthetic; a proposal that says "personas, journey map, wireframes, clickable prototype, component library with all states, accessibility spec" is describing work.

Then ask the handover question: what does a developer get, and can they build a screen that was never designed? That single question separates a system from a folder. And ask who owns the files — you should, along with the source, exactly as you should own the code.