When you approach us with a new product concept you want to build with us, the first thing we recommend is starting out by creating a prototype. We are big proponents of prototyping and are constantly improving our tools to make them efficiently and easily accessible for our clients. Here’s why and how we make prototypes.
reasons to prototype
In the prototyping phase we test the best way to execute your idea and figure out what makes your idea into a product. We want to answer questions like
- What is the problem your idea solves?
- What is the core functionality that defines your product?
- How does it work?
Prototyping is a process of figuring out what your product is as much as it is a process of deciding what it is not.
The prototoping phase is also the best time to get new ideas, test them, and fail. If a feature or its implementation doesn’t seem to work in the prototype, we can just rework it or scrap it spending somewhere between 15 minutes to an hour on it. Compare this to a day of work if we had implemented it during development, and prototyping starts to make a lot of sense.
A prototype also serves as a better specification for developers than a written documentation. The developer can instantly see in the prototype how the user interface is envisioned to work, instead of making their own assumptions based on a documentation. Again, we save time as the developer can just concentrate on implementing the already thought-out features.
think about these things before you start working on a prototype
Users. Decide who you are targeting with your product. If possible, write down a short story of how those people would use your product.
Goals. It is absolutely necessary to set wanted outcomes for your prototype before starting to work on it. Here are some goals you might think of:
- Testing your idea with users
- Building a spec for the first version
- Having something to show when looking for funding
Priorities. The goals above can all be achieved with one prototype, but your priorities may affect which parts of the prototype we allocate our resources to. Are we showing all the possible interactions in the product, or are we putting extra detail on the visuals?
how are our prototypes made?
One big question when starting a new prototype is whether to make a paper, an image-based prototype like InVision or an HTML prototype.
The problems we see with InVision and paper prototypes are that implementing changes can take a lot of work. For example, if you have to change a place of a button that appears on four different views, you may have to end up re-drawing the view or a part of it four times. Especially very interaction heavy prototypes can become really resource-intensive.
We usually build our prototypes with either Middleman or Carpentry and use Heroku as our hosting solution. The prototyping environment is usually up in a matter of minutes. We also reuse partials from our older prototypes to make the process even more efficient as time goes on. The prototypes are usually written purely in HTML and CSS, but we have also done React components in some cases to improve the user experience.
Another reason why we prefer HTML prototypes over InVision or paper is the quality of feedback.
With an HTML prototype we can just put our prototype to Heroku and you as the client can check the results when you have time – even when it’s still work in progress. Getting constant feedback from our clients is valuable and should never be left to the last minute. Continuous feedback helps us build shared understanding of the product we are building together.
This doesn’t mean that InVision doesn’t offer a good solution for gathering feedback or that that there’s no place for these types of prototypes. We definitely see the value in what they’re offering. We do draw wireframes and do light paper prototyping at times when creating prototypes and InVision is a great tool if you want to create a purely visual prototype without any coding. Also with Invision users can input their feedback directly on specific view or element.
But when we’re not only testing the idea but the whole user experience, even small changes matter. And when it comes to small changes, HTML prototypes have proven to be the most efficient to build. HTML prototypes also enable us to do responsive views as well as reuse a lot of the done work directly in the actual development. With HTML you get a realistic prototype that interacts with you the way a real-life application would. The quality of feedback we get from this is more valuable that the feedback we would get from static images of views. As Stephen Hay puts it:
In addition to all that, with HTML prototypes we save time and other resources as we don’t need to set up long testing sessions where we go through the prototype step by step. Or as in paper prototype’s case, schedule a meeting where a designer has to operate the prototype’s interactions every time it gets tested. We want the user interface to speak for itself.
Prototyping is ultimately a tool for making better products. It helps you see clearly what the core of your idea is. It’s a possibility to test whether your users are interested in your concepts and to improve them before you have invested your precious time and resources on developing them into a product. You can pinpoint the possible challenges in development and tackle them before they become an issue, and make a more accurate estimation on how much realizing your ideas would really cost.