Skip to main content

Paper Prototypes and Low-cost Prototyping

A paper prototype is exactly what it sounds like: a prototype of a device made out of paper. The point of a paper prototype is to use low-cost materials to make a version of your design to achieve some kind of conceptualization or testing goal. The advantage of literally using paper and other office materials, is that:

  • They are very cheap or free
  • They are very available, usually right at your desk in a nearby bin
  • They can be destroyed and remade quickly and without consequences
  • They materially convey a low-stakes commitment to the current design

Although paper really is one of the best materials to use, in UX design, we also use "paper prototype" to stand in for any kind of low-cost prototype. If it is really easy to make and destroy, then it "counts". If you have a lot of Lego, like we do in COGS 300, then Lego is fine to use as a "paper" prototype material. If it takes hours to recover from a mistake, like with 3D printing, then it would not be a "paper" prototyping material.

The paper prototype is always more than just the physical object itself. Since we are developing interactive systems, the paper prototype must include some kind of operation manual. The operation manual must include an interpretation guide to the prototype's parts, and a script, storyboard, and/or workflow to describe how the prototype operates.

Prototype for the Palm Pilot Some paper prototypes can be incredibly simple. The Palm Pilot (a precursor of modern smartphones) was famously first prototyped as a piece of wood that Jeff Hawkins carried around and pretended to take notes on with a chopstick. The point of that prototype was to answer the question "what would I do if I had a pocket-sized device that could take notes?" and it worked well.

You may need multiple paper prototypes to get to a point where you understand a design. It's not unusual to make a prototype that "feels like" the final product, and another one that "looks like" the final product. The Palm Pilot prototype combined a feels-like prototype (the piece of wood and chopstick) with a looks-like prototype (the piece of paper pasted on the front). A works-like prototype may not have any of the aesthetic design at all, and might be entirely a piece of software.

Prototypes are developed long before the software or mechanical design is anywhere near complete. In fact, the point of a prototype is to advance the design process. Therefore, you have to use some amount of imagination and play-acting to make a paper prototype work. This is called "Wizard-of-Oz", and it means, just like in the story of the Wizard of Oz, you make something act better than it really is. This is a core part of prototyping, and it's not just "allowed" but expected that part of your prototype will be not really functional yet.

For this deliverable, you must hand in one "advanced" paper prototype. That is, you might have made many throw-away paper prototypes to get to this deliverable, but the one you'll hand in should be after you've redesigned a couple of times. Potentially, it might literally be two or three paper prototypes that work together. Therefore, you will hand in any combination of:

  • Sketches
  • Moodboards
  • Looks-like prototypes
  • Feels-like prototypes
  • Works-like prototypes
  • Wizard-of-oz workflows
  • Written scripts
  • Video prototypes and demos
  • Storyboards

Since you will not have acquired your final electronics yet, your works-like prototype may be human-actuated, and your sensors and logic may be wizard-of-oz. However, your prototype(s) should be as close to your final project as possible without the electronics.

Take some time to review the paper prototypes that your classmates and COGS 300 alumni have made that are sitting on the shelf. Make note of the best practices: which prototypes are merely illustrative vs. could be used for making a clear plan for building something?

The point of this exercise is to not just try something, but to really plan your project. For example, you can say that every pin in the prototype will be a motor, but you cannot say that you will have "some number of motors". You should work out, using your paper prototype(s), the exact number of motors that you will need. Your annotated BOM should be a real drawing of your final product with the parts labeled.

Can your project evolve? Absolutely. We expect it to. This is not your final commitment. However, you should treat this prototype as the real plan. Real enough to base a budget off of it.

Requirements​

At absolute minimum, you will need to hand in and demonstrate (during lab):

  1. At least one physically-constructed 3D paper prototype
  2. An operations manual, which includes:
  • A short summary of the concept and purpose of the prototype
  • Any supporting materials needed to understand the concept
  • An operations guide such as a script, storyboard, or workflow
  • A completed first draft BOM that includes an annotated sketch of your parts

Note that you are NOT required to hand in a circuit diagram at this stage. You may make one if you find it helpful, but since we're still in the prototyping phase, it isn't always worth the effort to decide now exactly which wires go where.

Rubric​

All handed-in project items will be marked on clarity and completeness individually, and the overall handin will be marked on quality. These are defined as:

  • Completeness: would we reasonably be able to construct and run this project given just your handed-in materials? Is every component you plan to use present and accounted for? Does the documentation fully illustrate all of the possible interactions for your device? Etc.
  • Clarity: Is it easy to read and understand your documentation? Are the lines neat? Do you use multiple colours or patterns to indicate different parts? Did you use a ruler? Did you care to cut things straight? Etc.
  • Quality: Is the idea workable and conceptually complete? Could you reasonably finish this by the end of the term? Are there clear pathways to success if you encounter failures? Are you illustrating or working from course concepts reasonably well? Is this a coherent idea rather than a mix of random thoughts? Remember that we value a simple, well-executed project over a complex project.