Teaching stakeholders to tell wants from needs
LEARNING DESIGN
In product work at Pluxee, I kept running into the same pattern. A brief would come in shaped by what a single client had said loudly enough, "the client is shouting that they want a button," and that sentence would travel through the company until it became a development ticket. Meanwhile, the actual UX problems, the ones sitting in support logs and analytics, stayed unfixed. Development capacity went to features nobody used, and the real friction kept building.
For my final project in Learning Design, I built a workshop that teaches stakeholders to separate what a client wants from what a user needs, using triangulated data instead of the loudest opinion in the room.
Speculative
Futurism
Design challenge
IKEA
The brief
The course asked us to design a learning object, evaluate it with a recognised model, and reflect honestly on what worked and what didn't. I picked a problem I already lived with daily. Pluxee stakeholders, Sales, Account Managers, Product Owners, are in constant contact with clients but rarely have the analytical lens to translate complaints into structured problems. The cost of that gap is real.
Engineering time gets spent on features that solve nobody's actual problem.
The goal wasn't to turn salespeople into analysts. It was narrower than that: give them a repeatable way to confront a subjective email with three different data sources before it becomes a ticket.
Defining what success would look like
Before designing the workshop itself, I split the learning outcomes into three layers. Knowledge: participants understand the difference between a symptom ("it's slow") and a cause ("the UX flow forces too many clicks"). Skills: participants can take a subjective email and cross-reference it with support tickets and analytics. Competence: participants can independently fill in a structured Jira brief backed by evidence.
This layering mattered because it gave me something to evaluate against later. A workshop that gets a "great session, thanks" rating at the end isn't the same as one that changes how someone writes a Jira ticket the following week. I wanted to be able to tell the difference.
Designing the learning flow
I built the workshop as a case study in Miro, simulating a real product situation rather than teaching theory. The flow had four phases.
It opened with an icebreaker, deliberately silly, "if you had a superpower, what would it be and why," because the workshop topic is touchy. People don't love being told their briefs are sloppy. A bit of lightness up front lowered the defensiveness.
Then a quick audit of where data actually lives in the company. Sales sees one slice, Support sees another, Analytics sees a third. Most participants had never sat with the three side by side.
The core was the detective work. I gave them an email from a fictional colleague called Eda, full of subjective impressions and feature demands. Then I gave them three cards: a Support report, a Google Analytics snapshot, and field notes from real users. Their job was to investigate, not accept.
The final phase was application. They had to take what they'd learned and fill in a new Jira brief template, the same one I wanted them to actually use back at work.
Evaluating with the Kirkpatrick model
I evaluated the workshop using Kirkpatrick's four levels, because reaction alone isn't enough and results alone are too slow.
Reaction. I observed and collected feedback during the session. Early on, participants pushed back, "but Eda has a point, the client wants this." The turn happened when they hit Card B, the analytics. The visual confrontation between impressions and facts did more work than any lecture could have. The interactive investigation format kept engagement high throughout.
Learning. I tracked two specific "aha" moments. The first was the myth of the "slow portal." The email claimed the portal was technically slow. The analytics told a different story: users were spending eight minutes on the page and clicking back repeatedly. The problem wasn't load speed, it was a UX flow forcing users to drill into details one by one. Participants correctly rejected the "speed-up button" request and proposed a redesigned table view instead.
The second was the user-versus-payer distinction in the mobile app. The brief asked for bulk-order functionality in the portal. But the field notes (Card C) showed that the actual end user, the employee using the benefits card, doesn't care about administration. They care about how fast they can pay. Participants reprioritised the request from admin features to a geolocated map of partners and live balance.
Behaviour. The behavioural goal was a changed way of writing Jira tickets. The final template forced a different shape: Problem, Evidence, Proposed solution. Instead of "I want feature X," participants ended the workshop writing things like, "Problem: users make errors when approving. Evidence: 68 support tickets per month.
Solution: improve visual feedback after the action." Same person, different structure.
Results. This was a pilot, so the results level is necessarily partial. The immediate impact was cost avoidance. The workshop stopped two requests from reaching development: an "Export to Excel" feature used by 2% of users, and a colour change requested by a single client. Both would have eaten dozens of engineering hours with no measurable value.
Mind maps and three values per area
From the Good Time Journal, I picked three areas where I'd consistently felt engaged: travel, friendship, and respect. For each I built a mind map, words, situations, associated concepts, and then extracted three core values per map.
Travel: experience, freedom, discovery. Friendship: trust, understanding, love. Respect: research, recognition, design.
From those nine values I sketched three hypothetical roles that would actually let them coexist: a field researcher or sociologist, a social services worker, and a service designer or researcher.
The point of this exercise isn't to pick a job. It's to widen the range of jobs that feel plausible. The book calls it a mental warm-up, and that's accurate, it loosened up the assumption that my current path is the only one that fits my values.
What I learned
The "Eda email" simulation turned out to be the load-bearing part of the design. Participants enjoyed criticising a fictional colleague's reasoning, and that distance made it easier for them to see the same pattern in their own work. Visually separating impressions (the email) from facts (the data cards) did more than any verbal explanation, the spatial layout of Miro became part of the lesson.
The thing I had to fix during the evaluation was Card C, the mobile app one. The original framing wasn't specific enough about the difference between the manager's needs and the end employee's needs. In the next version I'll split those into two explicit personas, "Payer" (HR) and "User" (Employee), so they can't get blurred.
The broader lesson is one I keep coming back to: a clean Jira template doesn't fix bad briefs. What fixes them is giving the people writing them a repeatable habit for testing their own assumptions before they hand the problem off. The template is the artefact. The workshop is what makes the artefact get used.e. That gave me a much more reliable compass than any single answer would have.
