Co-Designing Services With Customers: Why Most Attempts Fail

Ask most service teams what "co-designing with customers" means and they'll describe a workshop: a room, some sticky notes, a facilitator with a marker, and a slide deck afterwards showing smiling participants around a table. Six weeks later, the blueprint that ships looks exactly like the one the design team would have produced anyway. The customers were in the room. They were not in the decision.

That distinction is the whole game. Co-design only earns its name when customers hold real authority over a trade-off in the service blueprint — not when they're invited to comment on one the team has already chosen. Feedback tells you what customers think of a decision. Co-design lets them make it. Most organisations that claim to do the second are, in practice, doing a more expensive version of the first.

What does co-designing a service actually mean?

Co-design is the practice of giving customers a seat at the table where the service is built, not just the one where it's evaluated. It sits on a spectrum first mapped clearly by design researchers Elizabeth Sanders and Pieter Jan Stappers, who distinguished "designing for" people from "designing with" them in their widely cited 2008 paper Co-creation and the new landscapes of design, published in the journal CoDesign. Their point still holds nearly two decades on: participation is a spectrum from consultation to genuine co-creation, and most companies stop several rungs short of the top without realising it.

In practical terms, co-design means customers help shape the stages of a journey, the sequencing of steps, the wording of a policy, or the design of a recovery moment — and their choices survive contact with operations, legal and finance. If the customer's input can be quietly overruled with no explanation back to them, it wasn't co-design. It was market research wearing a co-design costume.

Why do most "co-design" workshops change nothing?

Because the room has the wrong ratio of comfort to consequence. Workshops are optimised to make everyone feel heard, which is a fine goal for morale and a poor one for shipping a redesigned service. When the facilitator's real job is to keep the energy positive rather than to force a hard trade-off into the open, the output is a wall of Post-its that gets photographed, summarised, and quietly filed under "insights" while the roadmap proceeds unchanged.

Three failure patterns show up again and again in service redesign work:

• The veto stays hidden. Customers propose ideas; a product owner decides afterwards, off-site, which ones survive — with no visibility into why.
• The scope is too narrow to matter. Customers are asked to co-design a confirmation email while the actual friction sits three steps upstream, in a policy nobody invited them to touch.
• There is no blueprint to edit. Without a shared artefact — stages, steps, backstage actions, systems, evidence — "co-design" collapses into an unstructured conversation that nobody can act on the following Monday.

Each of these is fixable. But fixing them requires treating co-design as a governance question — who holds the pen on the blueprint — rather than a facilitation technique.

Why should customers help design the service rather than just react to it?

Because of a mechanism every service designer eventually meets in the field: people commit to what they help build. The behavioural economist Dan Ariely, together with Michael Norton and Daniel Mochon, demonstrated this directly in a series of experiments where participants who assembled their own IKEA boxes, origami, or Lego sets valued their own imperfect creations far more highly than identical items built by someone else — a pattern they named the IKEA effect, published in their 2012 paper "The IKEA Effect: When Labor Leads to Love" in the Journal of Consumer Psychology. Effort, even clumsy effort, generates attachment.

The same mechanism explains why a service co-designed with customers gets adopted faster and defended harder than one merely tested on them. A customer who argued for a particular queuing rule, or who chose the wording of a cancellation policy, has skin in that decision. When the service later frustrates them in some unrelated way, they're measurably more forgiving of the parts they helped shape — an echo of the endowment effect, where people overvalue what they feel some ownership of. We've written more on this dynamic in our deeper look at how customer effort converts into lasting attachment. It's not sentiment. It's a predictable behavioural asset that most redesign programmes leave on the table because they never let customers do any real work.

Where does co-design belong in the service blueprint?

The service blueprint is the right artefact for co-design precisely because it was built to expose trade-offs, not hide them. Lynn Shostack introduced the concept in her landmark 1984 Harvard Business Review article, "Designing Services That Deliver", arguing that a service could be engineered with the same rigour as a physical product if you mapped what the customer experiences against what happens behind the curtain to produce it. That's still the right lens forty years on: customer actions on one line, frontstage staff actions below it, backstage processes and systems below that, all synchronised against time.

Most co-design sessions never touch this artefact — they operate one layer up, on a generic journey map, which is why their output is so easy to ignore. A journey map shows what customers feel. A blueprint shows what has to change operationally to make them feel differently, and that's where customer authority has to land if it's going to survive the handoff to engineering, ops and legal. If your organisation is still mapping journeys without a blueprint underneath them, that gap is worth closing before you invite customers into the room — otherwise you're co-designing a story with no mechanism to deliver it. Our CX journey mapping work exists precisely to connect the two.

How do you run a co-design session that actually produces a shippable blueprint?

The workshop matters less than the sequence around it. Here's the version that has held up across service redesigns in banking, healthcare and hospitality — three sectors where the backstage constraints are unforgiving and customers still deserve a real vote.

1. Name the trade-off before you invite anyone. Co-design sessions fail when they open with "tell us about your experience." Open instead with a specific, bounded decision — speed versus verification at onboarding, self-service versus human handoff at complaint resolution — that customers can genuinely help resolve.
2. Recruit for friction, not enthusiasm. The loyal advocates who show up to every panel will validate what you already believe. Recruit the customers who complained, churned, or nearly did. Voice-of-customer data should drive the guest list; our voice of customer strategy work is built around surfacing exactly these signals before a session is even scheduled.
3. Put the blueprint on the wall, not a mood board. Bring the current-state blueprint — stages, steps, frontstage and backstage actions — printed large enough to annotate. Customers edit the actual artefact operations will inherit, not a proxy for it.
4. Give customers a real constraint, not a blank page. Total creative freedom produces wish lists nobody can fund. A defined budget of effort, time or cost to allocate across the journey forces the same prioritisation calls your operations team has to make — and customers make surprisingly disciplined choices once the constraint is visible.
5. Make the decision rule visible in the room. State up front which choices customers have final say over, which are advisory, and which are fixed by regulation or system limitation. Ambiguity here is what breeds cynicism afterwards.
6. Close the loop in writing, fast. Every idea that didn't make the cut gets a one-line reason, sent back to the specific participant who raised it, within a week. This single step does more for trust than the entire workshop — and behaviourally, it triggers reciprocity: customers who feel genuinely heard give more candid input next time.
7. Convert survivors into a tracked roadmap. Ideas that die in a slide deck were never really adopted. Move what survives into owned initiatives with deadlines, not a "backlog" that quietly evaporates — our CX implementation roadmap approach exists to stop exactly this leak.

Nielsen Norman Group's guidance on participatory design methods makes a related point worth borrowing directly: co-design works best on decisions where users have genuine expertise about their own context that the design team lacks — not on decisions that are really technical or regulatory calls dressed up as customer choices. Their overview of the method is a useful sanity check before you scope a session; see their piece on participatory design for the boundary conditions.

What should customers actually be allowed to decide?

Not everything, and pretending otherwise is how co-design programmes lose credibility with both customers and the board. The useful line is between decisions grounded in lived experience and decisions grounded in constraint. Customers are the world's leading experts on the first category; they have no privileged insight into the second.

• Sequencing and pacing — the order in which information, verification or choices are presented, where customers can spot friction the design team has stopped noticing.
• Language and framing — how a policy, a fee, or a delay is explained, where tone determines whether the same fact reads as fair or punitive.
• Recovery design — what a fair apology or fix looks like when something goes wrong, a domain where customer expectations are often more modest than companies assume.
• Channel preference and trade-offs — when they'd accept a slower human process over a faster automated one, and why.

What customers shouldn't be asked to co-design is the regulatory architecture, the core technology stack, or the unit economics behind a pricing floor. Inviting them into those rooms only to override them later is worse than not inviting them at all — it manufactures the exact cynicism co-design is meant to dissolve.

Where does co-design break down in practice?

Three places, reliably. First, at the handoff from workshop to delivery team, where the person who ran the session and the person who owns the backlog are rarely the same, and intent gets lost in translation. Second, at scale — a co-design session with twelve customers in one city branch produces a decision that a national operations team then has to defend across a hundred branches with different constraints, and nobody warned the twelve participants their input wouldn't generalise. Third, and most quietly damaging, at governance: without a clear owner for "who has final say on this blueprint," co-design becomes a political football, with different departments citing customer input selectively to support whatever they already wanted to do. A proper CX governance model is what stops the third failure from swallowing the first two.

None of this argues against co-design. It argues for treating it with the same rigour you'd apply to any other structural change to how the organisation makes decisions — because that is, functionally, what it is.

Does co-design actually improve business outcomes, or just customer sentiment?

Sentiment is the easier case to make and the one most articles stop at. The harder, more useful case is operational: customers who help design a process tend to expose friction that internal teams have normalised. Staff who've processed the same complaint workflow for years stop seeing the redundant verification step; a customer who's lived it once still sees it clearly. That's not empathy theatre — it's a genuine information asymmetry that co-design is structurally suited to close, because the people with the clearest view of a broken step are the ones standing inside it, not the ones diagramming it from a conference room.

The commercial case follows from the same logic that makes any well-run service design engagement pay for itself: friction removed at the point customers actually feel it costs less to fix than friction discovered after launch through complaints, churn, or a costly rebuild. Co-design, done with real authority rather than decorative participation, is simply the fastest route to finding that friction before it becomes a support ticket.

The blueprint is the contract

Co-design isn't a warmer version of user research, and it isn't a PR exercise to photograph for the annual report. It's a decision about who gets to hold the pen on the document that governs how your service actually runs. Give customers a real trade-off, a real constraint, and a real say in the outcome, and they will build you a better service than your own team would have shipped alone — and defend it more fiercely than any campaign could. Keep them in the room but off the page, and you'll have spent a great deal of goodwill producing a very expensive photograph.

If your last "co-design" session ended in a slide deck rather than an edited blueprint, that's the tell. The fix isn't a better facilitator. It's a clearer answer to the question of what, precisely, customers were ever allowed to change.