Design
Documents
Tasks
Companies
Groups
Contacts
Notes
Login
Implementation
Evaluation
((((((( note from jmelot - have organized this into three sections until Will makes it into prose or whatever )))))))
Users:
- course 6 junior at MIT
- course 5 sophomore at MIT
- high school CS teacher
Tasks: (copied and pasted from email - will let you figure out the formatting)Log in using your email address
Add a new Company, "BBN"
Add a new Document, "resume" (which is a file on your computer) and link it with BBN
Add a new Contact to BBN, "Jane Doe jdoe@bbn.com"
Add a Task called "Cover Letter" for BBN due 5/15/11
View all upcoming tasks
Delete the "Cover Letter" task for BBN
Usability issues:
The "view all tasks" task seems universally difficult, but that could just be because you don't have to actually do much other than navigate back to the homepage and look (also our user has only one company by the end of the user test, so in some sense they could make a case that they are viewing all companies when they look at the company page!).
Users seem to feel that they need to fill out all fields in the Add Company and Add Task forms (not really a usability issue though, maybe)
The "home" and "add document" icons seem to be somewhat invisible - some users take a long time to notice them.
The meaning of the "home" icon wasn't clear to one user, and he thought the "logout" icon was for backing up to a previous page.
One user got confused and tried to add a document with the "add task" button.
One user thought the editable text boxes were confusing.
The "are you sure you want to leave" alert can confuse users when they don't understand why they were prompted by that message.
One user wanted the "details" link to be on the same horizontal line as the delete icon for the companies on the company page.
Some users thought that the "details" link was too small, and accidentally expanded the company view when they were trying to go to the company page.
One user tried to click on the initial gray text in the company box to try to add a company.
The purpose of a "task" was unclear to a couple of users.
One user went back to the company page for the "delete the Cover Letter task" task, instead of staying on the main page to do it.
Reflection (or lessons learned)
Give users as much rope as possible - but don't let them hang themselves.
We found that users do not always know what is best for themselves. Our design once included groups, which were displayed with user-chosen colors. Users could chose any color from a color swatch - their freedom was enormous! We imagined users carefully picking colors that were easy to distinguish.
Instead, this happened:
As at least two of our heuristic evaluations commented, some color choices make the name of the company incredibly difficult to read. Our testers weren't employing the careful consideration we'd imagined, and our interface lost usability.
We know now that a better way to implement the colors would have been to give our users more help in not making this sort of mistake - perhaps automatically adjusting the font color, or restricting the colors to those that make a black font readable, or showing the user a preview. User freedom takes more planning than we thought!
The more testing, the better.
We noticed that our testers varied dramatically in their ability to interact with the interface. Some sailed through our tasks like they'd been using the interface for months; others made many mistakes. Similarly some of our evaluators were alone in disliking certain aspects of our interface strongly. While some individuals raised very helpful points on their own, we found that most of our major changes came about as a result of noticing trends in the way people interacted with our interface.
Prioritize what your target users actually want - let "wouldn't that be cool?" features come later.
Our "groups" again provide a good example of where we went wrong. In our initial computer prototype, we spent a fair bit of time implementing groups, only to find that our testers and evaluators found them confusing and unhelpful. When we interviewed potential users of what they would like in a system like JobTracker, not one of them mentioned wanting a way to group companies. We thought it would be helpful, but it wasn't, and our time could have been better spent by providing more useful (and requested) features.
The iterative design process actually works - and you could probably use another iteration...
Over the semester, we saw JobTracker greatly improve and significantly evolve as a result of the feedback we got on each iteration of the design process. One gratifying comment from our final user testing was "it seems pretty straightforward".
Even so, each iteration seemed to bring on a whole new onslaught of problems. Even now we have a list of improvements for our interface that came up in discussion with our users.
...so make the most of the strengths of each design step.
One mistake we made was on focusing too much on the backend of our interface for our first computer prototype. By the due date, we had a pretty functional interface, but we hadn't put as much effort as we could have into the visual design of our website. Our second computer prototype had a much more polished frontend, but we could still make improvements and might have ended further along if we'd focused our efforts more carefully.