I finally finished reading Sprint, a book published by the Google Venture designers Jake Knapp, John Zeratsky and Braden Kowitz. I knew about design sprints, and have had the chance to participate in a few, including one with Jake himself.
I have been thinking a lot about design process lately, especially as my career progresses. I still carry with me a lot of what I learned during my studies focused on industrial design. Amongst the invaluable things that my professors passed to me two really marked my way of thinking about the design process. Both of them are about what I consider the most difficult part of any design work, moving from the problem idea identification to the problem solving.
Okay, but what does that even mean? In order to answer that let me try to illustrate with real examples. The first one was very simple. We used to start projects and spend a couple of classes defining a problem from a marketing and business point of view. Once that was done, the next phase was to take action. It could be brainstorming ideas and concepts to sketching on paper. There were a few rules that were very important, first no criticism, all ideas are valid because the second rule was quantity is better than quality at this stage.
With those rules in mind we had to spend a lot of time ideating. For sketches, we had to do at least 150 different variations. It was literally counted. I know it sounds insane, but that was important for us to get comfortable at moving from theory to practice. Both are important, but most of the time great ideas are just great in thoughts and very hard to translate to real designs. That’s why getting those out quickly is super important. It’s also important to do that because, as my amazing professor used to say, the first couple of ideas are just unconscious copycats of things you like.
For sketches, we had to do at least 150 different variations. It was literally counted
The second example is also back to my college days. It was my final semester, and I, with a group of 5 people, was working on our final project. We spent a month identifying what we would work on and another month working on a draft idea/hypothesis of what the solution should be. So we had to defend it to a small group of designers. Then one student started presenting her project and showing the problem definition and what she was trying to solve. Everything made total sense. The process, the thinking, the insights even the inspiration for the solution. Everything connected, everything but the design she came up with. It was quite paradoxical, how can you get everything right and the outcome is wrong? The answer was quite simple, they told her, she spent too much time theorizing the problem and too little time ideating on the right translation of that to a product.
The lesson was simple, there’s no way to design something right at first crack, even if you get all the information needed. Even if after 150 different ideas, you go back to one of the first ones, you will have to go through this type of validation to make sure it is the one. That’s the reason I am sharing this. I feel that we tend to overemphasize the problem definition and the “design thinking” but end up spending too little time on the “design doing” part of the process.
This post is part of a series of articles I will be posting on the blog that are not about design per se, but rather thoughts and ideas I have and want to share.