Broker-Facilitated Cross-Domain Integration¶
Strategy · All strategies
Evidence · no claims cited
Description¶
When a learning design crosses institutional boundaries — a school partnering with a research lab, museum, or outside organization that has never before hosted this kind of activity — a single facilitator with prior experience in both domains (a "broker") pre-visits the partner institution, maps its constraints (safety rules, access limits, scheduling), and builds enough trust that novel practices can be introduced "painlessly." During the activity itself, the broker continues translating: helping the host institution's experts adjust their communication for a non-expert audience, and helping learners understand what constraints the host institution operates under and why.
Design Implications¶
Context¶
Requirements¶
- A facilitator who already has, or can quickly build, credibility with the receiving institution — prior experience in that specific kind of cross-domain collaboration matters
- Time before the main activity for the broker to visit the partner institution, surface concrete constraints (e.g., "no work in the sterile lab because flammable art materials are used"), and agree on adjustments
- Willingness on the host institution's side to have its own experts step into an unfamiliar, non-expert-facing role
Constraints¶
- Depends on a genuinely available broker with the right dual experience — not always feasible for a first-time cross-domain collaboration in a new context
- Even with a broker's preparation, host-institution experts may need explicit feedback and iteration on their communication style (in the source study, a researcher explicitly reflected on being told his first talk was "too technical")
Target Learners¶
- Learners in any cross-institutional design where one institution has established, unfamiliar norms (safety protocols, technical language, professional conventions) that could otherwise block or slow the collaboration
Target Learning Goals¶
- Enabling learners and host-institution experts to interact productively despite institutional and expertise differences, without either side abandoning its own norms
Instructions¶
- Identify and engage a facilitator with direct prior experience bridging the two specific domains involved.
- Have the broker visit the partner institution ahead of time to surface concrete operational constraints and negotiate adjustments (safety, access, timing).
- Brief the partner institution's experts on the audience they will be working with, and invite them to treat the encounter as a chance to practice communicating outside their usual expert-to-expert register.
- During the activity, have the broker remain present to continue translating in both directions — clarifying institutional constraints to learners, and clarifying learner needs/questions to host experts.
Related Strategies¶
- (none yet linked)
Examples¶
- A bioartist with prior art-science collaboration experience visited a university research institution ahead of a school project, negotiated safety-driven access limits with the resident researcher, and remained on-site throughout to mediate between students, teachers, and the researcher.
Key Sources¶
- Liukkonen, P., Vartiainen, H., Pöllänen, S., & Kokko, S. (2023). Interacting with nature in and through boundary crossing learning: A case of bioart-making. Journal of the Learning Sciences, 32(4-5), 534-572. https://doi.org/10.1080/10508406.2023.2263845
Page metadata
| Field | Value |
|---|---|
type |
strategy |
id |
broker-facilitated-cross-domain-integration |
title |
Broker-Facilitated Cross-Domain Integration |
description |
Assign a facilitator with prior experience in both domains to pre-negotiate constraints and build trust between institutions before learners arrive, and to explicitly help each side's experts translate their practice for the other. |
status |
review |
generated |
by claude/unspecified on 2026-08-29 |
trust |
unverified — no one has confirmed this page's content |
sources |
1 — liukkonen-et-al-2023 |
Frontmatter is the page's machine-readable record — see the Schema & Guide.