DressExchange - GR6 - User Testing

GR 6 - User Testing

Design

The final website for The Dress Exchange was built to be as simple and usable as possible, without falling into the trap of attempting to provide every piece of support which might exist in a retail online shopping site, as this was not the point of the project. The final site had five main pages - Index, Profile, Buy, Sell, and Save; however, Buy and Save had the same generic code, so we'll look at only four, as well as the menu most of them share.

Index

The index page was originally planned as just a placeholder, but we eventually realized through evaluations (and GR5) that people needed more clue as to what the site was about (learnability), and that the index would be the first thing they saw - so it needed to make an impression and actually be usable. Hence, we added a description of the site under the flavor quote and implemented a basic login system, which would be simple but visible.

Profile

The profile was likewise not one of the originally planned pages, but once we began trying to figure out how we would distinguish our design from that of a generic online shopping website, it became somewhat more complex as we tried to implement individual user-based dress selling.

Essentially, each user on our site has a profile page, which can be reached from a link through one of their listed dresses. At the moment, the History section lists all dresses that that user, or you (if on your own profile) has uploaded to the site, but is unfortunately not interactive. We did not want to go into immense detail on the backend, and were concentrating more on making the buying and selling dresses pages usable, so we used a placeholder image for the profile picture and didn't expand user-based information as much as we might have.

Menu/Titlebar

The menu, as illustrated above, is a simple left-justified sidebar that appears on every page after the user is logged in. We designed it with the intention of providing information and access to all parts of the site quickly; hence, all main pages of the site are listed with icons, and the most important information, the currently-logged-in user and his/her number of points available, is listed at the top.

Furthermore, we tried to be consistent with the use of words between the menu and titles. In the menu itself, options are listed mainly as "_verb_ Dress", and the title bars of each page match. While some of our testers appreciated the consistency, others thought the limited variation in menu options were confusing, as the options weren't different enough to pick out at a glance.

Sell Dresses

We conceived of this page as a large form to fill out about a dress the user was trying to sell, and didn't change it much over the course of the design except to make sure it was consistent with the Buy page (color, size, style labels); not many of our users provided much feedback on this page specifically. We did, however, change the picture-to-be-used to a link instead of an image upload, for mostly efficiency reasons.

However, we did try to include an explanation of the points system here, upon realizing that users were confused about how points worked during the user testing of HW2.

Buy/Save Dresses

We wanted to ensure consistency in the site's style and avoid unnecessary excess work, so we used the same template for both buying and saving dresses, only with a color change to make it more clear to the user at a glance which page they were on.

Essentially, this page is similar to that of an online shopping website, with displayed images for individual items, which can be clicked on to expand into a larger preview with more information, including the previously-mentioned color, size, and style values. We limited the number of dresses displayed on one page after users mentioned that the previous iteration (9 dresses) felt too cluttered and difficult to scan, and included variations in shades of grey as backgrounds and highlights, to make certain parts of the page stand out more. This page handles mouse interaction well, to appear more interactive; most items, such as previews or buttons, respond to mouseover with a cursor-hand or a hover effect.

The three "choose which dresses you want to see" buttons result in drop-down lists of checkboxes, which allow a user to select the dresses they want displayed. We used checkboxes to make multiple selection appear more feasible for users, although this eventually became less efficient due to the sheer number of checkboxes required for some items, like color. We also added a "sort by" option when users mentioned that they would have liked to be able to sort displayed dresses, so as to make the search more efficient.

Implementation

Our design was, fundamentally, a shopping site with many listed items which had to have certain pieces of information associated with them, and we ended up using SIPB-provided php script servers and databases to accomplish this. Essentially, all dresses and users are listed in a DB, which is queried for information each time a page is refreshed or loaded. This meant all information we stored on the site had to be as consistent in structure as possible; all dresses had to have certain values (name, price, color, image url, etc.) and all users needed to be similarly represented. This also limited the amount of variation we could have for different types of dresses or items in general, as each new type of item would have necessitated a new table structure. Also, because we were unfamiliar with file upload, we were unable to allow users to simply upload existing pictures of dresses, and had to resort to asking them to type in a link to the dress picture. Some users found this confusing.

While we felt this was the simplest possible implementation, we did run into several difficulties with this backend, especially communication with the server, figuring out occasional PHP foibles, and accounting for lag between requests to the server and returned information. (The latter necessitated the implementation of a "Loading" bar.) Furthermore, our current implementation retrieves every dress stored in the server, and then parses it client-side to show only currently available dresses. While this functioned well for our small test data, it wouldn't be feasible for an actual site that may have thousands of dresses in stock.

Evaluation

We found several users who were were college-aged girls who enjoyed wearing dresses and going to parties (which was our intended user population), all of whom were friends of one of the group members. We provided them with a briefing which included an explanation of the site's intended purpose (getting rid of old dresses, purchasing new ones) and a list of the following tasks:

1. Sign up on the site with a new account,
2. Log in to the site,
3. Sell an existing dress (we suggested a small red knee-high skirt)
4. Save one or several dresses that they found interesting,
5. Buy one of the saved dresses (or more).

Through testing, we came up with the following list of usability problems.

1.  The response message for a user signing up mentioned that an error had occurred, whether or not the sign-up was successful. While we had implemented checking for duplicate usernames, as well as successful confirmation of signing up, a bug seems to have broken this behavior.
   • Major: but fixable if bug is caught.
2. The lack of "submit form on enter" behavior, for the Login form on the index page, lowered users' speed of access for the site because they were forced to use the mouse to navigate to the Login button.
   • Minor: add enter-key detection to the password input.
3. The "Upload a dress" picture on the Sell page changes the cursor to a hand, indicating that it can be clicked on, but it actually does nothing.
   • Cosmetic: we should remove this functionality entirely, as it's misleading.
4. The "Upload a dress" picture is unresponsive even after the user has input a legal URL into the "your dress's photo link here" box, making users wonder if their link would be accepted successfully.
   • Minor: we can add functionality to the picture so that it changes to reflect the user's typed URL, hopefully displaying an image of the dress.
5. One user found the "you will receive __ points_"_ blurb on the Sell Dress page to be confusingly worded, as it didn't indicate clearly how many points would be awarded her, and when.
   • Major: we definitely want to either word the description better or write a separate help page for the site. Or we might include a numerical label next to the "Sell Dress for __ points" input, which shows how many points the user would get and changes when the value the user sets is changed.
6. One user found the Sell Dress form generally confusing to fill out, as she did not know where to start.
   • Minor: perhaps we should change the form to a single column, so that users can fill it out in order.
7. Users found the large number of checkboxes in the 'Color' drop-down filters tedious to click through; although one found the "None" option and used it to uncheck all selections, she didn't seem to realize she could use it while searching for dresses of a certain color, and manually unchecked every color except that one.
   • Major: we may want to allow users to select color ranges instead of individual colors, or change the filters entirely.
8. Users were unable to click on dresses on other users' profile pages, even though they might want to peruse other dresses sold by that user.
   • Major: we should be able to link to the clicked-on dress in the Buy page upon clicking on it in a user's profile.
9. The page numbers on the Buy and Saved pages, for allowing a user to go through the whole list of displayed dresses, are too low to see. This is a visibility issue.
   • Major: users who don't see the page numbers won't realize there are more dresses past the first four, and will be unable to use the site fully. We should move them to above the dresses.
10. The "no picture exists for this dress" placeholder image shows up even if no dress data is present, confusing users.
    • Minor: this is mostly a bug and can be fixed by checking for dress data.
11. One user felt that the provided color, style, and size options were too generic and did not allow her to search dresses based on specific occasions (cocktail party, dance), brand names, or materials.
    • Catastrophic: if our provided search filters don't suit the needs of users of our site, they won't come back. We should expand our dress representations to include those options, and our filters to match.
12. Users were also somewhat slow to learn the menu's use of "Sell Dress", "Buy Dress", and "Saved Dresses", as they were too similar to each other.
    • Minor: since the menu is the primary method of accessing the site's different pages, it ought to be quick to learn. We could change it to "Sell Dress", "Browse Gallery", and "Wishlist" instead.
13. The "History" section of the profile page doesn't show bought dresses, making it difficult for users to figure out what they've got.
    • Major: there ought to be more info available to users in the profile history, to help users recall what they've bought or not.
14. There is no indication anywhere on the site of how long it'll take for the dresses to actually arrive - shipping, etc. No "help" function, either, for people who've forgotten what to do.
    • Major: shipping might not be in the scope of this project, but having info about it, and a help page in general would definitely make our site much more accessible to users.

Reflection

First thing learned: problem-oriented, iterative design is hard. Designers can't simply go into the back room and come out with a finished product, but must listen to the input of the people whose problems their design is meant to solve, even if those people's opinions run directly contrary to good principles and reason - or more likely, designer preferences.

It was both fun and mentally exhausting to try to create a design that relied on existing abstractions, so as to be familiar to users, but wasn't so familiar that it was simply a rehashing of already-seen designs. It was also difficult to test such designs in a paper prototype, because a sufficiently unfamiliar interface requires the designer to think very hard about how to represent its parts in such a way that a new user would be able to understand how it works just by poking around. We did not spend enough time testing out how to implement different interfaces, and as such we may have ended up going with the most generic/general designs we could, without innovating enough.

We also learned that it is best not to try to redesign the wheel, especially in a class with limited time such as this. We had what could be generally regarded as an online shopping site, and many of our users took it that way. As such, they expected to see the amenities of an online shopping site, such as a help section, detailed user profiles, verification e-mails, "forgot password?", recommendations, reviews, and more, and as a result they didn't really pay attention to the problem our site was meant to solve, that of exchanging dresses.

Finally, we should have found more users from our target population. That users preferred searching dresses by materials, brand, and occasion is something that we should have been aware of from the start, instead of simply guessing the most relevant fields.

Had we more time, and now that we have experience, we will first strive to choose a problem with a solution that could be as different from current commonly-used UIs as possible, then talk more closely with the user population to gauge what sort of solution they would want. Only then should we start designing.