Prototyping IBM Design Thinking Method Cards

Eric Morrow
IBM Design
Published in
7 min readApr 26, 2017

--

Note: This is part one of a two part series. Part one covers the prototyping process Brian and I used to create the IBM Design Thinking Method Cards. Part two discusses how to use these method cards to plan a Design Thinking workshop.

Orienting

Figuring out what to do next when confronted with a design thinking challenge is a critical skill that is often overlooked during design training courses. This skill is called orienting, from the Observe-Orient-Decide-Act (“OODA”) decision making loop created by John Boyd. Boyd was a fighter pilot who also was the first to use a computer to simulate how an airplane would function in combat. His story is well worth a read.

In Design Thinking, we also have to Observe, Orient, Decide, and Act. Observing normally involves understanding a problem’s background and scope. Orienting involves considering the problem in its context, perhaps economic, cultural or political, and determining if it is susceptible to a design thinking approach. And in our case, the Decide and Act phases typically involve a Design Thinking Method.

But there are many, many methods to choose from! IBM has a core list in the Field Guide. LUMA distilled their set down to 36 methods. And there are books like 101 Design Methods. A quick and easy way to browse through the range of available methods and to pick one to use is method cards.

That’s why searching Google for “design thinking method cards” comes up with examples from IDEO, the d.school, LUMA, even 18f, the government design thinking agency. So Brian Burnette and I decided to iterate on the existing IBMDT Field Guide and make IBMDT method cards. Here’s the story of how we got there.

The Xerox “really, really small” test

Our first question was what people would think about method cards at all and if they’d enjoy using them in the context of planning workshops. We started by xeroxing small versions of the existing field guide pages where they describe the IBMDT methods. These prints were just the image of the framework with the name of the method pasted over the top. We gave these cards to the workshop participants and asked them to use the cards to plan a workshop for some existing Design Challenges.

Result: The cards were way too small but otherwise folks liked the idea of method cards for workshop planning!

The Card Format

Our second question was what visual format we wanted to use for the card. We were pretty sure we wanted to start with a few key pieces of information: the name of the method, an example of the visual framework, an explanation of the method, the time the method took, and whether it was an observation, reflection, or make method. We took all of this information out of the field guide, formatted it onto cards, and printed them out of the office printer. We then got feedback on the cards from folks in the office.

Result: Very little substantive feedback on the visual design either way, so we felt like we were good to go on that front. We did get a lot of feedback about what kind of information would be useful to have on the card. The number one most requested item was “Why would I use this method?” That question fits neatly into the OODA loop — once the facilitator observes and orients to the design challenge, the next question is which method should I choose to approach the challenge.

The Great Re-Write

Brian and I then spent a few weeks re-writing all of the elevator pitch statements on the front of the cards. For the most part this involved changing the sentence from a description of the method to an answer to “why should I use this method?”

Our third research question was whether the newly designed cards were functional for facilitators to plan workshops. So we did two things — we left printouts of the cards all around the Studio to see if people would spontaneously use them.

And I brought them to a facilitator training workshop where we used the cards in conjunction with a workshop planning module.

Result: We learned that facilitators still liked using the cards to plan workshops. Generally that involves scoping the Design Challenge, setting a Goal for the workshop, and using a variety of methods to connect the Design Challenge to the Goal.

What goes on the back?

Now that we had pretty good confirmation that the cards were useful, we thought about what kind of information should go on the back of the card. At first we had just copied in the information from the field guide about how to execute on the method. But during the editing process we realized that most method instructions are some version of generate post its, cluster, and remix.

So our fourth research question was to ask people who were already using the cards what information they’d like to see on the back. The most common answer was some form of “pro tips.” This ended up being a really hard task, since all of our text essentially began with a “how to run this method” explanation.

Result: We felt like we had a pretty good grip on the written content of the card, both front and back, as well as the utility of the card.

Replacing all the images

We had heard from a variety of users that the pictures of the frameworks on the front of the card were hard to view, since they were taken from real workshop photos under a variety of lighting and writing conditions. Some sets of cards (like those from LUMA and IDEO) do away with the frameworks all together and instead have iconic images that display the intent of the method. We heard from our users that having pictures of the framework is really useful for practitioners, so our fifth research question was can we make the images on the cards legible and useful. To do that we recreated all the frameworks on flipchart paper and made as clear as possible the permanent framework versus the post its on the framework that are subject to change.

We also tried to add in a little humor here, as well as some shoutouts to people, dogs, places, and web comics that we love. XKCD anyone? Shout out to Noble for spending so much time relaxing and getting pets during stressful workshops.

Result: In the most recent round of testing, we didn’t get any feedback on the readability of the frameworks, so we consider the problem resolved.

Going to full color, full size, and laminated

A guiding prototyping principle throughout this process was to keep everything as low-fi as possible so as to invite the most critical feedback. To that end we explicitly avoided making the cards look polished and finished… until now! We added color to the entire card, printed them in their full size (on 11×17 paper stock), and had them laminated. The final result was very impressive. Our sixth research question was whether a group of facilitators, after using the cards during a facilitator training, would take the cards home with them after the workshop. The cards were made available during the workshop but were not explicitly given away.

Result: At the end of the training with thirteen participants, only one method deck remained in the room.

What’s up next?

Brian and I still have a lot of big ideas for the method cards. We want a box to put them in, so they don’t just have to be rubber-banded for carrying purposes. We want to open source the template so other IBMers can add in the methods they have found useful during workshops. We want to have the deck available on BOND, so any designer, of any stripe, anywhere in IBM, can easily get one. We’d love for the decks to become great collateral for an OM to leave behind after a customer meeting, or swag for sales and marketing to distribute at conferences.

Finally, I want to send a huge thank you to all the people who have tested the cards over the past several months, both knowingly and unknowingly. We couldn’t have made a product we’re so proud of without your unflinching feedback.

In part two of this series, I’m going to describe how you can use these cards to plan your next workshop.

— — — — —

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.

--

--