Wonderful research insights being ignored? Here’s how to make it stick.

Role-playing workshops bring insights to life.

Rick Sobiesiak
Nov 4, 2019 · 8 min read

This article is co-written by Rick Sobiesiak (IBM Security) and Omkar Chandgadkar (currently with Amazon.com, Inc., formerly with IBM Security).

We design for people who work in cybersecurity and protect their organizations from ransomware attacks, malware infections, and other such threats. As you can imagine, working in cybersecurity can be a tough job that involves lots of complexity. So we embarked on a contextual inquiry research program to build a deep understanding of our users.

Over time, our research yielded rich insights into what makes our users tick. However, we found that sharing these insights with team members was challenging. They weren’t experiencing the same level of user empathy as the researchers who conducted the contextual inquiries. But a unique role-playing workshop approach helped solve this problem.

When sharing user-research insights falls short

Originally, we adopted traditional approaches to sharing research findings through presentations and curated audio recordings. It didn’t take long for us to realize our approach was ineffective.

This approach was limited by its inherently passive, non-experiential nature. The audience was consuming large amounts of information conveyed from researcher to recipient through either direct means (such as face-to-face presentations) or indirect means (such as consuming materials independently). As passive consumers of information, they were learning some high-level facts but not developing an appreciation of the human side of our users — their attitudes, motivations, joys, and frustrations.

Adopting an immersive approach

We decided that a radically different approach was needed. This led to the concept of an immersive, team-based workshop where each participant is assigned a different user role. Workshops would typically include teams of three participants. Members of each team of three would work together throughout the workshop, with each member representing their assigned user role in the team.

Participants would individually learn about their assigned user roles and then come together as a team to teach each other about what they learned. Participants would rapidly cycle through individual and team activities to incrementally build their user understanding. This diverge-and-converge approach — rooted in design-thinking methods — was applied throughout a holistic set of activities that started with understanding individual users and their journeys, evolved into how these users collaborate as a team, and culminated in a role-playing exercise where each participant acted out their assigned user role in a real-life scenario.

Workshop principles

As we developed this workshop we were guided by a core set of principles:

Learning by teaching: People think more critically and develop a deeper understanding if they are asked to teach what they learn.

Diverse perspectives: People internalize insights more effectively when they are exposed to diverse perspectives on the subject matter.

Rinse and repeat: Repetition can help solidify understanding of key concepts, especially when each repetition introduces a new twist.

Workshop structure

The workshop structure was designed with a layered approach to introduce information. Participants would start with a high-level understanding of the users and then gradually learn more detailed concepts such as cross-user collaboration. And to reinforce the learning we introduced some ideation that would leverage what they had learned.

After running pilots and significant iteration we ended up with a workshop divided into eight sections:

1. Homework

Each participant is provided with information about their assigned user before the workshop. This includes high-level user workflows and pain points as well as audio clips of users describing their work. Participants can optionally review these materials prior to the workshop.

2. User Snapshot

We give the participants a template they need to fill in (by writing on sticky notes) based on a quick review of the materials provided to them. The template has three sections: user role, key goal, three pain points, and one representative quote. We only reserve 15 minutes for this activity which forces the participants to focus on the big picture without getting lost in the details. At the end of the 15 mins, each participant “teaches” their user snapshot to the rest of the group. Other participants ask questions and the presenter answers them to the best of their ability. The anticipation of such a presentation (called a “playback” in the IBM Design terminology) forces everyone to learn critically. As they ask each other questions, they get confused, and more questions come up. This motivates them to find the answers the next time they diverge into individually reading and listening to the materials about their users.

3. User journey map

Participants are asked to build user journey maps by drawing out user workflows and annotating them with tools, pain points, and interactions with other users. These journey maps are drawn on a whiteboard using markers and post-it notes. After completing their journey map each participant presents it to the other participants and engages them in a discussion. The facilitators chime in and ask questions if the discussions do not cover sufficient depth or if other participants are not asking for clarification.

4. Team journey map

The participants are then asked to work together to create team journey maps based on all the individual journeys. During this time they draw out how the different users interact with each other to carry out their job. This ensures the participants get every bit as deep into the other users as they do for their assigned users.

5. Scenario role playing

Participants are then asked to play out their assigned user roles in real-life scenarios. For example, we would present a malware attack notification along with associated threat intelligence information about the attack, and then instruct the participants to collaborate in diagnosing and remediating the attack as a real-life security operations center would handle it. This role-playing further strengthened participants’ understanding of users and empathy for the pressure-packed environment these users would sometimes encounter.

6. Collaboration map

Each participant then created and presented a condensed version of the day by building a collaboration map with all the user roles, dependencies between the roles, and pain points. Participants end up with a single artifact they could take away from the workshop to serve as a reminder of what they learned.

7. Big ideas

For the final activity, we asked each participant to generate at least three “big ideas” and play them back to the other participants. Rooted in design thinking, this activity focuses on ideation of experiences within the bounds of realistic constraints. It helps participants internalize what they have learned and also gives them a sense of agency to act on user needs when they return to their day-to-day projects.

8. Feedback and new ideas

At the end of the workshop, we asked participants to provide feedback, both positive and negative, and generate new ideas on improving the workshop. We leveraged this input continuously as we evolved the workshop to its current form. In fact, the first workshop activity (homework) was incorporated into the workshop because it was raised as a new idea multiple times.

Preparing your own workshop

Interested in preparing a role-playing workshop to help make your research stick? Begin by assembling your research materials, focusing on:

  • Users: Persona information such as user attitudes, goals, educational background, task characteristics, journeys, pain points, tools used, and quotes.
  • Teams: Information about the broader teams that users are part of. This can include team roles, artifacts produced and exchanged, team workflows, handoffs between users, team culture, and value exchange map.
  • Tools usage: Information about which tools and related resources are used by the users and their teams. This includes when and why the tools are used, who uses them, and the key benefits and pain points of the tools.

Ensure your materials highlight the key insights from your research, and that they include the voice of the user through some combination of audio clips, videos, and documents that complement each other.

Next, design your workshop to incrementally introduce participants to your research materials. You may want to start with our workshop structure (described earlier) and then adapt it to meet your needs. The important thing is to factor in this participant experience checklist:

  1. Immersive: Participants should feel as if they were part of the research by teaching each other and by role-playing real-life scenarios.
  2. Holistic: Participants should develop an understanding of users, their teams, and how users collaborate.
  3. In context: Participants should develop an understanding of the tools and technologies that users leverage.
  4. Illustrated: Participants should see visualizations of scenario flows, tools, and technologies experienced by users.
  5. Documented: Participants should document the key users involved, journey maps, pain points, and team collaboration maps.
  6. Actionable: Participants should capture their own ideas for improving the user experience.

Finally, run pilot workshops to work out the kinks.

When you ultimately roll out an immersive, role-playing workshop then odds are you and your workshop participants will be amazed!

Further reading

If you’re interested in doing a deep dive on contextual inquiry we recommend the book Contextual Design by Karen Holzblatt and Hugh Beyer.

Want to learn more about researching teams of users? Here’s guidance on how to do that.

For more on design thinking, the IBM Enterprise Design Thinking site has plenty of resource information.

Rick Sobiesiak is a Design Research Lead for IBM Security based in Toronto, Canada. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.

Design at IBM

Stories from the practice of design at IBM

Thanks to Omkar Chandgadkar, Kim Vonder Haar, and Nathalie Martin

Rick Sobiesiak

Written by

Design at IBM

Stories from the practice of design at IBM

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade