Design
The purpose of ShutterConnect is two-fold:
- enables users to find and review photographers based on several criteria.
- allows photographers to create a profile page with their business information, thereby advertising themselves to potential customers.
The website consists of three main pages:
- a homepage, from where users can search for photographers based on criteria such as location, price range or event type. The homepage also allows new users to signup, or log in if they already have accounts.
- a search results page, which displays results of a user's search query.
- a photographer’s profile page, which gives an overview of the photographer’s work. Photographers can also edit their pages.
All the pages have a top horizontal bar that allows redirection back to the homepage.
A detailed discussion of the top bar and the 3 pages follows.
Top Bar
The top bar provides consistency of look and feel across all of ShutterConnect's pages, while also increasing efficiency of navigating back to the homepage. The top bar also allows users to log in or log out in one click.
When designing, we considered using a tab bar with different tasks, such as "find a photographer" and "leave a review". However, we decided to show only the tasks that were applicable to the particular page that a user was viewing. For example, having a "leave a review" tab at the top of the search results page might be confusing to a user. We therefore decided to appeal to the simplicity heuristic.
Homepage
We considered designing and implementing a site with a prominent login page, which required all users to signup before having any access to the website. However, we opted to allow users to have access to as much functionality as possible without being forced to register.
We considered using designs similar to travel websites, but decided that these pages look busy. We therefore opted on a minimal design, which is consistent with sites such as Google's search page that most users are familiar with. We also did not want to present too many options to users right at the outset. Instead, we opted to make it easy to start and show options when necessary.
SearchPage
We considered having a confirmation page in which a user could alter their search parameters before seeing the actual results of the page. However, we decided that it would more efficient if, upon entering a search query, a user saw their results immediately, and then had the option of changing their parameters based on the results received.
Photographer's
Photographer's Profile Page
- We decided to use editable fields instead of forms for logging in. In-place editing using editable fields has the following advantages:
+ 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.
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):
+ Name of photographer
+ Price
+ Sample work
+ Star Rating
+ Section headers (e.g. about me, reviews)
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.
- We decided to use editable fields instead of forms for logging in. In-place editing using editable fields has the following advantages:
+ 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.
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):
+ Name of photographer
+ Price
+ Sample work
+ Star Rating
+ Section headers (e.g. about me, reviews)
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.