 Good morning, good afternoon, or good evening, wherever you're joining us from today. Welcome to Engineering for Change, or E4C for short. Today, we're pleased to bring you this month's E4C focusing on human-centered design for engineers. My name is Yana Aranda, and I'm the president of Engineering for Change, and I'll be serving as today's moderator. The webinar you're participating in today will be archived on the E4C webinars page, as well as our YouTube channel. You are welcome to take a look at both of those. The URLs are listed on the slide after this event for the recordings. E4C members will receive information about upcoming webinars, as well as additional invitations directly in their inbox, so stay tuned for that. If you have any questions, comments, and recommendations for future topics and speakers, please contact the E4C webinars team. The URL is listed on the slide, as well. And if you're following us on Twitter today, I'd like to invite you to join our conversation with a dedicated hashtag, hashtag E4C webinars. Before we move on to our presenters, I'd like to tell you a bit about Engineering for Change and who we are. E4C is a knowledge organization, digital platform, and global community of more than one million engineers, designers, development practitioners, and social scientists who are leveraging technology to solve quality of life challenges faced by communities around the globe. Some of those may include access to clean water and sanitation, sustainable energy, improved agriculture, and more. We invite you to become an E4C member. Membership is free and provides access to news and thought leaders, insights on hundreds of essential technologies in our Solutions Library, professional development resources, and current opportunities such as jobs, funding calls, fellowships, and more. E4C members enjoy a unique user experience as they engage with our site. Essentially, the more you interact with our site, the better we'll be able to serve you resources online to your needs. We invite you to visit and become a member at engineeringforchange.org. Now, a few very important housekeeping items before we get started. We'd like to take a moment to practice the WebEx platform together and get to know a little bit about where you are. We invite you to use the chat window, which is located to the bottom right of your screen to type in your location. If the chat is not open on your screen, try clicking the chat icon at the bottom in the middle of the slides on the screen. So let's see. We have a variety of folks coming in today from all over the world. I see Italy, a variety of states in the US, Tunisia, my home country of Canada, Turkey, Peru, Ecuador, India, Mexico, Chile, Panama, Cambodia, and Columbia. Welcome, everybody. This is so exciting to have such a diverse audience today. We're thrilled to have you with us. All right. Just on the note of housekeeping items, please be sure to use the chat window to share any remarks during the webinar. If you have any technical questions, you can also send a private chat to the Engineering for Change admin. If you're listening to the audio broadcast and you encounter any problems, try hitting stop and then start. You may also want to try opening up WebEx in a different browser and, of course, feel free to reach out to our admin. During the webinar, please use the Q&A window, which is located below the chat to type in your questions to the presenter. Again, if you don't see this, click on the Q&A icon at the bottom of the screen in the middle of the slides. And we will leave at least 10 minutes at the end of our presentation today to do some Q&A with our presenters. Now, I'd like to take a moment to provide a little bit of context around engineering for global development. Engineering for global development is an interdisciplinary practice that aims to improve quality of life worldwide through the design and delivery of technology-based solutions combined with building of local capacity. EGD practitioners integrate their technical training with an understanding of economics and business, social science and politics to achieve social and environmental impact. And I want to say that it's positive social and environmental impact that we are trying to achieve. We at Engineering for Change are here to promote the practice and the science and the organizations behind this sector of engineering for global development. And people can enter this space or practice EGD through a variety of pathways, including as volunteers within organizations such as Engineers Without Borders or Water for People, for example, in academic settings as part of institutions such as MIT in their development lab or at Loughborough University as some examples as social entrepreneurs in organizations such as DRAB or Kickstart or Vestergaard-Francine. Also, you can be an EGD practitioner in industry. Many companies are now really engaging in this space, including organizations such as Philips, Tata and GE Healthcare. And there are engineers also working in this space within multilateral agencies, in particular in organizations such as USAID and the World Bank. So there are a lot of pathways to practice this discipline. Now, one of the important ways that we envision engineering for global development and how solutions are come to realize is through a process that we developed in collaboration with our expert community and we've termed solutions development process, which is what you see on the slides in front of you. Now, this process, while it appears to be linear, is, in fact, very much nonlinear. In fact, the lines between the phasers often blur. The phases as we've articulated them here include planning, learning, design, designing, realizing and sustaining solutions with these iterative cycles around, in particular, the learned design and realized phases. Today, we will be focusing in particular on the design phase, which is the intention of the design phases to explore inside driven solutions with stakeholders through iterative rounds of concepting, prototyping and testing. What we see is that design techniques are often a barrier to success, particularly in this phase. And field-tested methods as such as human-centered design, which you'll hear about today, really can help us enable sustainable results. So we are so incredibly thrilled to welcome our speakers today to give us insights around the tools and methodologies that can be applied in order to achieve sustainable solutions. Before we hop over to our presenters, I want to just highlight that much of the solution development process and the information we're sharing today is available in our Introduction to Engineering for Global Development course on E4C for free. And you can access this course at the URL listed on the slide. But we will be following up after this webinar with additional information for everyone who has registered to really give you that detail. So with that, I am so thrilled to welcome and introduce our speakers today. They are close friends and colleagues, and we've been working with them for a number of years in this space. In fact, the solution development process that I shared with you was co-designed with them, applying many of the techniques they're going to share with you today. First, we're going to hear from Heather Fleming. She is currently the member of the Board of Advisors for Catapult Design. She is also the co-founder and executive director of ChangeLabs, an organization supporting entrepreneurship and innovation on the Navajo Nation in the United States. Heather engages partners in and around the Navajo Nation to incubate, finance, and train new and prospective Native American entrepreneurs in an effort to diversify local economies and promote innovation. The inspiration for Heather's work to seed Native American social entrepreneurship was inspired by her upbringing in New Mexico Apologies and her work with Catapult Design, a company she co-founded in San Francisco and led for 10 years. Prior to that, she was a design and innovation consultant in Silicon Valley, designing products and services for a diverse range of corporate clients and an adjunct lecturer at Stanford University and the California Academy of the Arts. Heather was named a young global leader by the World Economic Forum and a PopTech social innovation fellow for her work with Engineers Without Borders and Catapult Design. She will be followed by Adam Horvinsky, who is a product designer with a passion at the intersection of social innovation and product development. Adam draws on his early experiences assisting disabled adults and homeless youth. His aim is in leveraging design to address the unmet needs of marginalized communities. His experience spans a number of industries and disciplines from working as a design engineer in off-grid energy to outdoor recreation to more traditional design roles in consumer electronics, packaging, and systems design. He often finds himself obsessing over proof of concept prototypes, much of that done with us in our programs and projects and searching for ways to improve inefficient processes. So with that, I'm going to turn it over to Heather. Let me just give you control to walk us through and thank you in advance for joining us today. Thank you, Yana. And good morning, everybody. So for the next few minutes, Adam and I are going to step through the HCD approach and methodology. And we're going to assume that most of you in the audience come from a traditional engineering background and therefore are probably pretty good problem solvers. Adam and I, we're both part engineer and part designer by training and the design mindset and the tools that we're going to talk about today are a pretty great complement to your technical and analytical abilities too. So let's get started. We're going to start with this mindset, the design mindset. So anybody who creates new things, whether they be products or systems or services, they have their own personal biases that affect the way she or he views the problem and the solution. And recognizing that bias is key to taking a design-driven approach to your work. So we want to hear from you guys. When you look at this picture, what would you say that this little girl needs? I'm going to pause and see some of the responses that roll in. Okay, so the answers I'm seeing are amongst the most common that we see whenever we ask this question, the girl needs a step stool or she needs a ladder. And this is common because most of us are hardwired to think about solutions instead of needs. But if you think of needs as a verb and you think of solutions as nouns, you can see that a stool and a ladder, they're both solutions. They're not needs. And by jumping directly to a solution, you limit your ability to develop different ways to solve the little girl's problem. And you risk creating a solution that may or may not work for her. Need finding, in my mind, is really the heart and soul of the design process. It's the way you look at and frame a problem. So this little girl needs a way to reach the top shelf. She needs a way to feel taller. She needs to feel independent. By forcing yourself to define needs and fighting that urge to jump directly to solutions, you can open up your mind to multiple ways to look at this problem. So if I asked you to design a way for this little girl to feel taller or to reach the top shelf, you have the information that you need to come up with multiple ways to solve that problem. So need finding is a critical mindset shift because solutions come and go. One of my favorite Bay Area firms, Jump Associates, uses this great example of the need to store computer data. So in the 70s, that solution looked like magnetic tape. Then it evolved to floppy disks, then to a hard disk, then to a hard drive. And now data is primarily stored in the cloud. Solutions change, but needs stay the same. So we always start with need. And that is the foundation of human-centered design. I'm gonna pass it over to Adam to take us to the next step. All right, thanks, Heather. Okay, so more often than not, when we try to, you know, when we try to problem solve, we identify a problem and then we choose the first viable solution that addresses that problem. And this tends to be more of a business-minded approach to problem solving. A more tech-focused approach to problem solving, you might develop a feasible solution and then search for a problem to apply that solution to. In human-centered design, we start with need, as Heather mentioned, and then we work towards developing a desirable solution. If we were to break these steps down and how we get there, it might look something like this. Where oftentimes it actually feels something more like this. It's messy, and there's really no clear path. And as we saw with the previous example, we go reaching from the top shelf. Needs are not always explicit, right? And so if we allow our assumptions or biases to get in the way, we will likely design a poor solution or much worse, we might design the solution to a wrong problem. And so we really need to feel comfortable in this space. And as designers, we need to embrace ambiguity and really trust in the process. HCD helps us make sense of the abstract. And more importantly, it really keeps need to the, it really keeps need central to the design process. So what is HCD? Human-centered design is a processor methodology for problem solving that incorporates understanding of human need, prototyping, and user testing in order to develop solutions to a problem. At a very high level, we can break HCD down into five modes of thinking. Each mode has distinct goals with specific outputs. In our empathy mode, we're really looking to cultivate empathy for the people we're designing for. We really want to deeply understand their needs and their wants. In the design mode of thinking, here we're looking to unpack and synthesize our findings to uncover key insights. We also want to work towards framing the problem and defining our problem statement. In the idea mode of thinking, we're looking to generate as many ideas as possible, both in terms of quantity and diversity of ideas. In the prototyping mode, we're looking to really bring these concepts to life and build them in the physical space. And then that allows us to demonstrate, share ideas with others. And then finally, in the testing mode, we're looking to put our prototypes in the hands of our users, and that way we can gain their feedback and really kind of refine our point of view. So although this, you know, although you can step through the stages and it appears to be linear, it's really a cyclical process. We're constantly learning from our user, we're iterating and testing, and we're reframing the problem that we're trying to solve. And so we'll take a deeper dive in each of these modes in a little bit. Back to you, Anna. Okay, we're going to show you guys an example of the early phases of the design process in action using an example from Catapult Designs portfolio. So this client was on a mission to inspire new behaviors, specifically to increase the use of soap when washing your hands. Now let me just screen share real quick and start this video. Okay, I see you guys can see my video. Let me just press play. So the organization we were working with was in Western Kenya, and we spent several days in observation mode just sort of documenting what we saw, and that included how people were using soap in their day-to-day lives, and when they weren't using soap, what household items were used for cleaning, for bathing, all that stuff. We also visited local stores just to see what items were readily available and what required significant travel to obtain, and also just observing daily life and ritual in this community. Our client had previously hired an engineer to design and build them a tippy tap, which is a ubiquitous appropriate technology used around the world for hand washing in places where there isn't running water or modern plumbing. So they took this design and they manufactured about 1,000 units for a two-year pilot test, but after they installed the first 100 units, our client observed that most of them were failing. So they hired Catapult to help them understand why these units were failing and to conceive of a new way to inspire the use of soap and washing hands. We spent a lot of time just watching these teams install the tippy taps, and we saw several problems. I'm sure you guys are starting to see them too. So there's a severe lack of stability with some of these units. The bird edges of the steel cutting the rope that activates the tipping motion just cuts through that rope. You're about to see that in a second. And there's also a lack of proper fasteners throughout the design. In one scene, you'll see someone using steel wire to fasten the brace that holds the cherry can. And in another scene, you'll see someone sawing bolts off because they weren't the right size. The assembly is also not very intuitive, even to this team that's already installed 100 units. When I was filming this video, they installed the pedals backwards, for example. And then also pouring soap and water into the small neck of those cherry cans made messes and pools of muddy water that splashed on users when they washed their hands. And when we watched adults and kids use the tippy tap, even more issues came up. The cherry cans aren't labeled, for example. So you don't know which has soap and which has water. Kids don't have enough strength to push down on those pedals. And the bird edges were at eye and face level for them. And I was picked out the whole time that would have been a place. So as a result, most of the tippy taps just weren't being used. Some were disassembled and being sold for parts. We saw a lot of UV degradation in plastics in a couple of weeks that just made the entire system useless. So we had to go back to the drawing board. And since I don't speak Swahili, we used translators and card sorting exercises to initiate conversations with families. So we drew some of the household items on cards. And then we would ask mom to arrange the cards from most useful to least useful, most expensive to least expensive, most valuable to least valuable. And we looked for discrepancies in their responses as a means to understand priority. We also spent a lot of time with other stakeholders. So the team that implements this program, this team that installs the tippy taps, who by the way had a ton of ideas for improving the design that they had never had an opportunity before then to share those ideas. But also the local manufacturers in nearby urban areas who will be building potential solutions, they're the last group that we spent a significant amount of time with getting their feedback on the design and also their ideas for making improvements. Okay, stop sharing. And I'm gonna hand it back to you, Adam. All right, thanks, Heather. So as we can see, Catapult uses the human-centered design process to really understand the context that we're designing for, to identify need and generate solutions, even with the people that we're designing for, and then test them in the field. So let's look at each mode of thinking and see how we can maybe apply some of those kind of processes or strategies in your own projects. So it may seem obvious, but if we don't understand what's important to the people that we're designing for, it's really difficult or even impossible for us to design instruments either desirable or valuable. And I love this diagram because what people say and do is really just the tip of the iceberg. And what we're, as designers, really interested in is we're interested in why people say and do what they do and, more importantly, what they think and feel. We wanna know about their motivations, what they aspire to, what they fear, how they think about the world. Understanding these things will actually help us uncover key insights that will help us define the problem at hand. So when the first kind of mode of thinking in human-centered design, we're really trying to understand inside and out what people need, want, what they do, what they don't like to do, who they interact with, all of that will help us really understand what we're trying to achieve. And we can do this by observing users in the context of their lives. We can immerse ourselves in their experiences or try to put ourselves in their shoes. We can engage and interview with users themselves but also we can interview people around them. So like we saw in the video, people that are manufacturing or maintaining the products, all of that will help us build out the picture of, what is the problem that we're actually trying to solve? And it's really important to human-centered design that we engage with people directly. We don't wanna do this from afar. And that's really important because ultimately what we're looking to do is adopt the user's point of view. And we wanna do this because we either wanna bring them along in the design process literally or figuratively. We wanna understand them so well that we could design a product as though they were designing it themselves. So in this first mode of thinking, we have three kind of distinct goals that we're trying to achieve. The first one is need-finding. When we talk about need-finding, we're not just trying to think about, what is it that they tell us they need? We're trying to look at their latent needs. And latent needs are needs that a person doesn't really even realize that they have. So this is kind of where we get to come in and play detective. We get to see what they do and how they act. And as I mentioned earlier, the discrepancies of what they say and do, there's actually key insights in there. And that is kind of the meat of need-finding. In the lower right-hand corner, you can see one of the catapulters is kind of doing some photo documenting. So this is one photo journaling is one way that we can actually kind of capture all the assets of the environment. And when we go back and kind of synthesize and look at this, we can see what they use in their daily life. What do they have available to them? What tools do they rely on? All of that will help us kind of figure out the direction that we need to go. The second goal that we really want to achieve is observe key behaviors or patterns. And we can do this by observing day-to-day activities and routines. This is really important because people tend to recall what they intend to do and not what they actually do. And so as a designer, we kind of have this important role of playing a third-party objective observer, right? And so we can kind of compare what they say they do with what they actually do. So observation is key to the empathy mode. As you can see in these photos, we're observing women hand-washing and washing dishes and understanding what they have with them and what's available to them, understanding their process. And when we're in this kind of fly-on-the-wall observation, we're not actually intervening with questions. We're not trying to direct, we're not asking them to do anything. We're just observing the way they would naturally do it. And finally, in the empathy mode, our last goal is to really engage with stakeholders. So you want to understand and map out all the different players that are involved in the user's lives and the lives of the product. So that could be who maintains it, who sells a product, who purchases it, who builds it, who uses it, who's a secondary user. All of these things will kind of provide key insights on what the actual latent needs are that we're trying to solve. So now that we've been in the field and we understand generally what's happening or at least we think we do, we have observations, now we move into the defined mode of thinking. In the defined mode, we're really looking to kind of unpack and synthesize these insights. And our real goal is to create frameworks for understanding our user and context. And we do that by visualizing our insights and organizing them into different clusters. In human standard design, we're constantly looking to visualize kind of the abstract. We want to kind of make things more tangible. So two ways that we can do this. One is by creating two by two matrices and there are plenty of different methods for kind of organizing data and doing synthesis. But these are just some of the ones that we use. The two by two matrix is a great way to kind of explore the relationship between people or attributes or things. And through that discussion of in your team discussing who is, how one person perceived it or the other, you can actually, that's the meat. You kind of get to the key insights through that discussion. Another thing that we like to do is called mind mapping. And mind mapping is really, in the field we capture all these observations and now we need to figure out how they're linked and connected to one another. And so mind mapping kind of shows us how we might, how concepts relate to one another. These are just ways that we can kind of get the data that we've collected onto the wall or onto the floor and kind of open it up for discussion. The next goal that we try to hit in the defined mode of thinking is we really want to set criteria for evaluating ideas. And what we mean by this is when we move into the ideation phase, we need to have a set of constraints that we've created that will allow us to kind of evaluate whether one idea is better than the other. And so going back to that kind of messy diagram, we're not given that. We have to create that information ourselves. And so what we want to keep in mind is we're trying to create these criteria and constraints from the user's perspective. What would they do? What is important to them? What do they need? And that's kind of how we're going to frame out these constraints. A couple of tools that we'll use in order to do that, visually, journey mapping. So on the upper right-hand corner, you'll see this is one way that we can kind of create a journey map of a process or document the steps that the user takes. And this is really helpful for kind of understanding where there might be pain points or where there might be redundancies in the process. And that kind of reveals themes or patterns or kind of gaps or design opportunities. And it also allows us to step back and look at an idea and say, does this fit within their natural process? So it's a one way to be kind of create criteria for developing ideas. Another way that we can do this is through journey mapping. And journey mapping is, oh, I'm sorry, personas. Personas is kind of where we bundle all the insights that we have. So you might interview 100 people. And each of those people have different, we observe different things or they have different needs or wants or, but what we want to do is we want to kind of distill that into one persona. One person that we can reflect back to and say, would this concept reflect with this person? Would they enjoy what we've developed? And so we use persona to kind of create a fictional character that we're bringing all of our insights together and creating this person that we then have to check our ideas against. And so this is another way that we can kind of create the criteria for evaluating ideas when we get into the ideation phase. And then finally, the last kind of goal out of the define mode is to define a discrete problem statement. And by defining a discrete problem statement, it's really important that we're creating something that is broad enough to allow the creative process to flow but also focused enough that we're not trying to design a product for everyone. So we really want to make sure that we're broad but also focused. And in our problem statement, we want to answer kind of the who and the why we're designing so that when we get into the ideation phase, we can really focus on the what and the how. So once we have our problem statement defined and our constraints and we have kind of these frameworks built, we move into kind of ideating, right? And in the ideating mode, we're really looking to explore concepts broadly. We want to throw everything out on the table. I like to use the term mile to wild to kind of explain, we want the most obvious concepts and then we want kind of the most far-fetched concepts. Typically when people think about ideating or concept development, they think about, you know, sketching, right? And sketching is very important because it allows you to get ideas out quickly. But this, in this mode of thinking, it's very project-specific and we really have to focus on who we're designing for or also who we're designing with. And so at times we might be actually designing with our clients or the user themselves. And so when we're doing that, it may actually be more useful instead of relying on sketching to ideate through, you know, pipe cleaners or possibly even, you know, tin foil mock-ups, right? And what these do are, they allow us to get our ideas out quickly. It's very easy for people to kind of generate ideas and walk through it. And this is really just, it's a communication tool. The most difficult part about the ideation phase is that you really have to try to maintain a non-judgmental mindset. The beauty of this phase is that you are trying to think broadly and you're really looking for kind of cross-pollination of ideas. So that idea that, you know, maybe shouldn't have, you know, it would never work. There might be some aspect of that that resonates with another idea that might kind of co-mingle and create something new. So that's really what we're looking for. We're not trying to set up any roadblocks in this phase. And this can really depend on how this, you know, how your ideation phase is really facilitated, right? So one thing we like to do is bring, like bookend the brainstorm. And so when we sit down, we'll try to throw out, you know, two or three really obvious solutions and then two or three really far-fetched solutions. And this kind of helps us bookend all the possibilities in between. So again, in this, when you're in the ideation phase, you don't want to cut anything out right away. That's not, we'll get to that later on, we'll refine later on. You're really just trying to get as many ideas out as possible. You can do that through sketching or through any other medium that makes sense for your project. So once we have our ideas, we move on to the prototyping phase. And this is my favorite mode of thinking. But, you know, in this mode, we're really looking to kind of bring these concepts into the physical space, right? We want to make them a little bit more real. And so our four goals here are to, one, we don't want to spend too much time, right? Time is valuable and it costs money. And so we want to try to, you know, have our concepts and get it out with the minimum viable product, right? The least amount of effort that we can to convey what we're trying to convey. The second goal that we're trying to do in this phase is really discover challenges early on. And by that, I mean, we want to evaluate our concepts ourselves. So it's really easy to, you know, sketch out a concept and then, you know, look at it, think it's gonna work, but as soon as you try to make it, even out of a paper maca, you realize that it's not gonna work or it's not scaled right or things become just more apparent. So prototyping is a really good way for us to challenge our own ideas internally. The big thing about prototyping is that we always want to make sure that we're testing assumptions or we're testing concepts, right? We don't just want to make things to make things. That's not productive. So you want to go in with a plan. And typically, you know, engineers think of prototypes as testing functionality. But in the human-centered design, as designers, we think of prototypes as communication tools. So it could just be, you know, it's a rough sketch. We're just thinking through making. And so any, you know, a prototype could be anything from a looks-like model to a works-like model. Maybe you're just testing one aspect. Maybe you're testing a handle or you're testing height variation or you're testing, you know, bucket-sized. All of these things are completely viable prototypes you could create as long as you have kind of your testing concept in mind. And then finally, you want to think with the user in mind. You want to build with the user in mind. And by this we mean it's really easy to create a concept or develop a concept that it has cool features or it kind of deviates from what we've defined in the earlier phases, right? We really want to try to keep the user needs central in this process. Also prototypes, you know, prototype fidelity varies by stage. And one of the most important things to remember is that if we develop a set of prototypes and we spend a little bit more time on the ones that we like, right? So we refine those, make them look a little bit prettier. We're essentially baking biases into our prototypes. And so we want to make sure that we're not doing that and that we're kind of presenting a set of prototypes that all look and feel the same, right? And then that way that we can get the best feedback from our users. So on the kind of the upper right image, you'll see, you know, this is a set of hand-washing stations that are really testing different product architectures. They're all different, but they all have the general sense of they all feel the same, right? They all, it looks like you spent the same amount of time on each prototype. In the lower image, you'll see that, you know, this is a refined concept. So now we've taken one of those and we're actually looking at trying to refine a little bit more. And then finally, after we test, we look at, you know, now we're looking at, this is how it could actually be manufactured or this would be the actual, the parts themselves. And so we're getting higher and higher fidelity. So once we have our prototypes in hand, we wanna get them into the hands of our users. And in this mode, the testing mode, we really have three kind of objectives. One, we wanna make sure the concepts address user needs. And this is really the reason why we're trying to test directly with users. To make sure that we're addressing our needs, it's really important that when you go into the field, you have a testing strategy, right? So we don't just wanna go and plop a prototype down in front of someone. We wanna know what we're trying to learn from that prototype. And then we wanna build a testing strategy that will allow us to gain that information. And so there are a couple of different exercises that we can use, some of which Heather mentioned in the video that will kind of help us hone in on specifically what we're trying to test and are we meeting that user need? So the first one is willingness to pay. So if we're trying to look at how much, what is the perceived value of something? The perceived value of a concept, we might do a willingness to pay study. We're actually having them by certain features or concepts and limiting what resources they have available to kind of weed out what's more important than what's less important. If we're looking at, you wanna see what's actually needed versus what's just wanted, sometimes those can be confused. We might do a trade-off exercise. And that's really important for kind of digging down and figuring out what is required and what is kind of an add-on that we could have. And then A and B testing. So if we're looking at, we have two or three prototypes that are very similar and they all do the same thing, but we wanna test one feature or one kind of assembly over another, we might do A and B testing. And that gives us kind of concrete evidence that this is preferred over that, and then we can kind of probe that deeper and ask why. Our second goal is to really understand, at a high level, are we addressing, are we, is our concept direction accurate? Are we even addressing the right problem? And this is something that we always wanna have kind of a good gut check on. The third kind of goal of the testing mode is we wanna evolve concept, we wanna evolve our concept based on the user feedback. And this is really important because we wanna make sure that we're set up to receive and act on user feedback. This isn't always intuitive. HCD really relies on qualitative research and it requires a sense of agility. We need to be able to maneuver in the field and respond to people in real time. And so it's really important that we bring material to co-design with people or evolve concepts in the field and kind of probe and test further when we see something come up that we didn't expect. And this is also important for understanding how we're going to evolve concepts and iterate once we leave the field. So keeping all of these things in mind is really important for making sure that we're learning what we need to learn coming out of the testing mode. And one thing that's also important to kind of mention is that, like I said before, it's not, this isn't a linear process. It is cyclical, but it's also, you might jump from the test mode and then say, you know what, we actually need more research on this component. We didn't understand that as well as we thought we did. So you move back into the empathy mode of thinking or you might say, wait a minute, you know, this concept didn't test out that well. We actually need to reframe the problem. We kind of missed the mark. So then you move back into the defined mode of thinking or we need to generate more ideas around this. Like you're back in the ideate or you just need to revise the prototype you have. And so you want to bring it to a higher fidelity and further test it when you're in the prototyping. So really understanding what you're trying to learn is really important for kind of being able to leverage the HCD methodology. And we always want to just make sure that we're keeping users at the center and accounting for their needs and then making sure that we're taking an iterative approach. All right, and then I'll hand it back to you Heather. All right, we want to have some time for questions, but before we finish up, the last thing we wanted to talk about was human-centered design and social impact. I've seen organizations make the assumption that by employing a design-driven approach that social impact is somehow guaranteed. HCD is not synonymous with social impact and employing a design-driven approach does not guarantee that's gonna happen, that social impact that you're going for. And in fact, measuring the social impact of design is tricky business. There's a lot of smarty pants working on it now. So hopefully someday soon, somebody will figure out like a concrete methodology for us all to use, but it doesn't exist yet. So social impact is the outcome of a deliberate set of outputs and activities that drive positive change to a social challenge. But in the product world, social impact is too often associated with just sales or distribution. So we assume that if somebody buys our solar energy system or that if we install a water pump in a community, that social impact is inherent. It's not. And there's too many examples of failed solutions and technologies littering the landscapes in developing nations that prove that. One of the most famous examples is the Plague Pump. It was designed in the late 80s to marry go round attached to a water pump. And the idea was to leverage children at play to ease the burden of pumping water. And the development world loved this innovation and the company raised $60 million to install Plague Pumps throughout South Africa. But it turns out that children playing wasn't an adequate input to drive the pump. And so adults ended up having to turn the merry-go-round by hand, which was actually harder than just using a traditional hand pump lever. So this solution committed the ultimate sin of actually making life harder for the people that it intended to help or benefit. So when we think about successful solutions, we don't think about unit sold or number installed or distributed. A good product meets the following criteria. It's something a user actually wants or needs. It's something that they can access. Something that they value enough to buy and also something that they'll use correctly after purchase. So that's a pretty tall order, but we hope that today's introduction to HDD can help you start thinking about new ways to create needed, accessible, and intuitive solutions capable of social impact. And that's our presentation. I'm gonna hand it back over to Yana right now. Thank you so much, Heather. And thank you so much, Adam. This has been so insightful. I'm particularly, for me what's compelling is to see some of these examples and to reinforce the point of even differentiating of the objective of prototyping where a lot of us engineers, myself included, would traditionally think of it as purely for functionality testing as opposed to making it a communication tool and leveraging for the purpose of really addressing whether or not this meets the needs of end users. So we are so excited to address some of the questions, burning questions from the audience, which have already been coming in. And let's go ahead and see what is everybody saying. A couple of questions that we already received, Heather and Adam. So first is how can we avoid anthropocentrism or human self-centeredness in human-centered design kind of implied in the name? In other words, how can we effectively effectively take into account non-human needs? Yeah, I think that's a great question. And something that I've actually been thinking about myself, I think in terms of sustainability, which is what I think that's to a certain degree addressing, I think when you design a product that doesn't meet human need and it's still pushed out there, it ends up not getting used and it becomes waste very quickly. So I think the water pump is a good example where all of this effort and design and engineering and production, resources went into designing the solution that ultimately did not get used. And so I think as we, if we use the human-centered design process to really develop products that address need and are sustainable in the sense that they'll be used for a long period of time, we start to kind of get at that a little bit. More so, I actually think that I think that we probably need to adapt this framework to take into account how do we respond to environmental challenges, right? Why are we prioritizing just human need? So I don't think that this is the only way forward. I think that we can actually kind of adapt the framework that we have. This is really just a way to think through the design process and make sure that we're addressing, and I would say need. So maybe that could be environmental need. It's a really good question. I think Catapult does a good job at advising. When we work with companies, we advise them on materials that will be more sustainable or how the end of life should kind of consider that early on or how to work with local manufacturers. So I think we do it kind of indirectly, but to answer your question, I think that it's possible that this framework does need to be adapted to take that into account more. Heather, I don't know if you have any thoughts on that. It's a really good question. I don't. Sorry, my Webex just disappears. Yeah, he kind of says that, okay. Well, we can hear you, which is the good news. So thank you for weighing in on that, Adam. That's really helpful. Let's tackle another question. Design thinking is great at designing the thing right, but not necessarily at designing the right thing. Can you address how Catapult addresses that? So I think you've already started on that, Adam, when talking about the need. Is there anything you want to layer on to really drill down to how you design the right thing? Yeah, so I think, you know, it's, HCD is a process, right? It's a methodology. So it really, it's how it gets applied that matters. But I think at the core of HCD, it is about trying to design the right thing. It's not, it's actually less about designing the thing right, at least in my mind, that's more of kind of the engineering and, you know, you get a little bit more to that. This is really about identifying the right problem, right? And the need that you're trying to solve. So I think how Catapult addresses that, we try to apply the HCD process to really make sure that we're looking at what is the root cause, right? We don't come in and, you know, if someone says we want a new hand washing station, we don't just come in and start designing a new hand washing station. We make sure that that's what's actually needed, right? We're evaluating what we're being asked to do to make sure that we're kind of designing the right thing. I don't know if that answers the question in the example, but yeah. Heather, do you want to add to that? The only thing that I would add is there, it's kind of the challenge of the way the development world works. So Catapult Design is a consulting organization. So it thrives on the consulting model. And Adam mentioned this presentation that there's quite a number of stakeholders that are involved in the creation of new products and new technologies. And all of those stakeholders have their own agendas, their own biases. So as much as you want to try to design the right thing, not everybody has your shared agenda. So funders, for example, I think are kind of the biggest, are one of the biggest problems. They're very prescriptive in their approach and they may only want to fund something if it's this or if it's run by solar. And the problem with that is because there's limited funding to create a lot of these solutions that people have to compromise and say, okay, well, we've got to make it powered by solar energy because that's the only way the funder would be interested in this program. Same with implementing organizations in order to stay alive, they have to demonstrate some sort of financial sustainability. So they're also driven by profit and sales. And all of those different biases make their way into the design. And that unfortunately has an impact on what is created and is that right or is that wrong? Don't know, but it definitely muddies the water. That's a very good point. I think one of the critical items that you shared during your presentation today or two really key things is the difference between even how you perceive prototyping. So Adam, you noted during your talk, the objective of prototyping for communications purposes versus functionality, which is often what engineers tend to veer towards and how important that is also further unpacking whether you are actually meeting the need of the user. And the video that Heather showed really demonstrated how observing users assemble a particular technology or work with it, really doing so objectively. It allows you to come back to understanding and packing whether you're meeting needs and not just putting forward something that is actually not going to address the core challenges. So a few more questions have come in and I think they're really exciting. Regarding another listener, what factors would you consider are important to the continuity of innovations in the developing context? So I guess in frontier markets or emerging markets. I'm looking for the question. I kind of want to read it. Where is it? It's in the chat window. That question is in the chat window. It's quite above. So what factors would you consider are important for continuity of innovation? So I suppose if we unpack this further, this user is asking about really meeting the innovation pipeline, particularly for developing context or development, developing countries, frontier markets and so forth. I'm not sure I understand it actually. I'm just going to read it. I can't see any of your questions though. I'm not sure, Adam. That one is it. Yeah, I actually was. So, Yana, can you just kind of clarify the question? Are you saying how do you drive innovation in developing countries or? I think this is what the user is getting at. I can tackle a little bit of this one if you would like me just to start and to weigh in, but I'm not sure if you have any immediate thoughts. No, please go ahead. So I think what's really critical in driving innovation is actually providing examples such as the ones that Heather and Adam have shared today, talking about what's already been done and in order to really avoid some of the pitfalls that we see in developing technology-based solutions for underserved communities worldwide. Heather's example with a play pump, the example of the tippy tap, these are all quote unquote innovations, right? Or were considered innovative at the time that they were developed. However, to continue to deliver innovative solutions that are really, again, meeting the needs of end users, what we need to do is take the time to reflect what has been already deployed, what has been considered to be innovative and unpack whether that innovation was in fact meaningful, whether it was accessible, whether it was useful, all of the elements that Heather noted at the very end. So I hope that addresses the question really, really briefly. I do wanna tackle a few others. I know we are over time and I really do appreciate everyone for staying longer if you can. But while we address just a couple more and then for those of you who have to log off, we completely understand we've kept you here past time. So a few more questions that were put into our chat, or sorry, our Q&A window here is how often did you check in with a community, say for the hand-washing stations to know that the solution was effective? This is a more pragmatic question. I was just typing a response to that, but I'm good as a leader. So I think this goes back to the issue of the model of the way things are built. So Catapult is a consulting organization. We're not on the ground where the team is all over the world, but we don't have anybody in that community in Western Kenya. So that makes the partners that you work with, these clients that you choose to work with incredibly important. You want to select partners that are there in the communities or that have, some of them have community champions and things like that. So the reality is it's not like our designers are there for a two-year pilot just keeping tabs on the hand-washing stations. We rely on our partners to do a lot of that work. And the reason that we were excited to work with this partner was because they were heavily invested in keeping tabs on all of the hand-washing stations because this whole pilot, this study was part of a randomized control trial, which is a pretty rigorous evaluation technique. So they had to keep really close tabs on these hand-washing stations, but we personally did not do that now. And one more question, and then I think we're gonna have to unfortunately wrap it up and I appreciate all the questions that have come in. Feel free to follow up with us if we didn't address your questions by emailing us on this email that you see in front of you. One last question, and this is more of an ecosystem question is, have you been looking at opportunities to integrate into the human-centered design process other tools, methodologies or processes related to responsible technology, inclusive innovation, tech for good practices, critical design, value-sensitive design, et cetera? Or have you all seen maybe that happening kind of more systematically? Heather, do you have any thoughts on that or? My thoughts, my thoughts, I mean, I can't say that I'm familiar with all of those terms, but my curmudgeony, you know, old self is like, a lot of this stuff is all the same thing with different words. I mean, even human-centered design, that's just the marketing term created by a design company in the early 90s. It's really an established methodology that was published, I've seen it in books from the 70s, called Something Else. I mean, you can call all of these things whatever you want, but I tend to think that a lot of those terms that were thrown around in the question boil down to this idea of processes or ways of creating technologies that consider human need, that consider environmental impact, that consider social benefit. And I like to say that we're all thinking about the same thing and wanting the same thing. And when I look at methodologies and processes between different design disciplines, I still see the design process there in almost everything. So yeah, the curmudgeoning to me just says like, it's all pretty similar. And yeah, that's my curmudgeony answer. Not that old, Heather. Adam, do you want to add anything to this? No, I think actually what Heather said is exactly right. I mean, inclusive innovation, I mean, it's the principles behind that and value sense of the design. I think that is what we do currently. If we have an opportunity to get into the field and actually involve people, we're working on a project right now where we're involving everyone that we can. And we're essentially providing a process, but we're not doing anything without them. We're, they're involved in the entire thing. And I think my understanding of inclusive innovation, that's kind of one of the principles. But I think like Heather's saying, that's all of these things share the same thing. It's just different branding. And that's not to say that HCD process can't evolve further or it can't incorporate new tools to improve it. I think that we should always be looking at our methods and how to improve it. But I do think that kind of at the heart of all of this is really focused on need and really kind of designed around the process that we outlined here. Thank you, Adam. I think that's a perfect note to end this on. With all of that, I hope we've met your needs today. Listeners, we're thrilled that you joined us. Thanks, Heather, for trying to bring it all back together. Thank you all for joining us. If you have questions that we didn't address, please do feel free to email us. We are always keen to hear, you know, what you would like to understand further. Please don't forget to join us at HCD for inclusive members to hear more about our upcoming webinars and other events and opportunities. And with that, we wish you all a good morning, good evening, good afternoon. Have you a fantastic day and this recording will be available along with additional resources afterwards. Bye-bye, everyone. Thank you. Bye. Thank you guys. Bye.