Learning How to Learn: Putting Design Thinking Methods Into Practice

If you asked me to evaluate an average bar stool three months ago, I would have probably looked at it and labeled it with one of two characteristics: “comfy” or, very creatively, “not-so-comfy.” Today though, after weeks of immersing myself into the realm of design thinking and its multifaceted nature, I’d have difficulty rating the stools in the same nonchalant way. Instead, I’d likely start by inquiring more details. My overall evaluation would be influenced by whether the stools can be adjusted for people of different heights, or if the stools have back support for people who need it, perhaps I’d even inquire about whether they swivel, just to know if the stools would allow for easy communication with others in group settings. These “questions,” like the many I conjure now when looking at everyday objects, analyze a product not just for what it is, but also for who it serves, how it serves, and how well it does the job.

Familiarizing myself with the design thinking research process — from empathizing, defining, and ideating, to prototyping, testing, and implementation — has changed the way that I approach problem-solving in multiple contexts. Through the multitude of examples I have seen and the firsthand experience I have accumulated in the field thus far, I’ve realized just how critical each step of the process is. The value in design research stems from the fact that by following these steps, new knowledge becomes new understandings and new understandings become new insights, which provide us with necessary direction. Additionally, without being able to properly define your problem, your users, and your goals, there is no way you can progress in your journey towards a solution, especially since you would have no foundation to ideate on. But even before defining and ideating, one must empathize with their user, a strength of design research that brings a sense of realism to our projects.

Before taking this course, I always oversimplified the meaning of empathy. While “putting yourself in someone else’s shoes” is a functional way to think of it, after seeing the direct role that it plays in design thinking, I realized that empathy is (surprisingly) more than just a shoe metaphor. In fact, it’s about being able to shift your perspective to fit the lens of someone else’s experience, within their individual context. As my classmates and I learned more about conducting design research, I concluded that some research methodologies are better suited to evoke empathy than others. For example, it’s much more difficult to learn about a person’s experience with a problem or a product solely through a 1-minute Likert scale survey. This is the reason why my team and I decided to conduct interviews for our project, because they offer us a direct outlet to understanding the decisions people make and the circumstances that surround those decisions. Situational context has proven itself to be one of the most important aspects of the design process because it allows us to think about the different people and scenarios our product would affect. I quickly realized that we should always be looking for the relationships between those different scenarios and people. By thinking in terms of a system, it became clear that more things than we recognize tend to be connected with each other.

A system, as explained by Donella H. Meadows in Thinking in Systems, is not just defined by the elements that make it up, but rather, how those elements interact in order to carry out a specific function or goal. In her book, she used the example of our digestive system by breaking down (pun intended) its elements (enzymes, blood, intestines, etc.,) interconnections (chemical signals, etc.), and its purpose (to convert food into nutrients, etc.). Systems thinking is about trying to make sense of the world by looking at it through a frame of reference that covers whole concepts rather than just parts. Acknowledging that there can be multiple influences on a single idea allows you to better understand the why and the how of established topics of interest. I applied systems thinking to my current project when I recognized the multiple cycles and feedback loops that exist within the lives of people dealing with food insecurity, my current project topic. By doing so, I was able to properly consider multiple scenarios and reasons for why food insecurity occurs for people without relying on invalid assumptions. Beyond this, my experience with systems mapping — and other mapping in general — showed me that the factors and elements that influence our lives are often interrelated, directly and indirectly informing the path that our life takes. Mapping is especially enlightening because one can see, interpret, and respond to information differently when it is formatted in a visually digestible way. It’s much easier to determine associations from figures, pictures, or single ideas on sticky notes rather than mere words on a page. Here is an example of a system map and feedback loop I made during week two of my Design Thinking course at NYU that demonstrates the truth in this statement. The assignment was based on our topic of choice, and I chose to map out work-life balance:

Diving back into the semester-long project my team and I are currently working on, we officially decided to create a product that helps combat food insecurity in terms of resource accessibility. We conducted at least 3 interviews each, from people who have either experienced food inaccessibility or those who have contributed to efforts that alleviate it. The interview process proved to be much more complex than I imagined it would be, as I quickly learned that while some questions are dead-ends, others are portals to worlds of new information (think of The Wardrobe in The Chronicles of Narnia, but better). Additionally, I discovered that no matter how many discussion guides or questions you prepare beforehand, it is extremely difficult to predict the direction that an interview will go in. This made me feel uneasy at first, I’ll admit, but it ended up being a pleasant surprise to learn things that I wasn’t expecting to learn during my conversations with the participants. When an interviewee says something that is unexpected, or that doesn’t answer one of your planned questions, it can feel like you’re not getting the information you need. However, sometimes it takes a bit of sitting down after your interview and combing through user responses to realize that they answered questions for you that you didn’t even think to ask. I believe that this is one of the unacknowledged benefits of using interviews as a research method. With other, more premeditated methods of getting information from users, you limit their options, essentially pushing them into a mold that doesn’t necessarily fit. From this, we must ask ourselves a new question: how much and which type of information are we willing to miss out on when choosing which research method to employ?

Similar to knowing how to get the most out of an interview, I also had to determine the type of information I was looking for while I conducted secondary desk research. The World Wide Web can be a scary, intimidating place, so it is always best to narrow your search according to your research goals. Nonetheless, convergence can be a tough task. Whether you’re figuring out what to do with all of the information you’ve collected, or if you’re trying to narrow down the path you would like to take for a project given an extremely general prompt, it’s not an easy task. Considering that many design projects are collaborative, this convergence step can either be a breeze or a hurricane. Oftentimes, input from others can help us identify both important and unnecessary information. However, separate brains do mean separate ways of interpreting information. So, how does a team come to a consensus? Well, after my group and I brainstormed for a bit, we compared each other’s ideas for the direction we should go in with the general prompt of “food insecurity,” and then had an open conversation about each of those ideas, comparing, contrasting, and ranking them until we determined our “winner.” This was one of the more challenging experiences that my team and I dealt with as we collaborated, since we had to assess the pros and cons of so many possibilities. All in all though, working in a team was definitely more rewarding than burdensome; it was extremely easy to bounce ideas off of and get inspiration from each other and I believe that we should continue to employ this cooperative ideation method in the future.

With our “winning” idea, we went through a cycle of gathering individual research data and coming back together once a week to share it. As we did this, I began to recognize some key takeaways of research. For example, while gathering data can be helpful to do together, there is a special aspect to getting with your team after coming up with ideas and gathering information on your own; it’s eye-opening to see how everybody’s different perspective shows through the data they end up sharing when the team convenes. At the same time though, brainstorming sessions with each other offer the unique ability to focus on quantity over quality and supporting over critiquing, two conditions that often lead to the most creative and innovative ideas. I believe that quantity is extremely valuable in the research process because the more research you and your team do, the more diversified your data will be, and the more likely you are to design a more encompassing and targeted solution. One of the problems we stumbled upon when dealing with all of our ideas was determining the best way to group them. I initially thought that categorizing would be one of the easier tasks in the research process. However, I realized that in order to truly benefit from grouping anything at all, we would need to create meaningful categories that would actually contribute to our research goal. It was also difficult to determine how “deep” we wanted these categories to be. Creating a subgroup titled “user needs” seems straightforward enough. However, it proves to be too vague of a category when you’re actually trying to do a clear and effective grouping, since we don’t know what the word “needs” represents here (i.e. can be about what an individual user needs in their life or can be about the necessary elements that a product should have for all users, etc.). Overall, I believe that my team and I did a relatively good job grouping our research for our first time, as seen in the affinity map below:

While some of our initial categories were not extremely conducive to synthesizing our data to draw relevant conclusions, as Robert I. Sutton famously said in his article, “Forgive and Remember: How a Good Boss Responds to Mistakes”: failure sucks but instructs. Without failure, as discouraging and counterintuitive it may seem, there is no way to learn. Think of it as a type of operant conditioning; failure acts as the punishment that persuades us to stop making the same mistakes. Failure can also be a reward, serving as the most reliable learning tool to ensure that we make optimal decisions in later situations. For example, in the future, I believe that my team and I should avoid generating too many questions to ask the participants in our interviews. Instead, we should always establish a purpose behind the few — but strong — questions that we do plan to ask and mainly focus on ways to direct the conversation rather than dominate it.

Working together on multiple visual syntheses allowed me to see the project come to life right before my eyes. Laying out our ideas, grouping them, and connecting those ideas with arrows and subheadings helped us see both a big-picture zoom-out and a detail-oriented zoom-in of the problems at hand. Something as simple as the empathy map (pictured below) that I created with my team, representing an NYU student dealing with food insecurity, was so informative in visualizing patterns within our findings. Just from this straightforward method of writing out one’s experience, you can learn an abundance about how social, economic, and psychological factors play into a person’s situation and the choices they might make.

Regarding the overall problems we have identified surrounding food insecurity so far such as lack of nutrition knowledge, lack of time, lack of income, food deserts, and improper budgeting, we have decided to prioritize finding a way to communicate how to find free, helpful, local, and inclusive resources to our target audience. We were able to identify these problems by synthesizing our research findings, grouping them, and determining overlap to draw inferences. While the problems themselves certainly aren’t pleasant, that doesn’t take away from the importance of discovering and acknowledging them. From problems, we can create “How Might We…” statements, a tool that helps us reframe problems in a way that makes room for opportunity. Here is an example of my team doing so:

Problems are also important because not only do they tell us stories about the real people that they affect, but they also help guide us to drawing the insights that will help us develop the most appropriate, accessible, and applicable solutions. Above is a series of solution ideas that my team and I came up with and our votes for the ones we liked the most.

Our research has already been a rollercoaster thus far, and I can only imagine the curves and loops up ahead such as prototyping, testing, and possible implementation. Luckily though, I’m a sucker for amusement parks!