Paper Prototyping: Academic Research

The introduction to the book was written by Jakob Nielsen.

There was emphasis on the value that paper prototyping holds: 'any mid-sized design project was probably get a ROI of several thousand percent from following the advice in this book'.

It is cheap, quick and easy. From the HCI module taken in the third year, it has proved invaluable and allows the testing and exploration of ideas without investing time and money in implementing high-fidelity prototypes. It also allows the user to become part of the design team.

'Measured usability can increase by an order of magnitude when it is possible to change the projects basic approach to the problem'.

What I aim to do with the paper prototype today is gage initial responses to the concept, pick up on any basic  problems and explore new ideas from users.

How paper prototyping works:

• choose a user/users
• determine typical tasks that you'd expect this user to do
• next make screen shots/hand-sketched versions of all the menus, windows.... and so on that are needed to perform the task
• it is not necessary to have a working version of the prototype
• a facilitator explains the prototype to users & how to interact with it. They sit next to the users, giving each task and interesting with the user as needed
• the facilitator manipulates the prototype in response to users actions
• questions can be asked by either party

Below is an example of a paper prototype

'What paper prototyping isnt.'

'There are three techniques-comps, wireframes and storyboards-that people confuse with paper prototypes.

• Comps - visual representations- usually of a website =- that show the look of the interface including colours etc
• Wireframes - page layout for a web site, showing what content goes where
• Storyboards - series of drawings that represents how an interface would be used to accomplish a particular task. It's basically a flowchart.

What can be discovered from paper prototyping?

1. Usability issues i.e. confusing concepts, poor terminology, lack of feedback, layout problems, improperly used widgets or any other situation where the users cant get the itnerface to work the way they want.
2. Missing or misspecified functional requirements - Its common for users to have some needs that the product team isn't aware of. The team may have a mistaken assumption about what functionality will satisfy a user requirement. 
3. Preference for one design alternative - sometimes there are different ways to provide a function and through user testing you can find out which users prefer.