Building Empathy Behind the Code – Why (and how) you should bring your developers into user research sessions.

Here's a scene I've witnessed too many times: A designer finishes a beautiful user research session, writes up a thorough report, posts it in Slack, and... crickets. The developers are already three sprints deep into building a feature that completely misses the mark.

Sound familiar?

The traditional approach: designers research, document, then hand off insights to developers: creates an expensive game of telephone. By the time the "why" reaches engineering, it's been diluted, misinterpreted, or completely lost in a sea of Figma files and Jira tickets.

There's a better way. And it starts with getting your developers into the room where it happens.

Why developers in research sessions change everything

When developers experience user struggles firsthand, something magical happens. They stop seeing tickets as abstract requirements and start seeing them as solutions to real human problems.

Jared Spool puts it perfectly: developers need a "thorough understanding of user problems" to do their best work. But here's the thing: that understanding rarely survives the translation process. When developers hear directly from users, they can explore alternative technical approaches that might achieve better outcomes. They start asking "what if we tried this instead?" rather than just "how do we build what's in the spec?"

For fintech and startup teams where speed is everything, this shift is huge. You're not just building faster: you're building smarter.

The real benefits (beyond just "nice to have")

Shared empathy means fewer arguments

Ever been in a meeting where design and engineering are locked in a debate about whether a feature is "necessary"? When both teams have sat through the same research session watching a user struggle with your checkout flow, those debates get way shorter. You're working from the same source of truth.

Better technical solutions emerge

Developers who understand user context can "optimize their time and provide an equal or better outcome to achieve the same goal the user is seeking." Translation? They'll find clever shortcuts, suggest better architectures, and flag potential issues before they become expensive problems.

Handoffs get smoother

When developers already know the "why" behind a design decision, handoffs become conversations, not presentations. They're invested in the outcome because they've seen the problem with their own eyes.

You avoid building the wrong thing

This is the big one for startups burning through runway. When developers understand user needs firsthand, you stop wasting sprints on features that won't move the needle. You validate concepts early and reduce the iterations needed to get to something users actually want.

"But developers don't have time for this"

I hear you. Your developers are already underwater. Sprint commitments, technical debt, production fires: asking them to sit in on hour-long research sessions feels like a non-starter.

Good news: you don't need to throw them into every session.

Here's how to make it work without tanking productivity:

1. Start with highlight reels

Record your research sessions and edit them down to 5-10 minute "greatest hits" compilations. Show the most impactful moments: the confused clicks, the frustrated sighs, the "aha" moments. Share these in your team channel or play them at the start of sprint planning.

This gives developers the emotional impact of research without the time commitment. Bonus: these reels are also great for stakeholder presentations.

2. Try observation rooms (virtual or physical)

Developers can drop in and out as their schedule allows. Set up a Zoom room or dedicated space where research sessions are happening. Engineers can observe for 15 minutes between meetings, grab key insights, and bounce. No pressure to stay for the full session.

3. Create developer-led research sessions

Here's a game-changer: let developers run a research session. Give them a simple script focused on technical feasibility or implementation questions. They'll learn research skills, get direct user feedback, and feel more ownership over the product direction.

These sessions don't need to be perfect. The goal is connection, not research purity.

4. Invite strategically

Not every developer needs to attend every session. Be intentional:

• Building a new payment flow? Invite the backend engineer who'll own the integration.

• Redesigning the dashboard? Loop in the frontend dev working on that sprint.

• Exploring a completely new feature? Get the tech lead involved early.

Make it relevant to their current work, and they're much more likely to see value.

5. Make it optional (at first)

Don't mandate attendance. Start with an open invitation to anyone interested. You'll usually get one or two curious developers who'll become internal champions for the process. Their enthusiasm will spread organically.

What this looks like in practice

At a fintech startup I worked with, we were redesigning the account verification flow. The designer had done several research sessions and documented everything beautifully. But when implementation started, the developers kept pushing back on certain design decisions that "seemed unnecessary."

We ran one more research session: this time with two developers in the virtual observation room. Watching a user abandon the flow after hitting a confusing error message changed everything. Within 24 hours, the lead engineer proposed a better technical approach that solved the problem at the API level, eliminating the need for a complex UI workaround.

That one 45-minute session saved at least a week of development time and resulted in a better product.

The fintech advantage

For fintech teams specifically, bringing developers into research has an extra payoff. Financial products are complex, and user trust is everything. When developers understand not just what users need to do, but how they feel while doing it: the stress, the uncertainty, the need for control: they make better decisions about everything from error messaging to loading states to data validation.

In an industry where one confusing interaction can cost you a customer (and potentially a lot of money), that empathy is worth its weight in gold.

Start small, start tomorrow

You don't need to overhaul your entire process. Pick one upcoming research session. Invite one developer. Record it and create a quick highlight reel. See what happens.

My bet? You'll notice the difference immediately in your next sprint planning meeting. Conversations will be richer. Solutions will be more creative. The invisible wall between design and engineering will start to crack.

Building great products isn't about creating perfect handoffs. It's about creating shared understanding. And the fastest way to shared understanding is shared experience.

Get your developers in the room. Watch what happens when empathy meets engineering.

---

The takeaway: Developer participation in user research isn't a luxury: it's a competitive advantage. Start with low-commitment options like highlight reels and observation rooms. Focus on strategic invitations tied to current work. The time investment pays back quickly through better technical decisions, smoother collaboration, and products that actually solve user problems. For startups and fintech teams where every sprint counts, this is how you build faster and better.