A two-person startup posts a job listing: "Looking for a designer to handle UX, UI, and general design for our app." One applicant asks, reasonably, what the difference is supposed to be. The founder doesn't have a great answer — and they're not alone. "Design," "UX," and "UI" get used as near-synonyms in job posts, agency pitches, and casual conversation, even though they describe three different kinds of work with different inputs, different outputs, and different ways of being wrong.
Design, used broadly, is the umbrella — the overall practice of shaping something to serve a purpose, whether that's a poster, a chair, or a checkout flow. In a software context, "design" often gets used loosely to mean "the visual stuff," which is really the UI half of the job.
UX (user experience) is concerned with the structure underneath the visuals: what steps does someone take to accomplish a task, where do they get confused, what happens when something goes wrong. A UX deliverable might be a flowchart, a set of wireframes, or a research report — often nothing that looks "designed" at all.
UI (user interface) is the visual and interactive layer that sits on top of that structure: which button is purple, how much padding a card has, what a hover state looks like, whether a loading spinner appears for 200ms or 2 seconds. UI is where structure becomes something a person can actually see and touch.
The overlap is real, which is why the confusion persists. A graphic designer making a poster is doing "design" without any UX component — there's no task to complete, no flow to structure, just a message to communicate. The moment you introduce a goal a user is trying to accomplish — sign up, check out, find an answer — you've entered UX territory, whether or not anyone on the team has that title. Small teams often have one person doing both without distinguishing them, which works fine until the product gets complex enough that visual polish and task flow start pulling in different directions.
UX and UI are more like sequential layers than separate departments. UX decides that a signup form should ask for email first, then password, then nothing else until after the account exists. UI decides how that email field looks, what happens when validation fails, and whether the "Continue" button is disabled until the field is filled in. You can have excellent UX with ugly UI (a form that's logically perfect but visually dated) and you can have excellent UI with poor UX (a beautiful form that asks for twelve fields before letting someone in).
Take a single element: the "Pay Now" button on a checkout page. Here's how each discipline touches it:
Ship any one of these badly and the whole button fails, even if the other two are excellent. A gorgeous button that submits the form twice on a slow connection is a UX bug wearing a UI costume.
Most of the friction around these terms isn't about correctness — it's about two people using the same word to mean different things in the same meeting. A cheap fix: when someone says "the design isn't working," ask them to point at whether they mean the flow (UX) or the look (UI). Groups like the Nielsen Norman Group have published fairly stable definitions of UX going back decades, and it's worth having your team read even a short summary once so "UX" stops being a catch-all complaint and starts being a specific, testable claim.
If you're the one person currently covering design, UX, and UI at a small company, the UI layer is usually where a head start pays off fastest — a solid visual foundation (spacing, color, component states already worked out) frees up your attention for the structural decisions that are harder to template. UIXDraft's template bundle exists for exactly that gap.
Job titles in this space are inconsistent across companies, but a few patterns hold often enough to be useful when you're reading a posting or deciding what to call your own role:
None of these titles are standardized by law or industry body — a "UX Designer" at one company might do exactly what a "Product Designer" does at another. Treat the title as a rough signal, not a precise spec, and ask what the day-to-day work actually involves before assuming.
If you're not sure which of the three disciplines your current problem needs, ask which sentence best describes the complaint you're hearing. "Users don't know what to do next" or "people abandon this halfway through" points to UX. "It works fine but looks unfinished or untrustworthy" points to UI. "Our messaging feels inconsistent with who we are as a company" points to design in the branding sense. Most real complaints are a blend, but naming the dominant one first keeps the fix focused instead of triggering a full redesign for what might be a one-paragraph flow fix.
No — they're historically separate fields that happen to overlap in software. Graphic design comes from visual communication (posters, branding, print); UX comes from human-computer interaction and cognitive psychology. A UX designer can be a poor visual designer and still be excellent at their actual job: making tasks easier to complete.
At small scale, yes — plenty of "product designers" do all three well. The risk isn't competence, it's time: research and structural UX work take uninterrupted thinking that's easy to skip when visual deadlines are looming, since visual progress is more visible to stakeholders than a well-considered flow.
UX fundamentals, not UI. Learning to map a user's task from start to finish — and noticing where they'd get stuck — pays off regardless of who eventually builds the visuals, and it's the layer most likely to sink a product if it's wrong, even when the UI looks polished.