Final Project: Designing for UX VI

Phase 3b: Design (On paper prototyping)

Paper prototyping has been a well known and widely used technique to test navigation and usability. However, I'm still curious as to why it is still so successful, even in today's context.

I chanced upon this website that i feel was quite useful. It answered some of our project's issues (and my doubts). Its called, "Five Paper Prototyping Tips" (http://www.uie.com/articles/prototyping_tips/)

Here's the 5 rules/tips mentioned, which i feel is very relevant, and some key takeaways from the site:

1. I’m proficient with HTML. I can create a working prototype fairly quickly. Why would I want to use paper prototyping?

"changes can be made on the fly during a test"
With just an eraser and pencil, changes can be done quickly. What I liken about paper prototype is that, its PORTABLE. It can be tested on the go, on the bus, mrt and places without internet connections etc.

"users feel more comfortable being critical of a paper prototype"
I think it's very true, esp for myself. I will usually not critise people's work, esp when you see them spent so much time and effort doing it. But when presented on paper, it feels more comfortable for me to voice out something that I feel is somewhat not right.

"With paper, all the team members can gather around one table with their eyes on the same design"
Very good point! I'm sure most of the peers experience this. Whenever there's project meeting, and when each of the individuals' lappy is on, there will usually be no focus on discussion. Everyone will be doing their own thing, and usually, one 'facilitator' needs to step up and get everyone's attention. Thus sometimes, I prefer meetings without lappies, or with lappies off. :)

2. How can I use paper mockups to test new technology? Trying to mimic Macromedia Flash using paper mockups sounds like a nightmare—and how would we create rollovers?

"The goal in testing a prototype is to create a usable site"
As the project requires interactivity, we will most likely turn to flash as part of our designing tool. So we faced a similar question on how to present visual that we intended to do, on a paper. Is it necessary? I guess not so, perhaps just a rough one.

"The inability to prototype a fancy effect on paper may be a warning that the effect is not usable"
I kinda 'disagree' though. It might not be usable per se, but it might have additional effects, such as UX.

"Users often choose a link to click on before seeing the associated content in a rollover"
True and not true. Some sites are really straight forward. But there's some whereby the links are actually 'pictures' embedded into the background. I cant help but just move my mouse around the screen and see is there any animations played (indication of a button).

"Paper mockups don’t need to incorporate all the frills of technology"
We will keep this in mind. :)

3. Our product has been up and running for a while. Why go back and create mockups to test an existing product? When should we start from scratch with paper?

(omitted for the purpose of this project)

4. How do you create a prototype that relies on a database? Do you create fake accounts? It seems like a ton of paperwork.

"it’s often impractical to have lots of data available"
As our team proposes a site that has a huge database of car parking info and booking data, i'm glad i read this statement. heh.

"In cases where users must look up data that is not provided in a prototype, we create tasks in such a way that we can predict the data"
As mentioned in the article, make testers do specific items, for our case, a specific car park.

"When a user enters real data into a field and the data needs to appear somewhere else later, we rely on sticky paper"
This will come in handy for stuff like registration page, or booking page.

5. It’s not easy to make links look like links in a prototype. How do you help users identify a link?

"If we see users click something time and again that isn’t a link, it’s clear what’s needed—make it a link"
Biggest takeaway.