Blog
Filter by tag

Why You Should Be Building Prototypes for Your Next Big Feature

August 8, 2018

Prototyping is a crucial step in creating high-quality products or features. But plenty of organizations choose not to prototype in favor of simply doing what they believe is best. The problem here is that they’re often building the wrong product for the right audience or a great product for the wrong audience. And if what’s built never gets used, how valuable is it really?

Our Machine Learning Team at Figure Eight believes strongly in prototyping. We have myriad solutions currently wending their way through the process with real users helping us along the way. The exercise is always valuable. We always find actionable insights that improve the final solution.

That said, and we mentioned this above, a lot of organizations don’t embrace prototyping. We thought it would be good to walk through the process of why you should be building prototypes and some tips and tricks we’ve learned along the way. We’ll start with the most holistic question of all:

Do I need a prototype?

In short, yes. Successful products often start with prototypes and, in some cases, those prototypes become products themselves.

When building a new product or feature the purpose of a prototype is to validate a hypothesis and assess the value of dedicating real resources to its development. A key concept for prototyping is that it should take a fraction of the effort to build and should illustrate a clear case for additional resources and development. This means that depending on the initial hypothesis a prototype can take many different forms. Not to mention that by validating–or disproving–the initial claims as early as possible, you can optimize where you spend valuable resources.

Let’s imagine that a team is looking to create a pet tracker called PetEye that will monitor your pet and help ensure that they are happy and healthy. The need here seems straightforward: pet owners care a great deal about their pets and often treat them as family. The team did their due diligence and surveyed pet owners to see if they would like a way of knowing how their pets were doing in real time and received an overwhelmingly positive response, along with hundreds of people expressing interest in the first available product.

Armed with this information the team wants to get to market as quick as possible and immediately begin development on the final product. After 4 months of development they have created an end-to-end monitoring application where pet owners place a specialized camera in their home that can accurately detect a pet’s activity (even when the pet is in a different room!) along with a mobile app that allows the owner to log in anytime and see exactly how their pet is doing. Excited about the new product that has exceeded their expectations in every test they go to market only to find extremely underwhelming adoption. As it turns out, pet owners don’t want to place cameras in their home because they feel like it is an invasion of privacy and ultimately that’s the end of PetEye.

So what happened in our hypothetical? The team did a good job at surveying the market and found that their idea was indeed in demand. However, without building prototypes and validating their solution, they ended up with a product that did not align with the needs of their target audience. Had the team decided to develop a simple prototype and shown this to the end user they could have quickly learned that an in-home camera is not the best way to go and that they must find a solution more suitable for pet owners.

By creating basic prototypes and iterating with end users we can develop products that fit the needs of the target audience and, ultimately, create more successful products. After all, it’s difficult to create a product and even harder to make sure that it has all the right components. Rather than spending time trying to guess what people want and don’t want, the easiest way is to throw a rough version together and test it. More often than not, you’ll learn more about the product through feedback than from sitting in a room trying to make it perfect. Figure out your audience and learn from them as soon as possible.

How do I build a prototype?

Prototypes come in all shapes and sizes and it can be difficult to gauge how much detail is needed. The best way to frame a prototype is to understand the fundamental goals of the end product and then work backwards. What kind of product are you trying to develop? Who are the end users? Why do they want to use this product or feature? These are just a few questions that should help direct the prototype. Once there is a clear understanding of what the final outcome might look like then take incremental steps to test the hypothesis.

It is always good to start with the primary call to action of the new product. What is the major benefit that users will see which they are unable to get from existing products on the market? Is this a completely new product that customers will have to learn how to use? Is your goal to improve upon an existing product and if so how will you convince them to switch over? The purpose of the prototype is to answer these questions and make it very clear to yourself and your target audience that what you are building does indeed warrant production. In this sense, a prototype doesn’t necessarily mean building something that actually works but simulating to an extent the user experience that would come from the product. If you are trying to create a new workflow, instead of building a full system that handles complex use cases, start with a paper prototype and have a small group of people test out your hypothesis. You may find that existing products on the market already cover the use case you are targeting, or you may find that there is a much larger opportunity than you initially imagined.

It is also important to note that prototypes are not limited to a particular type of product or feature. For example, a prototype could be built to test a new type of human-computer interaction. In that case, you’d want to simulate the exact interaction that you are looking to create and understand how users respond. Another prototype might be built to test naming conventions for software modules and a third prototype may be to test a new software development process. The outcome of these three prototypes could be a more mature prototype of a graphical software framework where developers can use touch gestures to build software. After going through this process there should be an understanding of how users would adopt this new platform and the team can evaluate whether or not they should spend 6 months building this product. By working out the unknowns as early as possible, there is a much higher chance of a successful product launch.

Prototypes do not necessarily need to be scalable either. The Wizard of Oz technique is commonly used in prototypes with the premise that rather than building complex systems that are needed to create the full experience, we can fake the interactions by hard-coding scenarios or having a human pretend to be a computer (the wizard, in other words). This will give the end user a rough idea of what the final system might look like without the overhead of developing large and complex systems.

While there is not a single way of building a prototype, there are fundamental principles that we can stick to to ensure that we are making the most of our efforts:

  • Have an understanding of the final product and use that to guide your process along the way.
  • Once there is an end goal, figure out what as many unknowns as you can.
  • Break down the unknowns into small pieces and spend the minimal effort required to answer whether or not your solution may be the right one.

There is certainly no way to know for sure that the shipped product will be successful but if you are able to eliminate or significantly reduce the amount of ambiguity up front, then you have built a successful prototype.

Is User Testing and Feedback Important?

When you build prototypes, your goal should be to validate assumptions you’re making about the final product. Whether it’s building a brand new product, creating a new feature, or even making incremental updates to an existing product, you want to minimize any risk associated with dedicating valuable resources to an initiative.

The best way to get usable feedback is to put your prototypes in front of real users. Presumably, if you’re building a product, there is a particular group of people you are targeting as the primary audience. This group might include smartphone users, the population of a specific region, a particular age group, or even a type of enterprise. Knowing who your “power” users may be will allow you to get to know them and develop your prototype to properly serve those users.

Once you know who will be using the end product, including them periodically throughout the development process will help ensure that what you are developing does indeed solve their problems. In some cases this is done through a formal process with strategic partners or sponsored users. These are people who will likely use the final product and have agreed to become a part of the development process to provide structured feedback. It is common in this case to offer these individuals some benefits such as early access to a beta product or even discounted rates on the final product. The goal of having these sponsored users is to loop them in over the course of ideation, prototyping, and design iterations and understand how you can best solve their problems and make sure that the products and features you create are directly catering to their needs. This will eliminate a lot of guesswork that could cause the project to stray from the ideal solution.

With sponsored users, you can learn a lot about our target audience and clarify unknowns you may have about the way end users will adopt a product. However, you must always make sure to take any feedback with a grain of salt. While end users will often have ideas about what they would like, they are ultimately going to speak from their personal perspective which could be very different from that of other sponsored users and the target audience. Keeping this in mind, the development team should be cognizant of what they are building and find a healthy balance of incorporating user requests with the planned roadmap. The prototyping process is always iterative and keeping a pulse on the market as well as internal goals is likely to lead to an optimal outcome.

Figure Eight and Prototyping

Here at Figure Eight we use prototyping frequently for any sort of development or research project. Human-in-the-Loop is an important piece of creating AI in the real world and it is critical that the tools we put into production are geared towards creating clean, structured data.

Our prototyping process includes hundreds of hours of development, user research, and testing before it is ok’ed for production. By investing time upfront we are able to streamline the production process and ship products that are used by enterprises around the world.

Making AI work in the real world means teaching machines how to effectively carry out tasks typically done by humans while making sure to avoid issues such as biases and overfitting that often plague ML algorithms. We believe in facilitating the creation of a smarter future and that means we must build a future for all. Getting our products right from the start is the only way that we can ensure responsible development, and prototyping is a major key to successful initiatives.

Kiran Vajapey

Kiran Vajapey

Kiran Vajapey is currently an HCI Developer at Figure Eight. He does R&D on machine learning-centric products and works to bring AI into the real world. Over his career, Kiran has worked on products in a number of fields including finance, computer vision, and natural language processing among others. In his free time Kiran dabbles in video production.