SoundingBox will end operations on August 1, 2021. Read the announcement. [x]

# Prototyping Guide

Prototyping before coding is quickly becoming a best practice. Let's look at why you want to do it, how to do it well, and how to get the most out of testing your prototypes.

As we covered in our UX Design Guide, a big goal in UX design is to delay the expense of actually building a digital product until the last possible minute. The more you're able to prototype, the lower your final cost of building it will be, with less developer time redoing things you didn't get right the first time. And it isn't just about cost. It's also easier to create products that will finally succeed when you prototype them first since it's easier to make changes and try them out.

Besides reducing cost and improving productivity, prototypes also help with collaboration. Since things are easy to change, you can quickly try out variations and share them, without costing you too much time and effort.

# Why Prototype?

Prototyping is a best practice for the following reasons.

  • Reduce costs - Delay developer time until the UI is fully baked.
  • Easy to change - Quickly try out new ideas.
  • Better collaboration - Easy to share and modify.
  • Get feedback early - Test with real people before you build.

This last point is what we're about here at SoundingBox. Prototyping isn't just about reducing costs and collaboration. It's also about making something you can test with users.


SoundingBox fully supports testing the prototypes created through prototyping tools like InVision, Axure, Figma. Adobe XD and Balsamiq.

# Prototyping Ancient History

To understand why this is so important, let's recall how we used do prototyping before the advent of prototyping platforms. Front end engineers would spend a great deal of time mocking up real HTML and JavaScript to get something resembling a web application prototype. This mockup is what we would test with users. Thankfully, coding up interactive prototypes using HTML and JS has been made obsolete by tools like InVision and Axure. Now you can build your UI—making it look and behave exactly the way it will in its final form—using what amounts to a drawing program—the prototyping tool.

You've worked hard to create your designs, and now it's time to put them in front of the people who matter: the people who will use it. That's where we come in. We support all prototyping platforms so you can get feedback before you build the final version.

# Overcoming Prototyping Reservations

We say that making HTML and JS prototypes as part of a UX design process has been made obsolete by prototyping tools. But this doesn't mean that every organization has adopted them. Many teams and clients still advocate for doing it the old way. They say, "Come on, you mean we have to build it in InVision and then go build it in HTML?—that's duplicating effort!"

Sure it's doing two different activities, separating UI prototype from UI implementation, but it's not duplicating effort. The effort and cost needed to implement a UI in HTML and JS are much more significant than required to create and modify the prototype. Since the two activities operate on different time and cost scales, it makes perfect sense to offload as much work as possible to the cheaper scale (prototyping).

# Prototyping Techniques and Strategies

As we've said, the art of prototyping is to build just enough of the UI so you can collaborate on it and test it. How this works out in practice will vary. There's no one right way to do it. The only mistake you can make is to not prototype at all and start building. That said, there are two general approaches to prototyping that are worth thinking through before you start: low vs. high fidelity prototypes.

# Lo-fi Wireframe Prototypes

Wireframing is the art of specifying a UI without visual design (mostly without color and images). It focuses the team on the arrangement and layout of the UI elements and labeling those elements. There's an argument to be made for starting your prototypes as wireframes and then iterating toward a more fully baked design.

# High Fidelity Prototypes

Many teams skip low-fi prototypes and wireframes altogether and start building their high-fidelity prototypes first. Because your prototyping tool is only a drawing program, it may not take much more time to do your work in high-fi mode, especially if you've done the work of coming up with a design system beforehand. When you've got a design system in place, you do not have to re-invent the wheel every time you need a particular widget, like a dialog box or form element style.

# When to Choose Each Strategy

Here are two guidelines for when to choose a high or low-fi prototyping strategy.

  • Use lo-fi prototypes when you're early in the process, and you're focusing on working out how everything fits together, in terms of views and layouts. And when you're highly focused on naming and labeling items.
  • Use high-fidelity prototypes when you're a little further along and are ready to apply look-and-feel or visual design.

Again, there may not be a penalty for skipping ahead and starting to build your hi-fi prototypes first, especially if you've already got a design system in place.


Sometimes people think that it's hard to do user testing on wireframes. We disagree, especially when you're looking to get feedback on what wireframes do a good job capturing: layout and labeling. Just make sure to note in your task statement that what the tester is looking at is a wireframe, and not fully baked, so you don't end up getting a lot of feedback on the lack of look-and-feel.

# Prototyping Platforms

There is a wide range of prototyping tools available. Two of the first were Axure and InVision. Balsamiq takes the approach of helping you build wireframes. All provide the ability to share your prototype through a share link and be tested on SoundingBox. Read more about that here.

# Testing Prototypes

You're prototyping before building—a best practice. But creating prototypes for collaboration and exploration is sometimes quite different from creating prototypes that you can use for user testing. You can easily convert what you have into a form that works great for user testing. There are a few things to keep in mind when tweaking a prototype to make it suitable for testing.

  • Make them functional, but not excessively so. The art of prototyping is to build just enough. The same applies to get prototypes ready for testers. Make sure that the interactions allow people to complete what you're asking them to do.
  • Test them yourself first. Put yourself in the tester's shoes, and make sure you can't break things. Don't turn your user test into a QA test of your prototype!
  • Make sure people can recover from errors. If there's a way for people to exit the prototype accidentally, make sure there's a path for them to get back.
  • Feel free to let people know it's a prototype. It doesn't hurt to let them know in the task prompt that they're looking at a prototype, and not everything may work. That way, you'll minimize the distraction of people giving you feedback on stuff that's not in scope.


Whatever platform you're using, make sure to turn off people's ability to leave comments in your prototyping tool. You want it to look as close as it can to the final app.

# Working with Prototypes in SoundingBox

SoundingBox fully supports performing user tests on any prototype you make, whatever the platform. The secret is to generate a share URL for your prototype using your platform and add that share URL to your SoundingBox study task. For details about generating the share URL for many of the big prototyping platforms, see our how-to guide to testing prototypes.

# Testing App Prototypes

A prototype for an app that will eventually hit the Apple App Store or Google Play store requires special handling when doing user testing. Unlike websites, apps run in a full-screen context on the device. So when choosing a user testing tool, make sure that it allows for your prototype to be tested on actual devices, with users of that device, running in a full-screen context. Even though you're sharing your prototype to the testing platform using a share URL, you don't want to see a browser address bar or browser navigation. You want your prototype to look as close to how it will look if you had downloaded it from the app store.


SoundingBox makes it easy to test app prototypes on actual devices in a full-screen context.

# Further Reading