...
The following modifications helped ensure that the above fields were indeed prominent:
- sample work: implemented using a widget in which photos were displayed with a black background to stand out from the white page.
- The photographer's name and section headings: are displayed in a larger font and have a lot of surrounding whitespace.
- The photographer's price was displayed in a larger font, and placed in its own column to the right of all other fields.
- In order to make a photographer's ratings, we used color. This was one of the few places where we use color in the page.
Reflections
If you did it again, what would you do differently?
In retrospect, less time should have been spent implementing the back-end, and more time improving the front-end features.
Risk assessments
We decided to implement as much in-site activity as possible and avoid switching pages to give a sense of efficiency and responsiveness to the page. This dynamicism involved a lot more coding (as opposed to making new static pages), but we took the coding & debugging risk for usability purposes.
Decisions about what features to prototype
As far as our paper prototype, we chose not to implement most user feedback messages (upon successful creation of a profile page) and validation symbols (such as during signup) and therefore did not get feedback about this until we user tested our website on some of our classmates.
In addition, most of the validation and instantaneous feedback functionality could not be fully tested until we had a working backend, thereby limiting the range of feedback we received from our test users.
We had four major design features: signup, search, profile creation and viewing, and leaving reviews. It was therefore relatively straightforward to get breadth, if not depth, of implementation for our computer prototype.
Which prototype techniques to use
- Paper prototype:
+ decided on overall look and feel of site,
+ chose between different appearance styles (google-esque minimal look vs kayak-style appearance)
- Computer prototype: decied on colors, fonts, margin choices, layouts, appearance of various dialogs and alert messages.
- Final prototype: added functionality that depended critically on performance of backend. For example
+ the performance of the natural language parser for search determined how flexible we could be with inputs.
+ Instant validation of email addresses/usernames or instant updating of search results based on user criteria would depend on performance of database backend and network latencies.
The paper prototyping exercise was valuable in challenging our assumptions and allowing us to incorporate feedback from multiple test users and realize a hybrid design.
How results of our observations were evaluated
The scoring of cosmetic/minor/major/catastrophic was very helpful in prioritizing which observations we should attend to first. After that, we focused on UI suggestions/problems that came from several users. We also focused on observations that seemed general rather than edge cases as a priority to have the maximum impact on most users. We added a lot of help messages and validation messages to guide users along and cater to all kinds of potential confusions.