As I've defined in a previous module (Module 1), prototyping is the process of creating a physical, interactive object that can be tested and used for feedback purposes. In regards to the physical plane, a "physical" prototype can be held, touched, seen, etc., and therefore interacted with in a physical sense by the stakeholder(s) in order for them to provide feedback. Rapid prototyping is the process of developing such prototypes at a "rapid" pace coupled with Iteration, which allows for each new version to be better than the previous.
Paper prototyping, however, is the process of making an interactive prototype via traditional "arts & crafts" methods. Using paper prototypes can help you and your users/testers ignore the technical details involved with high-fidelity prototypes, such as colors and fonts. This method of prototyping is also helpful because it is oftentimes easier to explain an idea or concept with a drawing or visual as opposed to mere words, and getting visual allows for an "out-of-ego" experience by all involved in the creative process. According to UX Planet, paper protoypes are useful in the following situations:
- When a designer/product manager is thinking through all the initial ideas running through [her] head
- When outlining the steps in a user flow
- When exploring and validating a variety of layouts
- When showing basic app structure
There are two types of paper prototypes: low-fidelity
prototypes are typically made for you and yourself when brainstorming, but can also be used for internal team discussions. How-fidelity
prototypes, on the other hand, are next-level presentations for when you want your designs displayed in front of users or clients. High-fidelity prototypes include detailed sketches, button shapes, colors, images, etc., and are helpful when having discussions with clients or testing with real users. High-fidelity prototypes are more practical for the design process; this is due to the fact that the more you iterate and flust out ideas on paper, the swifter you'll move with your digital designs in the future.
Moving on to getting started with your paper prototype, Sitepoint
recommends the following materials for the creative process:
- Paper with a grid/dot grid
- Sticky notes
- Pens (Sharpies in different colors and thicknesses are ideal)
- Scissors or a craft/X-Acto knife
- Glue (preferably restickable)
And these are some nice things to also have available:
- Index cards
- Mounting putty
- Adhesive tape (preferably removable to move items around)
- Highlighter pens
- Double-ended marker pens with fine and normal nib tips
- Transparent sheets and markers
- A box for filing/transporting your prototype
A helpful process, according to SitePoint, is to think "outward-in, focusing on increasingly smaller pieces as you go". Those pieces are:
For desktop or laptop prototypes, A4- or US letter-sized paper works best. However, you can also print out a browser frame graphic for a realistic effect.
For a tablet, A5 or US half-letter-sized paper is the primary option for standard devices, but you might want to stick with the above A4/US letter-sized paper for larger devices (i.e., an Apple iPad Pro, 12.9in). You can also create a "dummy" device with the paper as well, which includes sketching out the features of the device (say the home button on an iPad tablet) and slicing into the "device" itself in order to allow your mockup screens and displays to easily slide in and out, therefore creating for an even more realsitic, interactive experience.
Phone devices can be sketched directly onto any standard piece of paper, but SitePoint suggests A5/US half-letter-size paper once again here. On the other hand, index cards or sticky notes can also work with different orientations. Other options include cutting out a phone border to slide "screens" through, as mentioned and suggested above, or you can use a spiral-bound notepad to "flip" through each screen.
When developing the screens for your interactive prototype, start by developing a list from existing works such as user journeys, task models, sitemaps, information architecture, or a functional specification/requirement document—and once you're done gathering your information, start thinking about what the different elements each screen will require.
If your prototype's "big picture" are incomplete, vague, or unavailable, sketching out shapes can be useful for working out high-level details first, such as layout and flow.
These are the interactive touchpoints of your app. An insightful way of going about developing your elements can be guided with the following two questions, via SitePoint:
What needs to happen when a user touches that specific element?
How will users interact with those lements?
Scrolling and Sliding: To emulate scrolling and sliding on a digital screen, you can cut out part of paper prototype in order to thread strips of paper through where the "screen" would be. Threading the paper through horizontally would emulate sliding, whereas vertical would emulate scrolling.
Menus: Pieces of paper can be placed into position to simulate an interaction, or sticky notes can be used (which are great since they hold their position, but are easy to move). However, you can utilize cut outs here as well and slide the menu in and out for a reveal, just like an actual "hamburger" menu.
Messages & Pop-Up Boxes (Modals): Sticky notes are useful for these items since they can be placed, then removed following an action; they even sell sticky notes in the shape of a speech bubble, which can be a creative but practical way for prototyping "text" interactions. Pieces of paper with double-sided tape (or single-sided tape folded into a loop, which would be a lot more practical here) also allow for a more realistic experience, since the tape allows for elevation and shadows (which, according to UX Planet, designers can be real particular [and snobs] about).
Tabs: You can cut tabs out of paper or use index cards.
Accordions: These elements can either call for getting crafty, or you can go the simplistic route. Getting crafty involves some "basic origami," where you literally fold a piece of paper onto itself and create a mock accordion, then label each category/item at the top of the appropriate fold. The simplistic route involves utilizing individual pieces of paper or sticky notes to place on top of the screen or one another.
Slide Up/Down Reveals: The same approach as the other elements can be utilized here: hide/slide in to reveal content, or place the content on a separate card and place it where/when required.
Select Boxes: Sticky notes work well for this element to depict a "moveable" list of items (dropdowns), and can be removed when done.
Checkboxes/Radio Buttons: Simple drawings work perfectly fine, but you can also place "checked" state versions on top of an "unchecked" version following an interaction.
iOS/Android Native Design Elements: This can add visual complexity and eloquence to your prototype, but the best approach here is to take a screenshot of the needed elements or items and print them out—instead of taking the time to painstakingly sketch them out to be as accurate as possible.
Drawing Tips include using simplistic/shorthand wireframing visuals, such as a a rectangle with an X through it to represent an image (or notation in the middle of the X for further clarification of the proposed image), wavy lines for titles, and straight lines for paragraph text. On the other hand, drawing out graphics (even in a crude, underlying sketch fashion) can provide clearer communication to your user/tester.
As a last note to leave you with, here are a few tips & tricks I gathered from Marvel App's blog post, "Stop Sketching and Start Sketching" and UX Planet's (referenced earlier) "The art of UX sketching and paper prototyping":
- Begin with the user.
Vary the fidelity to gain appropriate insights.
- How does each screen of your app fit in with the tasks your user wants to do?
- In what context will your app be used? (I.e., will the user be driving? Running?)
- Does your user need to sign in? Will there be a news feed?
- Starting with your user goals can also help you have initial thoughts about an information architecture.
Exploration exercise: Think across devices.
- Excluding colors, fonts, and interactions can ensure feedback stays high-level and allows for answers about the layout and structure.
- Take an A4 sheet for your desktop screen. How do you design for that?
- Fold it in half—that's your laptop, now. How do you design with less space?
- Fold it in half again. Voila. Now you have a "phablet".
- And in half once more. There's your watch/phone.
Take images of paper sketches and create a digital prototype
- Assign some user roles:
- The User—participates in the test
- The Facilitator—arranges and documents the test
- The Human Computer—moves the paper in reaction to the user's interactions
- Set the scene for the user by telling them their role and setting them a goal to achieve
- As the user interacts with the paper prototypes, the "human computer" moves the paper around as feedback without saying anything, in true computer fashion
Thicker markers for different sections
- Ensures user/client/teammate understands user interaction on the app
- Timers for splash screen and onboarding
- Realistic drop downs (layers)
- Fixed headers/footers
If you have a theme color for the app, use colored papers of that shade
- Start with light grey and add layers of detail with darker markers/pens
Scan your black-and-white sketches and try color variations
- Helps maintain consistency throughout the paper prototype
- Reduces load of manually coloring larger sections
- The earlier you validate "which shade of blue" performs better over another, the better it will be in the long run in terms of project cost, effort, and time
For this low-fidelity prototype, I did not use mocked up graphics or icons, as that would have required more effort than what a low-fidelity paper protoype calls for. In accordance to true "lo-fi" fashio, I also didn't use any colors or markers; however, I did make sure to emphasize certain elements when called for.
Visual Graphical Key
Home Screen, not logged in
User Icon has been pressed; Login Screen
The login screen with both a login error modal and a success modal.
Home Screen after login
Logged in; User Settings and Nav Menu
Nav Menu, logged in and Favorites added and Editing Favorites
Make a Payment and Our Campuses
Maps & Directons
"Our Campuses" can be accessed by pressing the "More Info" buttons on the "Maps & Directions" screens.
Admission and Contact Us
As per the screens provided above, I ordered them (mostly) in the order of a generic user journey. The first two screens ("Home Screen, not logged in") show what the entire home screen looks like to a user who is not logged in. As you can see—and as per my information architecture, defined in Module 2—the items "Update Your Meal Plan", "Make a Payment" and "QCard" are not available. However, the user then signs in within the next three screens ("User Icon has been pressed, Login Screen"); failure and success modals have also been included for authenticity.
After logging in, the three previous mentioned items have now been added to the main screen, and the items (and sizes) have been adjusted accordingly. Once the user has logged in, they can now adjust their settings by pressing the User Icon. The user always had access to the Nav Menu; however, it's shown now with the updated items ("Update Your Meal Plan", "Make a Payment" and "QCard") that would not have been shown previously when the user was not logged in. Adding Favorites is also a feature accessible to users who are not logged in, but I chose to document a signed in user adding favorites for continuity. The user scrolls through the Nav Menu in order to get a feel of what their options are (as you can see, some items—like "Athletics & Recreation" and "International"—have sub-items, and the home screen only shows the top-two-most levels), then decides to add "QCard", "Make a Payment" and "Update Your Meal Plan" to their favorites—in that order. When they press "Done", a success modal pops up and lets them know their checked items have been added successfully to their Favorites menu.
One those items have been added to the Favorites menu, they are removed from the nav menu to reduce redundancy. The user now has the option to remove those items from their Favorites, but simultaneously has the ability to add more favorites.
A lot of the other screens are more informational than anything else, so I decided to document the QCard, Make a Payment, Maps & Directions, Our Campuses, Admissions and Contact Us, and the Undergraduate screens next.
The QCard page is a generic info page, but it also includes a visual clue as to how much money you have left on it—and gives you the ability to add more. A secure screen comes up that allows you to add more money via a saved Credit/Debit card, the external authorization of a Paypal account, or from a new card that can be entered. The user then goes through the motions of adding $15.00 to their card by manually entering the amount, entering the saved card's CVV for secondary authentication/security, then pressing Submit to be greeted by a success modal. In hindsight, I should've probably included information and a screen relevant to the saved card, but that can be added later to either another iteration or to the digital prototype.
Make a Payment works similarly to the QCash interface, but has the added option of scheduling a payment for a later date instead of making an immediate payment. This screen looks similar (and is styled off of) the WebAdvisor "My Tuition & Fee Invoice" page.
Our Campuses is styled with similar aesthetics to the QU website itself, as is Maps & Directions. However, the latter gives you the option to open the external Maps app with the address to the specific campus already entered so you can be on your way.
A lot of the informational pages are styled similarly and with the same information as the QU website, so I wanted to make note of that via the Admission and Contact Us screens (just to give a general idea). Undergraduate acts similarly; however, I removed the admissions (first-year, transfer, international, military, etc.) as to reduce redundancy—and I left them just Admission.