Turn method into magic—the alchemy of prototyping

Issue 77: How to go from idea to reality

Jan 30

A designer can mean means many things. The list of all specializations designers have ends up being the scale of a Cheesecake Factory menu. I wrote in a previous issue about my definition of what a product designer is. If there is one area in product design that makes my heart sing, it’s prototyping—a method led by curiosity and exploration. This week I spoke at Stanford's Product Management Fundamentals course (taught by our VP of Product at Webflow) about prototyping. I prompted the lecture with one of my personal design philosophy:

Turn method into magic. Design is not magic. It's a method—a rigorous process of exploration, iteration, and validation until you reach your outcome that feels like magic to end-users.

Like the definition of design, prototyping itself means different things. In recent years, prototypes were often associated with click-through screen designs; made popular by the design tool InVision. Though click-through prototypes are an effective method, there’s a rogue’s gallery of other ways to prototype. You can prototype beyond screen flows. It can be an entirely new business line or design language.

What makes a designer a good prototyper? There isn’t a step-by-step to it. Prototyping is alchemy, storytelling, and exploration. The best prototypers I’ve worked with are exceptionally good at learning, subverting tools, and re-purposing. They find shortcuts on how to gather insight. Great prototypers write, sketch, edit, code, no-code, etc. It's about developing the concept and less about the tools, but you have to know a lot of different tools.

When to prototype

There are many traps in the prototyping phase, and the classic one is over-designing. You may have heard the term, "solution looking for a problem" which describes a creation that is fully developed, yet the problem it's trying to solve is unclear. Here's a sample rubric I use to determine if prototyping can be helpful:

Building a new product or service line
Exploring a major paradigm shift in the product
Change that will affect service delivery
Technical architecture changes

The holy trinity of prototyping is learning about desirability, feasibility, and viability. These are three different focuses yet not mutually exclusive.

Desirability (Humans): Does the customer even want this?

Start with the end customer. If it’s not worth it to them, it’s not going to add value to the business and not be feasible. In this phase of the process, you want to build artifacts to help understand if the concept is something customers want; focusing on behavioral insights. This is where paper prototypes or click-through prototypes.

Feasibility (Tech): Can this be built?

People want your solution, but how do you implement it? There is always technical debt and constraints to consider in real-world products. The key is subverting your existing product to understand what you need to build to make it feasible. As you're prototyping and running pilots, you can use other services or platforms to mimic the experience. For example, if you need an onboarding survey, you might be able to get away with a type form survey instead of building it out in your product. It's not going to be the best experience, but it's enough to get an understanding of the feasibility of what to implement.

Viability (Business): Is it sustainable for customers and the business?

Business viability is crucial in product design. One of my favorite projects in my career was at Black Pixel when we worked on a camera app for a popular media platform. The late 2010s were the Check-In App Wars, and the mid-2010s were the Camera App Wars. The learning objective was to understand if the product was viable for the business. When you prototype projects like this, you need real results.

In the case of this project, the product owner wanted to be lean in product development. Instead of building a full app, we found shortcuts. Instead of using an asset manager, we used Dropbox to integrate with the iOS app. Building this lean MVP allowed them to test it at the MTV Video Music Awards. Bringing their stakeholders along the journey allowed further investment instead of pitching a very costly initiative.

Rightsizing

In product design, it's all about rightsizing. Think too long-term, it takes forever to build, eventually becoming a sunk cost. Think too short-term, you become a feature factory. The best prototype experiments plot the steps of how you rightsize your product road roadmap.

Define a learning objective

Like the problem statement, getting the learning objective defined is crucial to a successful prototype experiment. It's crucial to get the right signal on what you want to learn. Too many times teams start building cool prototypes and come back with no insight.

Success criteria

Be rigorous about what success means. A great framework is Google's HEART. I'm not going to offer up a success criteria framework as it's different based on the company, product, context—too many factors. Instead, I'll offer an example.

Let's say you define "task success" as the success criteria. In this case, it means if the end-user was able to complete a certain task laid out, such as "book a flight to Europe." Success, right? Wrong. This criterion doesn't say anything about if they can do it effectively or if it was a pleasant experience. They could have completed the task in a few days.

In qualitative data, I don't like having compound metrics. However, for qualitative studies, it can help. Here's an example of what you could write as a success criterion:

End-use was able to complete the task
The task was completed in under five minutes
No help was required to complete the task
End-user rated it an 8/10 satisfaction experience

This gives you a much clear signal. Awesome, you have a prototype experiment with a great signal. However, it's not over—in fact, the beginning.

Now what?

When prototyping, it is important to be comfortable with failure. Success is found through failure. When building prototypes, it's not a promise to the roadmap. You'll have to kill your darlings and iterate a lot. However, a lot of the insights and what you learn to live on in other ways manifested.

Prototyping is a capability, mindset, and culture

I hope some of these ideas resonate. This doesn't mean you have to do it for every project. It's something you have in your design arsenal to use to move the business forward.

P.S. I try not to plug too much about my own stuff here. However, since we covered prototyping I wanted to link to a few podcasts I've been on about prototyping: