Saturday, May 26, 2012

The power of the physical

In my user experience (UX) work, I often need to explore people's reaction to design propositions, and to ascertain whether people can understand and use the proposed product.

In the old days (the 90's and early 00's) it was fairly common to use paper prototypes of online or desktop applications. Producing full-scale interactive versions was relatively time-consuming.

However, prototyping tools arrived, existing tools matured, and UX practitioners learned how to produce more realistic and interactive representations of the products they wanted to test. To some extent, then, the use of paper prototypes diminished. At least, that was the case with my practice.
In developing mobile applications, there's something of a reprise of this trend; prototypes that run on mobile devices may take a little more time and effort to develop, and paper versions are again more common in my repertory.

(At this point, I should nod my head to my Frank Vetere at Melbourne University, who invited me to lecture recently on paper prototypes, and made me take take a slightly more critical look at this topic.)

In general, paper prototypes work well. Participants (the "test subjects") are willing to suspend their disbelief and pretend that a sheet of paper showing a screen, keypad, or whatever, is not just a representation, but the real thing. (Ceci est une pipe, if you like.)

I enjoy this type of prototyping, and it extends beyond the use of paper to represent screens. For example, when testing an interactive voice response and voice recognition system, we used a series of recorded announcements, and played them over a telephone connection at appropriate times to test an online banking application. Participants knew the system wasn't "real", but they behaved as though it was. (This is known as the "Wizard of Oz" technique.)

Recently, I've had reason to run tests with paper prototypes for iPad and iPhone applications. The purely paper form has limitations. In particular, it's not possible for users to explore interactive elements, and the facilitator has to expend significant energy in trying to explore how participants might activate various user interface components. It's difficult to tell whether touchable, draggable or swipe-able elements are recognised as such.

More recently, I was designing an application to run on an Android tablet, and created a very simple physical prototype as a proxy for the device. By cutting a piece of foam board to approximate a tablet device, and covering it with an acetate  "screen", a reasonable facsimile of a tablet device is obtained. Screens can be swapped in and out as participants navigate through the application.

This is not by any means a new technique, but what struck me again was the sense of satisfaction expressed by participants in handling the "device". There was at times almost a delight in the physicality of the prototype. Participants were able to rotate it, play with it, and consider how it would fit in with other tools or devices, and the overall context of use.

At the same time, it was apparent that this was simply a work in progress. It was not invested with any of the permanence or authoritativeness that might be associated with a more polished version. People felt relatively free to make critical comments (all-important during early design).

The few minutes it took to convert a 2-dimensional paper prototype to a 3-dimensional model was well worth the effort in terms of the increased level of engagement it engendered.

If this simple technique piques your interest, I recommend you check out the book Sketching User Experiences: The Workbook, which contains a range of simple exercises you can use to develop your skills in this area.


  1. I'll add in here that tools such as Axure are making it very possible again to get a prototype tested in the full context of the device they own, being Android or iPhone (aka SmartPhone) devices. With great results.

    Also if you have your own widget set with the typical range of buttons forms and navigation elements, the time to create these comes down considerably.

    When i build prototypes this way, I do find you are including a level of feasibility and viability testing when a developer is presented with the prototype during the testing phase. This has help me align functionality and content with the final budgets to make sure the experience is delivered in the required scope and the greatest outcome for the user.

    I still love paper prototyping, however I find there is high demand for tangibility early with clients that sometimes paper doesn't cut it, and as the quote goes "use the right tool for the job."


    1. Indeed. On the iPhone, using something like GoodReader ( can provide a fairly realistic experience from PDFs with hyperlinks (created in Keynote or PowerPoint or Omnigraffle or what-have-you). GoodReader is a snip at $6.