Entries in methods (1)


paper prototype

Paper prototype is a usual method used in testing design concept with end user. It is often recommended to designer as there is not much technique barrier - paper, scissors, pens for drawing and post-it notes are pretty enough for the task. I used paper-prototype in different contexts: signage design, web design and even in writing and teaching.

For those who are not familiar with the concept, here is a fairly self-explain YouTube video:

My recent paper prototype test was last week, testing two sets of user journey for a client project. The functionality is relatively simple; the focus is mainly on how user may read different elements on a screen and what their expectations are after finishing task on each screen.


Some reflections here: 

  1. think of realistic test stories and a lot of them
    Like any type of testing methods, paper prototype is only one of a set of tools to interact with your participant and probe information. Paper prototype lets the user to experience a story and try to interact with the proposed system in means as intuitive to them as possible. Good setting allows participant to really engage with the story you propose, thus, may leads to more validate test results.

    For example, I tested a jounry happens after the user purchased a number of things from one place. So my example is Tesco, and I mocked up a Tesco shopping list to help user to get themselves into the role and related the test case to their normal daily interactions, even though the test itself has nothing to do with Tesco.

    Prepare for a number of story lines, and make sure your design template is flexible enough to allow different scenario to happen naturally. Make a lot of small bits that can be replaced quickly is a good tip, also, maybe colour code different bits according to different storylines so you won’t lose count during the test.

  2. pilot with a number of people before go out to real test
    Test the test - this may sounds a bit funny but really key. I piloted it with 4 before I move on to real users, and again this is a very small test I did. In pilots, you learn two things (at least): 1) get familiar with your script. Especially while testing complicated tasks playing the role of a system and record user interaction as a solo tester requires a number of rehearse; 2) it reveals user reaction that you have not covered in the script. As designer, we become blind to the interface we designed. It always takes someone else to spot the most stupid mistakes. Also, it gives the tester a chance get a sense of how user might wish to interact with your setting and how easy they can follow your script. Do they wish to write or draw on your prototype? Would you need different colour coded paper for different path? Pilot gives you chance to think and learn by doing.

  3. prepare for extra sketch on the set
    No matter how well you prepare, there will be things pop up totally off the script. If the user suggested some interaction that I have not considered, then extra paper for sketch some scenario on the set might be helpful. I actually like these moments, as it is often very inspirations moments. I prefer to let these moment push the boundary a bit – letting user dominant the story and play along with the participant until we are seriously off the script. That is when the meaty stuff comes out. Forcing participants back to the script can make good test efficiency, but it might stop them from telling me what they honestly think, and start to treat the session as test to themselves - which should never be the point of any type of user testing. Again, a balance tricky for any tester, often the situation depend whether it is as inspirational piece you are working on, or you just want a clear answer: A or B?

  4. think carefully about how to collect and record user feedback 
    To be honest, I did not film my test often, sometimes due to short preparation time and more often I knew I won't have time to go through them afterwards. But if it is a piece of work involves different tester and might require review in the future, filming is always worth it. Personally, I find that I try to listen more carefully if I know there won't be a chance to go through the interview/session again. Well, I know many won’t agree and I welcome debate... What I do think any tester should spend some good time consider carefully before going into a test is how you want to let your participant give you feedback.

    Some prefer to test in silence because it represents a more realistic and objective interaction a user can have with the system. It allows the user to make decisions without influence from the tester. Then tester and participant can have an review on the session and ask couple of questions to clarify certain points. I tend to use probe questions during the test, but try not to give away too much answers in the conversations. I found these small talks build a trust between the participant and tester, thus they tend to reveal more about their doubts and thoughts. Whichever way, make as less influence on participant’s decision-making as possible.

    Personally, I likes to make small notes on the set, even when there are filming on set, to remind myself of ideas or to check out certain point user rise. Also, I put aside a lot time after each test to make reflective notes. For estimate, a 20 minute test, I will leave at least 10 minutes for notes taking after each session when my memory is still fresh and stimulated by the conversations. If there is a queue of participants, don’t forget to count the note-making time in.

  5. reduce information noise
    Remove elements from the paper prototype that will distract participants. Having said that I would let user go off the script, it does not mean let things get in the way. Paper prototype is so easy to create, it is hard to resist the attempt to add another link somewhere on page, even if you have not thought through what that link does or why it is on that particular page… reduce information noise sounds like a tricky business, but actually really easy to be spotted in pilot test, and all you need is to cut things off the page!


 I am no expert in paper prototyping, but I picked it up totally by accident thanks to student project I did back in my Masters at Dundee University. For those who wants to look more into this as a technique, Wikipedia is a good place to start. There is also a book devoted for this one technique. Also, it appears often here and there in all sorts of collection of design tools: e.g. Service Design Tools <- my favourite!

Also, found this brilliant step-by-step how to make your iPhone paper prototype – can’t wait to try out so give me a iPhone project please :)

My colleague just showed me this fab little toolkit for paper prototyping from UXPin  - I am happy with my post-it notes, but their kit does look very professional!