Co-Designing Services With Customers: A Practitioner's Guide

Ask a call-centre agent what breaks their customers' patience and you'll get an answer in nine seconds flat. Ask the customer who just spent forty minutes on hold, and you'll get something richer: not just what broke, but what they expected instead, and what they'd have accepted as a fair trade. Most service teams only ever collect the first kind of answer. The ones that collect the second — and build it into the actual service, not just the research deck — end up with journeys that work because they were built by the people who live them.

That is the whole case for co-design, stated plainly: co-designing a service with customers means giving them a seat at the design table itself — not as subjects to be observed, but as contributors who help shape the touchpoints, rules, and trade-offs of the service before it ships. Done properly, it produces services people defend rather than merely tolerate, because they had a hand in building them.

What does it actually mean to co-design a service with customers?

Co-design is a specific method, not a synonym for "customer-centric." It means customers sit inside the design process — sketching flows, arguing over trade-offs, stress-testing a prototype — alongside the service team, at a point when the design can still change. That's different from user research, where customers are studied but not consulted on the solution, and different from a focus group, where customers react to something already finished.

The distinction matters because it changes what customers are allowed to contribute. In research, they hand over data. In co-design, they hand over judgment: which of two flawed options is less flawed, what they'd sacrifice for speed, where they'd tolerate friction if the trade-off were explained. Design researcher Elizabeth Sanders, who helped formalise the field, drew this line in her 2008 paper Co-creation and the new landscapes of design, published in the journal Co-Design: participatory approaches treat people as "experts of their experience," not merely as sources of insight to be mined. That reframing — customer as co-author, not co-author's muse — is the whole method in one sentence.

Why do customers make better co-designers than most teams expect?

The polite objection to co-design is that customers aren't trained designers and will ask for things that are impossible, contradictory, or simply bad. That objection misunderstands what customers are being asked to contribute. They're not being asked to design the interface. They're being asked to surface the job-to-be-done, the unstated expectation, and the point at which a "minor" process step actually carries emotional weight — the kind of tacit knowledge that never survives translation into a research report.

There's a second, quieter reason co-design outperforms design-for-customers: the psychology of authorship. The IKEA effect — documented by Michael Norton, Daniel Mochon and Dan Ariely in their 2011 study "The IKEA Effect: When Labor Leads to Love", published in the Journal of Consumer Psychology — found that people who assemble a product themselves value it substantially more than an identical, professionally assembled version. Effort creates attachment. A close relative, the endowment effect studied by Daniel Kahneman, Jack Knetsch and Richard Thaler in their 1990 paper in the Journal of Political Economy, shows people irrationally overvalue what they already hold a stake in. Put a customer inside the build, even briefly, and you don't just get better input — you get a customer who has skin in the outcome, who will defend the new process to their own network rather than complain about it on social media.

Co-design doesn't just improve the service. It converts the customer from a critic of the outcome into a shareholder in it.

That shift shows up in advocacy, not just satisfaction. A customer who fought for a particular checkout rule in the room is far more forgiving when that rule creates minor friction later — because they understand the trade-off it was solving for. That's a behavioural dividend that no amount of after-the-fact communication can buy back.

Why does most "customer co-design" collapse into theatre?

Plenty of organisations run workshops with customers in the room and change nothing afterwards. The workshop photographs well. The output — sticky notes, a "customer voice" slide — gets filed and never touches the actual service blueprint. This is the co-design equivalent of what Richard Thaler calls sludge: friction dressed up as engagement, consuming everyone's time while producing no real decision.

Three patterns explain most of the collapse:

• No decision rights in the room. If the people empowered to change the process aren't present, or aren't bound to act on what's agreed, the session is theatre by design — customers negotiate with people who can't say yes.
• Blank-page framing. Asking customers to "design the ideal journey" from nothing produces wish lists, not workable services. Customers co-design well against constraints; they design badly against a blank canvas.
• No return loop. Co-design that never tells participants what shipped, and what didn't and why, burns the goodwill it was meant to build. Reciprocity is a two-way transaction; silence after the ask reads as extraction.

Each of these is fixable, but only if co-design is treated as an operating discipline with authority attached to it — not a listening exercise bolted onto a project that was already decided.

How do you run a co-design process that actually changes the service blueprint?

The method below is the sequence I use when a client wants co-design to change something real, not just generate a nicer slide. It assumes the team already has a baseline understanding of the journey — co-design refines and stress-tests a service, it rarely starts one from zero.

1. Frame the decision, not the workshop. Before recruiting anyone, write down the specific decision the session must resolve — "which of three onboarding sequences reduces drop-off without adding headcount" — not a vague goal like "improve onboarding." A workshop without a named decision produces opinions, not design.
2. Recruit for range, not comfort. Include the customer who complained loudest last quarter, not just your most cooperative loyalty-programme member. Homogeneous rooms produce consensus that collapses the first time it meets a real edge case.
3. Bring the current-state blueprint, not a blank page. Show the existing stages, steps, and touchpoints — including the back-stage processes customers never see, like handoffs between departments. Customers co-design better when they can see what the organisation is actually working around.
4. Prototype live, in the room. Paper flows, role-played scripts, or clickable wireframes let customers react to something concrete rather than describe an abstraction. Concrete objects surface disagreement faster than open discussion does.
5. Force trade-offs explicitly. Ask customers to choose, not just to wish. "Would you accept a two-day delay for a lower fee, or pay more for same-day?" produces design-grade data. "What would make this better?" produces a list nobody can prioritise.
6. Score the before and after. Quantify the emotional weight of the touchpoints under discussion, before and after the redesign, so the decision isn't settled by whoever spoke last or loudest in the room.
7. Close the loop publicly. Tell participants exactly what changed, what didn't, and why — including the constraints that killed their favourite idea. This step is the one most teams skip, and it's the one that determines whether customers show up for the next round.

This sequence works because it never asks customers to do the designer's job. It asks them to do the job only they can do: supply judgment about trade-offs the internal team is too close to see clearly. That discipline sits naturally inside a broader service design engagement, where the blueprint is treated as a living document rather than a one-off deliverable.

How is co-design different from just gathering customer feedback?

Feedback and co-design answer different questions, and confusing them is the most common reason "customer-centric" programmes stall. Feedback tells you what happened and how someone felt about it — a satisfaction score after a claim, a comment after a delivery. It's diagnostic. Co-design asks customers to help decide what should happen next, before it's built. It's generative.

A mature voice-of-customer programme should feed co-design, not replace it. The two data types serve different purposes: operational feedback (X-data, in the language of experience measurement) tells you where the pain is; structured customer interviews and co-design sessions tell you why, and what to do about it. Treating one as a substitute for the other is a recurring failure mode — a point explored in more depth when separating operational data from experience data in voice-of-customer design. The organisations that get this right run a continuous interview discipline that captures genuine signal rather than polite opinion — the difference between a customer telling you what they think you want to hear and a customer revealing what actually drove their last decision, a distinction worth taking seriously when structuring customer interviews built for signal, not opinion.

Where does co-design sit inside the service blueprint?

Service blueprinting, the method Lynn Shostack introduced in her 1984 Harvard Business Review article "Designing Services That Deliver," separates what the customer sees — the front stage — from everything operationally required to produce it — the back stage. Co-design belongs almost entirely on the front stage line, and that's precisely its limit and its value. Customers can tell you, with authority, whether a step feels fair, fast, or respectful. They cannot tell you whether your core banking system supports real-time settlement, or whether a fourth handoff is legally required. That's the operations team's call.

The best co-design sessions are explicit about this boundary. Show customers the line of visibility on the blueprint. Let them redesign everything above it freely. Below the line, ask them to react to constraints rather than invent solutions — "given that verification takes two business days for regulatory reasons, how would you want to be told, and how often?" That framing respects both what customers know and what they don't, and it keeps the session inside the boundaries a journey mapping exercise can actually resolve.

Nielsen Norman Group's guidance on participatory design methods makes a similar point: structured constraints produce more actionable input than open-ended ideation, because participants without domain expertise design better against a frame than against a void, as their overview of participatory design lays out. Constraint is not a limitation on co-design. It's the mechanism that makes co-design usable.

What goes wrong when co-design meets real operational constraints?

Co-design fails in the wild in a handful of predictable ways, and each has a practical countermeasure.

• The room agrees to something the business can't afford. Fix: state cost and compliance constraints upfront, in plain numbers, rather than revealing them after the fact as a veto. Customers negotiate well against real limits; they resent limits sprung on them late.
• One vocal participant dominates the session. Fix: use structured, written prioritisation (dot-voting, forced ranking) alongside open discussion, so the loudest voice in the room doesn't become the only signal the team hears.
• The redesign looks great in the workshop and falls apart at scale. Fix: pilot with a wider, less self-selected group before rolling out — the same trap that catches single-team CX pilots that never survive contact with the rest of the organisation, discussed at length in avoiding the pilot trap.
• Legal or regulatory teams weren't in the room and veto the outcome afterwards. Fix: bring compliance and operations to the table as participants, not gatekeepers who review the output cold. Their constraints are design inputs, not obstacles to spring later.

None of these failure modes are arguments against co-design. They're arguments for running it with the same rigour applied to any other design method — clear scope, the right people in the room, and a route from decision to deployment that doesn't evaporate the moment the workshop ends. Teams unsure how ready their organisation is for that level of discipline can benchmark it with a structured CX maturity assessment before committing to a full co-design programme.

The service that survives is the one someone else helped build

Every service eventually meets its edge cases — the customer whose situation doesn't fit the flow, the moment the script runs out. What determines whether that moment breaks the relationship or merely tests it is usually decided long before it happens, in whether the people who use the service had a hand in shaping it. A service built entirely in a conference room, however well-intentioned, asks customers to adapt to logic they never saw. A service built with them asks nothing of the sort — they already know why the friction is there, because they were in the room when someone chose it deliberately.

That's the quiet advantage co-design has over every other design method: it doesn't just produce a better service. It produces witnesses who understand why the service works the way it does, and who will explain that to the next customer before your support team ever has to.