On prototyping.

Lately, I’ve been upset with the way that playtesting and prototyping are received in an academic environment. While most designers appreciate the value of getting something reviewed in it’s rough form, others do not. I’m a true believer in prototyping and feel that showing off unfinished products early and often saves you time and headaches. Unfortunately, most people are squeamish when it comes to presenting a work that is unfinished. Even worse is when the people you ask to critique your work expect it to be a finished work of art. I’ve experienced both of these recently and have found that working with these conditions/assumptions can be deconstructive and demoralizing. So? What are we supposed to do about it?

Make sure that they know why you’re prototyping or playtesting.

  • The primary objective of this whole process is to identify problems with your assumptions and implementation. You’re not supposed to get it right the first time. In fact, you probably won’t get it right. Take this opportunity to reflect on how other people interact with your prototype and listen to their feedback. Chances are, if your testers have problems working with your prototype, or would like something else incorporated, there are also others who share that opinion. If you get a lot of negative feedback try not to see it as an attack on your skills. Instead be glad that you can address the issues early on.

Make sure people know that things are going to break.

  • For some reason testers want your prototype to work flawlessly the first time. When playtesting this demand is unreasonable. So, before you start playtesting make sure that you tell your tester things are going to break. In fact, tell them how rough the prototype is. If it crashes, tell them. If it uses stock art, tell them. If you haven’t proofread text, tell them. It’s better to paint a very accurate picture of the current state of the project than to have bugs that you already know about come out during the playtest.

Make sure your tester’s feedback feels wanted.

  • The testers are your friend. Think about it, if it wasn’t for them YOU would have to test the system. This poses a problem because you know the prototype. You know the expected input, and you know how you’re supposed to use your system. Chances are, you will not run into problems that playtesters, who are not familiar with your system, will. If you’re looking for feedback about usability, then there is no better way to get it than with actual users. For all these reasons, make sure your testers feel wanted! Tell them you’d love to hear what they think, and that they’ll be contributing to creating a great project.

Hopefully, when you address the misconceptions you’ll get a lot of mileage out of your playtesting.