Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a UX/UI Designer

A UX/UI designer designs digital product experiences that are useful, usable, and visually coherent, which is a perfectly reasonable job description until you remember that the user does not read the labels, the design system is a beautiful consistent set of components the engineers implement as they remember them, and the prototype that worked in the demo does not work in the field because the field has a user in it. You learn to translate "make it nice" into research, information architecture, interaction design, visual design, and accessibility — which is a feature, a legal requirement, and a moral baseline that arrives in that order of priority and should arrive in the reverse. The pixel the designer fought for is the pixel the user never noticed, and the pixel the designer surrendered is the pixel the user stumbled over for a year, which is the central irony of the craft and the reason designers learn to lose battles very carefully. This guide travels from observing one usability test to setting design practice across an organisation, with practical stops at research, information architecture, prototyping, design systems, handoff, and the recurring discovery that a screen marked "approved" is merely approved to the date of the last person who looked at it with the user in mind. The grand objective is an experience users can use; the daily evidence is usually a flow a user can complete, a component an engineer can build, and a prototype that fails to surprise anyone except the stakeholder, who has learned not to be surprised by their lack of surprise.

Things to recognise

• A user request describes a screen the user already imagined; the underlying need is usually larger, smaller, or adjacent, and building the request verbatim is the fastest way to ship the wrong screen on time.
• Design changes carry hidden cost: each one must be specified, built, tested, documented, and supported, so a backlog of design requests that grows without pruning becomes a museum of screens no one visits.
• Confirm the user, the task, and the evidence before drawing the screen, because a correct screen for the wrong task is still impressively wasteful and surprisingly persistent.

Take the useful exit

Level 1 · Novice

Watch the user before drawing the screen they will ignore

You observe usability tests, interview notes, and existing screens without committing design, learning how a perfectly polite interface can mislead a user for years after its product has moved on.

You begin with read-only artifacts: usability test recordings, interview notes, survey results, existing screens, a design system someone else maintains, and a feedback board expressing recent opinions about recent behaviour. User research is planning and running interviews, surveys, and usability tests to understand users, while visual design applies typography, color, and layout to create coherent interfaces. You review these with researchers, engineers, product managers, and an experienced designer so that everyone can trace how a vague complaint becomes a screen a user can complete before anyone draws a pixel whose rationale is still "it looked better this way."

Suppose a product manager reports that "users hate the new dashboard." In a research review, you watch the recordings and find that three users mentioned the dashboard, two of them in the same week, one of them while describing a completely different task. You draft a set of observed behaviours, list the jobs the dashboard would satisfy, and note that none of the three users looked at the same area of the screen. One brisk observation summary is an anecdote with good posture, not a design; but it prevents the team from commissioning a dashboard redesign for a job that one user performs twice a month with a perfectly good search.

Words from the spaceship manual, translated

User research: The practice of planning and running interviews, surveys, and usability tests to understand users before deciding what to design. It is the practice of finding out what is true, which is faster and cheaper than designing something and then finding out.
Usability test: A structured session in which a real user attempts a real task with the product while observed. It is how the team learns whether the screen works, and a test that the designer runs on themselves is a test of the designer's patience, not the screen.
Visual design: The application of typography, color, layout, and hierarchy to create coherent interfaces. It turns "it works" into "it can be understood at a glance," and a visual choice with no hierarchy is a screen that shouts every word at once.
Observation summary: A record of what users did, what they said, and where they struggled, written before any conclusion. It describes behaviour, not solution, and a summary that mentions a button is a solution in a costume.