Getting Developers to Care About Users: The Power of 'Exposure Hours'
The empathy gap between designers and engineers is one of the most consistent sources of product quality problems in software teams. Designers who regularly talk to users develop intuitions about user behavior, pain points, and mental models that shape every decision they make — from information architecture to error message wording to the sequencing of multi-step workflows. Engineers who never talk to users develop equally strong intuitions, but about different things: system architecture, performance constraints, code maintainability, and deployment reliability. Both sets of intuitions are valid. The problem is that engineering intuitions, applied without user context, regularly produce technically excellent implementations that users find confusing, incomplete, or misaligned with their actual workflows.
The solution is not to turn engineers into user researchers. It is to give engineers enough direct user exposure that they begin to internalize the user context that currently lives only in the designer's head. In Lean UX and continuous discovery practice, this is sometimes framed as the 'exposure hours' principle: every engineer on a product team should have at least two hours of direct customer exposure every six weeks. Not mediated through a research report. Not summarized in a presentation. Direct: watching a real user interact with the product, in real time, and having the experience of seeing that user struggle or succeed.
Engineers who watch users struggle build products that users can actually use
What Happens When Engineers Observe Research
The behavioral change that happens when engineers regularly observe user research is not subtle. Engineers who have watched a user struggle with a feature they personally built develop a different relationship with their code. They stop thinking of software as a system that works correctly when it matches the specification and start thinking of it as something that works correctly when users can accomplish their goals without confusion. This shift in mental model — from 'does it work?' to 'can users use it?' — changes the questions engineers ask during design reviews, the edge cases they consider during implementation, and the level of polish they apply to interactions that are technically functional but experientially rough.
The research observation also changes what engineers value in design decisions. Engineers who have never observed users frequently push back on design choices that appear to add complexity — extra steps, explanatory text, progressive disclosure mechanisms — because from an engineering perspective, simpler is better. Engineers who have watched users encounter a complex flow without scaffolding understand viscerally why the additional steps exist. The pushback becomes less frequent and more specific: instead of 'this is too complicated,' they say 'I understand why the extra step is there, but I think we can achieve the same clarity with this simpler approach.' That is the conversation of a team that shares a user model.
The Six-Week Cadence and Why It Matters
The six-week cadence — two hours of direct user exposure every six weeks — is not a precise prescription. It is a calibration point. Research on skill development and empathy maintenance suggests that direct experience with a user group needs to be repeated at a frequency where the human details of that experience remain vivid rather than abstract. At six weeks, most engineers still have clear memories of specific users and specific moments from their last observation session. At six months, those memories have faded to vague impressions. The six-week cadence keeps user experience fresh enough to influence daily decision-making rather than serving as a background principle that is intellectually acknowledged but operationally inert.
Two hours is the minimum effective dose. A one-hour session with a single user can be dismissed as an outlier — one unusual person having one unusual experience. Two sessions of one hour each, or one session of two hours with opportunity to observe more than one user, creates enough pattern evidence for an engineer to develop genuine conviction. The goal is not to make every engineer a research expert. It is to give them enough direct experience that they can apply user judgment to their own technical decisions without needing to ask a designer or researcher every time. Judgment, not expertise, is the target.
Two hours every six weeks is enough to maintain the user context that changes engineering decisions.
Practical Formats for Engineering Research Exposure
Several formats work well for building engineering exposure to users. The most effective for impact-per-hour is live observation of moderated research sessions: an engineer sits in (or joins remotely) while the designer conducts a user interview or usability test. The engineer observes in real time, takes notes on anything that surprises them from a technical perspective, and participates in the debrief afterward. The real-time observation is important — watching a recording reduces engagement and creates distance that attenuates the empathic impact. Being in the room (or on the video call) with a real user creates a qualitatively different experience.
A second effective format is the structured 'ride-along': an engineer joins a customer-facing colleague — a customer success manager, a support specialist, a salesperson — for a day or part of a day, observing real customer interactions. This format provides exposure to user behavior in naturalistic contexts rather than the controlled context of a research session, and it often surfaces workflow patterns and pain points that do not appear in research recruitment because they are visible only in actual usage environments. The ride-along format is particularly effective for B2B products where user behavior is deeply embedded in workplace context that is difficult to replicate in a research setting.
Making Exposure Hours a Team Norm
Engineering research exposure works best as a structured expectation rather than an optional opportunity. When research observation is optional, the engineers who participate are already the most empathetic and user-oriented members of the team — the ones who least need the intervention. The engineers who would benefit most from direct user exposure are typically the ones least likely to volunteer for it, because it takes them out of their technical comfort zone and into territory that feels ambiguous and hard to evaluate. Structure removes this selection problem: a rotating schedule where each sprint a different engineer joins the weekly research sessions, with the expectation explicit in the team's working agreements.
The designer's role in this system is facilitation, not enforcement. Engineers who are invited into research sessions and see something that genuinely surprises them about user behavior become advocates for the practice. When an engineer comes out of a research session saying 'I had no idea users were doing that — I would never have designed the backend to support that workflow,' they are generating the kind of internal motivation that sustains the habit better than any policy. The designer's job is to create the conditions for those moments of surprise: choose sessions where meaningful user behavior is likely to be visible, brief the observing engineer in advance on what to watch for, and create space in the debrief for the engineer to process what they observed.
The Bottom Line
Empathy cannot be transmitted through documentation. The best research report ever written cannot create in an engineer the visceral understanding that comes from watching a real user struggle with the product they built. Exposure hours are the mechanism for closing the empathy gap that documentation cannot close — creating the shared user context that makes design and engineering a genuinely collaborative practice rather than a sequential handoff. Two hours every six weeks is a small investment. The compound interest on that investment, accumulated across a product team over a year, is a qualitatively different product.
Related Posts from Sense & Respond Learning
Integrating User Research into Every Sprint: The '3-12-1' Method
The Death of the Handoff: Why 'Over the Wall' Design Is Failing
Dual-Track Agile: Managing Discovery and Delivery in a Single Sprint
From Requirements Gathering to Assumption Declaring: A Mindset Shift
Further Reading & External Resources
Lean UX (3rd Edition) — Jeff Gothelf & Josh Seiden — Chapter 15 makes the case for whole-team research participation including engineers
The Design of Everyday Things — Don Norman — The foundational text on designing for human cognition and behavior
Building Empathy with Developers — Nielsen Norman Group — Research-backed strategies for building user empathy in engineering teams
Want to go deeper? This post is part of the Sense & Respond Learning resource library — practical frameworks for product managers, transformation leads and executives who want to lead with outcomes, not outputs.
Explore the full library at https://www.senseandrespond.co/blog
