There is a quiet conversation that happens on most product teams. Someone says “we need UX,” and someone else nods and produces a UI mockup. Three weeks later, a beautiful interface ships — and the product still does not work for the user.
UX and UI are not the same discipline. Hiring one when you need the other is the most expensive mistake we see in product teams, and the most common.
The shortest possible answer
UX is what the product does for the user. UI is what the product looks like. UX is research, flows, information architecture, decision logic, and time-to-value. UI is colour, type, layout, visual hierarchy, motion, and component design. They overlap — a well-designed interface improves usability, and a well-designed flow needs visual clarity — but the work is genuinely different, and so are the people who do it well.
What UX actually does
UX is the practice of designing what the product does for the person using it. The deliverables are not screens — they are decisions about how the product behaves.
A real UX engagement produces some combination of: user research (interviews, surveys, usability tests), audience and persona definitions, information architecture (how content and features are organised), user flows (the step-by-step journey from intent to outcome), interaction logic (what happens when this button is pressed, in this state, with this data), accessibility requirements, content design (the actual words shown to users), and acceptance criteria the engineering team will build against.
A UX designer can ship valuable work without ever opening Figma’s high-fidelity tools. Wireframes, flow diagrams, interaction notes, and a shared understanding with engineering — that is the output of UX work, even when the visual design has not been touched.
What UI actually does
UI is the practice of designing how the product looks and feels — the visible layer. The deliverables are screens, components, and the rules that govern them.
A real UI engagement produces: visual hierarchy decisions (what’s most important on each screen and how the eye finds it), colour and type systems applied to product surfaces, a component library (buttons, inputs, cards, modals, tables — each with all their states), iconography, illustration where needed, motion language for interactive states, responsive behaviour across devices, and a design system the engineering team can build against directly (in code, not just in Figma).
A UI designer who skips the UX work either guesses at the right behaviour and gets it wrong, or implements someone else’s UX correctly. The visual layer is downstream of the decisions UX makes.
Where the two overlap
The boundary is not clean, and pretending it is wastes time. Three areas where they overlap legitimately:
Visual hierarchy is part of usability. A button that looks like the primary action but is not actually the primary action is a usability failure. UI decisions about size, weight, and colour affect what users do, not just how the page looks.
Component states are interaction design. Hover, focus, active, disabled, loading, error — these are visual states, but they encode behaviour. A loading spinner that does not appear for 200ms after the click feels broken, even if the visual treatment is perfect.
Motion is decision feedback. When a user submits a form, the motion of the success state tells them what happened. Motion design is visual; motion timing and choreography is interaction design.
In a healthy team, UX and UI work in conversation. The designer with the user-research notes sits next to the designer working in Figma, and they ship a coherent product together. In an unhealthy team, UX produces wireframes and throws them over the wall; UI redesigns the flow because the wireframes were “ugly.” Both fail.
The most common confusion in hiring
The job titles in this discipline are notoriously inconsistent. “UX designer” sometimes means a researcher with no visual chops; sometimes it means a senior designer who does both. “UI designer” usually means a visual specialist; occasionally it means someone trained only on Material Design defaults. “Product designer” tries to cover both and often does one well and one poorly.
When you hire, ask for portfolio work that proves the specific skill you need. UX hire: ask for a case study with research methodology, a user flow, and a decision they made that they later proved correct (or wrong). UI hire: ask for a component library, a colour system with accessibility ratios, and a screen they redesigned with the rationale.
“Senior product designer with full-stack UX and UI” is what you usually need, and it is the rarest hire in the catalogue. If you cannot find that profile, hire a senior UX person plus a senior UI person and pay them both. Hiring one and hoping they cover both is the most reliable way to ship a product that looks polished but does not work.
When teams confuse the two — three patterns
Pattern one: design without research. A team hires a UI designer and skips the UX work. The product ships looking polished, with a beautiful component library and considered visual hierarchy. Six weeks after launch, support is overwhelmed by users who cannot find the export button, the onboarding flow that nobody completes, and a settings page that contains six options nobody wants. The fix costs more than the original UI work because it requires rebuilding flows, not just restyling them.
Pattern two: research without design. A team hires a UX consultant who produces a 60-page audit, eight personas, twelve user flows, and a roadmap. Engineering reads it, gets stuck implementing it, ships something that resembles the recommendations but looks like an internal admin tool from 2014. Real users do not respond — not because the underlying flows are wrong, but because the visual layer signals “this is unfinished.” Both halves of the discipline need to ship together.
Pattern three: developer-led UI. A team without designers asks the engineering team to “just use Material Design” or “make it look like Linear.” The result is a UI that follows the patterns of those systems but does not encode any decisions specific to the product or its users. Familiar, but generic. The brand never establishes its own voice; the product never feels purpose-built.
How to choose
Three questions:
- Do you have user research? If no, you need UX. The visual work cannot be evidence-based without it.
- Do you have a coherent visual system? If no, you need UI. The UX work cannot ship without a visual layer.
- Do you have engineers building right now? If yes, you need both — sequentially is fine, but they have to be on the same team.
Hiring decision: prefer a senior person who does both, hire two specialists if that profile is not available, never hire one and hope they cover the other. The pretense of “full-stack product design” from a junior is the cause of most product-design dysfunction.
The single-line version
UX answers does this work? UI answers does this feel right? A great product needs both, in conversation. Hiring one when you need the other costs more to fix than to do correctly the first time.
Common questions
What’s the difference between UX and UI design?
UX (user experience) is what the product does for the user — research, user flows, information architecture, decision logic, content design, accessibility requirements. UI (user interface) is what the product looks like — colour, type, components, visual hierarchy, motion, responsive layouts. They overlap in visual hierarchy, component states, and motion, but the core work is genuinely different. UX is often invisible (research, flows, decisions); UI is always visible (the screens you ship). A well-designed product needs both, in conversation.
Should I hire a UX designer or a UI designer first?
Hire the discipline you currently have least of. If you have engineers building features but no research or flows, hire UX first — the visual work cannot be evidence-based without the underlying decisions. If you have flows and wireframes but the product looks unfinished, hire UI first. If you can find a senior product designer who genuinely does both, hire that person and pay them what the work is worth. Hiring one specialist and asking them to cover both disciplines is the most reliable way to ship a product that fails on one axis or the other.
Can one designer do both UX and UI?
A senior product designer can — but the profile is rare and expensive. Most designers who claim full-stack product capability are either strong in one half and adequate in the other, or strong in neither and excellent at presenting their work as if they were strong in both. The honest test: ask for a portfolio piece where the candidate produced both the research-backed user flow AND the high-fidelity visual implementation, and can talk about a decision they made that they later proved correct (or wrong) with data. That portfolio piece is the qualifying credential, not the job title.
What’s the difference between UI design and graphic design?
Graphic design is the broader discipline — typography, layout, hierarchy, composition, applied to any medium (print, packaging, brand identity, posters, signage). UI design is graphic design applied to interactive software interfaces, with the added constraints of state (hover, focus, active, disabled, loading, error), responsive layout, motion, accessibility, and engineering handoff. A graphic designer with no software-product experience can struggle with UI’s stateful behaviour and the requirement to design for real users, not just for aesthetic outcomes. A UI designer with no graphic-design fundamentals tends to ship technically correct but visually undifferentiated work.
Do I need a UX audit before building a new product?
If you have an existing product to audit, yes — an audit is almost always cheaper than redesigning and faster than guessing. A typical UX audit takes 1–2 weeks and produces a written report covering user flows that drop off, accessibility issues, content design gaps, and a prioritised fix list. If you do not yet have a product, you do not need an audit — you need discovery research (interviews, competitive analysis, hypothesis design) before any UI work begins. The order is always: research → flows → wireframes → visual design → build, even if some steps compress to days rather than weeks.
Need both halves of the discipline, working in conversation?
We design UX and UI as one engagement — research through to design system, on the same team.