Paper Prototyping in the Large

It’s always fun to push the limits of a process and see what it can do. Paper prototyping is our method for testing a design with users. With paper prototypes we discover and fix design problems in the context of use. We build paper prototypes all the time for desktop applications and websites. But recently we’ve pushed the limits of the paper prototyping method in two ways: scaling it down to a prototype cell phone UI and scaling it up to the size of a room. I’d like to share my recent experience with room-sized paper prototyping here.

Why paper prototypes

First, let’s recap why paper prototypes are such an effective technique. There are benefits of paper prototypes that you just can’t get any other way:

• They’re quick to create. Paper prototypes can be sketched with pen and Post-it notes faster than any other prototyping method. You can test design ideas quickly, before you’ve committed to them emotionally.
• They’re portable. Once you’ve built your prototype, you can slide it in a manila envelope and take it anywhere. That means you can take them to your user’s workplace and test them there. You get much better and more detailed feedback when your user has all the reminders associated with their own work practice around them.
• They’re rough. They communicate to the user that this design is a work in progress. They encourage users to focus on basic structure and function, not on the details of the pretty UI.
• They can be changed in the moment. You can modify the prototype to reflect the details of this particular user’s work practice — their tasks, their files, their workgroup. You can also modify the prototype to reflect your user’s feedback — you can try out different design solutions to problems the user raises and see which choices work best.

Different kinds of designs constrain the paper prototyping process in different ways. But however you modify the process, you want to make sure that you don’t lose these advantages.

The design challenge

Recently, I was working with Remmele Engineering, a company based in St. Paul, MN and one of their clients, a manufacturing company. The client is re-designing their manufacturing equipment — a machine 20 feet long and 8 feet high. Each machine is housed in a room with the whole layout of the room structured to support the operator of the machine and the work flow through the room.

Remmele is designing the next generation of this machine. A team of engineers from Remmele and their client worked with us to define the human/machine interface — the panels, buttons, and control station that the operator would use. But they also wanted us to pay attention to the overall structure of the room and workflow through it.

We used a fairly standard Contextual Design process, interviewing operators, supervisors, mechanics, and others interacting with the machine. We built all the different work models but focused on flow, sequence, and physical. We visioned the new machine, built a UE to show the relationship between its parts, and then faced up to the problem of prototyping this new design.

Prototyping a room

How could we prototype not just a machine, but an entire room layout so that we could walk operators and mechanics through their tasks and iterate the design as we did so?

The prototype

We set up one entire room (the room where the new machine would eventually be installed) as a mockup of the new system. The team took pictures of the existing machine with a digital camera, printed them out full-size on 3 ft x 4 ft plotter paper, stuck them to foam core, and hung them from the ceiling. (Modern digital cameras are amazing—even at this level of enlargement you have to get quite close to the paper to see the pixels.) The result was a façade that looked like the existing machine that we could stick our modifications to. Wherever a display panel appeared in the new design, we hung an ordinary paper prototype on this backdrop.

We took similar digital pictures of new elements of the design (a robot, for example), stuck these pictures to a cardboard box, and positioned the box where the robot would go in the new system.

We used a collection of different-sized boxes to represent hoppers and holding bins for other parts of the machine.

We used another sheet of foam core to represent a large electronic display positioned at one end of the room. We made banners for the different messages this display would show, making sure the letters were the size of letters on the real display so that operators would be able to tell if they could read the sign from a distance.

Finally, we mocked up the new operator’s console with foam core and positioned it at the right place in the room. We made sure the height and width were true to the real dimensions to reveal any problems the operator might have seeing the machine over the console.

The process

We tested the mockup by having operators come into the room one by one. Each operator got a quick overview of the new design. We then had them talk us and walk us through tasks as they do them now. Then we re-played that task, introducing features of the new machine and using new elements of the prototype as we went. Each new element prompted a discussion that sometimes led to the re-design of that element. The operator walked through the task, moving around the machine as necessary to accomplish it.

Operators gave us feedback on the physical layout of the machine parts, on the design of the human/machine interface, on the procedures we were planning on putting in place, and on the design of the console and the other stations in the room. They were able to tell us which information they needed at which station and what information to make prominent. We were even able to identify and fix ergonomic problems by watching them interact with parts of the machine.

Lessons learned

This process worked remarkably well. I worried that using the existing machine as a backdrop would over-constrain how operators interacted with the mockup, but that turned out not to be the case. In fact, since we weren’t in the real machine room, it was very valuable to have a picture of the existing machine there. It helped the operators re-situate themselves in the real work and use that as a basis for their feedback.

In the same way, it was very important to have the operators walk us through their tasks their own way first, and then re-play the task in the mockup. That reminded them of all of the details and problems with doing the task, and made it possible for them to explore cases they might not have thought about otherwise.

Making the different parts of the mockup beautiful or even accurate didn’t matter at all — except that it was critical that the dimensions of the different parts be correct. The height of the console, the size of the wall display, the height and orientation of the mechanisms — these all sparked fruitful design discussions.

Some of you may know that the origins of paper prototyping are in work done at Aarhus, where Pella Ehn and Morton Kyng¹ used cardboard mockups to design work environments. With this project, Contextual Design has come full circle, using the CD process to generate the design for the work environment that we then iterated with the people who would live in it.

1. P. Ehn and M. Kyng, “Cardboard Computers: Mocking-it-up or Hands-on the Future,” in Design at Work, J. Greenbaum and M. Kyng (Eds.), p. 169. Hillsdale, NJ: Lawrence Earlbaum Pub. (1991).)