Prototyping: Build to Think, Build to Decide


Recently, at a Meetup of our local chapter of the IxDA (International Design Association), fifteen professionals discussed how we approach prototyping in our respective organizations.

The group included designers, product managers, and developers from a range of organizations from  a wide range of businesses from education, non-profit, for-profit, early stage startups, and design studios.

Below is a summary of what we discussed, as well as a list of some of the most popular tools among our practitioners.

The discussion focused on:
  • Why We Prototype
  • Prototyping Pain Points
  • Popular Prototyping Tools
  • How to be successful when prototyping

Maybe “what is prototyping” short paragraph in here for a smooth flow?

Why We Prototype

The term prototyping is thrown around quite a bit among designers, product developers, and innovators. Yet, there seem to be varied definitions on just what we’re doing when we prototype, the reasons why we prototype, and what stakeholders expect from prototyping.

So, why do we prototype? In short to understand and reduce risk. While there are many definitions and practices surrounding prototyping, generally, we are trying to learn something specific.

At ConnectFive, the parent company of Handrail, we prototype to “de-risk.” We never claim to guarantee success through prototyping and implore you to beware of those that will guarantee success.

Build to Think / Build to Decide

Prototypes help us test our hypotheses and move from assumptions to facts. Prototypes should evolve as our maturity and understanding of a particular problem evolves.

Early prototypes help us make sure we are thinking about the problem or opportunity the right way. We refer to these prototypes as “build to think” and they are typically lower fidelity. Generally, the fidelity of the prototypes will increase over time. Prototypes increase in fidelity to help us make better decisions and understand tradeoffs. We refer to these prototypes as “build to decide.”

We use prototypes to reduce risks associated with assumptions.

If the function of a prototype is to learn and reduce risk, then we need to be willing to throw a prototype away. However, we’ve seen organizations that think, or want to believe, a prototype is version 1.0 of a product or service. If it is seen as an early iteration, few are willing to throw it away which invites more risk, as well as limiting what we are willing to learn from the prototype.

Pain Points Associated with Prototyping

After discussing competing definitions and expectations of prototyping, the group shared pain points associated with prototyping. In addition to the semantic and expectation challenges associated with prototyping four types of pain points were identified:

  • Willingness to throw it away. One of the challenges with prototyping is that teams may not be willing to throw out the prototype. Many times, a prototype may be considered as an iteration or version of the final product or service. This closes teams off from learning and may be asking too much of the prototype.
  • Getting too high-fi too fast. The pain here for practitioners is stakeholders in their organization thinking the prototype is a near final product. While similar to the previous pain, its challenge is that stakeholders think you’re just about to unveil to the final
  • Getting started / where to start. For many, just getting started can be a challenge in the organization. Friction points include: time, resources, and agreed on targets or hypothesis.
  • Dealing with rapid changes. This pain seemed to be a symptom related to traditional organizational challenges of time and resources.

As we discussed these pain points and ways that others have confronted similar challenges, additional pain points were revealed.

An additional pain was felt in the areas of scale and fidelity:
  • Appropriate scale. This pain focused on the level of scale necessary to test a hypothesis and the level of fidelity. The appropriate “zoom” – zooming in on a particular feature or zooming out to understand the broader system. Testing at scale and controlling for context.  
  • Appropriate Phase. This pain was related to a particular phase in the innovation / product development lifecycle. Using prototypes to answer questions of desirability (what people want), feasibility (what tools or technology could support the initiative), or viability (if the business should undertake the effort).
Deeper issues:

A deeper issue at play with many of these issues are fears. Before we enter prototyping are we comfortable with being wrong or having our assumptions proven to be wrong? Before prototyping, it seems that teams and organizations address what they’re willing to find out and do they trust the process… or confirm that they are not simply prototyping to confirm understanding.

Like Samuel L. Jackson’s character Jules in Pulp Fiction – “if the answers frighten you, then cease asking scary questions.”  At times, it feels like fear is holding us back from getting to the truth.

Favorite Prototyping Tools

A much easier and lighter tone was embraced as the Meetup participants discussed our favorite or “go-to” prototyping tools. As part of our Meetup, sharing tools and tips about our craft is important as we cultivate our community. Keenly aware that we don’t want to lead with a tool or solution bias, the discussion of “why certain tools are popular” led to more insights for the group.

Here’s a list of the tools we discussed, with links where appropriate, and a brief description of what participants found useful.
  • 53 Paper – Paper is liked for its ability to quickly capture ideas.
  • Adobe Illustrator - Illustrator is liked for its ability to create robust, high fidelity designs.
  • Adobe XD - XD (Experience Design) is liked for its ability to quickly highlight interaction flows and create interactives prototype
  • Angular – Angular is liked for the ability to build prototypes with****
  • Balsamiq – Balsamiq is liked for its ability to quickly support wireframing and basic user flows.
  • Business Model Canvas – The Business Model Canvas is liked to its ability to help get teams and stakeholder on the same page regarding assumptions and facts, which is especially helpful in “build to think” efforts.
  • Fake Press Release – The Amazon Future Press Release * The “presser” is liked for its ability to articulate and define what the project could produce.
  • HTML/CSS * Similar to Angular, using HTML, or code in general, is liked for its ability to replicate and present interactions as they will take place if the prototype was a live product.
  • Invision – Invision is liked for its ease of use and a way to build quick flows and interactions.
  • Just In Mind – Is liked for its ability to support collaborative wireframing and prototypes.
  • Keynote – Keynote is liked for its ability to produce linked screens that appear to be a robust prototype.
  • PowerPoint – Similar to the use of Keynote, PowerPoint is liked for its ability to produce linked screens that appear to be a robust prototype.
  • Microsoft Paint (yes, Paint)– affordance, team knows there no way it’s final
  • Paper & Markers / White Board – basic tools to help us get to a visual language as quickly as possible. RIP Paint
  • Sketch – like many of the other ease of use to have a digital prototype.

Recommendations/Take Aways

Manage Expectations

Recognize that we are humans participating in human systems. This means the need for communication to reduce uncertainty and manage expectations. It is critical to manage expectations regarding scope, time, resources of what to expect from prototyping.  Make sure the team knows that the prototype does not guarantee success and it prototypes are there to help us learn.

Be Intentional

Intentionality is critical to successful design. Be intentional about the purpose of your prototype and what you really expect to learn from the process.

Break Things to Learn and Improve

As many organizations work to embrace Agile and continuous deployment. It is critical to embrace continuous discovery and learning. Be willing to break things to learn and improve as you go. It is less about “failing” fast, but exploring ways in which you can learn quickly. Handrail can help teams throughout their prototyping process.


We’d love to hear from you. What are some of your prototyping pain points and how did you overcome them? What are some of your favorite tools and why?

About Handrail

We built Handrail to help teams collaborate throughout the entire user research process. Plan, collect, analyze, store, and share your research all in one location. Sign up for a free 30-day trial today.

Matt Arnold

Matt is a researcher and product specialist at Handrail, Inc. He is passionate about human-centered design and helping teams do more effective research. Matt has led strategy and design work for early and late stage startups, as well as some of the country’s most recognized brands.

Leave a Reply

Your email address will not be published. Required fields are marked *