The first time I thought of myself as a designer was when I began writing curriculum during my third year of teaching. I loved figuring out how all the pieces fit together and creating opportunities for students to discover and create for themselves. I became engrossed in the process of designing each unit and found myself taking days or weeks to think about certain aspects, then continually revising as the year went on. Most of this process was intuitive for me as I sought to design something truly beneficial for my students and future students, but little did I know there is an actual process for design work that includes terms for each phase and tips and tricks each step of the way.
Fast forward several years, and I ended up taking a graduate course called “Teaching Technology through Design.” I will be honest, I thought I would be re-learning a lot of the same material I did when I learned how to write curriculum, but this definitely wasn’t the case. For instance, several of my required reading came from an engineering and manufacturing perspective rather than an educational perspective. My husband, who happens to be a manufacturing engineer, was already familiar with some of the terms and processes I was beginning to learn; “Oh, you’re learning about the Five Whys?” he curiously asked one night while I was working on my coursework, “That’s what I learned when I went to my lean manufacturing training in…” and off he would go, talking about the parallels between his job and what I was learning. It was fascinating talking with my husband and reading different articles on the process of design, and it began to dawn on me that we are all designers regardless of our field of work. In fact, I had been designing my whole life and slowly learning more about design all on my own – the procedures and terms are really just tools that anyone can use to help streamline the process and bring others into the conversation.
I quickly learned that most design processes are very similar and inherently cyclical. My course used the Stanford Model of Design Thinking (Plattner, 2018) that includes five stages: empathize, define, ideate, prototype, and test. We spent a couple weeks on each stage in order to explore in depth and then apply our learning to a semester-long design project of our choice. Along the way, I realized that my past design projects could have been a lot more productive had I known about all the tips and tricks I was learning.
We began by exploring the importance of empathizing with our users. This is something I always strived to do as an educator – remember what it was like to be a kid, walk around in my students shoes, etc. – but I learned how necessary it is to be very intentional about this phase before launching into the rest of the design process. I read a case study where a group of researchers gathered empathic research by simply listening to stories told by various users and getting outside their own mind. This was motivated by their statement that “Unsuccessful design often comes from the assumption that users like what we like” (Fritsch et al., 2007). It is not enough to simply brainstorm what it would be like in our users’ shoes – we have to talk with them, interview them, see their side of the story before we can proceed. And the great thing about using this method in an educational setting is that all of this research requires building relationships, the cornerstone to great teaching and creating lessons that truly matter to students.
Before learning the proper design process, I would typically then launch straight into the brainstorming or ideation phase. However, I learned that I had been missing a step in between, one that is arguably the most crucial: accurately defining the problem. There are many ways to go about doing this, but it does require thinking outside the box and analyzing the heart of the problem you are trying to solve. Matt Stauffer (2019), the Technical Director for the technology consulting firm Tighten, describes problem definitions in terms of jobs to be done: “What job is this supposed to do for you?” The answer, he says, “should be able to be given in an elevator pitch” that strikes at the core functionality of your project. “If it takes too long to answer, then it doesn’t have a simple enough task” and is too muddled to find a proper solution. In other words, the definition must be short, sweet, and to the point, otherwise the rest of the design will be thrown off task, possibly in multiple different directions. I had a big “aha!” moment when I learned about this phase of design work. There were definitely times in my past design projects when I wandered down rabbit holes or discovered that my end result never really solved the issue – all because I may not have had a concrete, succinct problem definition with which I was working.
After coming up with a good working definition of my original problem, it was time to launch into the ideation and prototype phases. I was most familiar with these phases and how a cycle of brainstorming, prototyping, analyzing, brainstorming again, can begin. But the concept of rapid prototyping was fairly new to me. This was a term I had definitely heard my husband throw around on his conference calls but never really stopped to think what it might entail. I was not so surprised that it literally means a prototype that was built rather quickly, but I was surprised to learn that it is more of a mock-up, typically thrown together arts-and-crafts style, in order to give a concept of how an idea would function. I had used representations of my ideas before and played around with their functionality, but I had never called my representations “rapid prototypes” or deliberately used them as part of a process to stimulate another round of ideation and prototyping. Having these new terms, “prototype” and “rapid prototype,” helped me document each iteration and track the gradual progress being made in my design which, incidentally, helped me clearly see the path leading directly between my root problem and it’s ultimate solution.
Then once I came up with a working prototype, it was time to test its functionality with real users. When designing a classroom activity in the past, I would simply add my prototype to my lesson plans, hope for the best, then take mental notes of what worked and what didn’t. However, my new learning emphasized that a formal test includes more documentation than just ‘mental notes’ and should be conducted in several different methods besides mere observation. When practicing this phase with my semester-long project, I decided to use a test-group of adults from a wide array of backgrounds (see report on the testing results) and found several surprising values of using this method versus observations for gathering data. For starters, I was able to bounce ideas off my adult test-subjects in a way I would not be able to in a regular classroom setting. Time was set aside at the end of our testing session to discuss any modifications that needed to be made and why, and all suggestions were made in a low-stakes environment. It would be difficult to get this type of targeted feedback if the first use was in the classroom with all my students, the way I had been conducting my ‘tests’ in the past (if you can call it that). Ultimately, experiencing this phase of the design process showed me how necessary it is to be intentional about each step, otherwise my efforts might not provide the information I need to actually reiterate and make my design better.
While experiencing the power of properly conducted testing, I saw the following cartoon in my course materials and found it absolutely hilarious:
I was proud of myself for actually getting the joke, so I quickly showed it to my husband who also got a good laugh. He said that testing is unfortunately the step that is skipped the most, and it is typically due to hubris. Designers can become very self-assured, if they are not too careful, and can firmly believe their prototype is the final solution to the original problem. If a prototype goes into full production, kinks could be found that cost the company a lot of money to fix. In a classroom setting, this might translate to lost time with the students and/or creating misconceptions that are difficult to break later on down the road. I now understand why one of my husband’s mantras is “Always run a small batch first.”
Overall, learning the design process has taught me that each step is vital for reaching a proper solution to a problem and that each step must be taken with intentionality. At some point or another, we all design on varying levels of scale – smaller projects might not need as much documentation whereas large projects will need reports and data to keep the process organized and aligned. But regardless of the project at hand, a cycle of empathizing with the users, defining the problem, brainstorming, prototyping, and testing can help create the most effective solution.
References
Testing Cartoon (2020). Create a Testing Protocol and Report [Course Page]. Retrieved from Michigan State University CEP 817 D2L site.
Fritsch, J., Judice, A., Soini, K., Tretten, P. (2007). STORYTELLING AND REPETITIVE NARRATIVES FOR DESIGN EMPATHY: CASE SUOMENLINNA. Design Inquiries. https://archive.nordes.org/index.php/n13/article/view/150/133
Plattner, H. (2018). Design Thinking Bootleg. d.school, Hasso Plattner Institute of Design at Stanford.https://catharinesiemens.files.wordpress.com/2020/03/bcbc2-dschool_bootleg_deck_2018_final_sm28229.pdf
Stauffer, M. (2019, February 8). Jobs to Be Done: Design Thinking with Matt Stauffer . Retrieved from https://www.youtube.com/watch?v=8w5NCGGVswA&feature=emb_logo
catharine-siemens.com 