...
Severity | Description of Problem | Possible Solutions |
|---|---|---|
Cosmetic | Finding Wishdex.com - One user went to wishdecks.com instead of wishdex.com. | Buy both domains |
Minor | Log In - One had deactivated her Facebook account. She had also let a friend log into Facebook on her computer, so she had to log that friend out first. | Allow users to create an account and then later possibly link to Facebook. |
Major | Log In - Two users were reluctant to sign on using Facebook Connect. We had to reassure them that we were only pulling their full name and their profile picture. | Put a tooltip near the login with a disclaimer that we will not interfere with their Facebook lives or take any personal information. |
Catastrophic | Add Item - One of our users accessed the Anthropologie UK site. Although the item information scraping code works for the US site, it failed for the UK site. | We need to improve the scraping system immensely. This was a warning that unexpected things will break. We should look into APIs and smarter ways to get item data. |
Cosmetic | Edit Item - Every time the user edited the item description, an extra space automatically appeared at the beginning of the item description. | This is clearly a bug. We need to look at the code and if necessary strip the space on the frontend. |
Minor | Share Wishdex - With an item box open, it was difficult to find the "Share Wishdex" button. Many first tried "Item Link." | Ideally, users should be able to share individual items as well as entire Wishdexes. The backend functionality is already built in, we just need to add a button. |
Minor | Share Wishdex - Users clicked on the Share link a few times. They expected more to happen. | We should implement automatic selection and copy pasting, with a tooltip that says "copied." |
Catastrophic | Viewing - A user tried to click on the user's icon next to their comment. However, clicking on their name/image currently does not do anything. This can be potentially confusing or inconvenient for the user. | We can make the user's icon link to that user's Wishdex profile page. |
Major | Move Item - The user clicked on an item and tried to drag it into another Wishdex on the left navigation. | We should implement drag and drop to move items into other Wishdexes. |
Cosmetic | Copy item - Copy item is what we label the button used for the user to copy an item into one of their Wishdexes. The user found "copy" to be a misleading word. She said it implied copy and pasting, such as with a link. | We thought of changing the word "Copy" into the word "Add" with an icon that matched the "Add Item" icon, so maybe users will associate it with adding an item to their own Wishdex. |
Major | Like Item - Two users wanted to see who else had liked an item. | We should implement this. |
Minor | Copy Item - After copying an item from another user's Wishdex into his own Wishdex, the user was redirected to his Wishdex. He said it would be nice to stay on the friend's page. | We are not convinced that all users will feel this way. We would probably run a slightly bigger test to see what people prefer, or maybe implement some way of giving users a choice. |
Cosmetic | Move Item - A user tried to add an item from a different Wishdex by clicking on "Add Item" in the new wishdex. | We felt that drag and drop would probably clear up the confusing around moving items between Wishdexes immensely. We want to avoid implementing this too many times. |
Cosmetic | Explore - One user avoided hovering over the items on the Explore page. Instead, she pressed the arrows on the sides and did not discover the hover function. | One suggestion is to have a tool tip over the items the first time a user visits, telling them to hover over the items. Once a user tries this once, they often remember it. |
Cosmetic | Claim - When trying to go to the item's webpage, one user first thought of clicking the item name. She was hesitant to click "Buy" because she wasn't sure if it would immediately go to the buying page. | We are considering changing the word "Buy" into something more informative, or having the tooltip be visible by default. |
...
Reflection
Discuss what you learned over the course of the The iterative design process . If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observationswas a very rewarding learning experience. The following explains the most important things we learned from each of the phases (corresponding to the GRs), and what we would do differently.
- Project Proposal and Analysis
This phase showed us the importance of developing a clear idea of what we wanted our project to be before we started working on it. User, task, and domain analysis ended up being useful techniques to thinking deeply about the features and scope of the problem we were trying to solve.
If we were to do this phase again, we would try to even more clearly delineate the tasks involved in our project. Although we eventually fixed this, our original attempt at this phase did not produce concrete enough descriptions of each of the tasks. Some reduction of the number of tasks here probably could have helped us focus on building an interface that does a few tasks very well.
- Designs
This phase was significant in realizing that developing the full chain of events a user would go through in using an interface aids thinking about how to maximize usability. Also, resisting the urge to make initial designs too detailed was a difficult but, in the end, important skill to learn.
Spending more time developing ideas for the designs individually before coming together would have been a useful modification in this phase. Our project may have turned out more creative if we had gone through longer iterations of working separately and as a team on the designs.
- Paper Prototyping
As our first interaction with user testing, this phase helped us realize that showing an interface, regardless of how close it is in look and feel to the actual product, is much better method of figuring out how to improve the interface than critiquing it on our own.
Trying to make our prototype more similar in how actions would be performed to what we wanted the final version to be would have been useful in this phase. Usability problems that we had to deal with later could have been found here.
- Computer Prototyping
This phase taught us the importance of not becoming attached to the initial version of the interface. Realizing that the initial versions are meant to be scrapped helped in thinking openly about improvements, both before and after the prototype was shown to users.
Devoting some time at the beginning of this phase for developing some structure for the prototype would have made iterating on it easier. Even the prototype should first be planned before coding begins.
- Implementation
The implementation phase showed us the complexity of building even a seemingly simple interface. The various dependencies between building frontend and backend were difficult to cope with at first, and figuring out how to properly divide tasks even among three people was a good learning experience.
More planning before we started working on this portion would have been beneficial. In particular, deciding from the start the order in which the various features would be implemented and by whom would have reduced problematic dependencies later on.
- User Testing
The final user tests was a reminder that new usability problems can constantly be discovered, even after a product seems polished. In addition, it showed us that different users always find different problems, so testing with a diverse group is important.
More development of the briefing and tasks could have helped to make this phase run more smoothly.
...