Food For Thought: Design Thinking Put Into Practice

As a fourth grader — at the wise, ripe age of 10-years-old — I was mastering multiplication, curating current event reports, and parsing basic poetry. Beyond math, writing, and reading, I was also discovering new, fascinating scientific knowledge about the world; my curriculum ranged from classifying organisms and memorizing anatomy, to discovering food chains and trying to grasp the vastness of ecosystems. Most notably at the time though, I was introduced to the scientific method, even though I didn’t think much of it beyond what it represented at face value. Looking back on these sentiments though, I have realized just how foundational and applicable that simple scientific methodology can be within the multiple contexts and complex experiences of our lives. While there are different versions of its steps, I believe that the most popular order of the scientific method is an ongoing cycle of observing, questioning, researching, hypothesizing, experimenting, testing, and then concluding. To translate these steps into the language of designers, these stages parallel the ones that take place during the design thinking process: to empathize, define, ideate, prototype, and test, ad infinitum. So, if somebody were to ask me to define what design thinking is in layman’s terms, I would respond simply like this: design thinking is a science; it is about observation, experimentation, and repetition.

In my Fall 2022 Design Thinking for Creative Problem Solving course, I learned that along with angsty teenagers, designers also often feel misunderstood. In this past semester, I have learned that the process used to design the simple products that we use daily, is not at all simple itself. Every decision that a good designer makes has to be grounded in research and reasoning, a condition that is often overlooked by the average consumer. In reflecting on the topic of design thinking, I have reframed my perspective on what it means to create a usable, efficient, and accessible product. Through this reframing process, I had the opportunity to delve deeper into the many concepts that surround design thinking, such as systems thinking. In my effort to begin looking at the world through a systemic lens, I was simultaneously learning how to zoom in and zoom out of the world. Systems surround us; everyday we face the effects of the macro- and microsystems in our environments and make decisions based off of them, often subconsciously. Designing through a systems thinking approach is exponentially helpful in allowing designers to understand the why and the how of people’s experiences in the world. In a nutshell, systems thinking is being able to understand the non-linearity of relationships. There are more connections that exist between the elements of our lives than what the eye can see and many times, end products are the result of multistep processes and feedback loops. The core of systems thinking is acknowledging this ability to step back and acknowledge the influences that affect a person or a thing. I have used systems thinking during my course during its initial introduction. At that point, I mapped out work-life balance and quickly saw just how convoluted and complicated it can be to manage such a common issue that people have. In the center of a piece of simple copy paper, I wrote the words “Work-Life Balance”, and words I associate with it and from there, used a multitude of arrows going in a multitude of directions to acknowledge connections. Here’s what the map looked like:

Inspired by the amount of insight yielded from just that simple map, I also applied systems thinking in the semester-long design project that my team and I completed. We started off with the prompt, “how might we reduce food insecurity and/or improve nutrition for individuals or families?” Despite this prompt’s generality and limited direction, we ended up producing MADMatch, a food resource matching app. In the app’s final state, people have the ability to type in their location on the app and immediately find free or affordable food resources within a filtered distance around them. To come up with something like this, we conducted secondary desk research via journals and scholarly articles and primary research via interviews with people who have dealt with food insecurity and organizations that have helped to alleviate it. Through the research itself and the synthesizing process, the systemic implications of food insecurity floated to the surface rather quickly, giving us a clearer big picture of different ways that food insecurity experiences manifest in different contexts.

Circling back to fourth grade me, I only believed that research consisted of white lab coats, microscopes, and (very reliable) Wikipedia searches. However, over the years, I have been proven wrong time and time again, especially during this semester. During the last few months, I have been exposed to the many ways that research is integral in the design thinking process. Beyond being a commonly used buzzword in many classrooms and academic settings, research also plays a vital role in design careers. With research, especially in the design frame of reference, you are able to understand users better, and therefore, build better solutions. Without hearing a firsthand perspective from someone who has dealt with food insecurity, I doubt I would have been able to make such real observations, conjure such relevant insights (pictured below), and ultimately design such a fitting solution. New information is a sacred gift to designers; the value in research lies in the fact that it provides clues that people can use to guide their design choices. Research is a strength because it helps us minimize biases, make corrections, and provide inspiration for features and design decisions. Since research is all about investigating and drawing conclusions based on reality, that fact alone is enough to determine that without research, a majority of the popular products that we use today would surely not be as effective as they are. John Heywood was onto something when he said that Rome wasn’t built in a day. To make the quote more applicable in this context, we can modify the quote to say, “your most useful product wasn’t built in a day.” Along with learning that research is incredibly important, I also learned how much of an in depth process it can be. From outreach, to creating discussion guides, to recording interview notes, and synthesizing those notes, it made me realize that there are processes embedded within the design thinking process itself.

Aside from questioning what the research data will look like, it is just as important for us to think about what we will do with our research findings in general. After all, it is a pointless endeavor to look for answers that you won’t put to use. This is where ideation and solution exploration come along. For as long as I can remember, I have always been used to putting things in order. This is why learning how to synthesize pages and pages of research data and information was quite the experience. However, the affinity mapping portion (pictured below) felt like matching unsorted socks (a.k.a instant serotonin boost). Without this stage of convergence, it would have been really difficult to have a useful brainstorming and ideation session. Luckily, this was not the case for my team and I, as we came up with over 50 potential design solutions (pictured below) that would help us help others combat food insecurity. Among those initial ideas were a physical/digital cookbook that would have had simple recipes using affordable ingredients, a traveling food pantry, and even an advertising campaign. It was a rewarding experience not being tied down or obligated to use the ideas that we came up with; this alone helped us stay fresh, non judgemental, and creative. As a whole, this solution ideation portion of the design process demonstrated that no singular idea is perfect, but also that no singular idea is actually “bad.” We actually practiced an exercise where we had to come up with the “worst possible idea,” and somehow, even though it sounded like an easy enough task, this was actually very difficult for me. Nonetheless, coming up with so many ideas gave my team and I the wiggle room and opportunity to sift through and analyze our options. We eventually had to narrow our solutions down to one that could effectively answer the initial prompt, have feasibility, and be relatively accessible to a large array of people. In doing so, I learned that ideation can sometimes be a more straightforward and effective process when in a collaborative setting. Seeing an idea written by a peer can inspire new ones from you, creating a never-ending cycle of idea generation; this feat in itself reminded me just how beneficial it is that everybody’s mind is unique and processes things differently.

Moving forward from exploring potential solutions, and finally selecting the “winner,” we moved on to the prototyping and testing stage. Approaching this stage seemed daunting at first, because I felt a certain pressure that the most effective testing of our solution would require a top-tier, refined prototype. However, during that daunting day, I was given some of the best advice a designer could get. I was told that a prototype doesn’t need to be extravagant or truly contain all of the elements you imagined for your solution. As long as you decide on a medium that will help you test the concept of your solution effectively, you can create a functioning prototype. In our case, we simply used a Google form to determine interest and figure out exactly what we needed from our users in order to design the most optimal product to provide them with. Building this prototype — or quite literally, typing it out — was a lesson within itself. For our final app, we planned to create a screening process where individuals would put in their information, submit it, and immediately get brought to a page that would return a list of food resource matches based on their inputted details. Users would also have access to a multitude of different special features (pictured below) that would allow them to keep track of food resources, and keep track of their personal spending habits. With testing, we had to be strategic about the questions we would ask, and how we would ask them, given the sensitive subject of food insecurity at hand. During different iterations, we would change some of the questions or reformat them (i.e choosing whether we wanted typed out answers, multiple choice, or the “select all that apply option”). Given the resulting responses from the app we received, we compiled enough information to create a profile for each individual, which is exactly what the final app would need to do. Additionally, we learned a lot about our participants through the testing process, such as the fact that some people are just not very comfortable giving out personal information and that some people need very direct, clear directions when it comes to answering questions or providing feedback. Without us giving options for some of the questions, the answers would have varied too much to the point where there would have been a lack of consistency and therefore, a limit on the accuracy of the conclusions that we could have drawn from the data. This was the one drawback of our initial prototype. The fact that we weren’t directly speaking to individuals and we were only able to learn about them through their response to a 5-minute survey put a figurative barrier between the answers they provided and the “why” behind them. This is why balancing this prototype with the original primary interview research that we conducted was necessary to maximize the usable information we were able to utilize in subsequent stages of our project.

Fieldwork in and of itself has its own highlights and challenges. In my experience, research and prototype testing are infinitely rewarding in the design thinking process. There is nothing more refreshing than someone asking you to corroborate your choices, and having the actual observations and insights to do so (pictured below). With that being said, the process of conducting research can be difficult in that it requires you to know almost exactly what you’re looking for, before you even do the “looking.” I realized this when my team and I were deciding which questions we should ask for our participants. Trust me, it was quite the humbling experience to have a few of my questions get called out for being too leading or bias-ridden. Nonetheless, I wouldn’t have had it any other way. In the future, I believe that we could always test more potential users as well as modify our questions to be more general and open-ended to provide for more individualized and specific answers. One of the most valuable parts about researching people of different backgrounds is the fact that they are from a different background; there is power in having your own story to share. Given this though, a question came up: how can we actually tell where one’s story lands on the spectrum of “the general population” to “edge case”? This is one of the most difficult things to navigate when doing research. If you don’t do enough research, then you can easily fall into the habit of inappropriately generalizing information to more people than you should.

Sure the design thinking process can be a solo activity, after all, you do you. However, I found it to be a much more effective experience with having other people along for the ride. As difficult as it can be for some people to accept, no person has all of the answers. However, you have a better chance of reaching potential answers by putting multiple heads together. Whether my peers were contributing entirely new ideas, building off of existing ones, or agreeing with or respectfully challenging potential ideas, the multi-angled support was quite beneficial to our project as a whole. In my opinion, collaboration is more valuable than it is challenging, as long as everybody is on the same page and committed to the project to the same extent. If this is not the case, it is very easy for a group to clash, ruin productivity, and ultimately lose sight of the goal. I plan to approach collaborative projects in the same fashion that I did with this one since it worked out so smoothly. In the beginning of our project, my team and I clearly outlined our expectations of each other, communicated our schedules, exchanged contact information, and generated a project plan. When people have transparency and clearly defined responsibilities to take on (in writing, especially), collaboration becomes equally simple as it is advantageous.

While this course has been constantly changing my mindset, there were a few instances where I felt the shift in my thinking a bit more prominently. One of these, for example, took place when I heard a brief story about a product that was created that had an unsuccessful run. The story was spoken about for no more than two minutes during class time, however, its impact has lasted. Essentially, a travel planning app was created with the objective of helping people plan out their vacations in a straightforward and organized manner. When I first heard this, I immediately — and I admit, dejectedly — thought to myself, “wow I’d totally use that, I wish I thought of the idea myself.” However, learning about how the idea of the product seemed so ideal and useful, but how it still failed to gain traction after launch, provided me with more wisdom than I would have expected. It simply put things into perspective for me and made me realize, candidly, that sometimes people just don’t want what you’re offering them. You could have the most red, crunchy, juicy apple, but there will still be people who don’t like apples. We cannot really help what people will and will not use, but we can use research to the best of our ability to predict these things. This one story shifted my thinking because it served as a reminder that designing products and services is always a risk. However, it is up to us as designers to research and dissect the risk factors that would affect the success of our products across audiences.

In summary, I experienced successful highs and challenging lows in my Design Thinking course this past semester. Among my successes was collaborating properly, conducting interviews with the right people, curating copious amounts of research data, and synthesizing all of that data to come up with a real, practical, and usable solution. As much as I wish that it was a smooth sailing experience to attain these goals, it wasn’t. I had trouble with recruiting participants, making sure I was asking the right questions, coordinating with fellow peers’ busy schedules, and figuring out how to present our process and solution in the most clear and communicative manner. My team and I overcame these challenges by just increasing the amount of outreach we did, asking questions about our questions, sticking to a consistent time to meet, and secretly researching “the best ways to pitch a product” — in incognito mode, of course.

Three months after walking into this course for the first time back in September, I am a changed person. While my height has been unwavering, my approach to concepts, and conversations in different contexts has evolved. One of the key takeaways from this class is how dangerous assumptions are. It is easy to view something as a great idea if it came from your own head, or if you could see yourself identifying with it. While the first stage in the design thinking process is to empathize, we should be wary of confusing this with making ourselves — the designers — the users. This is one of the biggest lessons that I learned during this course, since I am so used to viewing situations and ideas through my own personal lens. I realized that without keeping ourselves in check, we can easily fall into the routine of designing a product for ourselves rather than for our target users. As an adjunct takeaway resulting from this one, it is imperative that we always refer back to not just our research, but also our initial goals. Design thinking is not just a process, it’s a cycle. So, upon following the usual order of the steps, it would benefit us to sometimes take a step back, look at everything we have put together thus far, and ensure that our observations are relevant to our questions and our solutions are relevant to our intentions. Since designing is like one giant puzzle, just imagine trying to finish a 1000-piece puzzle by focusing on only one piece at a time, a borderline impossible task!