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.

The Journey

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.

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.

The discovery

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.