How I Actually Put User Research on a Sprint Board (Without Pretending It’s Magical or Making Everyone Hate Me)

There’s a weird myth in digital teams that user research exists in a separate dimension to delivery.

It’s not blocked by delivery. It’s not accountable to it. It’s just… hovering nearby. Observing. Judging. Occasionally descending from the clouds to drop a 60-slide deck on people who are just trying to get a button to work with supreme judgement.

Then sprint planning happens, the room goes quiet, and someone inevitably asks: “So… when does the research bit happen? What do the tickets say?”

This is how I avoid that conversation entirely. I put user research on the backlog, in the sprint, and into the delivery flow. No fake tickets. No pretending insight arrives on a rigid, magical schedule.

I break it into five chunks. They’re not sexy. They are, however, honest and perfectly cromulent tickets.

1. Recruitment & Research Ops

(The work everyone forgets is actually work)

If recruitment isn’t on the board, it doesn’t exist. And if it doesn’t exist, it magically becomes “Jason’s fault” when a study slips because we couldn't find the right people.

I ticket the admin. I ticket the hell that is research:ops.

• Defining participant criteria: Actually getting the team to agree on who we’re talking to before I start looking.

• The Approach: Are we using a panel? Are we being scrappy? Are we begging people on LinkedIn? Spoilers, I don’t recruit via LinkedIn, that’s just for shovelling my my memes.

• The Ethics & Logistics: Consent, incentives, accessibility needs, and scheduling that works for real humans, not just our calendars.

• The sign up log: I create a centralised sign up sheet with timings and links to all the notes and prototypes.

This makes the invisible work visible. It also forces trade-offs early. When the PO asks for 12 users by next Friday, I point at the board and ask: “Ok - what type of person do you want to speak to and who is helping me with this?”

2. Planning

(Where research becomes useful or stays vague)

This is the bit I protect the hardest. Before we talk to anyone, I want total alignment on the "North Star" questions. WHAT ARE WE ACTUALLY WANTING TO FIND OUT?

If we can’t explain why we’re doing the research in two sentences, we aren’t ready to do it.

Planning tickets usually cover:

• The Decision Map: “If we learn X, we’ll do Y.”

• The Discussion Guide: Not a script—a thinking tool. I know some people like beastly scripts but I avoid this like the plague.

• The Design Triangle: Lining up with my content and interaction designers to ensure everything makes sense and we’re all comfortable with what we’re doing.

This avoids the dreaded “interesting but not actionable” feedback. I don’t want trivia; I want to unblock a developer. Although I will listen to the trivia.

3. Interviews & The "Wash-Up"

(Don't just run sessions, ANALYSE AS YOU GO!)

I never use a ticket that just says “Run interviews -> Done.” That’s a trap and it’s reductive.

Each interview ticket includes the session itself, but also the immediate wash-up. After a session, I want a 15-minute debrief with whoever was observing and anyone in the team who would like to learn about what we saw.

• What surprised us?

• What assumptions are currently wobbling?

• What didn't land at all?

• Didn’t Jason ask some brilliant questions?

By the time we get to the final analysis, the team already feels the research. They’ve heard the quotes. They’ve seen the struggle. I’m not dragging them to an "insight session" later; they were there when it happened.

4. Analysis

(Not a solo sport)

Analysis is where research either earns trust or quietly dies in a folder. I break it up because analysis isn't one singular "moment”, it’s sustained supported learning and understanding shared by the team.

• Synthesis: Me pattern-spotting and sense-making with a brilliant soundtrack from 1999-2012

• The Sanity Check: Reviewing with the UCD team to make sure I’m not just seeing what I want to see and what I’ve found passes the sniff test.

• Meaning-Making: Sitting with product and design to decide what the research means and how we move forward.

I’m not chasing a perfect academic model. I’m chasing the confidence to act. If the output doesn’t change a decision, what’s the point?

5. Playback

(Same research, different shapes)

Playback isn’t “The Presentation.” It’s a series of translations.

On the board, I split this into different cuts for different audiences:

• The Sprint Review: What we learned this sprint.

• The Design Crit: Presenting concepts and findings to design nerds to rake it over the coals.

• The Leadership Summary: Shorter than you think, focused on what the point of it is and what we’re going to do about it.

• The Repository: For future humans who join the project in six months when people inevitably move on.

If you only do one playback, you’re optimising for yourself, not the real world.

Why I Bother Doing It This Way

Making research visible on the board stops it from being mysterious. It sets realistic expectations and makes the trade-offs explicit.

But mostly, it makes research feel like delivery, not an abstract aside.

I don’t want to be the person who turns up at the end with a list of "insights" that everyone is too busy to implement. I want to be part of how the team makes better decisions under pressure.

It’s not clever. It’s sharing research through visibility.

The Art of a Delivery Manager

​I’ve worked with a lot of Delivery Managers (DMs).

Some were absolute structural engineers of sanity, logical creatures with emotional understanding.

Some were baffling, erratic and odd.

And some felt like they’d been deployed by the universe purely to test my patience and make me question everything in my life thus far - I still have the scars (metaphorically of course).

​A DM can tilt a whole team’s universe, toward cohesion or chaos and most of the time, they don't even realise they're doing it.

​The brilliant ones? They serve the team. They make themselves invisible, like a hidden Fat Controller. It’s trite and rolled out on podcasts to say ‘servant leader’ - but there’s something to it.

The awful ones? They see the word “manager” in their title and decide that they're the boss. They give off the the frantic, ego-driven stench of someone who applied for The Apprentice, didn’t get in, and has been performing to an imaginary camera crew ever since. Their business tiktok is gonna blow up any day guys.

​The Best DMs Are Guardians of Culture

​A good Delivery Manager doesn’t just keep the trains running. They are the guardians of the conditions the work needs to survive, they’re focusing on delivery and working with and for the team.

​They’re the quiet custodians of the unglamorous essentials:

• ​Psychological safety

• ​Clarity of purpose

• ​Conflict hygiene ("What we do when things go wrong")

• ​Emotional temperature (noticing when someone sounds "off")

• Ensuring the team have the right tools (I apologise profusely for getting locked out of JIRA…)

​These people understand that culture isn’t a trite motto poster on a Teams background or an AI informed workshop. It’s the day-to-day weather. And they keep the skies clear like some kind of celestial bulldog.

​You’ll find them:

• ​De-escalating tension before anyone realises it existed (even me, the poster child of overthinking)

• ​Blocking toxic noise from senior leaders who want to derail the team as it might stop their empire building.

• ​Reminding everyone why we’re doing this, not just what we’re doing.

• ​Setting a tone that the team naturally synchronises to.

​A great Delivery Manager is a tuning fork. They don’t impose culture, they hold the frequency steady so the rest of us can lock into the work.

​The Worst Ones Are Apprentice Rejects

​Then there are the others. Yes I have list - no you can't see it.

​The ones who treat delivery like an aggressive performance review conducted by Lord Sugar. They are the main character in the story of the project.

​Their trademarks are loud, confident, and destructive:

• ​Performative urgency (all caps emails).

• ​Weaponised Kanban boards (boards used to shame, not inform).

• ​Buzzword-driven ceremonies (meetings for the sake of metrics - No, I will not take this offline).

• ​"Managing up" while the team quietly burns beneath them.

• ​Treating impediments like plot twists they must dramatically announce - a 30 minute staff wide meeting to announce you’re not going to be in on Friday? True story.

​They bring that Apprentice energy: loud confidence, minimal competence, and the deep belief that process is something you inflict on people. These DMs don't guard culture—they erode it by making the culture whatever mood they happen to be in that day.

​The Best Ones Don’t Centre Themselves — They Centre the Work

​Here’s the secret pattern I’ve seen again and again:

​The brilliant ones aren't invisible - but they're not the main character. They're the amazing support character that makes everything click.

​The terrible ones make themselves the main character and they think they’re in ‘Peaky Blinders’ or ‘Sex and the City’.

​Great Delivery Managers don’t need to be the loudest voice in the room because they’re too busy listening and fixing. They don’t need to rack up personal "wins" because the team’s success is the only win that matters. They don't chase influence; influence naturally accrues to people who make other people calmer and more effective.

​The Real Test: What Happens When Things Go Wrong

​If you want to see the difference instantly, watch a team on a bad day: a massive bug, a sudden pivot, a critical deadline missed, Jason shouts at someone…

​With a great DM:

• ​Blame disappears.

• ​The pace steadies.

• ​Communication sharpens.

• ​People lean in rather than scatter.

​With a poor DM:

• ​Chaos accelerates.

• ​Decisions freeze.

• ​Meetings multiply to assign "ownership."

• ​"Ownership" becomes a weapon.

​One is a culture keeper and a stabilizing force. The other is an accelerant of chaos.

​The Big Takeaway

​Don’t look at their frameworks. Don’t look at their dashboards. Don’t even look at how the sprint is going.

​Look at the team.

​Ask yourself: Do these people feel safe, clear, supported, and able to do their best work?

​Or do they look like contestants bracing for Lord Sugar to point and say “You’re fired”?

​That’s the difference. A great Delivery Manager makes the team feel more capable. A bad one just makes them feel observed.

The Firefighter Fallacy: Why User Research Needs to Break Hierarchies

There’s a quote that’s haunted me since I first read it in my first year at university, a Google search has told me that it’s attributed to Kenyan commentator Onyango Oloo:

“One New York firefighter is worth ten British bobbies, is worth a hundred Bosnians, is worth a thousand Rwandans, is worth ten thousand Africans dying in a civil war.”

It’s brutal. It’s also true. It captures the media’s quiet mental model, how proximity, nationality, and familiarity decide whose suffering counts. People care the most about those in their close surroundings.

And, like it or not, we do the same thing in user research.

We build our own hierarchy of grief. Our own hierarchy of what matters.

Some users get our attention, our empathy, our meticulously crafted Miro boards. There are stories I can recount now of speaking to victims of modern slavery and addiction, as well as happier tales like the ‘Chicken King’.

Others? They get written off as “edge cases.”

Or “not our target audience.”

Or, the worst one: “interesting, but not actionable.”

The Firefighter: The Convenient User

In our world, the “New York firefighter” isn’t the hero running into a burning building, it’s the easy user.

The articulate one.

The one who shows up on time to their remote interview with good lighting and a nice microphone. The one who is closest to home.

The one whose worldview doesn’t challenge ours too much.

They might be:

• A stakeholder whose “gut feeling” somehow becomes a research insight.

• An early adopter in London or San Francisco who looks suspiciously like your design team.

• A squeaky wheel customer who’s always ever so helpful when engaging with the sales team.

• A loyal power user who says nice things and validates your backlog.

They’re great, they make us feel productive. They’re some wonderfully juicy low hanging fruit. But if we only listen to them, we’re designing for a subsection, one journey, one experience.

That’s not insight; that’s self-affirmation with via Figma, homogenous Heroku.

The Silent Thousands

Then there are the people at the bottom of the hierarchy — the users who never make it onto your recruitment spreadsheet.

They’re:

• The ones using your service on a broken Android 6 phone over 3G.

• The ones who need a screen reader and can’t get past your cookie banner.

• The ones who don’t speak your default language, but have no choice but to use your product as ‘98% of users speak a level of English’.

When they do appear in your dataset, as a small, lonely dot in a sea of “positive feedback” we call them outliers.

We literally flatten their struggle into a data point. An aberration to be turned into an anecdote, to a blip, to being cut out of the narrative.

Their pain becomes “low priority,” or worse, “for phase two.” Stuffed into the backlog to be revisited ‘at some point’, which we know, never happens.

That’s the real tragedy of poor research — not lives lost, but opportunities missed, markets ignored, trust eroded.

Rewriting the Hierarchy

We love to say “users are at the heart of everything we do,” but all users are equal and some users are more equal than others.

If your sample skews to the loud, the local, or the lovely, your insight isn’t wrong - it’s just incomplete.

And incomplete research builds brittle systems.

The real work is unglamorous:

• Recruiting the inconvenient. The ones who cancel twice or need translation support. When working within the public sector, those who are afraid of engaging with government.

• Designing for the edge cases first. Because that’s where resilience and innovation live.

• Context over convenience. Get out from behind the Zoom call and into the actual environment where people are struggling.

That’s how we stop treating users like headlines — and start designing for the full storyThat’s how we stop treating users like headlines — and start designing for the full story.

Because in user research, our job isn’t to rank suffering.

It’s to listen to every voice and actually hear them.

The Art of Interpretation, Sonic the Hedgehog and UX Storytelling

There are many Sonics.

I’ve fallen down the 90s nostalgia trap that is Sonic the Comic the Podcast, where the hosts go through every issue of Sonic the Comic. For me it is the definitive version of the blue hedgehog, however my opinion isn’t wholly common online. In recent years I’ve found out that many people don’t appreciate Fleetway’s take - and it’s reminded me just how many wildly different versions of the world’s fastest hedgehog exist.

There’s the cocky, anti-authoritarian 90s icon we all grew up with and marketed to within an inch of our lives.

The anxious, endearing movie Sonic who just wants a mate and some peace and sounds remarkably similar to Jean Ralphio…

The silent, existential runner from the games.

One character. A dozen narratives. Zero canonical truth.

And that, my friends, is basically user-centred design in a nutshell.

The value of what we make isn’t in the thing itself — it’s in what people do with it once it’s out there.

Stop Designing “The Final Product” (You’re Building a Starter Kit)

Design teams love to argue about canon.

What’s the real user journey?

What’s the one true tone of voice?

What’s “on brand”?

But users don’t care about your internal mythology.

They care about what actually helps them get through their day.

The second your product lands in someone’s world, amid the noise, kids, caffeine, browser tabs, and general chaos, it stops being your design.

They’ll use your beautifully crafted to-do app as a shopping list - that will slowly become abandoned.

They’ll turn your pristine comms tool into a meme dump, well I do anyway.

They’ll write their hopes, dreams, and expletives into the CRM notes field and then panic when they find out that it’s shared with the client (true story).

You designed a precision instrument. They’re using it as a hammer.

And honestly? If it still drives in nails, that’s a success story.

Fleetway Super Sonic: WHY Workarounds MEET USER NEEDS

Fleetway Super Sonic is what happens when a design gets broken on purpose — and ends up even more interesting.

Originally, “Super Sonic” was meant to be heroic and in most interpretations he still is.

Sonic the Comic didn’t know that though, they saw a wild yellow design and thought “What if it’s pure evil instead?”

Same material, same design. Different story. Better result (fight me.)

Your users do this all the time:

They build a 12-sheet spreadsheet to replace your expensive dashboard because their way ‘just feels better’.

They send each other unofficial “fixes” in Slack instead of logging tickets.

They take a photo of your QR code, print it out and share it amongst each other because the “share” function is buried three menus deep.

They’re breaking your design for reasons that make perfect sense to them - but in their minds they’re not breaking it - they’re working with it.

They’re not misbehaving - they’re using.

Sometimes the best insight you’ll ever get is watching someone completely ignore your instructions and still win.

Coherence Beats Consistency Every Time

When fans debate Sonic, they’re not arguing about quills or shoes — they’re arguing about vibe.

Does this feel like Sonic?

That’s coherence — and it’s the holy grail of design storytelling.

Consistency is keeping the logo the same size on every page.

Coherence is making sure the story still makes sense when someone uses your product upside down, backwards, or with a broken mouse.

If your brand promise is “we save you time,” but your user spends two hours trying to export data, the story falls apart.

Coherence is what lets your design flex and still feel true when it’s bent by reality.

Design Isn’t a Finish Line. It’s a Starting Line.

Your user is the final designer. Always has been.

Everything we make is just a set of invitations and affordances, a starter kit for behaviour we hope happens.

The best designs expect to be broken, stretched, hacked, and remixed.

So stop designing like you’re writing a novel.

Start designing like you’re building a sandbox and share your iterative plan.

Let people play with it, break it, rebuild it, and tell their own story with it.

If it still holds together after that, you’ve made something genuinely human.

In the End: Sonic Survives Because His Story Does

Sonic has survived decades of reboots, rebrands, and reinterpretations because his story is simple - run fast, jump on robots to free animals.

That core still holds up, no matter how weird it gets. The same story could be reinterpreted countless ways.

• Evil scientist Doctor Robotnik (I’ll be long dead before I call him Eggman) is playing god, warping nature, enslaving innocents and remaking the world to his ideal automated hellscape.

• A plucky band of environmentalists fight up against the man.

• A hedgehog runs fast and jumps on robots.

Same source material - WILDLY DIFFERENT INTERPRETATIONS.

That’s the real UX storytelling lesson.

The story doesn’t have to be consistent, it just has to be true enough for people to keep making it their own.

Your product isn’t a sermon, let people play with it and get to their destination - play with it.