The standard answer is that UI is how it looks and UX is how it works. That is repeated everywhere and it does not survive five minutes in a real project, because a button that looks wrong works wrong.
A more useful split is by the question each one answers. UX asks what should exist, and in what order. UI asks what it looks like once it exists. The first is a set of decisions about the problem; the second is a set of decisions about the artefact.
What each one actually decides
| Decision | Belongs to |
|---|---|
| Should this feature exist at all? | UX |
| How many steps is this task? | UX |
| What happens when it fails? | UX |
| What does the failure message say? | Both — UX decides what; UI decides how it reads |
| Which of these is the primary action? | UX decides; UI makes it obvious |
| How big is the button? | UI |
| What is the spacing scale? | UI |
| Does the brand feel calm or energetic? | UI |
Why the distinction gets abused
Two failures follow from taking the split too literally.
“That’s a UI problem, not my job.” A flow designed without regard for how it will be rendered produces screens that cannot be built as drawn — eleven fields that must fit above the fold, a table with nine columns on a phone. The constraint was always there; ignoring it just moved the problem downstream.
“Make it look better.” A visual pass applied to a broken flow produces a beautiful screen that still asks the wrong question. This is the more expensive failure, because it is invisible until users arrive.
What each role produces
- UX outputs: a map of the task, the decisions a user has to make and in what order, the states that exist (empty, loading, error, partial, full), and what happens at each one.
- UI outputs: the type scale, the spacing system, the colour roles, the component states, and the rules that keep 200 screens looking like one product.
The state list is the piece most often skipped by both. Everyone designs the full, happy screen; nobody designs the one with zero items or the one where the request timed out — which are the screens that decide whether people stay. We went through why in six design principles.
Which should you learn first?
UI, and not because it matters more. Because the feedback loop is visible: you move something four pixels and you can see whether it improved. That loop builds judgement fast.
UX judgement takes longer because the feedback arrives weeks later, through other people, and is easy to rationalise away. You need to have watched several people fail at something you designed before the instinct forms — and there is no shortcut for that.
The practical route: learn to build interfaces properly, then start watching people use what you built. The second half is what turns a UI designer into a designer.
Hiring: what the titles really mean
| Title in the advert | Usually means |
|---|---|
| UI Designer | Visual work inside an existing product |
| UX Designer | Flows and structure; sometimes research |
| Product Designer | Both, plus arguing about what to build |
| UX Researcher | Studies only — no design output |
| UI/UX Designer | One person doing everything, usually at a small company |
If a job advert says UI/UX and the team is under twenty people, expect to do research, flows, visuals and probably some front-end. That is not a warning — for a lot of people it is the most interesting version of the job. It is just worth knowing before you accept.
Common questions
Can one person do both well?
Yes, and most good designers do. What is hard is doing both at the same moment — deciding what should exist while also deciding what it looks like tends to produce a design that justifies its own visuals. Separate the sessions.
Does UX need research?
It needs contact with users, which is not the same as a formal research programme. Five people thinking aloud gets you most of the way; support tickets get you the rest for free.
Where does accessibility sit?
In both, and it is not a separate discipline. Keyboard order and clear states are UX; contrast and focus styles are UI. The eight fixes split neatly across the two.
Do developers need to know this?
Enough to notice when a design has no error state and to ask about it before building. That single question, asked early, prevents a large share of the rework on any project.
Leave a Reply