Why We Prototype
Over the course of my career, I have learned that the most critical ingredient to success in any software development project is clear communication across all team members and stakeholders. It is also extremely difficult. Why? We have more channels than ever to communicate (in person, phone, email, IM, etc). Modern project teams are almost always distributed - in many cases across numerous time zones and with language barriers. People in different roles don’t think about things the same way - developers think differently than project managers, designers think differently than CEO’s. The list goes on.
As a result, most communication - both verbal and written - leaves quite a bit of room for interpretation. Interpretation is great when reading a novel or listening to a storyteller. Unfortunately, interpretation can be deadly when trying to clearly communicate complex concepts to a project team and diverse groups of stakeholders.
Seeing Is Believing
As the saying goes, “a picture is worth a thousand words”. At Originate, we use prototyping heavily to support our product development process and to create clear alignment of goals and expectations. It is by far the most effective tool to aid in communicating thoughts and ideas to others. It also serves as a visual anchor that everyone can understand, rally behind, and use as reference throughout the project until the real product has been built.
Defining Your Objective
A prototype can be built to serve a number of different purposes. In order to determine the best approach, it is critical to define the objective of the prototype first. What are you trying to accomplish and who is your audience? In our experience, there are 4 common objectives for creating prototypes:
Learning - Sketching, doodling, and drawing on whiteboards is a great way to spark creative thoughts - either alone or as a group. Wireframing multiple versions of a particular screen can be a great exercise to flush out the best solution. Stringing a series of wireframes together can help quickly identify obvious gaps in a workflow that were hard to anticipate when looking at a flow diagram.
Explaining - Finding a common language that everyone on a project can understand is difficult. Prototyping can help bridge this gap. The prototype makes it much easier for a PM to articulate what features are required, how features should work, and how they fit into the broader product. The prototype also enables those tasked with creating the product to ask specific questions, shortening the knowledge transfer process so that more time can be spent designing and building.
Selling - Even the most obvious ideas and solutions require selling. It can mean selling your vision to an executive team or a team of investors. Or rallying your team to understand the business opportunity staring you in the face. Showing a vision is far more powerful than trying to explain it.
Testing - Real world usage is by far the best way to inform future product and design decisions. Before you have a real product - and thus before you have real users - prototyping can be an invaluable exercise to determine the market viability of a product or feature. Creating a prototype that potential users can touch and feel produces far more accurate and tangible results than explaining an idea or showing them a picture.
Choosing The Right Approach
Once you know your objective, you need to determine the strategy. The word prototype itself can mean many things to many people. We create different types depending on what we are trying to accomplish. Here are some attributes we take into consideration:
Visual Fidelity: How polished does the prototype need to look? Will a sketch or a wireframe be sufficient or do we need to create more realistic, pixel-perfect visual designs?
Interactivity: Are static screens with limited interactivity sufficient or do we need to demonstrate deeper interactions on the screen and transitions between screens?
Sharing: Will the author be the only one demonstrating the prototype or will it be distributed to a group to review or test on their own?
Collaboration: Is it necessary to have the audience mark up and annotate their feedback? Is the goal to track user patterns or to conduct A/B testing?
Another thing to consider is time. How long do we expect to leverage the prototype? Is it a quick and dirty example that we’ll throw away in a few hours or a few days? Or do we intend to use it for an extended period of time - continuing to iterate on it over time?
Thinking through these priorities makes it much easier to select the right tool(s) to accomplish the task. It also helps determine how much effort to invest in the process. With every prototype, there will be a point of diminishing returns. The key is to strike the right balance so that you can accomplish your objectives with the least investment of time and resources.
Mapping To The Objective
The below chart is a rough guideline for how we balance the various attributes for each objective.
There are tools available to build nearly any kind of prototype - ranging from paper and pen to fully functional code-driven prototypes. There are quite a few lists out there comparing a variety of tools - including here, here, and here. Hopefully this helps others narrow in on a solid strategy, which should make selecting the right tools much easier. Remember, the prototype is just an enabler of communication. The ultimate goal is to build a great product!