...

• Efficiency: users don’t have to go to a new page to do edits; they can make changes as they appear. For example, when looking at his profile, a photographer may notice a required change in their 'About Me' section. The photographer can make this change immediately instead of going to a new page, editing one of many fields and clicking save.
• The profile page looks exactly the same for photographers as it does to users. This way, a photographer can see exactly what potential customers would see without having to sign out and view their page as a user.
• However, editable fields are not easily discoverable. We therefore decided to use the following redundant clues to make this feature more apparent:**  Background color changes to yellow upon hovering on editable fields (consistency with Flickr, a website which photographers would be familiar with)**  Cursor changes from pointer to an 'I' bar to signify editability**  Dashed light gray margins around editable areas

Prominent Elements

An important design decision on the photographer's profile page was which fields to make prominent. We opted to have the following elements stand out (tested using the squint test):

...

Since different OSes come bundled with different fonts, getting a web page to look the same across platforms is a challenge. A solution is to use the Core Fonts, or to use generic font names such as “sans serif”, but that severely limits our graphic design palette. By using Google’s Web Fonts, we were able to pick distinctive fonts while ensuring that pages look consistent across platforms. Several of our users commented favorably on our fonts.

Reflections

If you did it again, what would you do differently?

In retrospect, less time We should have been spent implementing the back-end, and more time improving the front-end featuresmore aware of the widgets that are available before deciding on a design. For example, we had wanted the "leave a review" controls to appear in view when the link was clicked. However, if we had known about Jquery UI's dialog, we would have been able to prototype that and would have benefited from user feedback much earlier.

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 dynamism involved a lot more coding  (as opposed to making new static pages), but we took the coding & debugging risk for usability purposesThe primary risk in our site was the extensive use of ajax interactions and in-place events. For example, instead of having a seperate "edit your profile" page for photographers, we allow them to interact with the page inside the page itself. The problem was with making this discoverable and usable (as discussed earlier). It was difficult to prototype this at the paper stage (because things like "hover to change background" is hard to do on a paper). So, there were important things that we couldn't test until we reached the computer prototype stage.

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 all of them tested during the prototype stages. In fact, we were able to test all three of our designs during paper prototype, and come up with two different versions during computer prototype.

Which prototype techniques to use

- Paper prototypeFor paper protoype, we decided to test:        + decided on

• overall look and feel of

...

• the site (e.g. google-esque

...

• look vs kayak-

...

• esque look)
• workflows (how to leave a review? should we have a link always visible or show it only in profile page)

For computer prototype, we decided to test:

• aesthetic choices: fonts, margins, layouts
• use of dialogs
• use of "flash" messages

For the final prototype, we

...

- Computer prototype: decided 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 :

• The quality 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.