Paper prototyping

As we have been saying for quite a while on this blog now, it is vital that every user can understand and use this product instantaneously.
90% of the value for the user is in the interface, and by interface we mean ‘the way you accomplish tasks with a product – what you do and how it responds’ (cf. Jeff Raskin, The Humane Interface).

Work tools for designing an app.
Work tools for designing an app.

Therefore, while planning and developing this app for readers, we have been studying interface design. In initial tests, we began by developing prototypes. In particular, paper prototypes.

Other than our good old Donald Norman and Jeff Raskin, whom we often remember in these posts, Carolyn Snyder’s Paper Prototyping  is a reference point for our work. In fact, following our app for bookstores, we have been following him almost word for word in the development of the new TwoReads product, an app for readers – which we will present to you soon.

In the meantime, let us review our development process of a prototype inspired by Snyder.

– The best way to make an interface user-friendly is to bring the user’s responses to the app as close as possible to development of the interface. For this reason, the primary objective is to begin trials with real users as soon as possible.

–  The two principal qualities to keep in mind during the development of a prototype are simplicity and speed, both in the initial development stages and in modification.
A paper prototype offers optimal speed advantages in in both situations: no coding is involved and modifications can been made in real time, during the tests.

– A noteworthy feature of these prototypes is that they recall drawings of a ten-year-old boy: they are nothing more than rough sketches, which look unfinished, made with a pen on a blank sheet of paper.

In this manner, we encourage user participation in designing concepts and basic functions, which is otherwise limited to aesthetic issues, such as typography and colours – aspects which are absolutely fundamental but which must be dealt with at a later stage. In the words of Carolyn Snyder: ‘you can put lipstic on a pig but it’ll still be a pig’.
In other words, colours, typography and an aesthetically pleasing layout do not save a bad design. You can like the app, but it won’t work.

Furthermore, user trials will clearly show which features will need to be underlined and which will need to be toned down with the use of colours, typography and spacing.

– The principal objective of the prototype is to highlight what won’t work, so that it can be corrected as soon as possible. This is why it doesn’t make much sense to spend too much time refining aspects which will be very quickly changed. Tests must be designed so that they address the experience issues which most worry us. To have users who encounter problemts during the user tests is probably the most interesting and most valuable thing for us.

Five to eight tests are all that’s necessary to provide a detailed list of what are the main problems of the interface; in fact, in the initial stages such as ours, we only need three. Obviously, this is a cyclical process and every three tests we fix the main problems and repeat the process.

The two corner stones of our current work.
The two corner stones of our current work.

– A well conducted test must create specific tasks which bear on the critical points of the project. Therefore, it is fundamental to start by defining the characteristics of the target which will be tested, by planning a series of realistic objectives which reflect real necessities – or supposed ones – by listing all the required steps for the development and by drawing up a prototype.

This sequence allows us to reason on objectives and processes, instead of single functions. We can observe users during this entire procedure, instead of singling out each individual step; it is only by allowing a task to play out to the end that it is possible to view an interface from the point of view of a user.

In concrete terms, a test is designed to describe the final objective of the app to the user and not each individual step necessary to reach it: these he must figure out by himself, by using the interface. Because, the objective is to create an intuitive and logical interface, which shows the relationship between cause and effect of each action.

– In short, paper prototypes are the best tool for shedding light from the very first moment on:

  • concepts;
  • terminology;
  • contents;
  • work flow;
  • logical relationships, such as cause and effect.

An important note: users that carry out a test provides extremely valuable information for development and we owe them our thanks to the time they have lent us. We have decided to give a free book to each of our volunteers, in order to create a link between tasks and “final payment”.

A technical footnote: it is advantageous to prepare an explanatory piece of paper and a disclaimer for the use of the data and material which is gathered. In some cases it is also worth suggesting to have volunteers sign a non-disclosure agreement for the material which will be seen (we have skipped this second point).


And what about the new TwoReads app? We already have a paper prototype at hand. The next steps will include the completion of backend development – which is being followed by Lorenzo and is already at an advanced stage – the development of the frontend and lastly, graphic design. But we will update you soon with more news.

Paper Proto TwoReads

Leave a Reply