Mock-Paper-Scissors (Paper Prototyping and UX testing)

Beginning the design process by constructing paper mockups allows you to quickly iterate through different ideas and make decisions on what works and what doesn’t in a very cost-effective manner. Additionally, it requires no coding so everyone on the team has an equal opportunity to contribute their ideas to the overall design ofthe project, regardless of their technical background. We’ll start the session with an introduction to paper prototyping, and then you will get a chance to work on designing a tablet-specific user interface. If time allows, we will also do some UX testing of the prototypes. An assortment of pens, colored pencils, sticky notes, etc. will be provided to assist in creating the prototypes.

This outline is meant to be approximate. I expect I may need to change plans on the fly and be flexible in how the class progresses

• 5 min - Brief Introductions of Participants:
  • Name
  • Library
  • 15-30 second description of your group's project & where you are at in the design process.
• 10 min - Overview of Paper Prototyping - I'm going to go through this FAST:
  1. Draw out your interface ideas on paper, index cards, sticky notes, etc.
  2. Test out your interface idea by having someone outside your group try it out (quick user test).
  3. Back to the Drawing Board: Draw out a new interface/change parts of your interface.
  4. Test again.
  5. Continue this cycle until your design stabilizes.
• Keep in mind:
  • Have fun with it! Paper prototyping is primarily a creative process, so get your creativity flowing by trying quirky ideas, using bright colors, using crayons and markers, etc. Most importantly, be positive!
  • It is better to draw than talk.
  • No idea is a bad idea. No idea is a dumb idea. We just discover some work better than others when we test them.
  • When in doubt, test. Paper prototyping, like most design, is an empirical process.
  • Fail early, Fail often! Failure is good! Failure is your Friend! You will learn through failure.
  • Try out many things. It is cheap, and you will quickly figure out what does not work.
  • Bring in your potential users as co-designers. Encourage major feedback. Encourage your potential users to draw out their own interface or interface components if they do not like your interface, or if they are having trouble using your interface.
  • Do not get possessive of your interface, your potential users can tell. Yes, it is your idea, but babies grow and change over time. And they stumble, fall, and scrape their knees. Welcome the change, do not resist it.
• Drawing the Interface:
  • Must: One interface screen per piece of paper. One piece of paper for each interface screen.
  • Draw static interface components on paper.
  • Draw menus, dropdown lists, etc., on sticky notes
  • Draw buttons on stickers
  • Right size it when possible. If you're drawing a mobile interface, cut down your paper to the size of a mobile screen.
  • Use real words instead of scribbles (or lorem ipsum) whenever possible. Words help your potential users understand your interface. They also show difficulties you might run into regarding font size, too much text, etc.
  • Drawn interfaces should be relatively complete as far as covering different possible clicks. But don't overdo it with every combination and permutation of, for example, a search.
  • Use colors, markers, crayons, etc. Have fun with it.
• Running the User Test:
  • Keep quiet until your potential user has completed their first effort at using your interface!
  • No, seriously, don't say a word, don't give them any hints, don't point! Instead, watch them struggle and keep your mouth shut!
  • Take notes instead of talking. The temptation is to say something to help the potential user out when they run into trouble. Instead of saying something, write down that they are having trouble, and describe the trouble they are having in your notes. When they have trouble with your interface, it means your interface needs to be re-designed.
  • Have your users use the Think Aloud Protocol. This means, have them narrate their thoughts and actions as they are struggling to use your interface. It is easy for them to forget to keep talking about their thought process, however, so the only words you are allowed to say are reminders to think aloud.
  • One designer must act as the computer by moving the interface screens around as the potential user interacts with them.
  • There are two strategies for running a user test: (a) prepare a specific task or tasks that you want your users to complete; (b) tell them what the design is for, and let them use it like they normally would. Either approach can work for this. The first approach allows you to test out specific functionality you have designed. The second approach allows you to see what your user wants to do on their own, and whether your interface facilitates their interests/needs/desires effectively or not.
• Why bother with paper prototyping?
  • It is impossible to know ahead of time what a good design is. Paper prototyping allows you to discover a good design instead of trying to think real hard and magically come up with it in a flash of inspiration—there is no such thing as magic!
  • The more you fail, the more you learn, so the goal is to have something testable as quickly and cheaply as possible, so you can iterate through as many versions as possible.
  • Lo-fi prototypes are better than hi-fi prototypes to get quality feedback. Paper prototypes look sketchy, so potential users assume they are malleable, and thus feel empowered to make suggestions. They also have the skill to create their own prototypes—everyone can make a crappy drawing. When you present potential users with a design that looks like a finished product, they all-too-often assume that it is already built and already complete and it is too late for them to give feedback, or that their ideas will cause you too much trouble to redo the design. They are more likely to give you small ideas rather than big design overhauls.
• The in-class exercise:
  1. Pick an interface to design. Ideally, pick something you are actually designing/building. Some of your Group projects should work well for this—anything involving a computer interface whether desktop or mobile should work (ask me if you are not sure how to make your project work). If your project doesn't work, or you don't have enough group members to use your project, then either consider joining someone else's group project, or pick from the following list of ideas, or develop your own:
     • ILEAD U Group Project
     • Library OPAC - When was the last time you saw a good OPAC? How many ideas have you had to make even good OPACs better? Now's your chance! Design a better OPAC!
     • Mobile Conference Navigation App/ILEAD U App - Trying to find your way from workshop to workshop? What are other people doing? How can you find people who share your interests? Design the perfect Conference Navigation App! Pick a particular conference you know well: ALA, ILEAD U, South by Southwest, etc.
     • Cataloging Interface - Catalog a lot of books? Could the process be easier? Design a better cataloging interface!
     • Social Library - Why would patrons want to connect with your library over social media? What benefits would they get? How could various social media like Twitter, Facebook, Linkedin, Google+, etc. fit together? Design a social library interface for computer or phone that puts it all together!
     • Etc.
  2. Find a group of 3-4 people who share your idea or want to do something similar. This might mean joining your existing project group, or finding a new group of people to join. Project groups of 2 are small, project groups of 5 are really big. It is impossible to do paper prototyping effectively with groups of 1 or groups larger than 5.
  3. Discuss your design ideas briefly, then start drawing as quickly as possible. It is tempting to keep talking about your ideas, but talk is cheap, and drawing can be used both as communication, and potentially as a draft interface you can test out.
  4. Solve arguments by drawing. If they can't be resolved that way, solve them by testing. And maybe both ideas are equally good. There's no one right answer to any of this.
  5. Test your interface once you have drawn it. Recruit someone from a nearby group, run them through the interface, record when they run into trouble.
  6. When they have completed the user test, talk to them about their experience, see if they have any suggestions, encourage them to draw their suggestions.
  7. Iterate your design. Redraw the interface. Address the challenges your user faced. Make it better.
  8. Test your design again.
  9. If you have time, iterate your design again.

  During the project time, I will be walking around from group to group so you can ask questions, and I'll try to give suggestions. I'll also push you to start drawing quickly, and start testing quickly, so you have time for at least two iterations. The first iteration should be completed in 20 min, the second in the next 20 min.