Engineering Empathy: How 'Exposure Hours' With Users Change How Engineers Build
There is a reliable pattern in engineering teams that have watched a real user struggle with something they built: the engineers remember it. Not in the abstract way they remember a bug report or an analytics alert, but with the specificity and emotional resonance of having watched a person — a real person, not a persona — sit in front of their work and not understand it, or misinterpret it, or give up on it. That direct observation changes how engineers think about what they are building. It introduces a human reference point that no specification document, no user story, and no analytics dashboard can replicate.
Jeff Gothelf and Josh Seiden advocate for what they call 'exposure hours' in Lean UX: a practice in which all team members, including engineers, regularly observe real users interacting with the product. The recommendation is not incidental. Cross-functional user observation is a structural element of the Lean UX approach because user empathy is not a design competency that can be delegated to designers and then transferred to engineers via documentation. It is a direct experience that changes how the people who build the product think about the people who use it. Engineering leads who build an exposure hours practice into their team's rhythm are making a long-term investment in product quality that no code review process can replicate.
Direct user observation changes how engineers think about edge cases and interaction design in ways no specification can replicate
What Engineers Learn from Watching Users
The insights engineers gain from user observation sessions are systematically different from the insights designers and product managers gain, because engineers observe with a different mental model. A designer watching a user struggle with a form layout is thinking about information hierarchy and cognitive load. An engineer watching the same interaction is thinking about state management, error handling, and the specific code path the user's behavior is triggering. This engineering lens produces a category of insight that user research reports rarely capture: the gap between how a system was designed to behave and how it actually behaves in the hands of a real user operating at real-world speed with real-world expectations.
In session after session, engineers who observe users discover that the edge cases they optimized for are not the edge cases users actually encounter, and that the interactions they considered obvious are not obvious to users who do not share their mental model of how the system works. This discovery is humbling and valuable in equal measure. It is humbling because engineers consistently overestimate how intuitive their implementations are. It is valuable because the observations translate directly into engineering decisions: error messages that are actually informative rather than technically accurate, loading states that communicate what the system is doing rather than that it is doing something, form interactions that recover gracefully from the mistakes users actually make rather than the mistakes engineers anticipated.
Engineering observations during synthesis sessions add a technical analysis layer that researcher notes alone miss
Building the Exposure Hours Practice
The logistical challenge of engineering participation in user research is scheduling: engineers are the scarcest resource in most product teams, and research sessions compete with sprint commitments for their time. The exposure hours model addresses this by making the time commitment small and regular rather than large and occasional. The target is one to two hours per engineer per week observing users — either by participating in scheduled research sessions, watching recordings of recent sessions, or conducting brief informal usability checks with accessible users. This time investment is comparable to a code review or a sprint planning session; it is not a significant capacity burden if normalized as a team practice.
The mechanics of engineering participation in research sessions differ from designer or PM participation. Engineers should be observers, not facilitators — their role is to watch and take notes on what they see, not to guide the session. Brief them in advance on what the session is designed to learn and what the team's current hypotheses are. After the session, run a fifteen-minute synthesis conversation where the engineer shares their observations alongside the researcher's notes. The engineering perspective on what they observed — which edge cases surfaced, which assumptions were contradicted, which implementation decisions looked different in a real-use context — adds a layer of technical analysis to the research synthesis that would otherwise be missing.
Measuring the Impact of Engineering Empathy
Engineering empathy built through exposure hours produces measurable outcomes that engineering leads can track. The most direct measure is the rate of user-facing bugs reported post-launch for features where engineers participated in research during development, compared to features where they did not. Teams that track this consistently find a meaningful reduction in user-facing defects when engineers have direct user contact during the development process. A second measure is the rate of implementation changes requested during design review: features where engineers and designers have co-observed users require fewer post-implementation design changes because the engineer's implementation decisions are informed by the same user observations that shaped the design.
Engineering leads who track these measures have a data-driven case for the exposure hours investment that goes beyond the qualitative argument for empathy. The case is straightforward: engineers who observe users build features with fewer user-facing bugs and fewer implementation rework cycles. The hours invested in user observation are recovered through reduced defect rates and design review iterations. This is the same return-on-investment argument structure that works for instrumentation, for co-design participation, and for technical debt remediation — connecting an engineering practice investment to a measurable reduction in downstream cost.
The Bottom Line
Engineering empathy is not a soft skill. It is an engineering practice with measurable quality implications. Engineering leads who build regular user observation into their team's practice are investing in a form of product quality that code reviews, automated testing, and QA processes cannot address — the quality of alignment between what the team builds and how actual users experience it. The engineers who watch real users struggle with their code and then go back to their editor with a different understanding of what 'done' means are producing better software. The investment in creating those experiences is among the highest-return activities available to an engineering lead.
Related Posts from Sense & Respond Learning
Getting Developers to Care About Users: The Power of 'Exposure Hours'
Why Engineers Should Co-Design: The Business Case for Technical Participation in UX
Integrating User Research into Every Sprint: The 3-12-1 Method
Instrumentation as a Feature: Why Measurement Must Be Built, Not Bolted On
Further Reading & External Resources
Lean UX — Gothelf & Seiden (O'Reilly) — Source of the exposure hours concept and its rationale in cross-functional team design
Just Enough Research — Erika Hall — Practical guide to user research methods accessible to non-researcher team members
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
