Back

The Basics of Design Thinking for Problem Solving

There is a solution to every problem out there. The hard part is simply coming up with said solution. Today’s article brings you a methodology to do just that: How to get together with your team, think creatively, and design solutions or workarounds for the obstacles in front of you, whether it is for business ends or personal growth.

Where To Begin?

We can trace the beginnings of this method to author Peter Rowe’s Design Thinking, written in 1987. It was initially aimed at architects and urban planners as an approach to solving the problems they faced during each design project. However, as great ideas usually do, they spread to any field involving a project and a problem that needs a solution. Handy!

How Does It Work?

I found this quote on Interaction Design Foundation, by Ralph Caplan, that reads: Thinking about design is hard, but not thinking about it can be disastrous.

In the past, I was constantly at the end of that situation. We’ve all worked for an autocratic boss who thinks they know all the answers and does things on a whim, only to have projects not perform as initially envisioned.

And while the tactic of throwing stuff at a wall and seeing what sticks might give you something good, eventually (at the full potency of that word), I refer back to Caplan when I say: Why not make informed efforts?

That’s what Design Thinking is about a method to approach problem-solving that is structured in such a way as to get to solutions or redesigns until solutions are produced. Here’s a graphical representation of one of the many that are out there for this method (That we have understood from the get-go there isn’t one sole way to do this):

This is the visual representation of design thinking as proposed by the Hasso-Plattner Institute of Design at Stanford, as we can see it comes with five definite phases, and from now on we’ll get to talk a bit about each and thus learn how the process works.

  1. Empathize: Essentially, to get in someone else’s shoes. This is part where the team, faced with either a problem to solve or an idea to bring the body to, tries to think as their clients, users, or anyone with the said problem would. You can see it as a bit of organizational roleplaying, where the end goal is to understand said users better.
  2. Define: Now that you’ve all gotten into the consumer’s mindset, it comes time to shape that problem. Here is where the problem is defined and explored, where the needs of the consumer are understood and broken down, and after that discussion, some interesting insights might be developed, which leads into the next phase.
  3. Ideate: Here is where the creative magic happens. Putting your brains together (works as well on your own, don’t worry), you come up with an idea (or several) on how to attack this need that needs solving. What’s important to remember here is that this is not the final step, so said idea does not have to be perfect or final, but it’s closer to being helpful now than where you were before.
  4. Prototype: Time to make the ideas something in the real world. We could be talking about anything: Architects (as per Rowe’s original intention) will get to design the plans, structures, positioning, and so on. I can certainly imagine this is how kitchen gadgets and innovative gizmos are created, and this is the phase where that first working prototype is produced. But alas, this is also not the final step.
  5. Test: As the name says, you put that working prototype to the test. But what it doesn’t immediately scream is what you do with this. And this is the beautiful part, I believe, about this methodology—it’s an Ouroboros Snake. This self-continuing loop strives towards perfection because, after testing, you analyze the positives, the negatives, and every detail in between. Then, you decide if the idea is approved, scrapped, or returned to the drawing board, also known as phase 3. 

Now, an important thing to remember is that this is not exactly a step-by-step rigid guide on how to progress, but an overarching framework to modify and improve on. This is why you will find other versions of the same visual map when researching the same Design Thinking topic.

Do not feel constricted by any, and keep in mind that each phase might have its own steps and schedules, it can be so much more than something one can cram into one article. If you liked reading this, and want to learn more, here’s another of the sources I consulted during my research on the topic, which I’m sure would be of interest to you.

See more articles by Haward Méndez.