Paper-in-Screen Prototyping

In many industries, prototyping is an effective way of modeling a system to test it and gather feedback from engineers, other designers, stakeholders and, most importantly, end users.

Practitioners in the UX field are familiar with prototyping when designing physical devices, web, and mobile applications. UX designers can use Flash, HTML, or other robust programming languages to build prototypes that closely resemble the final product, allowing test participants to interact with the prototype more realistically to generate valuable feedback for designers.

Unfortunately, these types of prototypes aren’t generally used early in a product's lifecycle because they can be difficult and slow to produce. UX designers trying to build these prototypes may need the help of software engineers or developers in the team. Besides taking considerable time and effort to create, implementing any changes on these type of prototypes can also be time-consuming.

Low-Fidelity Prototyping

To produce prototypes that are low cost, fast and easy to recreate, designers can turn to low-fidelity prototyping techniques such as paper prototyping. This technique involves creating rough drawings or sketches of interfaces that can be used as models of a design in usability tests. Paper prototyping is practical and useful because it allows for input by end users in early stages of the design cycle. The feedback gathered in these usability tests in turn informs design iterations before a design goes into full production.

But unlike high-fidelity prototypes, paper prototypes lack the context of the physical device the product will ultimately be deployed to. For example, a paper prototype of a website can only be experienced on the piece of paper that it was created on, whereas an HTML/CSS-based prototype can be experienced in a web browser. Paper prototypes also depend on a facilitator to act “as the computer,” changing different states of the UI in response to a participant’s actions.

The lack of physical context of paper prototypes is particularly problematic when designing mobile experiences. Because mobile applications are inside mobile devices, they can be experienced in many possible positions and contexts. Showing prototypes in an unusual setting (such as a flat piece of paper on a table) doesn't give users a full and accurate experience of the design. Simple paper prototypes can test a product's UI and content, but leave much of the broader product experience untested.

If we could replicate more of the mobile user experience using low-fidelity prototypes, we could get more of the feedback that would otherwise be more difficult and take longer to obtain. This can be done using a mixed-fidelity prototyping technique called paper-in-screen prototyping.

What is Paper-in-Screen Prototyping?

The idea behind this technique is simple: place the paper prototype of the mobile application inside the mobile device. This is achieved by adapting images of low-fidelity (paper) prototypes to display on a mobile device’s screen. This allows users to get closer to experiencing aspects of the mobile user experience that are absent with paper UI sketches alone.

This prototyping technique is practical since it leverages prototypes that are likely to have been previously made for testing. If a designer has sketched a number of paper prototypes to conduct a usability test or a heuristic evaluation, these can be easily turned into paper-in-screen prototypes.

These mixed-fidelity prototypes share some important characteristics with paper prototyping. They are still relatively easy to create and discard. They also look “sketchy” and “unfinished,” which allows participants to provide feedback they otherwise might not have shared for fear of criticizing a design that appears to have many hours of work behind it.

Paper-in-screen prototyping and regular paper prototyping both have a similar place in the overall lifecycle of the design of an application. They both allow for quick production testing and iterative design.

How to Create a Paper-in-Screen Prototype

The following are the keys steps to produce a paper-in-screen prototype, taking the design of an iPhone application as an example:

3. Optimize – Edit the digital images so they fit the mobile device being tested.

4. Organize – Organize the images within folders such that they’re in the right order to follow a predetermined scenario. These folders, each containing an individual scenario, are then uploaded to the device. Each folder becomes an “album” of photos in the device.

5. Upload – Transfer the folder(s) to the device.

6. Test – The prototypes are now all in one place, inside the device they were designed to work in.

Testing a Design Using Paper-in-Screen Prototypes

It is important to establish linear scenarios before conducting a test using paper-in-screen prototypes because the prototypes aren’t fully interactive. Test participants should go through a series of pre-defined scenarios during in the same way they would with paper prototypes.

It is evident that paper-in-screen prototypes are not as realistic as high-fidelity prototypes, but they have the important advantage over low-fidelity prototypes in that users can hold the prototype in their hands in the same way they would hold the product in their hands.

Besides bringing a paper prototype to a more adept context of use, this makes it more practical for practitioners to carry all the scenarios and their corresponding prototypes in one place: the mobile device itself.

Visceral, Behavioral, and Reflective Levels of Design

The value of testing a design prototype extends beyond just evaluating UI elements and interactions; behavioral and emotional feedback are also valuable insights that prototypes draw out of test users. Although a paper prototype can allow a user to experience the way an application might look, it doesn’t generate the immediate emotional impact that the product ultimately will. These are things that matter at the visceral level of design, one of the three levels of design (along with behavioral and reflective) that Don Norman explains in his book, Emotional Design. Failing to account for the visceral level of design results in failing to anticipate the real mobile user experience because it dismisses the level of affect, or emotional response, that a prototype could elicit in the participant in a particular context.

Paper-in-screen prototyping also accounts in part for Norman’s behavioral level of design, which should be of main interest to UX professional as it deals directly with interaction and usability. With this prototyping technique, practitioners can easily get closer to contextually relevant behaviors of participants interacting with a low-fidelity prototype that would otherwise not be possible. For example, a paper-in-screen prototype of a mobile application can easily allow a UX designer to see where a participant is placing a finger on the screen, which sections may be getting overlooked, and even how the mobile device is being held.

Paper-in-Screen and UX Practitioners

The benefits of paper-in-screen are clear from a test participant’s perspective. To find out whether UX professionals would find paper-in-screen valuable, this technique was tested with ten UX professionals as part of the study behind my master’s thesis project at Indiana University. The goals were to discover whether this prototyping technique is able to effectively replicate the mobile user experience, and whether UX professionals would be willing to adopt it.

The participants were asked to create design paper prototypes for two scenarios involving a fake iPhone application. For this, they used a pre-made template (shown to the right). After examining the scenarios with the paper prototypes, the participants were introduced to the paper-in-screen technique and shown how to make one step-by-step. Finally, they were able to test their own paper-in-screen prototypes inside an iPhone with the study’s facilitator.

The majority of the UX professionals in the study found paper-in-screen prototyping to be engaging and suitable for early design stages. Some wished it could be even more interactive like higher-fidelity prototypes. However, the most interesting finding was that paper-in-screen was regarded as providing better user feedback compared to paper prototyping, despite being more difficult to achieve.

The perception of better feedback was based on how paper prototypes can’t approximate the mobile user experience as well as paper-in-screen prototypes can. The perception of such better feedback being more difficult to achieve with paper-in-screen prototypes came from the fact that they can’t be annotated or written on in the way paper prototypes can.

As a result, paper-in-screen prototyping falls somewhere between low-fidelity and high-fidelity prototyping in terms of the tradeoff between the richness of the test experience and the rapidity with which prototypes can be created.

Paper-in-screen prototyping also allowed for the discovery of some essential elements than can help simulate the mobile user experience: contextual interaction experience, a better sense of realism, a focus on visceral and behavioral levels of design, the prototype-digitizing speed, and overall interactivity are all key benefits of this mid-fidelity approach.

Paper-in-screen doesn’t come without its drawbacks. This technique requires test participants to follow a predetermined scenario, which leads to a strictly linear experience that inhibits any spontaneous actions. If paper prototypes could be easily scanned into image files with clickable “hot spots” that could be rendered by a mobile browser (displaying the image in full screen), the usefulness of paper-in-screen prototypes would be improved.

Clearly, this prototyping technique could be improved in order to get more realistic feedback from lower-fidelity prototypes. It is important, however, to make sure any modifications of this technique don’t result in making mixed-fidelity prototypes more difficult to create than necessary, or as time consuming to create as full-fledged high-fidelity prototypes.

This technique aims to bridge the gap between low- and high-fidelity prototyping in providing a contextually relevant user experience early during the test of a design idea. From one UX designer to another, I hope you find this technique useful by including in your personal and professional design process.

I would like to formally thank Dr. Davide Bolchini and Dr. Anthony Faiola at IUPUI's School of Informatics for their contribution and assistance on developing this concept.

About the Author(s)

Diego Pulido is an Interaction Designer at Dell in Austin, TX. Prior to moving to Texas, Diego worked as an Interaction Designer at Pearson Education in Indianapolis and as a User Experience Designer at Roundarch in New York. He is passionate about Mobile UX, prototyping and sustainable design. While his background is in humanities, Diego always had a keen interest in technology and web design. It was through the field of Human-Computer Interaction that he was able to bridge the gap between his BA degree in Psychology and French from the University of Nevada, Reno and the world of User Experience Design. He earned a Masters degree in Human-Computer Interaction from Indiana University. You can find him on Twitter: @ixDiego and his website: http://diegopulido.com

Comments

Tony

April 30, 2012

I have mixed feelings on the utility of scanning things like this because it kind of kills off some of the major benefits of paper prototyping. That said:

I'm kind of surprised by a few of the responses, which seem to indicate that sketching in the first place doesn't count as "prototyping" or isn't worthwhile. Paper prototyping is a very accepted way to design something quickly and cheaply so that it can quickly be shown and interacted with by users. Why spend two days building something once a group finally comes to a decision when you can put something together in hours?

It's an intermediate step -- just because you all agree on a sketch isn't enough to move on to something more robust. Paper prototyping's notable benefit is that little time has been invested in it and it requires no real software skills -- anyone can do it, anyone can do it quickly and the drawings can be scrapped without the typical hurt feelings involved in scrapping more final designs.

It prevents expectations that users sometimes have with higher fidelity designs and, more importantly, you can create things completely on the fly right when that user is using the prototypes. You've wasted as little time as possible and often you'll find that users seem to be more honest with something they see as being less "in stone" than anything more robust. Nothing else facilitates this nearly as well, whether you're coding or using a tool like Balsamiq. It's extremely useful when you're trying to work with your users, what they want and what they expect from your site or software -- particularly if the product you're making is something completely new.

Whether you scan in sketches or design something more hi-fidelity in Photoshop etc, give App in Seconds a go. It allows you to launch your mock-up / prototype from the homescreen of the iPhone. All of your sketches or screens can be linked together in an intelligent fashion. No technical knowledge required. Bob's your uncle :)

Nice article! I'd like to add another benefit of this method to the list: having a prototype on a physical device is better suited to contextual situated use than a paper prototype. Especially for testing mobile applications with a strong tie to the context they are used in (augmented reality comes to mind), having your users at 'real' locations with physical devices can result in richer insights, without needing to go for high-fidelity.

I agree paper prototyping is great, but some of the steps here seem slightly long winded. I can't personally see the relevance of scanning and importing to the device – why not just jump straight to hi-fi mockups?

Personally, I think this is a bit wacky to be honest. After all, there are some perfectly great tools available (such as Balsamiq) which can achieve a similar end without resorting to paper and scanning.

More importantly (in my experience) is that once something is purely in the digital domain, it's far easier to modify/clone/adapt/compare/contrast and so forth. So, why even bother with the paper prototypes in the first place? It strikes me to be unnecessary extra work and a good tool - such as Balsamiq, or others such as JustProto or WireframeSketcher - will probably work out even quicker to use than drawings - and avoid the nasty scanning & fixing stage.

Interesting approach, though, and it might just be the 'working pattern' that works for somebody!

I encountered this issue and devised a similar approach three years ago to prototype an iPhone application I was designing. The approach I used differed in a couple of respects from the approach outlined in the article.

1) Instead of creating low fidelity prototypes, I made use of Yahoo's Design Pattern Library for iPhone. With this I was able to quickly lay out the screens, using their OmniGraffle stencil. Since the iPhone was relatively new at the time, being able to mimic iOS felt like an important choice to make.

(Naturally as iOS devices become ever more ubiquitous, this is less necessary, and may even be counterproductive, depending on the project). I imported the flat screens into Axure and created a clickable prototype which was capable of mimicking some of the iPhone's interactions.

2) I generated a prototype from this and embedded it in an iframe, designed to fit exactly to the dimensions of the iPhone's screen. I uploaded the prototype to a server then used Safari on the iPhone to navigate to it. It rendered the prototype in the iframe quite small, but it was a simple matter of zooming it to scale it to the iPhone's screen.

With this approach I was able to test and refine gestural interactions and examine the flow through the application.

Scanning doesn’t make a sketch a prototype. Prototypes are simple models of finished products. You can’t click or touch a sketch. You don’t know how long a sketch will take to implement until you try. Once you have agreement on a sketch, it’s time to move straight to the prototype. That means code. A single screen should take no more than day or two. If you can’t do that, it’s time to buck up and learn your medium.

At Epicenter we've been using this approach inside InVision (http://www.InVisionApp.com), our new prototyping tool (soon to be commercially released). Here's a really quick example we whipped together. It's an app that lets you find movies that are playing back-to-back so you can take in a double feature :)

Love this approach Diego. I especially love the idea of showing hand-drawn materials more often. I've used a similar approach, digitizing and annotating paper prototypes, and found it to be very effective and efficient. I'd love to see an app that allows for hotspot linking between images to make for a more interactive experience. Can we get on that?