Loud and interactive paper prototyping in requirements elicitation: What is it good for?

Paper prototyping can be used to elicit requirements for user-facing applications or evaluate user interface designs. There are several ways to do paper protoyping. Shakeri, Moazzam, Lo, Lan, Frroku, and Kim investigated how interactive and “loud” paper prototyping can be combined to achieve better results.

Regular and timely feedback from customers allows developers to continuously improve the design of their software applications and avoid design choices that might drive customers away.

A good design is especially important for mobile apps, which have high levels of user interaction and are often used under less than optimal conditions.

Paper prototyping can be a useful way to elicit requirements for such apps. There are several paper prototyping techniques that can be used:

• Sketching simple user interfaces using pencil and paper allows designers to focus on the functionality of each UI element rather than visual aspects that ultimately matter less;

• A storyboard consists of a series of sketched UI snapshots that are represented as a flowchart. This shows how a user can navigate through the app;

• Wizard of Oz allows a customer to interact with a paper prototype. The prototype consists of different sheets of paper that together represent the UI states and elements. Every time the customer performs an action (side note: e.g. presses on a sheet of paper that represents (or resembles) a button), the designer “animates” the prototype by replacing (some) sheets of paper.

The authors conducted a case study with 50 app development student teams, all of which had already gathered an initial set of requirements for their mobile app prior to the study.

Each team was asked to confirm their requirements using one of the following techniques:

• loud paper prototyping, a variant of the Wizard of Oz technique that involves users articulating their thoughts while they navigate through the app;

• silent paper prototyping, a different variant in which users navigate through the app without voicing their thoughts;

• face-to-face meetings only, without interactive prototyping.

Each team was asked how paper prototyping helped them capture requirements for their mobile app. Overall, teams mostly reported effects on changed requirements, usability, and visual presentation.

Paper prototyping helped many teams revise or clarify their functional requirements:

• many requirements were improved, which made it easier to understand what they mean and how they should be implemented;

• a fifth of all teams added new requirements, which in some cases even turned out to be core functionalities;

• some teams modified requirements due to improved understanding of the product;

• a couple of teams removed requirements, as they would not have been effective.

About half of all teams also reported positive effects on the quality of non-functional requirements:

• paper prototyping helped many teams work on the clarity or interaction of their product’s user interface, which led to improved usability, learnability, and navigation;

• observations resulted in new and modified requirements, but no removals.

Loud paper prototyping has a stronger effect on functional requirements than silent paper prototyping and no paper prototyping.

Silent paper prototyping is better at influencing non-functional, UI, and existing requirements. Face-to-face meetings on the other hand are more effective at influencing functional requirements, and adding and removing requirements.

Teams generally liked using interactive prototyping. Most felt that the loud variant was the best way to manage mobile app requirements, as it allowed customers to directly interact with the design.