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.
For this module, we were to take the paper prototype created for Module 4 and put that physical, interactive object to the test‐to the user tests, that is. User testing is an integral part of any prototyping process, as it helps to identify bugs or flaws in the system and demystify any ambiguities in the interface and design. Smashing Magazine suggests that you utilize paper prototypes early on in the design process "before undertaking your initial design", using low- and high-fidelity clickable prototypes during the digital prototyping phase, and then refining what you've built at the end of the process. The important (and beautiful) thing about prototypes is that they're supposed to be rough drafts that help you finalize the masterpiece at the end of the road. As an argument for utilizing paper prototypes, the Mozilla Case Study (yes, for the browser Mozilla Firefox) helped the design process immensely, as the team was able to develop "7 versions over the course of 2 weeks".
To summarize a major point of UsabilityGeek's article on "Paper Prototyping as a Usability Testing Technique", there are two major uses of paper prototypes:
To Communicate Ideas
Between designers, developers, users, and other stakeholders in the first stages of the user-centered design process
As a Usability Testing Technique
To observe the human interaction with user interfaces even before these interfaces are designed and developed
As per the Smashing Magazine (referenced above) article "A Comprehensive Guide to User Testing," another important point to note about usability testing is that it's "far better to run some usability testing, using what you have on hand, than to run no testing at all". If you gather as much feedback as you possibly can, as early as you possibly can, then you'll be able to fix and clean up whatever you're working on that much faster. The earlier you identify the problems your prototype has, the quicker (and less expensive) they are to fix. Here's a general checklist for determining early problems in your prototype via user testing:
- Identify if users are able to complete specific tasks successfully
- Establish how efficiently users can undertake predetermined tasks
- Pinpoint changes to the design that might need to be made to address any shortcomings to improve performance
- Does the product work effectively?
- Do users enjoy using the product?
Be sure to include the following people when performing your usability testing (via UsabilityGeek):
"5 users should be able to identify about 85% of all usability problems", Jakob Nielsen
These people will interact with paper version of the user interface that is being tested.
This person records the issues raised during the meeting; they may need to probe into the issues raised so that these are well documented.
May need to mediate between presenters.
A Human Computer
This person manipulates the paper prototype so that it can provide feedback based on the user's interaction.
No hints or explanations are to be given; the facilitator leaves users alone to perform the tasks they have been assigned.
Members of the development team who will observe and interpret the user’s interactions with the paper prototype.
Speaking of including specific people in your usability tests, you should develop a solid test plan that outlines your usability test. Create use cases in this test plan for your users to try and perform by interacting with the prototype. However, if something goes wrong, it's the software's fault; not the user's.
This test plan should also incorporate you establishing clear criteria for recruiting participants: it's important that your participants share the characteristics of your typical customers. Make sure to get permission from each user, and have a record of each usability test that you run.
Where and When?
Find a quiet space that you can welcome your test participants and make them feel at ease, but make sure this space is large enough to allow for facilitators and some observers.
You only have so much time to both perform usability tests (large-scale time commitment) and test with individuals (small-scale time commitment), so focus on the important aspects that you need to address. You should also specify what you'll be testing, say the navigation system(s), or the e-commerce flow. With this in mind, you might want to run a series of different usability tests, each with a particular focus on a single aspect—if the design is complex/has multiple moving parts.
The rule of thumb is to allocate 30–60 minutes per participants. However, you should incorporate/include sufficient time between tests to allow for discussion amongst the team immediately following a particular test (since the information and feedback will be fresh in their minds).
You should prepare and be able to record or capture the session in some form (ideally using video). Using video helps to record oral user feedback while also capturing physical aspects such as facial gestures, body language, etc.
Creating a Script
Focus your mind on what exactly you're testing so that your usability test doesn't drift/remains focused. Maintain and ensure cnocistency across multiple test participants, but also remember to put your user's mind at ease—remind them that you're testing the product, not them. Clearly articulate the different goals that you're testing, and also talk about different user scenarios.
Gathered from Harvard Business Review, UsabilityGeek, and Smashing Magazine:
- Each iterative test generates little bits of data
- Enables involvement of developers, designers, users, and other stakeholders very early on (even before design/coding has been implemented)
- Client will see reaction of users become more positive as their feedback is incorporated into the next iteration (and, thus, the client cannot help but become more confident in the design as user becomes more pleased)
- Provides forward-looking designers in creating new ideas and their clients with proof of concept
- Very cheap (cheaper than engaging a designer to create mockups of the UI/developer to code a prototype)
- Paper is cheaper than software needed to create simulations of design mockups
- Identifies problems before any design/development has commenced
- And sharing of ideas across a multidisciplinary team that would otherwise have great difficulty in doing so
- Not coded; simply hand drawn, eliminating need to be drawn by a graphic designer
- Requires less human/financial resources than prototyping/interface testing techniques
- Quickly prototyped/tested; facilitate the quick introduction of modifications and refinements needed to address any usability problems that have been identified
- Annotations can be written on sticky notes and stuck to the prototypes
- Will assist designers/developers when they are creating the actual system
- Endorsed by several usability professionals (and successfully applied for the past 30 years)
Lastly, here are some lasting impressions that paper prototypes had on Mozilla:
Frequent changes are better when testing prototypes
- Give each design more time in front of users, which allows for more evolution to occur
- In-house teams should test a few new design ideas each week
Test alternative designs early
- Allows best design components to be used on fewer pages as testing progresses
Be consistent with fidelity, size, and colorspace
- High-fidelity screenshot cutouts of interface elements didn’t work well in this test because colors attracted too much attention on predominantly grayscale pages
As a refresher, here are the paper protoype screens from Module 4.
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
User Testing Plan
For this usability test, I will recruit 3-5 users (timing is an issue, especially for coworkers; Rich is the one person I can always get a hold of, since we live together—thankfully). All users will use the POP clickable prototype, and this is because the purpose of user testing is to create as simple an experience as possible. Given the task at hand, I believe that using an interactive version of a paper prototype that functions almost exactly the same as how the app would will yield the best results.
User Testing Tasks
Since this app is pretty straightforward in its information and its purpose, I came up with three relatively simple (but insightful) tasks for the users to perform:
- Log into the app
- Add some funds to your QCard (now that you've logged in)
- Peruse the app in order to find information that is either pertinent or would be helpful to you
User Testing Results
The first thing I noticed about testing the prototpe is that, because I talk about my work and the things I do with Rich so much, he was the only one who understood the prototype. I think for future tests I need to actually present the Visual Key to the volunteers and users. In one part of Test 2, my volunteer thought what I had sketched out on the page was completetly different than what it was—this person thought my circles with X's (which are supposed to be representations for graphics that will be added in later) were supposed to be accordion buttons.
Other than that, I learned two things from my users—two things I was already previous aware of, but made me laugh to watch in action. There are two types of people: those who hate using apps, and those who enjoy them. Although Rich and I fit into the former group, my two other volunteers fall into the latter category. Rich and I are the kinds of people who, because of our technical background and aptitude, will find exactly what we're looking for in the matter of a few, short minutes—and would prefer to be on the computer. My other two volunteers are both tech-savvy, but are definitely more open to using mobile apps and are willing to take a bit more time to find what they're looking for (Rich and I like results in seconds, otherwise we try a different search term/query/etc. almost immediately). However, I digress—here are the points I gathered from the tests:
- "Visit" isn't really needed — people who would be using the app would already be admitted
- Should include "Add QCash" option directly to the menu
- Straightforward and easy to use
- Icons look like they're collapsible accordion buttons — I need to include the Visual Key in future usability tests so wireframing items are demystified
- Straightforward and easy to use
- "Make a Payment" — Look into connecting with a third-party payment provider (such as Navient, and connecting the two apps) and be able to check the status of payments directly within the app or have the option to "check/select" your third-party vendor, otherwise have the ability to be taken straight to the appropriate external website
- "Maps & Directions" — Should perhaps be filed under something more relevant, like "Contact Us", "About Us", etc. (perhaps should be implemented on website as well, instead of falling under Graduate)
- "Student Experience" — International students may need two landing pages: one here to give them more info on housing and student life in general, and perhaps this will link to the International page that falls under Admissions (in order for these students to find resources they need about applying)
- Include a top-level "Upcoming Events" calendar landing page for all events, and include filterable buttons for the categories (i.e., "View All", "Admissions", "Undergraduate", "Extracurricular", "Athletics", etc.)
- Difficult to include in the prototype, but a successful login notification should pop up at the top of the screen after the user successfully logs in
- Pro:"I like the Preschedule Payments option"
- Pro:"I like the ability to add favorites to the menu"
- Search functions in all and every context are helpful — should be added
- Pro:"I like and very much appreciate that you make a callout to the military specifically"
To summarize, the things I need to adjust are as follows:
- Potentially remove "Visit" section from logged in users' view
- Add the option to "Select Your Third-Party Payment Provider"/Check status of third-party payment in the app/External link to specific third-party payment provider
- Categorize "Maps & Directions" under wither "About Us" or "Contact Us"
- Perhaps create a separate page uniquely for International students under "Student Experience"
- Add an "Upcoming Events" calendar landing page with filterable content
- Add a Search feature/function
All participants/volunteers consented to being recorded and partaking in the study and signed/dated permission forms.
The password is We1comeM0d5Us3r.
Participant has requested that this video be removed after the time of submission and grading.
Participant has requested that this video be removed after the time of submission and grading.