Design
Login Page
Our login screen features a minimalist design, with the JobTracker logo, a brief paragraph on what services JobTracker provides, and a field where users can type their username. We decided to leave out a password field because there is no reason to ask our users to remember a password if we aren't designing for security.
We do, however, require that our users provide a username so that we can load their data! This message appears every time a user tries to login with an empty username.
We ask for a an email address as a username because email addresses are usually unique identifiers which the user has to remember anyway. Our login page, therefore, places little memory burden on the user.
Homepage
Documents
Documents have been reduced in importance as we have iterated our design. In our original design, documents were alongside companies on the homepage. By our first round of paper prototyping, however, we put tasks on the homepage instead, reasoning that users would want to view all their tasks much more frequently than they would want to view all their documents. The "Add Documents" button moved to the top left corner of the page, where it has stayed ever since.
Originally we let users type plaintext documents directly into the "Add Documents" form. By our second iteration of paper prototypes, however, we dispensed with this feature, since our user tests found it to be confusing and because it needlessly complicated our interface.
Tasks
Companies
Groups
Contacts
Notes
Implementation
Evaluation
((((((( note from jmelot - have organized this into three sections until Will makes it into prose or whatever )))))))
Brief:
Hi, I'm _____ and these are my partners _____ and _______.
Thanks for helping us out! We're testing out a system to help people
manage a job search. The system, named JobTracker, is a website that
people can use to manage documents and keep track of tasks related to
their job search.
We'll show you a prototype of the website. You'll get a few index
cards with tasks written on them. Try to execute these tasks on our
prototype. After we start, my partners and I will be taking notes on
how we can improve our interface design.
Remember, this is a test of the interface and not a test of you. The
interface is in a preliminary stage and might have problems that make
it difficult to use. Your input is important to fixing these problems.
While you execute the tasks, feel free to think out loud so we can
understand your thought process. Also, you are free to stop the test
at any time. Before we get started, do you have any questions for me
or my partners?
Users:
- course 7 junior at MIT
- course 6 junior at MIT
- course 5 sophomore at MIT
- high school CS teacher
- course 6 MIT alum '06
The users are quite representative of the populations described in the GR1. We have college students that are still in school with varying levels of technical expertise, but they all are quite familiar with websites and the conventions used on them. We also have users from the different populations listed in GR1, a recent grad looking for a new job will have different demands than a college student looking for an internship. We also have an user who is in the middle of their career, there would be different demands for this user.
Tasks:
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
Demo:
Users were not given a demo besides the initial briefing. We felt a demo would hurt learnability testing for this site. Since a brand new user would not be given a demo beforehand, it's better to test how the user would respond and how they would interpret items on the page.
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!). One user was confused by the word "upcoming", thought that might be different than just viewing all the tasks, tried to use the company selection box, and ended up more confused.
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)
Users couldn't figure out if a field was required or not in the Add Company, Add Task, or Add Contact forms.
The "home" and "add document" icons seem to be somewhat invisible - some users take a long time to notice them. One user went to the company details page to add a document and took awhile to find it.
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.
Alert was ignored by some users, they did not bother to read it.
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.
When you add a document on the company page, the submit button remains disabled until you click outside of the text boxes after filling them in. This is confusing.
One user lost his train of thought after clicking on the "Name" field of the Add Contact form, and then couldn't remember what that box was for.
One user entered dates in directly to the text box and didn't use the date picker. He ended up entering in 5/15/11, which will confuse the database ordering.
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.