A Design Thinking Framework |
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!
No comments:
Post a Comment