Breaking Design Thinking into questions
Design Thinking is a buzzword. If you google it, you will find different ways to describe it. Probably, it will make you feel more confused about it. But relax, almost every piece of information is correct even if they are quite different from one another. Design Thinking (DT) is not just a framework, a recipe or a checklist. Design Thinking is a mindset. However, when you need to start working with something new, it is really good if you can have a few steps to follow until you feel secure and internalize the mindset in order to apply it in your own way. This set of articles are my two cents to help you develop a hands-on Design Thinking project. It describes my step-by-step way of working. If you are a beginner in the subject, this article is your number. Enjoy it, and use it as a step to organize and create your own way of work.
DT and a million frameworks
There are different ways of describing the DT mindset, and three of them are the most popular ones. They are all human-centered mindsets full of empathy, collaboration and prototyping with some slight variations. Let’s start with the British Design Council definition. It describes DT as a process with four phases, known as Double Diamond: Discover, Define, Develop, and Deliver. The thing that I most love about it is how they help you shape your way of thinking. Sometimes you need to be divergent and other times you need to be convergent — I will go back to this point in a few paragraphs. The second mindset is the Stanford d.School and their five hexagons: Empathize, Define, Ideate, Prototype, and Test. Last, but not least, we have the IDEO‘s four-phase process: Gather, Generate, Make, and Share. Also, you can spend your entire day comparing millions of Design Thinking frameworks on this amazing website, or you can focus and finish this practical article.
Recently, I started a project with a new partner. She has a background in HR and is an expert in the field — but is not a designer. She has heard a lot about DT, but she never had the chance to work with it. This will be her first experience and she is so excited and full of questions about the process that we decided to do a few meetings before the project starts. My goal was to share the DT process with her. While I was speaking to her using words like co-working, ideation, inspiration, prototyping, etc, I realized she knew the common-sense meaning of these words, but she was not getting their technical meaning at first. I was silly using jargons and explaining all the philosophy to her, although her head was searching for a practical meaning. She kept asking me how to do it. That was a breaking point to start writing.
She had researched a lot of information on her own, including the frameworks I mentioned before. However, she thought that those descriptions were either too broad (when talking about the framework) or too specific (when talking about tools and methods). She could not understand how to use them. She kept asking herself questions like: “How are those tools connected with the framework?” and “How can I get started?”. Her questions were not silly at all. Actually I also ask myself similar questions during a project — yep, I’m one of those crazy people who talk to themselves!
We all know that feeling when you have so many options that it is hard to make a decision. To avoid that anxiety, I decided to write something in between. In order to put in a practical mindset you will probably need some tools. If you focus only on the tools without a mindset, it might me be useless. You need both. So, I wrote down which tools, methods, or approaches I usually apply during my work process to answer those questions my partner asked. This is the first of three articles wrote to help her — and other newbies — to see clearly when they might want to use a tool or a method in a DT project timeline.
Usually, I divide a project in two big moments of focus. In the first part of the project I must only think about the PROBLEM. This means that every time some idea for a solution pops-up I will write it down on a post-it and only go deeper in that when I figure out what is the real problem. The second focus is all about the SOLUTION. In this case I try to stop digging into the problem and I activate my brain to solve the challenge instead.
Finding the PROBLEM
1.How to listen to clients?
2.How to convert clients’ problems into a challenge?
3.How to understand the challenge?
4.How to organize the learning points?
Creating a SOLUTION
5.How to transform a learning point into (many) ideas?
6.How to select the best ideas?
7.How to prototype?
8.How to choose the best prototypes?
9.How to implement the project?
10.How to know if we are on the right path?
After that, I break the project down into phases and mark up how my way of thinking should be — convergent and divergent. If it is a divergent stage, I might expand my thoughts, gather all kind of information and inspiration, collect, observe, the more the better. On the other hand, if it is a convergent stage, I might decide, cut off, be critic, make decisions, be more rational and align with the project’s goals. If everyone in the project is on the same page, we can minimize unnecessary conflicts and help to increase the team spirit.
From my experience, a DT project gets better results when you work with a team. I only did it alone twice. It works, but when you have others to contribute, to criticize, to co-create, it makes a huge difference.
Finally I choose the tools and methods. Some of them have different names, it depends on the source, but the essence is the same. In this article, I wrote down the tools and methods that I tried at least one time. But I always keep an open mind, there are a lot of good tools and methods out there. That’s why I will never stop studying. Also, keep in mind that even if this looks like a recipe, each project is unique and demands adaptation.
Here is my diagram, to show you how the frameworks are connected with the questions.
To understand which methods and tools you can use for each question, read the next two articles: