d.school
July 2012 - Expanded Notes
d.thinking Modes: Empathize. Define. Ideate. Prototype. Test.
I attended d.school at Stanford for their July bootcamp. It was a fantastic experience because of the richness of the ideas that formed over such a short period of time as well as for an introduction to a really solid and approachable process, Design Thinking, for generating viable product and experience design opportunities.
I'm writing this for my benefit. I want to catalogue some notes to my self and expound a bit on them so as to make it easier to reflect on the experience in the future and to build on ideas right now. It's been roughly 2 weeks and spontaneous new ideas as a result of the experience have stopped forming on their own. I thought it time to use writing to push the process a bit. Further, I figured I'd stick them on this blog because 1) I wanted to simply make them available as an act of openness and 2) I'd welcome the chance to chat through any of the following. I am freshman as it comes to this process and I welcome the chance to work with these ideas further because they've proved quite profitable thus far. Now I am intent on getting practice.
The Design Thinking process includes the following "modes:" Empathize. Define. Ideate. Prototype. Test. I've sorted my notes from the "d.bootcamp" experience into these categories. I've added a +Plus bucket at the end for stuff not tailored to a specific step in my mind to this point.
So… on with the show. I know that the three days did not all sink in. The following is some of what did.
Design Thinking seems like a practice. It's something that is moving and changing and that you can get more effective at over time like a Doctor or Lawyer might. I look forward to that process.
Empathize
I was struck by the contrast between the rigor of Stanford, an institution (e.g. brand) of the "mind," you might say, powerfully championing deep interest in other humans. This is about blatant curiosity well packaged and pointed at others. This mode, empathy, might seem like an obvious first step. I now know, done a d.way, it's a fantastic first step. Yet, I've noticed It's not a step I've often first thought to do. That'll change going forward.
It's simple. Observe folks. Just what do you see… (not judge) the facts to be. Then, Engage with users… real live folks. The more fringe the folks the better it seems. And, finally, aim to Immerse or find ways to experience a something as your user experiences that something.
The tricky part about Empathize is that you have to take your face and your body and go meet a stranger and be genuinely curious in them and what they are doing and felling. After some practice it's easy to build some momentum and for this stage to not be crazy. Without the practice, I, and a large group of folks I've talked with regarding this stage, find this subtle fear to be just enough of a reason not to use the Empathize mode. After having done it… get to it… The reward and value of the process far offsets the tiny and short lived discomfort you might have just thinking about talking to a stranger.
"Bias toward action" is a phrase I saw written on boards and mentioned through to the d.bootcamp. I really like it. Here seems like a good place to mention it. While it applies to most everything about working in a d.way I think it defiantly applies to empathizing with others. It takes work and your decision to act to learn about other people to the point where you can put yourself in their shoes to any meaningful degree.
And having a Bias toward action leads me to a brilliant phrase I heard and really dig… "Don't get ready. Get started." There is way way to much planning on a whole to my mind. Even more me… and I love starting things. What I want to embrace about this phrase is it's tight relationship to action. There is so much learning to be done by doing… get out there and do it.
So… Empathizing… just do it. As a Marine might say "Get some."
Define
Is a process of packaging what was learned in the Empathize mode. I really dig the fill in the blank approach. Blank needs Blank Because Blank. Love it. It's simple. It also seems to open space for a whole problem to be Re-Framed. When something is seen or thought of in a different way it opens the way to magic. I love this mode. This is the core of what the remaining modes continue to return to.
Ideate
Make ideas and log ideas. Go for volume and variation. The d.school has a number of methods for this mode. They were quite helpful in providing structure. The empathy map and the voting process were particularly efficient at wrangling our teams seemingly skitzo focus. We had fun. We made some real solid ideas.
The most interesting things I learned in this mode was not about a method but about me. I've been known to spin off ideas in rapid form. I really dig this mode. Ideate! The crazier the idea the better to my mind. The faster the better. I enjoy soaking up information from all over and learning about how things work. Not many days go by where I've not sought to learn something new or different. Partially because of this making ideas and making wild ones moves fairly quickly to my mind. What I learned is that I need to seek clarification regarding these crazy ideas.
We had a set of ideas that quickly ran off the chart. Looking back… I assisted. What I know now is that tending to the quality of delivery and a recipients understanding of an idea might be more important than the craziness of an idea or even it's quality. Maybe. I'll need to test.
Further, I know I need snips of time to digest and re-frame issues. What I learned is that if I take that time in a group setting it's easily perceived by a team as a lack of focus on my part. I often work physically alone but connected to a team via digital means. When I am working on an Idea I often get up and just go walking. That does not play as well in a physical team setting. I'll watch that in the future.
Space signals permission. This seems like a solid place to address space. There was an exchange between an academic perspective and a practitioner perspective that seemed to argue both sides of this debate. One says space has no meaningful impact on productivity or financial payback. The other said basically that space signals permission. It's not the space that's important but the behaviors a space promotes in a context as it relates to a participants regular work. Space can be a trigger to work differently, to be free with ideas… to make and do new things.
Prototype
Make - The behavior of physical-izing ideas, whatever they are, is of rich value in rapid form. Ultimately we built a change for an experience as a team. So, there was nothing really physical about what we were making. However, The process of prototyping was abundantly helpful. As we started to roll play and act out experiences our ideas were morning and so also our solution. We'd "run it again" and find something new and change the solution or product all with in 5 minutes or so. We did this again and again and refined and refined the solution. When moving that quickly it was magic to prototype. More of this please.
Test
Having to test builds pressure to get your prototype done. Go. It also provides the opportunity to iterate rapidly. We had the kernel of an idea. As we tested with new folks we kept tweaking after each test. We changed the product 5 or 6 times in a 45min window and all because of interacting with new folks and testing.
Aim to be re-interpreted. I like the serendipity of this disposition. As a Design Thinker stepping through the process you have a vague idea of what you're making. It's fantastic when others see the context and your test and re-interpret something. We made a couple nice discoveries by being mis-interpreted… and thus we needed to re-interpret.
Cycles bring greatness. I heard this phrase and initially brushed it off. Yet, as we run the process in macro multiple times in three days and then in micro many times it became more and more clear to my mind that the doing and doing and doing is where some great thinking can come from.
+ PLUS
Learn by data. Learn by doing. Learn by teaching. These three ways to learn were all used. In many experiences I've only engaged in the Learn by data approach. The doing and the teaching mixed in made the whole process much more rich.
This one is a bit side rail. Reasons are bullshit. People do things. When you ask them why they did certain things they can say just about anything and those can be nice reasons. The reality is there is a huge difference between what people say they do things for and why they actually do things. Many times, if not all the time, it's not a nice little package of an answer as to why anyone does anything.
Trying is not nearly as important as intending. This connects with the point above. If you decided to do something then you don't have to try. Rather, that something will get done.
Design is not good business. I found this return on investment (ROI) answer to be really curious so I asked Diego about it separately. Most of the arguments about Design and Business, to his mind - and I agree, miss the point. Using design to make good business is good business (operations). Using to design to simply effect the products of a business and not the business it's self misses a huge opportunity.
Ideas worth building can come from any group or person provided there is a means to obtain them. Groups are inclined to assume that new has to come from outside the organization. This d.thinking process stands as a strong method for making and advancing new ideas from with any group.
As a member of a startup there is me, and my group… there is no organization. In day three there was a focus among the attendees about how to bring d.thinking back to each person's organization. Most of this talk seemed not to apply to startups. That's curious to me. A startup has individuals and small groups. There are not many "organizational" formalities to jack with a d.thinking process.
The Design Thinking process is a Sales process. This was a brighter moment from the three days to myself personally. In a debrief is was pointed out how quickly passionate folks can become for ideas generated via the d.thinking process. It is remarkable how invested one can get in a crazy short period of time. That's sales. I am still unpacking this insight for now… but I know there is something core here.
A different work product comes from working differently. That seems obvious. This insight occurred to my as I described this d.thinking process to a top Planner in an agency context. I am really interested in how focusing on how work is being done and the context it's done in can easily alter work product. Focusing on the work does not seem to have the same impact. That's curious, really really curious. Maybe it's summed in a phrase like "the how commands the what," I am not sure at this point.
Those with the prototype wins. Making prototypes don't seem to be a common practice. I don't see them nor hear of many of them. Therefore, they stick out when you see them. Make them. See if you win and win quickly when you have a prototype vs not having one in a pitch or internal meeting. It's working for me. It worked for a client last week. I think it works.
Wrap
Ok… there are a pile of notes and reflections above. I suspect that my progress on advancing these ideas and understanding them more fully is dependent on conversations and practice. If you're interested in either… shout.
Onward,
Joseph Rueter