In short
UX is the structural work — does the product solve the right problem, in a flow that makes sense — while UI is the surface expression of that structure; a beautiful UI on a broken UX foundation fails just as surely as a well-structured UX with confusing UI, but they fail for different, identifiable reasons.
The definitions everyone knows
"UX is how it works, UI is how it looks" is the standard shorthand, and it's not wrong — but it's abstract enough that it doesn't change how most teams actually operate, which is the real problem worth addressing. The distinction matters practically, not just definitionally.
Why conflating them causes real damage
When a team treats UI and UX as the same activity, a project can spend all its energy on visual polish — color, typography, micro-interactions — while the underlying flow logic, information architecture, and problem-fit go essentially unexamined. The result is a beautiful interface for a product that doesn't actually solve the right problem in a sensible way, which is a much more expensive failure to fix than a plain interface with solid underlying structure.
What UX work actually looks like
UX work is largely invisible in a finished screenshot — it's the discovery and structure phase: understanding the actual problem, mapping the flow a user takes to solve it, deciding what exists and how it connects. A well-executed UX phase produces boxes-and-arrows diagrams and validated flows well before any visual design begins.
What UI work actually looks like
UI work takes an already-validated structure and gives it visual form — hierarchy, color, spacing, type — that makes the structure legible and pleasant to use. Good UI work can meaningfully improve how well a sound structure is perceived and used; it cannot fix a structure that doesn't actually make sense.
Why the order matters
Doing UI work before UX work is validated is the single most common cause of expensive late-stage redesigns — a polished interface built on an unresolved structural question tends to reveal that unresolved question anyway, just later and after more has been invested in visual details that may need to change along with the structure.
The practical takeaway
Treat UX and UI as sequential, distinct kinds of work with different outputs and different validation methods — not synonyms, and not activities that happen simultaneously by default. A team that can name which phase they're in, and hasn't skipped the first one to get to the more visually satisfying second one, tends to ship more coherent products with fewer expensive surprises.
Primary source: Nielsen Norman Group documents the specifics referenced above.
Common questions
Can UI and UX work happen at the same time?
Some overlap and iteration is normal, but skipping UX validation (flow logic, structure) to move straight to UI (visual design) is the most common source of expensive late-stage redesigns.
Does great UI ever compensate for poor UX?
It can improve the perceived quality of a sound structure, but it can't fix a structure that fundamentally doesn't solve the right problem or doesn't flow logically — the underlying issue tends to surface anyway.
Is one of UI or UX more important than the other?
Neither — they serve different purposes and both matter, but UX validation generally needs to come first, since UI work is meant to express a structure that's already been validated, not substitute for validating it.
