Paper Prototyping — How-to, Pros & Cons, and the Struggles of Guerrilla Usability Testing
Lessons learned while prototyping for a new feature using paper.
While working on User Experience at Fiskkit, I had the chance to prototype a new feature we’re working on. To better explain what I was making for a prototype, Fiskkit is a platform where you can comment on your favorite (or least-favorite) articles by “fisking” individual sentences. This means that you can apply any one of a set of pre-determined “tags” as well as your own comment to any one sentence. Example shown below.
Our new feature is allowing the user to be able to “fisk” others’ comments sentence-by-sentence, just as you would a normal sentence in an article on Fiskkit. It’s a completely new commenting system.
This is where paper prototyping comes in.
A quick and inexpensive way of designing and testing a new feature, prototyping with paper was the perfect tool for a startup powered purely by sweat, tears, and blood. (Maybe not blood.)
My plan was to create the paper prototype, and use it for usability tests with the help of strangers in public — the most cost-efficient way for us.
So, how do you make a paper prototype?
A prototype is a model of a product built for demonstration purposes or as part of the development process. A paper prototype is a prototype made with — you guessed it — paper, and it will allow you to test a concept / design fairly quickly and efficiently. The only thing someone needs to be able to do to make a paper prototype is to draw user interfaces with their hand, using some pencils, markers, maybe rulers, or any other items at their disposal.
Step 1. Create sketches / wireframes of the feature you’re working on
Before you get into cutting your paper, you should create sketches of the idea or feature you want to test. This way, you’ll be prepared to cut the right sizes of paper later on. It would also be helpful to finalize your designs (for this stage, anyway), so that you’re certain of the moving pieces that you need.
Step 2. Gather some paper, pens, markers, scissors, and maybe some cardboard if you have them.
If you’re anything like me, you probably have a stack of unused cardboard boxes lying around. No? Just me? Well, you can still make a paper prototype without them.
If you have it, the cardboard can be used for making some sort of backing that will give it a more substantial feel & structure, or allow you to make a physical frame that will simulate the screen you’re building the feature for. If you don’t have cardboards at your disposal, just use paper.
I ended up using the lid of an old shoe box to make a “frame” for my prototype. Because I wanted to simulate a computer screen, the size of the box was perfect. I colored in the border around my “screen” to further simulate the feeling of a computer screen. You don’t have to do this, but it will be easier to take with you than a flimsy piece of paper.
Step 3. Cut out the individual components of your prototype.
The most important thing in this step is to create your individual components as according to your designs and how components will be expected to move around on the “screen”.
Make sure that the individual pieces you’ll be cutting reflect a modular way of presenting your feature. For me, the pieces I was concerned with was “levels” of commenting sections, as well as the actual area where someone writes a comment. Because these parts will be demonstrated to the user on a step-by-step basis, they are separate components cut individually, later moved around on the “screen” where needed.
Example of why modularity will help you — If you’re making an app, and you want to reflect the change from a button’s inactive to active state, you don’t want to have two whole wireframes of the entire page with only the button color being different. You’ll want to create two different paper versions of the button, and replacing the inactive version with the active version when the user clicks — or presses — on it.
Step 4. Play around with your prototype to make sure that you have all the pieces you need for what you want to test
At this point you should have an idea of what you want to test using this paper prototype. It will help to list a few tasks that your user is expected to do. This way the test will be structured, and not just you looking down at your user trying to see if they can find the feature you’re trying to test and fumble around by themselves.
Have a few solid tasks written down. What is the user expected to do when you first present the prototype to them? What are they expected to do next? What is the goal of your usability test? What are you really trying to see? Knowing the entire point of your usability test — what you’re trying to measure — will give you an idea of what tasks you should create.
Run Some Usability Tests!
At this point, you’re ready to run some usability tests! If you’re in the same boat as I am, armed with little to no budget, you’ll probably want to turn to the general public for feedback.
Before you go out to the wild, make sure that you have a partner or two! You will need at least 2 people (3 would be even better), whose roles will be:
- The human computer.
This is the person who responds to the subject’s finger movements by changing up the components of your prototype. If a button is expected to change color when the user clicks (or taps) on it, the computer will change out the piece of paper for the button with the active version.
2. The task prompter / note taker.
If you have enough resources, I’d split this part into two people. One person can read off the list of tasks to the subject, and the other person can observe and take notes. Or, if you’re limited in the number of people who can help out, this can be done by 1 person as well, but they will have to be careful about taking down notes on the specifics of what the test subject says.
Before you go out and ask people to try your prototype, bear in mind two things:
1. Not everyone is your user.
This is hurdle #1 for us when I conducted the usability test guerrilla style with a co-worker. Our target audience are people who comment online often. Out of the people we approached, most of them do not comment online often. Out of those who do and agreed to try our paper prototype, most of them are familiar with commenting online — which was good enough for our purposes.
Granted, testers of our prototype only needed to know how online commenting works, it would have been much more productive to interview people who actually comment often, and who cares about improving online discussions — arguably the ultimate goal of Fiskkit. However, in retrospect, the latter did not make up most of our testers.
2. You will be limited to how much time people can give you
I think this is probably obvious, but it is an important thing to note.
If the user needs to have some sort of background on what your product is, or some knowledge of the interface of the thing you’re trying to test, you’ll need to spend some time (maybe a few minutes) describing the basics of what the user needs to know before you start testing.
For example, we had to explain to our subjects that the “sentences”, or lines representing sentences, were clickable. This translated to the user being able to click — or press with their finger — on them. Without this knowledge, the user wouldn’t have been able to start the tasks at all.
The strategy we took while interviewing our users was to ask them whether they comment online & how often (an important thing we’re trying to record), and telling them that “sentences” are clickable.
Method
In our testing round, we brought out the paper prototype and explained that this was mimicking the screen of a website, and that we have a few tasks we’d like them to try.
We went through the explanation stage rather hastily, but some important things to let your user know include:
1. Ask them to interact with the prototype as if it was the actual device being used
2. Ask them to think out loud during the entire process
3. Tell them to not be afraid to interact with the prototype in ways they see fit as relating to the tasks
4. Tell them that they’re not the ones being tested, the prototype is. If they can’t figure something out, likely there’s some underlying design / usability problems with the prototype, not the user themselves.
All of the above will help you in receiving useful feedback.
If someone clicks on a place you don’t have a drawing for…
If someone interacts with the prototype in a way that you did not expect, or don’t have the necessary components for, ask them what they expect to happen.
The worst thing you can do is to say you haven’t thought of that specific interaction and leave it at that.
By asking the user what they expect to happen, you might be able to find something that you haven’t thought about at all, or a usability problem, or additional insights that you wouldn’t have had realized.
Now you’re ready!
Pros & Cons
Usability tests based on paper prototypes has its pros & cons. While it minimally served our purpose — seeing whether one design of the new comment system is preferable to another, there are issues you need to consider when testing a paper prototype.
CONS:
- People interact with paper differently than they do with actual screens.
Instead of interacting with a mouse and keyboard, they are using their fingers. There is limited context to reflect the actual screen environment the user will be using the feature in the real world.
In our experience, many of our subjects simply verbally told us what they would do — “I’d click on this ‘collapse comments’ link” — rather than interacting with it themselves. This might be due to us not having stressed the fact that they should use it as if they’re using the real feature, but it is a problem nonetheless.
2. There is limited interactivity / context.
Sure, you will be manually changing up the components of your prototype to reflect what happens when user “interacts” with it, but it is simply different from using a responsive application on the internet or on a device.
For example, one thing that is crucial to the Fiskkit environment is the ability for users to hover over sentences and see a change visually, prompting the user to potentially click on it and discover the fisking feature. This is nonexistent in paper prototyping. We were not able to reflect the hover functionality in our prototype, rather, we told our subjects that “sentences are clickable” and inserted in a piece of paper with a highlighted sentence.
In addition, there can be animations that you simply can’t incorporate into a paper prototype. For example, what if we wanted the comments highlighted to move to the top of the commenting area using a fade in effect? There was no way to show this on paper.
To an extent, there simply isn’t enough you can do for a paper prototype that will reflect the exact context the user will be in when they’re using an actual product /app on a device.
All of that aside, there are good scenarios for paper prototyping.
PROS:
- It is a quick, simple, and cost-effective way to mockup an idea at its very very early stage.
Because our idea for the new commenting system is in its early stage, we were able to gain preliminary feedback from potential users on which version of our prototype they preferred. With these data we have some idea of what steps to complete next & what additional research we need to do to create our digital prototype.
2. It’s a good way to show / test ideas that may be simple to complete
If you have a prototype where the user is only required to do a couple simple tasks for you to get an idea of how effective your design is, go for it.
3. You don’t have to write actual code!
If in the process of conducting usability tests with your prototype you realize a huge design mistake, you haven’t cost your company anything! This is better than having your engineering team spending an eternity working on a feature, only to realize a huge design / usability problem afterwards. Another reason for you to never skip usability tests — no matter if you have money or not.
All that being said, paper prototypes have their limitations. It’s an effective way to test an idea in its very early stage, but you will have to move on to a digital / web prototype to get to more significant results.
Thanks for reading! Feel free to tweet / msg / stalk me on the interwebs @sheneral. Or see my work at gaodesigns.com
