Brainstorm and record a particular stakeholder’s responsibilities, thoughts, and feelings to help the team develop a greater sense of empathy with stakeholders’ goals.

Benefits

• Discover your audience’s needs before developing an architecture description

• Help decide what information to include or exclude

• Create a rubric for evaluating the effectiveness of an architecture description

Activity Timing

10--30 minutes

Participants

Software architect, development team

Small groups of 3--5 or as a solo exercise

Preparation and Materials

• Before the activity starts, choose which stakeholders, systems, or users will be the focus of the activity.

• Flipchart paper or a whiteboard, markers, and sticky notes

• This activity can be adapted for remote participants with screen-sharing or remote collaboration software.

Steps

1. Draw a grid on a whiteboard or piece of paper. Label each quadrant—do, make, say, and think.

2. Pick a specific stakeholder and write his or her name in the middle.

3. Brainstorm tasks this person does, artifacts this person makes, things this person says, and feelings this person may have.

4. Write each idea on a sticky note and place it in the corresponding quadrant.

5. Review the empathy map and highlight insights.

Guidelines and Hints

• Be specific. Pick a person to empathize with, not a general role.

• Validate the findings from your empathy map with stakeholders.

• Mention quality attributes, risks, or other concerns this person may find relevant.

• Adapt this method for understanding application end users, external systems (for interface design), or for use with proxy stakeholders to understand quality attributes.

• Use software such as Mural^[26] when participants are distributed.

Example

There is an example empathy map for a developer stakeholder persona.

Alternatives

The quadrants of an empathy map can be changed. Another common schema is hear, see, do (or say), and think (or feel).

Empathy maps are also useful for quality attribute analysis.^[27] This approach is especially useful when your stakeholders are unable to participate in other workshops, such as the Activity 7, ​Mini-Quality Attribute Workshop​. Instead of focusing on what the stakeholders do, say, or think, we focus on how stakeholders react to specific quality attributes. Obviously, it’s better to ask stakeholders directly. When they are not available, this is a good substitute.

To use this variant, pick a stakeholder and brainstorm at least two quality attribute scenarios or general concerns for each relevant quality attribute. Use dot voting^[28] to estimate how this stakeholder might rate the quality attributes. Ideally, you should validate the outcomes of this exercise, but this is not always practical. These insights can be used during other workshops to help ensure a stakeholder’s perspective is represented even when that stakeholder is not present.

In the following example, from a workshop facilitated by Thijmen de Gooijer, sticky notes represent raw quality attribute scenarios. The lines in the center of the chart show how different absentee stakeholders might have felt about different quality attributes shown on a quality attribute web. The quality attribute web helps us visualize the importance of different quality attributes during structured brainstorming activities. During the workshop, different participants were asked to play the role of an absentee stakeholder by using the empathy map as a guide.