Design Thinking, a journey of discovery

Raul Espinosa
Jun 29, 2019 · 4 min read
Image for post
Image for post

Recently I participated in my first Remote Design Sprint, and I asked myself: “How did I get here?” I want to tell you all about my experience on how I got to be a “design thinking” and “design sprint” practitioner.

I’m an engineer, and I have a bachelors degree in computer science.

Since the 90s, my approach to solving problems was with a technical point of view, always. I was a problem solver — a clever one — a developer, and I was a technical leader. It’s funny, but when my team and I started developing software, we never thought about what the user wanted. We defined features because we felt they were cool and believed it was what the user needed.

In the mid-2000s, we started designing applications with metaphors; we made a website look like a notebook with a checklist of the tasks that the user was supposed to complete. I guess we started to think a little bit of what the user wanted, but again: we never asked, we just assumed. We began to understand and research the user experience. Now somebody would study where a button location, what color, and how the flow of things made sense for the user. Moreover, blindly, we started following those rules.

In the mid-2010s, we started hearing about creating delightful products and making tools that users wanted to use. Facebook and Google were making excellent products, and they were doing user research. For example, they tried A/B testing to choose which feature to roll out to all users.

I remember working on a project with our first product manager/designer. He was always worried about every decision and how the user was going to be affected. We started seeing better thought out, beautiful, and useful web applications. The technical stuff still mattered, but now we were not developing features because an engineer thought they were cool.

In 2016 our company started talking about design thinking. Our Chief Product Office ran the first Design Sprint, and I got an invitation to participate. I flew to Los Angeles to spend five days inside a meeting room with a multi-functional team and followed a process that was laid out in a brand new book called “Sprint” by Jake Knapp. It was a process widely used by Google Ventures and then Google to solve big problems and test new ideas in five days.

Image for post
Image for post

At the end of the week, when they asked for my opinion, I trashed the process. I said that it was a waste of time, and I watched as the sprint facilitator’s face went white.

I need to confess that the engineer in me needed to understand “why” and “how” things work. So, I bought a small book about design thinking. Then another one. Later I learned about IDEO and started reading their blog. I got into a course about Design Thinking, and then I read the “Sprint” book, and then I took the IDEO Course followed by another.

My mind was spinning. I learned about empathy, something that some engineers lack. I learned about research and other related topics to design thinking (a great philosophy), and about Design Sprints as a ground level practical tool to solve big problems when collaborating and innovating with others.

Our company started to learn about our users: creating empathy maps, creating personas, detecting pain points + understanding them, and trying to solve problems using human-centered design.

Everything started to make sense, and now I can’t see a method of delivering a product or a service with just the engineering point of view. Now I not only need to understand if the product or service is usable but also if it is required and if it is helping users to solve and ease problems.

Image for post
Image for post

Here are five things that surprised me the most:

  • You have the opportunity to explore a problem from different perspectives due to the multi-functional team approach.
  • It encourages innovative thinking.
  • You connect with people in your organization with diverse backgrounds.
  • During the process, the team starts aligning to solve the problem; it’s like magic.
  • You actually can get real feedback from real users and validate your idea before you start building it.

As engineers, we focus on problem-solving, designers on problem framing.

Technologies enable we engineers, whereas designers are inspired by it.

We are excellent in optimizing solutions, and designers enjoy creating great solutions for others to build it.

Don’t get me wrong; the technical execution is essential. However, it is a risk to build a product or service without a human-centered point of view driving the design.

Design and Engineering Thinking stimulate and complement each other. None of both is superior.

What do you think?

The Startup

Medium's largest active publication, followed by +755K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store