Shared understanding is a common interpretation of a problem, its context, assumptions, concerns, domain language, and the decisions made about it. It does not mean that everyone begins with identical mental models. It means those models are made visible, challenged, and brought into enough alignment for a group to act deliberately together. In collaborative software design, this alignment connects stakeholders’ knowledge of user and business needs with the team’s technical knowledge. section 1.0 section 3.1
Without it, hand-offs and isolated work invite untested assumptions. Developers may implement incomplete interpretations of user needs, use quick fixes to satisfy demands, and accumulate complexity around design decisions that remain implicit or misunderstood. A visual model helps because it makes a conversation inspectable: people can notice when they use the same word for different concepts, add missing context, and test whether the group actually agrees. section 1.2 section 2.1.2 section 3.1
From hand-offs to a shared model
A team building features for a back-office system receives requirements through sequential hand-offs rather than direct discussion. Developers lack a shared view of both user needs and architecture, so assumptions fill the gaps. Bring the relevant stakeholders and decision-makers together, visualize the business problem, and use the model to examine needs, alternatives, and design consequences. The useful result is not merely a completed diagram; it is a group that can explain the decision and continue making it sustainably. section 1.2 section 1.2.1 section 1.3.4
Build and maintain shared understanding through collaborative modeling:
- Invite the people who hold relevant domain, user, stakeholder, and technical perspectives; alignment only within a development team cannot confirm the business problem. section 1.2.1
- Externalize mental models with a shared visualization rather than relying only on dialogue and memory. section 2.1.2
- Let participants write and place their own ideas. A “You think it, you write it” rule turns private interpretations into material the group can inspect. section 2.4
- Work first in the problem space: model and validate user or business needs before treating a solution as settled; then compare and test solution models. section 2.3.1
- Record context, decisions, and consequences for later clarity, while treating the collaborative effort—not documentation alone—as the primary outcome. section 1.3.4
Shared understanding is active maintenance, not a one-time agreement. A group can revisit models as needs, solutions, and their consequences change. Multiple representations may be useful because a problem can be understood from different perspectives. The aim is not to declare one person’s model correct, but to expose assumptions and create a sufficiently accurate shared sense of reality for the next decision. section 2.3.1 section 3.1 section 4.3.3
Make an unspoken conflict discussable
When a delivery discussion repeatedly circles without progress, test the group’s mental model instead of guessing at the cause. Ask a concrete polarity question such as whether the organization is building a standard product or custom-made solutions. Have people place a dot between the poles. The exercise can surface beliefs that were shaping decisions without being spoken, allowing discomfort, different perspectives, and possible agreements to be addressed openly. section 4.3.3 section 4.3.4
Figure 2.1 Visualization of the conversation with the business stakeholders at BigScreen on extending movies using EventStorming. domain events are business-relevant events that happen in a conversation. We’ll go more in-depth on how EventStorming works later in the chapter.
Use the EventStorming visualization as a concrete example of turning a stakeholder conversation into a shared, inspectable model of business-relevant events. section 2.1.2
Facilitation matters because social dynamics can prevent agreement even when the right people are present. Rank, cognitive bias, conflict, resistance, and polarities can keep important concerns in the shadows. Treat resistance and conflict as information about perspectives or consequences rather than obstacles to suppress. A facilitator can make these dynamics visible while remaining neutral and leaving the group responsible for whether and how to address them. section 1.3.3 section 8.2.3
Shared understanding supports sustainable design decisions, but it is not a guarantee of faster delivery or a complete remedy for every design problem. It requires stakeholder buy-in and time from participants, and difficult conversations may bring vulnerability or discomfort. Use it to improve the quality and clarity of collective decisions, then let the group decide what action follows. section 1.2.1 section 4.3.4
