Using IBM Design Thinking Method Cards to plan a workshop
By: Eric Morrow
Tags: IBM, IoT, Beekeeping, Design Workshop, Design Thinking

Note: This is part two of a two part series. Part one covers the prototyping process Brian and I used to create the IBM Design Thinking Method Cards.

In this post I will show you how I use IBM Design Thinking method cards to design an agenda for a workshop.

The planning process

Planning a Design Thinking workshop has three steps (read more about How IBM trains its design facilitators.)

1) Design Challenge — Define the problem statement

2) Focus — Define the participants, users, outcomes, and team expectations

3) Agenda — Choose the Design Methods that will connect the Design Challenge to the Focus

I recently received the following project brief on the problem of declining honey bee populations. Let’s look at the brief as an example, and then I will build out the Design Challenge, Focus, and Agenda.

Step 0, Project Brief

New Bee Hives

Honey bee populations across the United States have been decreasing at an alarming rate. While research is being done on the why this is happening, there is also potential to have a positive impact right now. We can do this by combining an improved understanding of honey bees with the practice of bee keeping.

Bee keepers do not have sophisticated methods of tracking and monitoring their hives to understand their health, and to identify and react to problems before they occur. IBM can use current technology to build an application that bee keepers will use in their day to day activities to help them maintain their hives. This might include taking notes as they check on hives, assessing weather patterns or checking sensors collecting data points on the hives.

The goal of this project is to improve the experience of bee keeping through the creation of an application to monitor and maintain the bee hives. As part of the project IBM will partner with Bee DownTown in Raleigh, NC. This group will share their subject matter expertise, participate as sponsor users, and provide hives for IBM to customize and monitor.

IBM is going to host a kickoff design workshop to get the project moving.

Step 1, the Design Challenge.

Start by considering whether your goal is incremental improvements or earth shattering leaps, and tailor your design challenge to the situation. Sometimes design challenges are framed with high emotional tension, such as “How Might We give bee keepers as much information about the health of their hives as Facebook has about the data of its users? or “How Might We create a up-to-date report that makes bee keepers into omnipotent gods of their bees’ world?” This way of framing the challenge gives the team space to come up with creative and breakthrough ideas. Given this project brief, I’d say the challenge could be “How Might We help bee keepers better understand the health of their hives, and identify and react to problems in their hives before they occur?”

Step 2, the Focus.

The participants are IBM designers, developers, offering managers, and employees from Bee DownTown.

The users are bee keepers.

The team expectations are to align the team around an idea for an application to monitor and maintain the bee hives.

The outcome is to leave the workshops with a couple ideas for a MVP.

Step 3, the Agenda.

Agenda for the workshop

The facilitator needs to choose an agenda that will help the team connect the Design Challenge to the desired outcome, in the time allotted for the workshop.

I always make sure that the output of one activity (say a collection of ideas from Big Ideas) feeds directly into the next activity (perhaps ranking those ideas using the Pyramid of Prioritization.)

Looking at the challenge, the first question that comes to mind is who are these bee keepers and what challenges do they have with maintaining the health of their hives? This seems like a good opportunity for an empathy building method, such as an Interview of As-Is Scenario.

The next question I have is what opportunities are there to improve the bee keeping experience. Rather than spending time to fully develop Needs Statements in a short workshop, I’d have workshop participants label Needs/Pain Points/Opportunities directly onto the As-Is Scenario.

The next question is what can IBM do about these identified Needs/Pain Points/Opportunities? Big Ideas is a method for quickly generating lots of ideas. Another possible method is the Creative Matrix (from LUMA). For the Creative Matrix I’d put the Needs/Pain Points/Opportunities as column headers and then choose some IBM IoT technologies as row headers.

The next question is, from all of these ideas, what do we want to focus on first. There are a few ways to go about this. We can write Hills to get a high-level vision for the direction of this product. Depending on the level of research done, it might be too soon to get something good. The second way is to do a Prioritization Grid or Pyramid of Priority to see which ideas should be done first and start user testing. A third way, which is less common, is to create a Mind Map of the features for this product, and then dot vote or use a Bulls Eye Diagram to decide where to start.

Coming out of the workshop the team should have a clear idea about what they want to do next, which will revolve around testing ideas with their users or testing the technological possibilities of their ideas. This aligns with what the workshop sponsor was expecting.

Try it out!

The best way to practice workshop planning is to do it! Short workshops are easier to handle, so start with some two or three hour workshops. Make sure to solicit feedback from your participants at the end of the day using a Feedback Grid. Then use the feedback to iterate on your delivery and continue to improve.

— — — — —

Eric Morrow is a Design Facilitator at IBM based in RTP. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.