...
Task / Design Images | Storyboard | Usability Analysis |
|---|---|---|
Uploading wardrobe | In order to upload his wardrobe, Sylvester uses the mobile application. When he opens the application he is presented with the sign in page (if he wanted to register he would have had to have done so on the website). Upon signing in, he is brought to the phone's proprietary camera interface. He takes a photo of an item of clothing, and is brought to a page with a thumbnail of the image and the option to accept or retake the photo. No matter what he selects, he is directed back to the camera. If he chooses "Upload" the photo is uploaded to his account, and if he chooses "Retake" the image is discarded. | This mobile app for taking pictures offers some strong learnability, has good safety, but lacks efficiency. The mobile app is separate from the web app, which can be confusing, but otherwise takes advantages of previously used interfaces: we use the built-in camera phone interface, and limit the options to a few, clearly labeled buttons. While an uploaded item cannot be taken out of the wardrobe on the mobile app, any poorly taken pictures can be discarded and redone. The biggest problems are in the efficiency: each picture requires multiple steps to be uploaded, and must later be tagged in the web app. While some of this inefficiency cannot be removed under current constraints (each article of clothing needs a distinct image for use, after all), it is noteworthy. |
Requesting advice | On the homepage, Sylvester chooses "Ask For Advice" and a simple window pops up where he can request advice and add details to give context for the request. He requests for advice about what he should wear to impress the girl, adds a few details about the girl, and hits "Ask". | Requesting advice on this web interface is fairly straightforward. The system is learnable, fairly efficient, but not very safe. The button to access the requesting advice page is well labeled and has strong affordance, but is similar to other buttons on the page and therefore doesn't scan differently than the other buttons. The request interface itself is very simple, with two text fields and two buttons. The lack of tagging makes it very efficient to make a request, and a user can make as many requests as they have with ease. However, once a user commits a request to the system, it cannot be removed: requests will exist in the system indefinitely in this design. |
Browsing requests | Felicity and Sylvester visit the homepage. They see Sylvester's request at the top of the list under both the "Friends" and "Everyone" tabs (for Sylvester his is also shown under the "Me" tab). Requests are organized by date added, most recent at the top of the list. Because the system relies on a scenario with quick turn around, we have prioritized organizing by date submitted in order to encourage people to post advice on the most recent requests. | Browsing requests on this web interface is very learnable, very safe, but only moderately efficient. The main page dedicates much of the screen real-estate to the scrollable list of requests, each of which pops when moused over. Clicking on the highlighted request moves to the specific request's page - strong affordances here improve the learnability. The request's page has limited options on the page, as well as a familiar scrolling window and up/down vote mechanics for rating existing responses. Moving about the browsing regions (forwards and backwards) is easy and reversible, guaranteeing safety. Efficiency is compromised by a lack of tagging in the previous section, as there is now no easy way to sort through the list of requests. Efficiency at looking through responses is a little better, as they are ranked by popularity (net number of up votes), but still lacks an efficient searching mechanism. |
Creating an outfit | Felicity selects "Answer" on the comment page, and is brought to the outfit creation page. There she is able to add items to the wardrobe. The left panel is a selection of labels, organized and presented entirely visually. Types of clothing include items like t-shirts, dresses, neckties, etc. When she selects to narrow by a filter, the rightmost pane displays all items in Sylvester's wardrobe that fall under that category. In this example, she has narrowed down the selection to neckwear. | Creating an outfit with the web interface is a task that is mixed in all of its qualities: some elements are learnable, others are efficient, and others still are safe, but nothing really provides everything desired at once. Articles of clothing are sorted by part of the body, and are dragged to that part of the mannequin to show to others, which is learnable. There is also continuous visual representation of the drag & drop actions, informing users of exactly what actions they are taking. However, viewing parts of the wardrobe with each of the icons on the other side is not immediately obvious - the interaction isn't learnable. Similarly, the inability to show layered clothing breaks the continuous representation down. The process of creating an outfit involves many steps, all of which are easily reversed (clothing can be deleted easily, different menus can be opened with a single click), making the system safe in the short run. But once the response is posted, it is static - updating and deletion isn't applied yet, reducing safety in the long run. The lack of shortcuts and other efficiency-increasing elements means that behavior is fairly static - once the menus can be navigated competently, an expert user won't find additional efficiency in this design. |
Browsing a response to a previous request | In order to browse answers to his own requests, Sylvester can visit the page for his request as shown earlier in the storyboard under "Browsing requests." When an answer is selected (the thumbnail clicked), a window opens with a larger view of the outfit. | The interface doesn't change after a user has made a response; the analysis of the browsing structure is repeated here for completeness: |
...