A Design Thinking Exercise and the Stories of Redirected Edges

I've written occasionally about how I use an adaptation of George Kembel's design thinking framework in my teaching and research. Back in April 2016, I gave an overview of how I use it in CS222; today, I will give a few more details, since I saw something new happen this semester that I haven't seen before.

A Design Thinking Framework

I introduce this design thinking framework during the third iteration of the CS222 final project. I tell my students about how I use it and how my teams have used it, usually by leaning on the story of my VBC seminar—a story that is repeated in my Meaningful Play 2012 paper. The short version of that story is that, even though that team knew this reference model ahead of time, they fell into an Ideate-Build-Test loop that brought them further and further away from the community partner's needs and an understanding of the audience. It wasn't until an outside force pushed on them that they were able to recognize the problem and realign themselves.

The CS222 exercise has each team start by drawing the model on the whiteboard, and I challenge them to trace their paths through the different phases, starting with what initiated their project pitch. I encourage them to annotate each arc with evidence, noting how they know that they shifted between phases. I have to be careful to tell them that no path is wrong, especially since they didn't have this model ahead of time; rather, we are using this reference model to describe different kinds of activities and consider the transition between them.

After fifteen or twenty minutes of working at the whiteboard, a student team might come up with something like this:

The above diagram is from a team who decided to create an Android project, and they did not know what kind of challenges they would face by having to learn a new platform. It's not uncommon for these teams to have no activity in the Empathy area: it wasn't required, and teams usually jump in with Ideate. After all, my CS222 class is the first place in the curriculum where I empower them to make what they want, since I'm evaluating the processes they follow rather than looking for a specific implementation detail.

Some of the teams take a bit more care in laying out and labeling the diagram, producing something like this:

This happens to come from a team that is building a tool to assist students in scheduling classes. Again, it's not so much the content of these figures that's important, but the form. Once everyone has completed their diagrams, we go around the room and ask for an overview of the process. This usually leads to some interesting discussions, for example about the role of empathy, or the difference between identifying problems and coming up with solutions.

On Tuesday, I noticed something on the board that I didn't remember seeing before. Check out this diagram from a team that is creating a Dungeons & Dragons character generator:

In particular, look at the arc coming out of Ideate and how it heads toward Build and then spins back around to Identify. I asked the team about this to make sure I was reading it right, and they confirmed: after coming up with ideas, they were prepared build a model... but then they realized that they weren't really sure what problem they were solving. In pure graph-theoretic terms, it's just a directed edge from Ideate to Identify, but it's clearly so much more than that: the team felt a force on them, they felt a shift, and they pushed themselves purposefully in a particular direction. I am not sure what to label this phenomenon. I thought about "storytelling arcs" but that sounds like three-act structure, and I thought about "narrative arcs" but that's even worse. I'll call it a "redirected edge" for now.

I talked to this team as they were working on the diagram, and a few minutes later, we had the class presentations. The first team to present is working on a tool that aggregates online information for people who are moving to a new city, and their diagram looked like this:

Look at the black arc from Identify to Build: it's another redirected edge! In this case, the team identified the problems that they would like to solve and had planned on using the Zillow API. When they sat down to start building experimental code, it was only then that they realized the API would not work, and so they bounced over to Ideate to come up with new potential solutions to their problems. Now, one might argue that they had in fact been in the Build state, or that they were not really coming from the Identify phase because they had ideas of how to solve the problems, but that's not relevant here.

I'm not so interested with how well the students understood the design thinking framework after a thirty-minute introduction, but rather with how they are using the diagrams to build a visual narrative of key events in their project. The rest of the arcs in all the diagrams I have shared are drawn in a pragmatic way, with some care toward making the lines clear and reducing edge crossings. These redirected edges are different: they are capturing a feeling the teams had. In the case of the D&D team, they had a feeling of moving in one way and then being pulled in a different one. In the case of the Moving Cities team, they felt like they "bounced" off of one phase and landed in another.

I am not entirely sure what all this means, but it strikes me as interesting. I don't remember having seen it before, and the fact that I saw it twice on Tuesday struck me. If nothing else, I want to keep my eyes open to this kind of phenomenon, where the team is breaking out of the genre norm to express something meaningful to the team. Maybe there's even something there that could be used as a seed of a team retrospective meeting. The diagrams reminds me in some ways of when I used to use mind maps in CS222, that most of them would be somewhat perfunctory but occasionally I would see one that told pieces of a coherent story. I have since cut that exercise primarily for time's sake, although I think about bringing it back in.

Thanks for reading, and if you're reading this on the day it was published or its anniversary, Happy Thanksgiving!

Metacognitive learning through a design thinking framework

I have written a few times about the design thinking model that I use, lightly adapted from George Kembel's:

Brian McNely and I wrote a paper about how we observed a team falling into a failure mode of looping like this:

That experience inspired me to start using this model as an exercise in CS222. Around the beginning of the third three-week iteration on the final project, I take a day where I begin by introducing this model. Then, I ask the teams to annotate their paths through the phases, starting with their project pitch, and annotating major milestones such as the ends of iterations. This is a great metacognitive exercise that gets students thinking about how they have been proceeding. Inevitably, I get a student who reports that they did it "wrong" by starting in somewhere other than empathy or by jumping between phases, but then I explain that we're not using this in a prescriptive way, but as a tool to help us think about our processes.

In this semester's CS222 class, we did this exercise last week Friday, which was the first week of the final iteration. This is the only photograph I have of the event, but rest assured that this is representative of the kinds of diagrams the students generate.

I usually tell the story about the study that McNely and I did, pointing out that sometimes we software development types get stuck in "ideate-build-test" loops without stepping back and remembering for whom we are building this thing. The arcs in students diagrams tend to have a similar shape, often skipping over the empathy step entirely (which is understandable since it's not really connected to our course learning outcomes).

On Friday, though, I saw something I had never seen before. The last team to present their models showed that they had a strong arc like this:

That is, they observed that they identified the real problems within a specific demographic, but they never actually decided which of those problems they would solve, and how they would do so. Instead, they went right from identifying the problems to programming. Having looked at their code in two formal evaluations and some information evaluations, I think this is astute: it perfectly describes the failure mode that they fell into. The team is pulling itself together in this last iteration, and I hope that this exercise is formative to that process.

As I was talking to my class about this model, I had a moment of inspiration where I realized there may be disciplinary differences in how one gets trapped in subcycles. This is only a hypothesis at this point, but I think I've seen this before in my multidisciplinary classes:

I see programmers fall into the trap where they think of something, build it, think of something else, build it, and so on, without ever meaningfully evaluating it or really returning to the user's needs. The humanists--such as English and History majors--tend to think about the problems that exist and think of solutions, then think of other problems, then think of solutions, and so on, without actually building anything to validate their ideas. I wonder if teaching this model early would help students to frame their processes in a useful way and help them catch themselves unproductive spiraling.

The Design Thinking Game

This morning in my game programming class, we started a short unit on game design. I brought in some prototyping materials and gave the students ten minutes to whip up a board game in the roll-and-move genre. This was inspired by Ian Schreiber's Game Design Concepts Level 1 activity and its primary purpose is to get students over the invisible barrier, "what if I cannot make a game?"

To explain what "design" is, I had started with a brief presentation of design thinking. Once I got the students started with the activity, I decided to sketch out a game as well. Glancing at the chalkboard, it struck me that the design thinking cycle could be modeled as a board game, so I made this:

The captions on the boxes are:

• Empathy: an audience
• Identify: a problem
• Ideate: a solution
• Build: a prototype
• Test: a strategy

Each player starts at Empathy. Each turn, you roll a die and move that many spaces along the cycle. Grab a blank card and write down something that happens in that phase, using the caption to guide you. For example, my first turn, I rolled a three, and ended up on Build, so I made a build card, "Sketch." Then I rolled a two, putting me on Empathy, so I made an empathy card called, "Elderly." As soon as there is at least one card for each category, that player takes one card at random from each category and has to make narrative that explains how these five things fit together. I didn't get far enough in my own design process to decide on an initial scoring or elimination process, but I imagined that the other players would somehow score the story, and there would be a time or point threshold to trigger the end of the game.

That's it. A ten-minute game, most obviously inspired by design thinking, 1000 Blank White Cards, and Dixit. Is it fun? No, not really. You fly around the board and are forced to invent artifacts separated from any context, so you can only be very generic. Is it good? No, not really. It completely misses the point of design thinking, that you have to go through each phase to get to the next. So, why write it up here? It was actually a fun thought experiment. I used this ten-minute design exercise at the AIM conference a week ago, but I did not actually participate, I just observed. It was much more fun to actually get in and do it. I also enabled me then to present my flawed game design first, demonstrating the importance of metacognition, specifically learning from the process rather than judging the artifact too harshly.

Bloom meets Design Thinking

I have been working on a book chapter the explores many of the themes on this blog, particularly those relating to the Morgan's Raid project. Here is a sketch that did not make it into the chapter: an exercise in comparing Bloom's Taxonomy of the Cognitive Domain to a design thinking process.

I think the idea is compelling, but I have not had the time yet to fully flesh it out. My initial analysis revealed what one might expect: most of the design thinking steps explicitly involve cognitive activity at the highest level of the cognitive domain. Maybe there's something more there, and maybe there isn't. In any case, it was fun to draw.

Design thinking graphic

Design thinking.

I needed this image for a proposal I am writing. I can't tell you how many times I've sketched this. It's not quite as pretty as the one I had been using, but it saves me space in the attributions, and it should be reproducible in greyscale without trouble.

Design Thinking by Paul Gestwicki is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.