Why Prototype?
As we mentioned earlier, when you’re embarking on an app development journey, you’re facing a ton of unknowns. Prototyping can prevent those unknowns from becoming huge issues by helping you to define, test and evaluate them up front - allowing you to build a better product with greater efficiency from start to finish.
There are three primary reasons for prototyping: Feasibility, Failing Quickly, Better Product Decisions and Test Market Fit
Feasibility
Working on new products often involves needing to build new functionality that your team isn’t quite sure how to approach building. Prototyping can help you to figure out how feasible the new functionality is by focusing on those unknowns.
The key questions to be answered during the prototyping process should be:
- Are there existing technologies for this new functionality that we can leverage?
- Can we find one that we can get working in the necessary timeframe?
- How long do we estimate it would take to build a production-ready version?
- Do we need to research more and potentially develop these technologies ourselves?
Failing Quickly
Sometimes, when your prototype is built and finished, you realize that it simply isn’t a good idea to see it through to a full production version. In this scenario, the time, money, and effort saved from building just a prototype instead of the full product is usually huge.
Failing quickly by prototyping can also help you make the decision to pivot and take your product in a different direction when necessary, before you’ve gone too far down the product development path.
Often, a failed prototype can be leveraged for success by incorporating the lessons learned to produce a far better version of the initial prototype. You can continue with this cycle of prototyping until you land on something that sticks.
Better Product Decisions
When you first explain your product idea to potential users verbally, they may be able to give you some immediate feedback, but this type of feedback is not of the same quality as if they had actually tried the product itself.
Building a prototype lets you see real users interacting with your product, which is essential to making the best possible product decisions for the production version of the product.
Some of these product decisions can be focused on what features to keep in your MVP and which ones to drop. Having real users testing your prototype can get you feedback on what features are actually more valuable to the user very early in the product development process. Often just as important, a prototype can also get you early feedback on which features are more likely to be ignored or not be discovered.
The prototype can also give you valuable clarity on tradeoffs between the value added to the user and the time & resources needed to actually build the feature for the production version. You’ll find that one of these trade offs will not be worth it, and those features will be dropped for the MVP, saving you time and money.
Lastly, prototyping can help you make better user experience decisions in your product, by seeing if the user really understands how to use your prototype. You can give the user a challenge or a goal that needs to be accomplished by using your prototype and evaluate how easy or hard it was for them to accomplish it. For example, you could ask them to try to invite a friend to the application and see how quickly they can find the appropriate part of your prototype to complete that action.
Test Market Fit
Another important benefit of prototyping is having something tangible to use when researching product-market fit. By having users interact with an actual prototype, you can get significantly more accurate feedback about if they have a need for the product, how much they would pay for it, and where they might learn about your product in the first place before using it.
You can also do more in-depth studies on the specific market segment your product is targeting, and make iterations of the prototype to see if it will appeal to different users based on changes you’ve made.
When NOT To Prototype
The practice of prototyping is useful for many different kinds of products and scenarios, but there are some times when it’s not needed prior to actual product development.
Existing Solutions
If the product you’re looking to build uses stable, common technologies that are well documented and well tested, it could be that you don’t need to prototype to figure out the feasibility of your product idea.
Proven Market
If there’s a clear market for your product idea that’s already been vetted by other means, you may not need to build a prototype just to prove that users find it valuable and worth paying for.
Adding Enhancements
When you’re building new features onto an existing product, often those enhancements might be very straightforward to implement and don’t need to be prototyped, especially if they’re adding low-risk functionality.
Non-visual Product
Often prototyping is used to create something visual for users to test and give feedback on. If your product involves something more along the lines of scripting or back-end work, it may not make sense to build a prototype to gather feedback.
Methodologies: Low & High Fidelity Prototyping
There are a variety of ways you can approach prototyping, ranging from very quick and basic to very robust and time-intensive. Here’s a high level breakdown of prototyping methodologies.
Low Fidelity
A prototype doesn’t need to actually be digital in order to start getting feedback from users. Usually, when first thinking through a product idea, a low fidelity prototype can be used to quickly iterate on the product idea. This often takes the form of a paper prototype that is hand sketched and used to walk others through user flows.
Since these can be created rather quickly and don’t require someone to have an extensive design or development skill set, it’s a great beginner's way to prototype.
Your Low Fidelity Prototype Should:
- Present the information that will be displayed on screen
- Provide an outline of the structure and layout of the screens
- Convey the overall direction and description of the user interface
The key to a good low fidelity wireframe is simplicity. The only thing you should be demonstrating is how elements are laid out on the page and how the site navigation will work.
When creating your Low Fidelity Prototype make sure to:
- Use grayscale - avoid any colors except black and gray.
- Keep fonts to a minimum. Try to use a single font - utilize bold, italic etc to denote hierarchy.
- Avoid graphics and images. You can use rectangles and squares to denote where an image will be placed.
While you can create low fidelity prototypes with just a pen and paper, there are a lot of easy-to-use online tools available to help make the process that much easier. We recommend trying:
High Fidelity
The Design Oriented Prototype
Currently, there are several tools that exist to help create prototypes where users can click through high fidelity mockups. Essentially, a designer can create the individual screens in a tool of their choice and then link them together through simulated interactions.
For example, a button on a mockup when clicked would show the next mockup in the flow. With this approach, you don’t need anyone with a very technical skillset to work on the prototype.
This type of prototype could also include some basic front-end coding, but essentially have no real back-end or data that is flowing through the app.
Prototyping in a basic front-end programming language can sometimes be quicker than creating mockups and linking them together in a tool. This approach also lets you potentially iterate on the prototype faster, and eventually hand it off to a developer in a more seamless fashion.
For this type of prototyping we recommend using:
The Fully Functional Prototype
The most specialized prototype is the one that is fully functional. This means it is actually both designed and developed to be similar to how the production version of the product would be built.
This requires contributions from team members with the most specialized skillsets, and requires the most overall effort. Fully functioning prototypes, however, can produce some of the richest user testing and feedback compared to all of the other prototyping methods, due to how close it is to the real thing. Users can interact with this prototype the most naturally and are less aware that it may just be a prototype.
For Fully Functional Prototypes we recommend the following tools:
- Firebase
When working on a functional prototype, you often don’t want to have to worry about making a full functional backend as well. This is where Firebase comes in as a remote database that allows your product to quickly store and fetch data without any setup of your own infrastructure. - Raspberry Pi/ Arduino
If your prototype involves hardware, you should likely be using a hardware dev kit that allows you to quickly iterate on your idea, such as the Raspberry Pi or Arduino. They have both become very popular and have a lot of tutorials, guides, and pre-built components at your disposal for getting up to speed quickly. - Heroku
After the prototype is built and ready to be tested, if you’d like it to be publically available but don’t want to spend time setting up the infrastructure, you can leverage a service like Heroku which can handle hosting the prototype for you. - MVC frameworks (Django, Rails, etc)
Sticking to stable and modern frameworks, such as Django, when developing a prototype can help give a solid foundation for you to build from. Starting from scratch or using a really new framework can often be a hindrance to the prototyping process, unless that new technology is specifically why you’re looking to build a prototype.
Stages In The Prototyping Process
While each prototyping project is unique, there is a system of thinking that requires tested and proven practices and aggressive goal setting to ensure success. For the best results, prototyping should be approached in the following stages.
Identify your riskiest assumption
When first considering building a prototype, you should specify the exact part of your overall product that you’re looking to build - you’ve likely done this when you defined your MVP. Part of this process should be considering what assumptions you are making about the product and its potential users. If you analyze what kind of assumptions exist in your product development plan, the ones that have the most ambiguity are likely the best suited for prototyping.
Set Expectations
Before you start on actually building the prototype you should define a strategy. A key part of this plan should be to timebox your team and to set a clear deadline for when the prototype will be ready to test. This will help your team work within constraints and not get too carried away with any one part of the prototype itself.
Having a deadline helps keep the prototype on a set course and filters out any scope creep that can happen along the way.
Sprinting
When it comes time to actually build the prototype, your team should be fairly small and stick to agile processes (more on this in the project management module). This will help keep the team flexible and enable experimentation throughout the prototyping process. Your team should be collaborating closely and checking in with the product owner on the prototype’s progress at least once a week.
Validation
After the prototype has been built, it’s time to reap the rewards and get valuable feedback from user testing. You may have a very organized user testing process setup, which is obviously ideal, or it may be as off the cuff as going out into the public and asking people to try out your prototype. Either way, you need to get your prototype in front of as many users as possible and record all of the insight you find. After all, the main point of prototyping an idea is to gather feedback to leverage in making the actual end product that much better.
We’ll be talking more about exactly how to user test your prototype in the next section.
Next Steps
Once you’ve built your prototype and received plentiful user feedback, there are a few choices you can make.
- The results of the prototype have proven that you should not move forward with this particular product and should pursue something else.
- The prototype resonated with users, but you have more questions that need answering through more prototyping and testing.
- You’ve gotten enough feedback and are ready to build the actual product that the prototype was testing for.
Five Common Pitfalls To Avoid
Just as there are strategic misconceptions about prototyping, there are also common tactical pitfalls that can be equally damaging.
Pixel Perfection
When working on a prototype, the goal should not be building immaculate mockups and having your application match them exactly. Your time and effort should be put towards building the main user flow you’re looking to test and get feedback on. If you’ve started to push pixels on your prototype, it might be time to stop prototyping and start getting users to take it for a test drive.
Over-Engineering
It can often be tempting when working on a prototype for developers to over-engineer what they’re implementing. A prototype is not supposed to make it to production and be maintainable for the long haul, meaning you can have some technical debt. If your team is spending too much time making the code perfect or more complicated than it needs to be, you should have them refocus on the core goals of your prototype.
Too Many Team Members
A prototype should be a focused subset of features for a larger application, likely meaning you don’t need too many designers and developers involved to get the prototype finished. Be careful about having too many cooks in the kitchen when building prototypes, and keep your team lean.
Going Past Your Deadlines
Since a prototyping project usually involves a lot of unknowns, it can be easy to blow past deadlines and sink more time into trying to get something functional. Often, it’s helpful to timebox your work and stay true to deadlines, keeping the exercise of prototyping focused and valuable.
Failing to User Test
After spending time, effort, and money to build your prototype, don’t forget to validate the results. Building the prototype is only half of the process - don’t let it overshadow the true end goal of testing with real users to gain valuable feedback & insight.
Top 10 Tips For Prototyping Success
Now that you know the various forms prototyping can take, how it works, and what common pitfalls to avoid, it’s time to share our secret sauce on how to ensure prototyping success with these ten tips.d
1. Identify your riskiest assumption.
When building a product from scratch, the riskiest assumption you can make is that your target audience is actually experiencing the problem you’re seeking to solve. If they aren’t, your product has no market.
Base your prototype on concrete knowledge and focused problem-solving. Many similar products have entirely different audiences, so ask, “What am I solving, who am I solving it for, and do they actually need my solution?”
2. Don’t commit to one solution.
Part of your prototype’s job is to solicit audience feedback. If you’re committed to one solution, you’ll look for any way to justify it. It’s not easy to change this mindset: You have to train yourself to transition from solution-creating to problem- solving. Be open to feedback, and focus on solving the problem—not creating your solution.
3. Don’t get lost in the details - simplicity is key
We’ve seen many companies attempt to prototype an entire product and get lost in the details and features that don’t need to be solved for another six months. Prototype the core of the product, identify what you need to revisit, and then expand outward, knowing you’ve built a solid foundation.
4. Utilize everything at your disposal.
Know what you need to do, and seek tools that help do it faster. If you can find a shortcut to make prototype creation simpler, move production faster, or build it better, take it — even if that means removing functionality from your prototype to solve the problem. Do not, however, take shortcuts on core functionality that will cheat you of the knowledge you’re trying to gain.
5. Be willing to throw it away.
If you can’t crumple up your prototype at any point in the process and throw it away, you’re not building a true prototype. Thomas Edison learned hundreds of ways not to build a light bulb before he found a method that actually worked.
6. ‘Iterate’ can’t be reiterated enough
At Yeti, we use design sprints to rapidly prototype and challenge our riskiest assumptions with target users. Based on their feedback, we test, modify, and re-test without the overhead costs of redeveloping the product. Design sprints break down the creation process, making it easy to pursue the ultimate destination without losing sight of the small steps required to reach it.
7. Give every side a voice.
Involve the product owner, designers, developers, strategists, facilitators, customer advocates, and salespeople. Everyone associated with this product’s lifecycle should be engaged in the early stages to help the group discover any potential oversights. Limit contributors to seven or eight people, but bring in as many diverse viewpoints as possible.
8. Done is better than perfect.
With a prototype, the goal is not to have a pixel perfect, bug-free product ready to release to the world. Your target outcome should be an application that is reliable, testable, with users to properly validate the idea and provide feedback. When users test a prototype there can be guidelines set up so that they stay within the bounds of the main flows that were worked on. Edge cases are usually best to consider after the prototyping process, since the feedback you gather might lead to removing that aspect of your product anyways.
9. Go with what you know.
When prototyping, you should not be experimenting with new technologies unless they are key to the product and functionality that you need to test. When trying to validate an idea, you should stick with technologies, frameworks, and libraries that you are the most familiar with in order to complete the prototype and get feedback as soon as possible.
For example, if your team is most familiar with web development, you might think twice about having them build a prototype for a native mobile application. In this scenario, it might make the most sense to build a mobile web application which can approximate what the native mobile app’s experience would be (as long as your riskiest assumption doesn’t include validating a native mobile application feature).
10. Feedback is king.
Ultimately, what you’re aiming for with your prototype is to understand the feasibility of specific functionality, and to establish whether users find value in a product with that functionality. When making any decisions during the prototyping process, ask yourself, “What will help us test this product more effectively with users and get us better quality feedback?”.
