Sit in enough meetings and you'll hear someone defend a budget line called "UX," another called "CX," and a consultant pitching "service design", and quietly wonder whether they're three things or one thing wearing three lanyards. They're one thing, viewed at different distances. Interaction design (IxD) is the screen up close. UX is the whole product in your hands. CX is every encounter you ever have with the company. And service design, with its blueprint, is the only one of the four that turns the camera around to face your own organisation. Confuse the zoom levels and you spend a fortune polishing a button when the problem was a handoff three departments away.

The quick version

  • They nest, they don't compete. IxD lives inside UX, UX lives inside CX, and service design is the discipline that makes the experience deliverable from the inside.
  • UX is broader than the screen. The founding definition covers every aspect of a person's dealings with a company, not just how a page looks.
  • The blueprint crosses the line of visibility. A journey shows the customer's pain; a service blueprint shows the backstage handoff that caused it.
  • The leadership move is altitude. Diagnose at what level the problem actually lives, then commission the matching tool, not the one with the loudest budget.

The idea in depth: four names, one nested system

Start with the term everyone uses and few define. "User experience" wasn't coined on a screen, it was coined to get off one. Don Norman, who created the phrase for his group at Apple in the early 1990s, defined it with Jakob Nielsen as covering "all aspects of the end-user's interaction with the company, its services, and its products" (Norman & Nielsen, Nielsen Norman Group, 1998). They were emphatic about the boundary: "It's important to distinguish the total user experience from the user interface (UI), even though the UI is obviously an extremely important part of the design." A flawless interface on a product that doesn't meet a real need is still a poor experience. The international standard says the same in colder language, ISO 9241-210 defines UX as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service" (ISO 9241-210:2019). Note anticipated use: the experience starts before the first click.

So if UX is the whole encounter with one product, the other three are simply different focal lengths on the same lens. Interaction design zooms in: the specific behaviour of a thing as you use it, what the button does, how the form responds, the feedback after a tap. Customer experience zooms out: the sum of every interaction a person has with the brand across its whole lifetime, the ad, the salesperson, the app, the invoice, the call centre, the renewal. UX is one product; CX is the company. So the move is: when a team brings you an "experience problem," your first question isn't "what should we build" but "at what zoom level does this live?" A clumsy checkout is IxD. A product that's lovely to use but impossible to cancel is UX. A great app undermined by a hostile billing department is CX. Three different fixes, three different owners, and naming the level out loud stops the room defaulting to whichever budget is biggest.

flowchart TB
    CX(["CX, every encounter with the company
ads, sales, support, billing, renewal"])
    CX --> UX(["UX, one whole product or service
does it meet the real need, end to end"])
    UX --> IXD(["IxD, the moment-to-moment behaviour
buttons, forms, feedback, flow"])
    SD(["Service design, turns the camera around:
the people, systems & handoffs that deliver all of it"])
    SD -.-> CX
    SD -.-> UX
The acronyms are nested zoom levels of one discipline. Service design is the odd one out, it faces inward, at how the experience gets produced. Leaders Loop

Where the camera turns around: service design & the blueprint

The first three labels all describe the experience from the customer's side of the counter. Service design is the discipline that asks the harder question: what does it take, on our side, to deliver that experience reliably? Its signature tool is the service blueprint, and it's older than the screen-era jargon by decades. Banker G. Lynn Shostack set it out in her 1984 Harvard Business Review article, "Designing Services That Deliver." Her complaint was that services were being run as something "intangible and ephemeral," improvised by trial and error, when they could be drawn, measured and debugged like a manufacturing process.

A blueprint stacks the customer's actions on top of everything happening behind the scenes, divided by a line of visibility, the boundary between what the customer can see (frontstage) and the staff actions, systems and support processes they can't (backstage). The Nielsen Norman Group, the usability research firm, frames the blueprint as the natural "part two" to a journey map: the journey map finds where it hurts; the blueprint shows which internal handoff caused it (Gibbons, NN/g, "Service Blueprints: Definition"). That distinction is the whole reason the tool earns a leader's attention. Most customer pain isn't created at a touchpoint, it's created in a handoff below the line, between two teams that each own their box and neither owns the seam, and it only surfaces where the customer takes the hit. Here's the practical move: when a journey map exposes a sharp dip, resist redesigning the screen the customer was looking at. Blueprint that one moment downward, past the line of visibility, until you find the orphaned handoff no team owns. That orphan is the fix, and the first thing it needs is an owner (see decision rights & escalation).

UX is one product. CX is the company. The blueprint is the only tool that looks at how the company actually makes it.

flowchart TD
    A(["Customer action:
'Why was I charged twice?'"]) --> B(["Frontstage:
the support agent the customer reaches"])
    B --> C{", line of visibility, "}
    C --> D(["Backstage:
agent can't see the billing ledger"])
    D --> E(["Support & billing systems
were never connected"])
    E --> F(["The orphaned handoff:
no team owns this link"])
The dip the customer feels (top) traces down past the line of visibility to a handoff nobody owns (bottom). Fix the orphaned link, not the script. Leaders Loop

An honest limitation. The neat nesting is a teaching model, not a law of nature, and two things complicate it in practice. First, the labels are genuinely contested, practitioners argue endlessly about where UX ends and CX begins, and job titles rarely match the textbook. Don't relitigate the taxonomy in the meeting; use it only to ask the one useful question, "what level is this problem on?", then move. Second, a blueprint, like any map, is confident and possibly wrong. The classic failure is the imagined blueprint: people who know the product sketch the backstage they assume exists, complete with plausible handoffs, none of it observed. NN/g is blunt that this work should rest on real research, not workshop hypothesis dressed up as fact. A beautifully rendered diagram built on guesses doesn't reduce your uncertainty; it launders it into something that looks like evidence. Ground it first with cheap usability & guerrilla testing before you trust where it points.

Why a leader should care which word they're using

Precision here isn't pedantry, it routes the money. Each label implies a different practitioner, a different tool, and a different owner. Call a problem "UX" and you'll get a designer redrawing screens. Call the same problem "service design" and you'll get someone tracing it backstage to a broken handoff. If the real fault is a backstage seam, the first answer is expensive theatre and the second is a fix. The cost of mislabelling isn't a wasted definition; it's a wasted quarter.

There's also a discipline lurking under all four names that the acronyms can obscure: none of them is a matter of taste. The ISO standard's first principle for human-centred design is "an explicit understanding of users, tasks and environments," refined by user-centred evaluation, done iteratively (ISO 9241-210:2019). Whether you're tuning a button (IxD), shaping a product (UX), orchestrating a lifetime of encounters (CX) or blueprinting the machine behind them (service design), the load-bearing input is the same: evidence about what an actual person does and feels, drawn from real customer needs identification & latent needs rather than the org's own assumptions. The acronym tells you the zoom; the research tells you the truth.

A worked example

Illustrative figures, the numbers below are invented to show the reasoning, not real benchmarks.

A mid-size insurer is haemorrhaging customers at the worst possible moment: the claim. Leadership's instinct is a "UX refresh" of the claims app, because the app is the bit everyone can see and argue about, and there's a design team standing by. Before signing it off, they run the diagnosis-by-altitude.

They map the journey of one persona, "Tom, just had a minor car accident, filing his first claim", built from a dozen real customer interviews, not a workshop guess. The emotion line tells a clear story. Finding the app and filing sit fine; the interaction design is genuinely competent. The catastrophic dip is somewhere nobody scripted: "the silent week" after filing, when roughly 1 in 3 claimants hear nothing at all, phone in, and reach an agent who can't tell them where the claim is. Satisfaction craters there and never recovers; that single gap is doing most of the churn.

Now they blueprint that moment downward. Frontstage: an anxious customer and an apologetic agent. Below the line of visibility: the claim has moved to an assessor's queue whose status the support team simply cannot see, an orphaned handoff between assessing and support that neither owns. The fix was never the app. It's a status the assessor updates once and both the agent and the customer can see, a change to a backstage handoff, surfaced only because they zoomed out to CX, mapped the journey, then blueprinted below the line instead of redrawing the screen. The "UX refresh" would have repainted a room the customer was already happy in. Before committing spend, they'd pressure-test the call against their retention numbers: does closing "the silent week" actually move renewal? The blueprint told them where to look; the metrics tell them whether they were right.

Frequently asked questions

What's the difference between UX and CX, really?

Scope. UX is a person's experience of one product or service, end to end, does it meet their real need without fuss (Norman & Nielsen, NN/g). CX is the sum of every encounter that person has with the brand across the whole relationship: the ad, the salesperson, the app, the invoice, the call centre, the renewal. UX is one product; CX is the company. A great app can sit inside a miserable CX if billing and support are hostile, which is exactly why you can't fix a CX problem with a UX tool alone.

Where does interaction design (IxD) fit?

IxD is the most zoomed-in of the four: the moment-to-moment behaviour of a digital thing as you use it, what happens when you tap, how the system responds, the feedback that confirms it worked. It's a craft inside UX, not a rival to it. If UX asks "is this product right for the person's need?", IxD asks "does each action feel responsive, clear and forgiving?" You can have flawless IxD inside a product that solves the wrong problem, which is precisely why the broader labels exist.

Do we need a service blueprint, or is a journey map enough?

Map first; blueprint when the map finds pain you can't explain from the customer's side. A journey map shows where the experience hurts. A blueprint shows why, by stacking the backstage staff actions, systems and support processes under the customer's line and marking the line of visibility (NN/g). If the cause of a dip is obvious and frontstage, the map is enough. If the cause is some seam between two teams, you need the blueprint to find it.

Isn't all of this just common sense dressed up in acronyms?

The acronyms are jargon, and you can ignore them. What you can't ignore is the discipline underneath: these traditions exist because "we already know our customers" is usually a polite description of guessing from inside your own boxes. The value isn't the vocabulary, it's the obligation to ground decisions in observed behaviour and to look below your own line of visibility, where the expensive seams hide. Drop the labels if they irritate you; keep the habit of looking from the customer's side and tracing pain backstage.

Who should own all this, do we need a "Chief Experience Officer"?

Often not a new title; almost always a new owner for the seams. The reason experiences break is that every team owns its box and no one owns the line that runs across them. You don't necessarily need a head of CX; you need each orphaned handoff a blueprint exposes to get an explicit owner and an escalation path. The most uncomfortable output of this work is usually a list of cross-team seams with nobody's name on them, and assigning those names is the actual leadership job.

Related in the Toolkit

Where to go next