...
Observations | Notes |
|---|---|
The user tried to find a ride by filling in the "Post a Ride" form. He realized that he had made a mistake after he pressed the "Post Ride" button and saw the result of the action. | This may be prevented by making the "Find a Ride" and "Post a Ride" labels more prominent (using more noticeable colors, etc). |
The user manipulated the "Find a Ride" form. He couldn't find the ride he wanted because it didn't exist, but he kept narrowing the filter a few more times before realizing that the ride really didn't exist. | A label specifying the number of rides matching the filter (e.g. "_One _ride found on May 17, 2011") may have prevented this. |
When the user posted a new ride, he didn't use the autocomplete feature when he filled in the "From" field, but he did when he filled in the "To" field. | The autocomplete feature is learnable. |
|
|
|
|
After posting a ride, the user was automatically directed to the "Your Rides" tab, which was prepoputated. When he wanted to share the ride, it took him some time to find the one he just posted. | After posting a ride, the user should be directed to a tab showing only the ride he just posted. |
USER #2
The user had no problem at all searching and posting a ride. Her actions exactly followed what we intended.
The user had no problem at all searching and posting a ride. Her actions exactly followed what we intended.
USER #3
Observations | Notes | ||
|---|---|---|---|
When the user filled in the "Post a Ride" form, she asked if it was OK to type only "Logan" (instead of "Logan Airport") in the "To" field. | Users may think that what they put in the "From" and "To" fields will be processed by the system for purposes such as sorting or filtering. Users will eventually realize that the system doesn't actually process the data (other than storing them in the database), so this is not a major problem. | ||
While filling in the "Post a Ride" form, the user accidentally pressed the Enter key, and the unfinished form was posted. | The Enter key shortcut should be eliminated. |
|
|
Reflection
The iterative design process allowed our team to really focus on one stage of development at a time when building our interface. We appreciated that the prototypes we built increased in fidelity as time went on and allowed us to focus on achieving a usable interface as the ultimate goal of the entire project. One of the most important things we gained out of building a paper prototype was the idea to pare down our interface complexity and try to implement something simpler both to improve usability and augment ease of implementation. The computer prototype we built focused on the front end, using canned responses for server queries and trying to make the interface look good. Because our interface was so close to done after the first computer prototype, we could focus on adding the "meat" behind the server calls to populate fields with real data and only make minor adjustments to the UI's look.
...