Prototyping, You’re Probably Doing it Wrong

To many, the design process is very intimidating because of the perception that design has to be perfect. In my experience, that is not the case. Design is like an iceberg, all the ugly and failed attempts are hidden and all the great ideas are on full display at the top.

The design process is almost never linear. You’ll end up throwing out 90% of the ideas and making at least 30 iterations of the remaining 10%. Some of the most used applications (like Google, Facebook, Yahoo and many others) had many design iterations before they became the beautiful things they are today. They all started with simple and buggy MVPs that eventually mature over time. During the early states, they embrace the art of GSD (getting s*** done) to explore many ideas and concepts. Let me tell you about how embracing the art of GSD should be an attitude that a product team should have when creating products.

I started my career as a Print Designer doing mostly logo design and marketing materials. My mindset was that every time I was presenting my work, it had to be perfect. I would spend hours making sure the colors were perfect and everything was aligned properly before anyone else looked at it. When I attempted to use this same workflow when I became a product designer, I soon found out it wasn’t going to work. I was spending too much time perfecting one idea rather trying out many….and this was making it hard for me to keep up. I made the assumption that the first idea I was attached to was my best, and doing so, prevented me from exploring other ideas. And since any work I wanted to show had to be perfect, I missed out on valuable feedback from my co-workers early in the process. I realized that I needed to adapt a new workflow in order to survive. It took me about 6 months of trial and error to find a workflow that fits the environment and my work style.

Fast forward now where I’ve spent over 3 years building web based products at NASDAQ, my mindset is totally different. I trust the process that if I understand the problem well enough and exploring as many ideas as possible, the probability of creating the right solution increases. Most of the ideas you will come up with aren’t going to be good at first. Some are going to be so bad that your eye will bleed, but that is part of the process.

One example of this was when working on IR Insight contact management system. I got an user story about inputting travel information into the system for a future roadshow. I got attached to an idea of the user actually adding everything from flight time to plane number. The solution worked but it wasn’t the right for experience. I spent more time prototyping the idea in code and at that point, it was hard to start from scratch due to time and resources. If I had quickly tested idea in the early stages, I would have found out that it was a tedious process, especially for those who have multiple trips during a road. If I invested a little more time exploring, would have been better solutions.

Now that we know how most of our early designs are often not the good, why do we hang on to them? As designers, we sometimes put our emotions into our work. Doing so makes it hard for us to share and get constructive feedback. We always want our work to be perfect, and striving for perfection can hinder our ability to execute. That is why we can never put perfection above execution. But we’ve all seen those perfect wire-frames, mock-ups and prototypes on sites like Dribbble and Behance. Most often than not, these perfect artifacts don’t show the many failed attempts and bad ideas. But seeing those failed attempts often tell a great story on how and why the final solutions were selected. The quick and dirty ideas often pave the way to the better solutions in the future.

Execution should be worshipped during the prototyping phase. Being able to go through a bunch of ideas and concepts at a fast pace is a great way to filter out the bad ones and get clarity the good ones. This process reminds me of drawing exercises I did in high school where the class would sketch an object at least 30 different ways in 5 minutes. After the 5 minutes, you can see the progress and see how the first 20 sketches weren’t that good but over time, the sketches got better. That exercise proved to me why execution should be a priority over perfection. Bring this back to product design; the concept of rapid prototyping is a great way to quickly and effectively test out design solutions. Doing so not only saves time and money, but it also makes it hard to get attached to an idea. The main purpose of rapid prototyping is to make the best design decisions possible around user experience for your application.

Since prototyping is fast and cheap, it makes it easy to pivot if the direction you were going isn’t going to bring the best user experience. And sometimes when pivoting, going back to rejected ideas is a route that can be taken if the ideas were good but the timing wasn’t right.

Bringing some context to the idea, I use this process when I prototype code. I don’t spend a lot of time making sure my code is clean or scalable. So you will often see very bad techniques from me from my prototype code like having half of the file commented out, nesting 10 levels deep and using !important like I don’t know better. But to reiterate what was stated before: the purpose of rapid prototyping is to make the best design decisions possible around user experience for your application. When prototyping is code, being able to communicate your idea with code is the top priority, and that trumps all the bad techniques listed earlier.

It is very hard to rapid prototype in code and at the same time make the code scalable and efficient enough that is production level ready. It’s better to separate iteration phrase from the maintaining so that process can be less rigid. Once the front-end prototype has been tested and validate, that is when scalability and performance can be focused on.

For my parting advice, don’t always try to perfect an idea. Your first ideas are going to really suck, but that’s okay. As long as you trust the process and the ideas are getting better over time, the right direction easier to get to than the right idea. Because it’s better to go slow in right direction rather fast in the wrong direction.