Design Thinking Process Education For Teams - Algrim.co

Design Thinking Process Education For Teams - Algrim.co In this article I’d like to cover a brief summary of what design thinking is, get you up to speed with the process and then discuss active ways you as a leader or contributor can put process and exercises into place which flexes the muscles of your engineering, product and design teams in way that will lead to better outcomes. Design thinking, as a process, is simply about empathizing, planning, prototyping and executing against a problem set. As you could probably tell from that simplification, this covers a lot of ground when you think about your software development teams and how they are interacting with each other. This is a unified way that engineers look at their problem sets, large and small. And also how designers look at it. So our focal point today will be on the visual representation of this effect and what outcomes happen from it. Design Thinking can be captured as follows: Design Thinking is a design methodology that provides a solution-based approach to solving problems. It’s extremely useful in tackling complex problems that are ill-defined or unknown, by understanding the human needs involved, by re-framing the problem in human-centric ways, by creating many ideas in brainstorming sessions, and by adopting a hands-on approach in prototyping and testing. Understanding these five stages of Design Thinking will empower anyone to apply the Design Thinking methods in order to solve complex problems that occur around us â€" in our companies, in our countries, and even on the scale of our planet. This is sourced from the Interaction Design Foundation, who does a fantastic job of planting our feet firmly on the ground when thinking about this mental practice. Let's dig into the stages a little bit more so you have a good grasp of them. Interaction Design Foundation puts Empathize, Define, Ideate, Prototype, and Test as the main areas of focus. Empathize means to have a firm understanding of your problem set. This can be from a human level or any maybe even from a technological level. It is about relating to the problem firmly, before concluding a potential solution. I like to think of this step as research. Define means to firmly document what that emphatic path has led you to. The foundation for which we can reference the various paths or situations of which a user or human might be presented with. I like to think of this step as what you do with research. Ideate means to brainstorm practical solutions to what problem set or design issue we’re faced with. This is a key part of the design thinking process, to make sure we’re thinking about what ideas might address friction. This can be large or small, in my personal opinion. Prototype is quite literally as it sounds. The process of which we build a working, functional model of our product, engineering, and design collaborations together. This allows us to benchmark our ideate phase against something tangible. Test is also pretty self-explanatory. It shows us that we want to be sure we are setting a place for which we understand the problem exists and putting in a function that we can test the outcomes are either positive or negative. Without testing, it will be unclear that we’ve been able to successfully emphasize with our core audience. This entire process is usually quite iterative. They don’t normally work without each other. For instance, I wouldn’t recommend jumping from ideate to prototype without first going through the empathize process. It's helpful if you clearly document each one of these steps with your thinking so that you can later alter one portion of the process and then clean up how the other parts of the process are affected. As you can probably tell by now, this is a fantastic team building tool. So let's talk about how this can be used as a way to build your software development teams into positions where they can better execute their work in the future. Meaning, we will be training them. For me, this is the best way to start design thinking as a process for teams. By going through hypothetical scenarios, either large or small, and seeing how the team works together to propose their own paths and get to outcomes. The first recommendation I have is what you might call a hack week. Something where you are providing a week of downtime to address training. The work being done will most likely never go into a production state. In fact, I would urge you to attempt to address a market and category that the team does not know about. We want to this to be hypothetical. And be clear this a creative exercise for learning. Once you have that, you must train your team about the design thinking process. It's not very difficult to comprehend but more of a difficult skill to learn both doing more frequently as well as doing at various phases of a company or products lifespan. Set the tone of the scenario. Tell the team that each person must come to the table with their hypothetical documentation on each of the design thinking process points of interest. For the prototype phase, if you don’t have any engineers who are working on this, paper sketches or drawings should suffice. We’re really trying to get to the thought process here, not the output. In your scenario setting, put a problem, a market/category, a persona or audience, and the desired outcome into place. Your desired outcome should be the end result. The thing that you want the customer or the user to experience. Next, provide ample time to go through the process together. Break the process into multiple days and workshops. From a design perspective, we want to give ample time for each person to draw their own conclusions and document them for sharing later. If you can dedicate one day to each part of the process, at the very last day there should be a lot of time left for presentation. If running a larger headcount software company, where directors of product design or other roles might exist, try to put them into small groups. Again, it's our hypothetical role-playing efforts here that will really exercise the design thinking muscle. As you can probably tell by now, what we’re doing is providing freedom, flexibility and ultimately putting role reversal in the mix. We want each team member to be part of something they may not have been part of before. This way in the future the engineer can better relate to the designer. Or the designer can better relate to the product marketer. This is our ideal outcome as an exercise. For you, a leader of a software development organization, you know by now that every person comes to the table with a different set of experiences. They may have a clearly defined discipline with their focus of work. But we want to give them the opportunity to break that so they can empathize with their fellow employee’s. This will then educate each person about what steps might be ahead of them in their product development agile cycles or simply how to communicate about managing expectations better. I’d highly recommend one week each year dedicated to this hypothetical role-playing exercise. And I hope this framework gives you some basis to generate your own path for how the team will do this.