Reflection on paper prototyping.

Last Friday (10/10/14) we had our first encounter with paper prototyping. In this blogpost we will reflect on our experience, and the pro's and cons of paper prototyping.
None of us had experience with paper prototyping, thus the whole experience was new for us. So without further ado, a summation of the main pro's and cons, according to three inexperienced paper-prototypers.

Pro's

One of the of the main advantages of using a technique like paper prototyping vs a software implementation, is the speed with which new concepts and ideas for our casual game can be explored and evaluated. Adjustments, as well as complete new ideas, are cheap, resource and time wise. Draw a couple of lines, and you'll have a new pop up box. Think of some additional menu you would like to add? It's just a piece of paper away. The ease with which things are adjusted makes it easy to iterate ideas. Iteration is good. It is impossible to completely plan a big project ahead, without forgetting or misjudging some things. Building a project in small iterations will allow you to discover minor screw ups early on, minimizing the time and effort it takes to fix them. Paper prototyping fits perfectly within this philosophy.

We found that paper prototyping works best when modelling discrete states. Having users interact with a mock up of the interface, will show what they expect in terms of functionality, and what you might have forgotten (apparently users want return buttons). Having users think out loud about what they expect a button to do, helps identifying areas that are vague and should be improved.
Finally paper prototyping is also good for the exploration of ideas. After the main concept has been established by brainstorming, paper prototyping can help discover new ideas, that you wouldn't have thought of without actually interacting with the system. New game mechanics can be inspired by how users expect things to work differently than the developer originally envisioned.

Cons

Once a prototype has to display a dynamic system, it is harder to model with a paper prototype. For example, in the case of our casual game, showing multiple moving object during our game play is more difficult. It is thus harder to verify whether the envisioned game mechanics are actually fun, which is a major part of a casual game. Of course it is still possible to see if users understand the game mechanics, which is important. However when the main appeal of the game should come from the dexterity of the user, it is not a viable tool to see if users enjoy it.

Conclusion

Paper prototyping definitely has its merits. It is a useful tool to explore and evaluate the design of interfaces and game mechanics. It allows the developer to more accurately reason about which parts would work, and which parts require more attention. Improving at this stage in the development cycle is still cheap, thus a lot of iterations can be done. However paper prototyping is not a holy grail. Its limitations show the moment you get more and more different states in which the game can be. The moment you actually want to evaluate the fun of a game, as well as the difficulty, a more refined technique would probably be needed.

That being said, we will definitely be conducting several more paper prototypes with different people. This will hopefully lead to a more polished product, and will save us time, once we get to the actual development process.