UX vs UI and the Design Process

Ask a room of ten designers to define UX and UI in one sentence each, and you'll get ten different answers that all sound roughly right and are all slightly wrong. "UX is research, UI is visuals" is the answer most candidates give in an interview, and it's the answer that signals you've read a glossary rather than shipped a product. The real distinction is about scope, not discipline — and the process frameworks built around that distinction (Double Diamond, Design Thinking, human-centered design) are what interviewers are actually probing for when they ask "walk me through your design process." They're not asking you to recite a diagram. They're checking whether you can adapt one to a two-week sprint with no research budget, because that's the job.

This subject is the opening piece of the UI/UX Design Interview track — the vocabulary and mental models the rest of the track (research, IA, interaction design, visual design, testing) builds on without re-deriving. Wherever a distinction here changes what you'd actually do differently on a project, it says so.

UX vs UI: Scope, Not a Research/Visuals Split

User experience (UX) is the end-to-end quality of someone's interaction with a product — whether they can find what they need, whether the flow matches how they think about the task, whether the product respects their time and gives them confidence they did the right thing. It spans research, information architecture, interaction design, content, and yes, visual design, because a beautiful screen with the wrong information architecture is still a bad experience. UX is a property of the whole system, not a phase or a deliverable.

User interface (UI) is the specific surface someone touches — the screens, components, typography, color, spacing, motion. UI is a subset of what shapes UX, not a separate discipline running in parallel. A product can have excellent UI (polished, on-brand, pixel-perfect) and terrible UX (the checkout flow asks for your shipping address twice because two teams built it independently) — this is the example interviewers reach for constantly because it's the cleanest illustration that the two are not opposites or complements, they're different altitudes of the same problem. UI is never "wrong" or "right" independent of whether it serves the UX; a gorgeous button that triggers the wrong action is bad UI because it's bad UX at the interaction layer.

Where the "research vs visuals" answer breaks down. A visual designer who chooses a type scale that makes an error message unreadable has made a UX decision through a UI lever. A UX researcher who never validates whether users can actually parse the resulting screen has left half the job undone. In most teams under ~30 people, one person does both, which is why the industry increasingly hires "product designer" — a title that assumes the split is a spectrum of the same job, not two jobs. Naming this explicitly is a stronger interview answer than the two-clause dictionary definition, because it shows you understand why the boundary is blurry in practice, not just where a textbook draws it.

The Double Diamond

The UK Design Council's Double Diamond (2004, still the most-cited process framework in design interviews) models design as two diverge-then-converge cycles, not one straight line from problem to solution:

        DISCOVER            DEFINE            DEVELOP           DELIVER
      (diverge)           (converge)         (diverge)         (converge)
   ◇─────────────────◇──────────────────◇─────────────────◇──────────────────◇
   Explore the        Synthesize into    Explore many       Narrow to one,
   problem space       one clear          possible            build, test,
   broadly — user      problem            solutions —         and ship it
   research,           statement /        sketches,
   competitive         "how might we"     prototypes,
   analysis, data                        concepts

• Discover (diverge): understand the problem before assuming you know it — user research, stakeholder interviews, analytics, competitive scans. The mistake candidates make here is skipping straight to solutions ("we should add a filter") without establishing that filtering is actually the problem.
• Define (converge): synthesize everything from Discover into a single, sharp problem statement — often a "How might we…" framing. This is the step most junior work skips entirely, going straight from a pile of research notes to a Figma file.
• Develop (diverge): generate multiple candidate solutions before committing to one — sketches, low-fidelity concepts, competing approaches. The point of staying divergent here is to avoid anchoring on the first idea that came to mind during Define.
• Deliver (converge): narrow to the strongest concept, build it out, test it, and ship. This is where wireframing, prototyping, and usability testing (later subjects in this track) live.

The critical interview point: the two diamonds are not the same activity twice. The first diamond is about the right problem; the second is about the right solution. A candidate who conflates them — jumping to Develop-stage prototypes while still in Discover — is a common red flag interviewers listen for, because it describes a designer who solutions before they understand the problem.

Design Thinking

Design Thinking (popularized by IDEO and Stanford d.school) is a five-stage model — Empathize → Define → Ideate → Prototype → Test — that overlaps heavily with the Double Diamond but is framed as an iterative loop rather than two clean diamonds, and leans harder on empathy as the explicit first step.

The meaningful difference isn't the stage names, it's the explicit loop-back. Design Thinking is drawn as a cycle where Test can send you back to Empathize, not a one-way pipeline — it's a better model for ongoing product work (a live product with a backlog) than for a single, bounded engagement, which is where the Double Diamond's two discrete diamonds fit more naturally (a research phase, then a design phase, each with a clear end). In an interview, naming both and explaining when you'd reach for which is stronger than treating them as interchangeable synonyms for "the design process" — they answer different shapes of project.

Human-Centered Design (ISO 9241-210)

Both frameworks above are instances of a broader principle formalized in ISO 9241-210, the standard defining human-centered design (HCD). Its core requirements, independent of which named process you use:

1. The design is based on explicit understanding of users, tasks, and environments — not assumptions or stakeholder opinion standing in for user data.
2. Users are involved throughout design and development — not just at the end for validation.
3. The design is driven and refined by user-centered evaluation — testing isn't a final QA gate, it's a continuous input.
4. The process is iterative — you expect to revisit earlier decisions as you learn more, not treat each phase as permanently closed.
5. The design addresses the whole user experience — again, the "UX is everything, UI is a surface" point from the first section, formalized.

HCD isn't a competing framework to Double Diamond or Design Thinking — it's the underlying philosophy both of them implement. If an interviewer asks "what is human-centered design," the strong answer isn't a restatement of "design thinking about humans," it's these five concrete requirements, because they're falsifiable: you can point to a project and say which one was skipped.

Lean UX and Agile UX vs. Waterfall Handoff

The Double Diamond and Design Thinking describe what the phases are; they don't say how tightly design and engineering are coupled in time. That's a separate axis:

• Waterfall / big-design-up-front: research → design → a complete, polished spec → handoff to engineering, who build it largely without further design involvement until QA. Low iteration cost within design, high cost of being wrong (a flawed assumption from Discover isn't caught until the built product ships).
• Lean UX: borrows from Lean Startup — design in small, testable increments, build-measure-learn loops, and explicitly favors a rough prototype validated with 5 users over a polished spec validated with none. The artifact isn't "the deliverable," it's the validated learning.
• Agile UX: design work is broken into units that fit inside sprints, designers work roughly one sprint ahead of engineering (a "design sprint zero" or a dedicated design track), and the two disciplines iterate together rather than handing off once.

Why this matters for the process-walkthrough question. A candidate who describes a rigid Discover→Define→Develop→Deliver sequence taking six weeks, applied identically regardless of context, hasn't actually described a process, they've described a template. A strong answer says which parts compress under a two-day deadline (skip formal Discover, use existing analytics and support tickets instead of new research; combine Define and Develop into one working session) and which parts don't compress no matter the timeline (you can't skip Test entirely without accepting real risk — but you can shrink it from a 20-participant study to a 3-person hallway test).

How the Roles Blur in Practice

Job titles map only loosely onto the UX/UI distinction, and knowing the real landscape signals you've worked on a team, not just read about one:

• UX Researcher — owns Discover/Empathize: interviews, usability studies, synthesizing data into insight. Rarely touches visual tools.
• UX Designer / Interaction Designer — owns flows, information architecture, wireframes, interaction patterns. May or may not do final visual polish.
• UI Designer / Visual Designer — owns the visual system: typography, color, spacing, component appearance. Increasingly rare as a standalone title outside large orgs with mature design systems.
• Product Designer — the now-dominant title at small-to-mid companies, explicitly spanning research-lite, UX, and UI in one role, because most teams can't afford to split the work three ways.
• UX Writer / Content Designer — owns microcopy, error states, onboarding copy (covered in ux-writing-and-microcopy); increasingly considered part of UX proper, not a late-stage add-on.

The interview-relevant takeaway: when a job posting says "UI/UX Designer," it is almost always describing a Product Designer role covering the full span from Discover to Deliver, at a company too small to specialize. Answering "what's your process" with an assumption that research, design, and testing are three different people's jobs is a mismatch signal for that kind of role — the stronger answer names what you'd do yourself vs. what you'd need from a researcher or engineer, given the team size implied by the question.

The Interview Trap: A Process Recited, Not Adapted

The single most common weak answer to "walk me through your design process" is a memorized recitation of Double Diamond or Design Thinking stage names with no connection to a real project's constraints. Interviewers have heard the five-stage list hundreds of times; it proves you can read a diagram, not that you can design under pressure. What separates a strong answer:

• Naming the constraint that shaped the process, not just the process: "we had one week and no research budget, so I skipped formal Discover and used support-ticket themes and a competitor teardown instead."
• Being explicit about what got cut and why it was an acceptable risk, not pretending nothing was cut.
• Connecting a synthesis step to a concrete decision — "the journey map showed the drop-off was at account creation, not checkout, which is why we redesigned that screen first" — rather than listing journey maps as an artifact with no consequence attached.
• Knowing when the process itself is the wrong tool — a one-off internal tool for three colleagues doesn't need a Discover phase at all; treating every problem with the full five-stage ceremony is itself a sign of process-over-substance thinking.