...
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. |
Miscellaneous Observations
- The users had no problem using the category buttons and the time slider, indicating that the features are learnable.
- All three users used the Facebook "Share" button instead of the "Share via Email" button.
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.
...