The difference between designing a product and designing an experience is not a matter of semantics. It’s a fundamentally different job.
There’s a tension that quietly builds in many design teams. Someone asks the product designer to write the confirmation email. Or to figure out what the help center article should say. Or to decide whether the category page needs more educational content. The designer does it — because it needs to get done and no one else is stepping in — and somewhere in the process, the actual product work starts to slip.
This is not a discipline problem. It’s an organizational design problem.
Most product design teams are structured around products: specific tools, screens, or surfaces that need to be built. But customer experiences don’t live only inside products. They stretch across awareness, education, communication, in-store moments, and post-transaction touchpoints. When a single designer is asked to own all of that, something breaks. Either the product suffers, or the broader experience gets cobbled together reactively.
The solution isn’t to hire more product designers. It’s to get honest about the fact that you’re asking two different roles to live inside one title.
The User Lens vs. The Customer Lens
Product designers are trained — and most thrive — on a user lens: the person in front of the interface, completing a task. What does this flow feel like? Where do people get confused? How does this interaction perform at scale? This is deep, contextual, craft-level work.
An experience designer, by contrast, works at the level of the customer: a person with a life, a problem, a set of expectations built up long before they open the app. Their job isn’t to design the interface — it’s to understand the full arc of what that customer is going through and ensure that every touchpoint, from the first time they encounter the brand to the moment after a transaction completes, tells a coherent story.
These are genuinely different orientations. One starts with a screen. The other starts with a person.
When organizations conflate the two, they tend to get mediocre versions of both.
Where the Blur Causes Harm
The clearest sign that these roles have blurred is when product designers are regularly asked to make decisions they don’t have the context to make well.
Should the product detail page include a more educational overview section? That’s a merchandising and customer journey question — it requires understanding what customers are looking for before they arrive at the product, not just how they interact with it once they’re there.
What should the confirmation email say after a customer books an appointment in-store? That’s a communications question — it lives in the experience designer’s world, requiring knowledge of what the customer is about to experience and what they need to feel confident going in.
When product designers are handed these questions, they usually answer them reasonably. But they answer them without the benefit of having mapped the full journey. The output is fine. It just isn’t designed — it’s filled in.
The Embedded vs. Non-Embedded Problem
The downstream effect is subtle but compounding. Customers get fragmented experiences. Designers get overloaded. And the team loses the ability to see the experience as a whole.
Many design teams have experimented with a non-embedded model: a central pool of experience designers that any category or product team can draw on for support. The model is efficient on paper. In practice, it tends to produce reactive, piecemeal help.
A team gets a bit of support here, another team gets some there. But no one is consistently watching the whole arc of what a customer goes through across a given category. Insights from one team’s research don’t automatically flow to another. Work gets duplicated. Opportunities to build a coherent narrative across touchpoints get missed.
Embedding an experience designer in a category for a meaningful stretch of time — even six months — creates something different. They start to understand the particular rhythms of that customer’s journey. They develop relationships with the product designers working within it. They become the connective tissue between what the product does and what the customer needs to understand, feel, and do around it.
This doesn’t scale infinitely. But for high-priority areas with significant customer complexity, it pays off in ways the pooled model rarely does.
Defining the Split in Practice
The hardest part of this work isn’t agreeing on the principle — most teams nod along quickly. The hard part is drawing the actual line.
One useful framing: product designers own the product surface and end-to-end flows within it. The experience of using the thing. The UX of the scheduler, the checkout flow, the account management tool.
Experience designers own what surrounds and connects those surfaces. The awareness content. The educational materials. The communications that set expectations before someone enters a flow and follow up after they leave it. The question of how someone even gets to the product in the first place.
In practice, this might look like: a product designer owns the self-serve appointment booking flow, while an experience designer owns everything the customer needs to understand before they start the flow and after they complete it — what to bring, how long it takes, what the confirmation should say, how the in-store handoff should feel.
This isn’t a perfect boundary. There will be overlap. But naming it explicitly means the team can have a real conversation when work lands in the grey zone, rather than defaulting to whoever is nearest.
Using Projects as Pilots
For teams unsure where to start, there’s a practical approach: pick one significant upcoming project and try the split deliberately.
Choose something with both a clear product surface and a meaningful surrounding customer journey. Assign a product designer to the flows and a cross-functional partner (or experience designer, if you have one) to the surrounding communications and education. Document where the handoff happens. Notice where the collaboration is easy and where it creates friction.
This kind of pilot does two things. It produces better work for the specific project. And it generates concrete examples — things you can point to — that make the ongoing role clarity conversation much less abstract.
Closing
Most design teams weren’t built with this distinction in mind. They were built around product delivery, and experience design got layered in as a secondary concern — handled by whoever had bandwidth, or not handled at all.
The cost of that approach is visible in the experience customers have: good in places, generic in others, fragmented overall.
The fix isn’t a reorganization. It’s a conversation — a clear-eyed look at what work is actually being asked of your designers, and whether the roles you have are structured to do it well. Two lenses, two orientations, two kinds of ownership. Getting that distinction right is one of the most underrated levers a design leader has.