Prototyping for user research is a major consideration of product development and one that often confuses, because it’s not an exact science. There’s always a question of what to test and when, and there’s no one “right answer.”

At the start of most research projects, you don’t have a finished product and you don’t have the product you really want to test, so what and when should you test? A lot of user research starts with generative research — which is seeking unmet needs to reveal opportunities; and, on the other end of the development process, you have evaluative research and summative testing. This is when you have a finished product and you want to make sure people will use it correctly to accomplish the tasks the product was intended for.

Every product development team must make myriad decisions about their design along the path from idea generation to validation. Selecting the right prototype, deciding what you need to learn from testing, and deciding when you are going to test is critical to ensuring your development is appropriately informed and driven by user inputs.

Although it’s true that there’s no single correct approach, here are nine thoughts to consider as you refine your prototyping strategy:

1. Even feedback on a “bad” prototype is more information than no feedback. It’s not easy for all designers to feel good about showing somebody a product (or a sketch or a mockup) when you know it’s not your best work, or when you know it doesn’t fully capture your intentions. But it’s worth fighting the instinct to wait, because, in many cases, testing with incomplete prototypes sooner can be better.

2. Anything can be a prototype. From napkin sketch to sophisticated rendering, from paper versions of wireframes in website design to iPads running sample apps, anything can be a prototype. Be creative.

3. Nothing can be a prototype. Okay, that’s putting it a bit cheekily, but before you worry about all the cost and effort involved in producing a prototype to test, be sure to ask yourself whether you need any prototype at all to stimulate the user feedback and inputs you’re seeking.

4. A related product can be your prototype. You can use a competitive product, a related product, or an earlier generation product as a prototype. Depending on which aspects of the product you’re trying to probe, you can find close analogs to your intended product and get clever about how you design the test to leverage the aspects of those other products that mimic the user interaction you’re testing.

5. A prototype doesn’t need to stop at the product’s edges. Early-stage concepts can be used to simulate space. Anything — an idea, a space — can be prototyped. We often prototype different environments to bring the conversation closer to reality and inspire meaningful discussions.

6. Plan your user research timeline alongside your development timeline. Researchers add a great deal of value throughout the development process — we can help pinpoint the best points during development to test and provide clear goals for that testing. And researchers are important to have around while you’re writing prototype requirements. Before creating a prototype, it’s important to know what you’re trying to learn. 

7. Make more prototypes than you think you’ll need. A general rule is to overestimate the number of prototypes you think you will need by at least twenty percent. Overestimate by more than that if the prototypes are small, fragile, or likely to break. (Testing syringes with fifty users? Make a hundred.) If it’s a highly complex and expensive prototype, make at least two — and be ready to MacGyver small repairs in the field. I have been the one sitting in the observation room of a user testing session, quickly soldering a prototype back together between users. Make extra prototypes especially if you plan to bring them abroad for a study! You’ll want a fallback if your prototype breaks on day one.

Part of planning for testing is planning for your prototypes to get broken. Letting people break the models can be instructive. If you need to interrupt sessions to stop people from breaking a fragile and expensive prototype, you’ll miss opportunities to learn. Sometimes this is necessary, but if user testing is part of the planning when you design a prototype, you can likely make it robust enough to let people interact without fear of destroying your model.

8. Find a user research partner who has easy access to a prototyping workshop. To be shamelessly self-promotional for a sec, one of the benefits of working with a company like ours is that we have a prototyping workshop right next to our usability lab. With prototyping capabilities in-house, we can work miracles (and we have needed to, at times), thanks to our model makers. We can iterate quickly during user research, coming up with a new prototype between sessions or overnight during a multi-day study. Recently we turned around prototypes for a connected home appliance using foam core to fill out the shape and an iPad to stand in for the touchscreen.

9. Prototyping needs will differ based on industry. Testing by companies that develop consumer goods is driven by business risk. Medical device companies are also driven by patient risk. The former may have the freedom to only test specific elements of a device or system, but in medical, a device needs to be tested to ensure safe and effective use, so you’re always going to need to test the complete, final product. At the summative testing stage, the prototype must be production equivalent — which makes it more of a first-run product than a prototype. With consumer and other types of products, you can be a bit looser.

All of these ideas come back to the core principle that product development is most valuable when it’s centered on the user. Product development that is driven by user needs greatly benefits from regular user testing. You don’t need to break the budget to test early and often — you may just need to get creative about how you’re prompting user inputs.

This article was written by Conall Dempsey.