Edit: Somehow I left out the last paragraph of my essay. Now it’s fixed!
For the last four weeks in Tom Inns’ Strategic Design Thinking class, we have been practicing various tools. We have covered a different tool each week, and at the end we were asked to write an essay on them, explaining how they would fit into our design practice, and if so, why? We were also to address which tools we thought were the most useful, and how we felt they could be improved. Before I get into the essay, I thought I’d show you the tools we worked on. My group (consisting of Cora, Caoimhe, Jamie, Mark, and I) was redesigning a grocery delivery service. (More tools after the jump!)
Tool 1: Stakeholders
Tool 2: Complexity
Tool 3: Synthesizing Strategy
Tool 4: Service Blueprint
These tools highlighted for me how much I either do not have a design process or do not understand the design process that I do have. I began to suspect this when I did the Process assignment earlier in the semester, but I had not yet realized the significance of that lack of defined process. In addition to simply making the question of “Where do these new tools fit into your practice?” more difficult to answer, it also makes the process impossible to improve. What I do understand of it is this: I am an ideas person, a magical-stroke-of-inspiration person. I approach most tasks in an unstructured, create-by-the-seat-of-my-pants way; I think about the problem until I get an awesome idea, and then I take that awesome idea as far as I can take it. Occasionally, that idea won’t pan out, and then I reconsider, modify and reiterate. I hate being slowed down in the pursuit of an idea. What is noticeably missing from that is a period of idea consideration, of “lensing” and “pulsing”, in which I contemplate numerous ideas, building on and playing with them to see how they fit into the world at large.
The essay that I was planning to write is quite a bit different than the one I find myself writing. I was planning to write about how frustrating I found the complexity tool set. I was going to write that it was repetitive and pedantic and patronizing. I was planning to say that it would never fit into my design process–it slowed things down, brought my creative self to a screeching halt, like an impact with the side of a rhinoceros. “I do not need to sketch to communicate ideas effectively. That is why we have language instead of hieroglyphs. Words are evocative and concise,” I planned to write. I was going to throw in a “and lensing and pulsing are irritating and mostly meaningless buzzwords,” as well.
My extreme irritation with the tool sets in general and the complexity tool specifically is really telling. As I have come to learn more about myself this semester, I am realizing that it is often the things that I hate the most and fight the hardest that will be of the greatest use to me. I am recognizing that anything that makes me kick and scream and hiss and scratch is probably exactly what I should be doing. Those are the things that I can most use to improve myself as a designer and as an ethnographer (and maybe as a person).
The trick, then, is how to incorporate them in way that doesn’t make me spend my entire design process wanting to peel off my skin with a fork. Three of the tools I feel are excellent the way they are. In particular I love the stakeholder tool and the service design tool just as they are: short, sweet, clear, and obviously useful. Both I feel are particularly well tailored to software, which is the variety of design with which I am most familiar. Those will fit seamlessly into what little organized process I have. The only modification I would make there is to rename the “primary”, “secondary”, and “tertiary” needs, as those labels are confusing. As currently labeled it suggests that the primary needs are more important than the tertiary needs, while in fact they are just less specific. A more clear presentation of their purpose would be to call them “general”, “more specific” and “very specific”.
Trickier to incorporate is the complexity tool. While I am aware that it forced me to do something I need to start doing, it also dragged on forever. I feel it is inappropriately long for a single sitting, and the purpose of the final sketching of the process is not readily apparent. The “Free Creativity” and “Free Evaluation” could be dropped entirely, as those are almost entirely a repetition of the “Priming the Mind” step and the unarticulated step that occurs between “Priming the Mind” and “Mapping the Levels”, in which the group decides which idea to map. If “Free Creativity” and “Free Evaluation” must be left in, they should occur between “Priming the Mind” and “Mapping the Levels”. If that organization is used, “Forced Creativity” and “Forced Evaluation” should follow “Free Creativity” and “Free Evaluation”. However, I feel that having both is unnecessary–Forced Creativity feels like a brainstorming technique for those unfamiliar with brainstorming (and would be wonderful used as such), but is not as useful for those familiar with the technique.
The best way to struct
ure this, in my mind, (and the way I will structure it in the future), is to split the complexity exercise into a number of rounds, to be decided based on how much time there is available for the idea-generation and evaluation phase.
Each of the current sections is sorted into one of three categories: creativity, evaluation, and levels. “Forced Creativity”, “Free Creativity”, and the “Green Hat” are all in creativity. “Forced Evaluation”, “Free Evaluation”, “Black”, “White”, “Red”, and “Yellow” hats are all in evaluation. “Mapping Levels” is in the levels category, which should probably be augmented with another spin on the same issue.
Then, based on the audience and the design problem, one selects activities from each of those categories. For instance, if I were working with clients who had never designed before on a problem they considered truly intractable, and I had time to do five or six activities, I would select “Green Hat”, “Black Hat”, “Mapping Levels”, “Forced Creativity”, “Free Evaluation”, and “Mapping Levels”. If I were running that exercise in an engineering setting, I would use “Forced Evaluation” instead of “Free Evaluation”. Breaking up the tool kit in that manner allows one to customize it to each setting, and prevents the frustration that the static exercise caused. Additionally, I believe that modifying it thusly will allow it to fit into my design practice in a way that requires less brute force and induces less angst.