The Translation Failure Is Not About Communication Skills
Every research team has experienced it: you deliver rigorous findings, clearly presented, with actionable recommendations. The product team nods, thanks you, and proceeds to build something that ignores or misinterprets the research. The standard diagnosis is communication failure -- researchers need to present better, speak the product team's language, tell stories instead of sharing data.
This diagnosis is wrong. The problem is not communication skill. The problem is that research findings and product decisions operate in fundamentally different epistemic frameworks. Researchers think in terms of patterns, evidence weight, and uncertainty ranges. Product managers think in terms of user stories, sprint scope, and priority stacks. Designers think in terms of interaction patterns, visual hierarchy, and component systems. No amount of better storytelling resolves this structural incompatibility.
What does resolve it is boundary objects: artifacts that sit at the intersection of multiple disciplines, are interpretable from each perspective, and enable coordination without requiring shared understanding of each other's full context. This concept, borrowed from science and technology studies, explains why certain research deliverables create action while others create shelfware.
What Makes Something a Boundary Object
The Key Properties
Boundary objects have four properties that make them effective across epistemic boundaries:
- Interpretive flexibility: Each group can read the artifact through their own framework without distortion. A journey map means "evidence of user pain" to a researcher, "design opportunity" to a designer, and "feature priority signal" to a PM -- and all three interpretations are simultaneously valid.
- Shared material form: The artifact is concrete and specific. Abstract findings ("users struggle with onboarding") are not boundary objects. A specific flow diagram annotated with user quotes, drop-off data, and emotional states is -- because everyone can point to the same physical thing and discuss it from their perspective.
- Coordination enablement: The artifact allows different groups to coordinate their work without requiring full mutual understanding. The designer does not need to understand p-values. The researcher does not need to understand component libraries. The boundary object lets them coordinate nonetheless.
- Local adaptation: Each group can take the shared artifact and adapt it for their own context. The PM extracts user stories. The designer extracts interaction requirements. The researcher extracts follow-up questions. The artifact supports all these downstream uses without being designed exclusively for any one.
The translation problem in research-design handoff exists precisely because teams try to translate rather than share boundary objects. Translation requires one party to fully enter another's framework. Boundary objects require no such translation -- they work across frameworks by design.
Effective Boundary Objects for Research
Annotated Experience Maps
Not journey maps in the traditional sense -- those are usually research outputs designed for researchers. Effective boundary objects are experience maps that integrate multiple data types into a single artifact:
- User actions (observable behavior from analytics and observation)
- User emotions (coded from qualitative data)
- System responses (what the product actually does at each step)
- Pain quotes (verbatim participant language at specific moments)
- Metric callouts (drop-off rates, time-on-task, error rates)
A designer reads this and sees interaction design opportunities. A PM reads it and sees priority signals. An engineer reads it and sees technical constraints. A researcher reads it and sees evidence integrity. Same artifact, four valid interpretations, zero translation required.
Decision-Framed Insight Cards
Single-page artifacts that frame a research insight as a decision context:
- What we observed (2-3 sentences of evidence)
- What it means for the product (implication without prescription)
- What options exist (possible responses, not recommendations)
- What we do not know (explicit uncertainty boundaries)
- Related evidence (links to supporting data)
These cards work as boundary objects because they do not prescribe action (which would privilege one interpretation) but frame the decision space that each role can enter from their own perspective. The PM sees a prioritization input. The designer sees a constraint. The researcher sees a finding in context.
This approach directly addresses why stakeholders ignore 90% of research findings: the attention economy of product organizations rewards artifacts that are immediately actionable from each reader's context, not artifacts that require translation work.
Provocation Prototypes
Research-informed design provocations that embody findings in concrete form without being actual product proposals:
- Low-fidelity mockups that make a research insight tangible
- "What if" scenarios rendered as interaction flows
- Counter-examples that show what happens if the insight is ignored
These are not design proposals (designers create those). They are research artifacts that use visual form to communicate what textual findings cannot. They provoke discussion across roles because everyone can react to concrete form more easily than abstract description.
The scaffolding problem in concept testing applies here too: abstract ideas need concrete form to be evaluated. Research findings are abstract ideas. Provocation prototypes give them the concrete scaffolding that enables cross-functional evaluation.
Living Evidence Walls
Physical or digital spaces where evidence accumulates visibly over time:
- Participant quotes organized by theme
- Behavioral patterns with supporting clips
- Contradiction clusters (where different participants report conflicting experiences)
- Confidence markers (how much evidence supports each theme)
Evidence walls work as boundary objects because they are never finished -- they accumulate. Product teams can visit them at any time and draw their own conclusions. Researchers update them continuously. The wall itself mediates between research production and product consumption without requiring formal handoff moments.
Why Standard Deliverables Fail as Boundary Objects
Research Reports
Traditional research reports fail because they are designed exclusively for research-literate audiences. Their structure (methodology, findings, recommendations) follows research logic, not product logic. Product teams must translate the entire document into their own framework before extracting value -- and most never bother.
Slide Decks
Presentation decks fail because they are optimized for a moment (the presentation) rather than ongoing coordination. After the meeting, the deck becomes a static artifact that nobody revisits. Boundary objects must support ongoing reference and adaptation, not one-time consumption.
Raw Data Repositories
Sharing raw transcripts and recordings fails because it requires full research literacy to extract meaning. Only researchers know how to read transcript data without over-indexing on individual quotes or mistaking articulate participants for representative ones. Raw data is not a boundary object -- it is a research resource.
Building Boundary Object Practice
Start With Observation, Not Prescription
Before designing new deliverables, observe which existing artifacts naturally create cross-functional engagement. Look for:
- Artifacts that get referenced in meetings by multiple roles
- Documents that get forked or adapted by non-researchers
- Outputs that provoke questions rather than passive acknowledgment
- Materials that product teams share with each other without researcher prompting
These already-working artifacts reveal what your organization's natural boundary objects look like. Design new deliverables in their image rather than in the image of ideal research outputs.
Co-Create the Format
Boundary objects work because they serve multiple audiences. The best way to design them is to involve those audiences in the design process. Run a workshop where researchers, designers, PMs, and engineers each describe:
- What information they need from research to do their job
- What format they can actually use in their workflow
- What level of detail helps vs. overwhelms them
- When in their process they need research input
The intersection of these needs reveals the boundary object specification. It will not look like a traditional research deliverable -- and that is exactly the point.
This mirrors how cross-functional research workshops work: getting different disciplines to engage with the same material from their own perspectives builds shared understanding without requiring anyone to learn another discipline.
Invest in Artifact Infrastructure
Boundary objects require maintenance. An outdated evidence wall misleads. A stale insight card misinforms. Budget for the ongoing care of boundary objects as part of research operations -- not as a one-time deliverable cost.
This means treating boundary objects as living research infrastructure rather than project outputs. Just as data contracts define the agreement between data producers and consumers, research boundary objects define the agreement between insight producers and decision consumers. Both require active maintenance to remain trustworthy.
Measuring Boundary Object Effectiveness
Action Latency
How long between research completion and observable product action? Effective boundary objects reduce this latency because they eliminate the translation step that creates delay. Track the time between final research artifact delivery and the first product decision that explicitly references that research.
Cross-Role Citation
Do people outside the research team reference research artifacts in their own work? Track how often PMs cite research in PRDs, designers reference research in design rationale, and engineers mention user context in technical decisions. High cross-role citation indicates effective boundary objects.
Adaptation Rate
Do other teams adapt research artifacts for their own purposes? A PM who takes your experience map and creates user stories from it is demonstrating boundary object effectiveness. A designer who extracts interaction requirements from your insight cards is doing the same. If artifacts are consumed but never adapted, they may be informative but not truly coordinating.
Return Visits
Do teams return to research artifacts after the initial presentation? Boundary objects support ongoing reference. If your deliverables are consumed once and forgotten, they function as presentations, not coordination tools. Track page views, document access patterns, and physical wall engagement over time.
The Epistemological Implication
Boundary objects succeed because they abandon the fiction that research communication requires shared understanding. They accept that researchers, designers, PMs, and engineers will always interpret research differently -- and design for productive difference rather than forcing consensus.
This is philosophically honest. The sensemaking gap cannot be closed through better communication alone because it reflects genuine differences in how disciplines construct knowledge. Boundary objects do not close this gap. They bridge it -- letting different knowledge systems connect without merging.
The organizations that integrate research most effectively are not the ones where everyone thinks like a researcher. They are the ones where research artifacts are designed to be genuinely useful from multiple perspectives simultaneously. That requires abandoning researcher-centric deliverable design and building artifacts at the boundaries where disciplines meet.
