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
Users
The pool of test users are quite representative of the target audience. We built the website mainly targeting college students, and because of this the bulk of the test users were college students. We have two other users that are apart of different populations; while the site was not directly targeting to them, we wanted to make sure that the site was still usable.
The users we tested on are the following:
- course 5 sophomore at MIT
- course 6 junior at MIT
- course 7 junior at MIT
- high school CS teacher
- course 6 MIT alum '06
Briefing
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?
Tasks
The tasks we gave the test users are listed below:
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. We felt a demo would hurt learnability testing for this site, and we wouldn't find out if design choices we made had or had not improved learnability. Since the target audience would not normally get a demo from the designs of the site, we felt that the best way to find out any issues was let test users approach the site the same way we though new users would.
Usability issues
- While not directly a design issue, "View All Tasks" task seems to be universally difficult. It is possible that since there was only one company in the testing environment that all tasks were on that company. One approach to test this would be to add some information on the site, however since we wanted to recreate what a new user would see that would not be the best approach. I think the best approach would have been to add multiple companies and add multiple tasks before given them this task, but since the test users' time was precious we felt that this was probably the best way. 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.
- It wasn't clear which fields on all the forms (Add Company, Add Task, Add Contact) was required, this caused some users to make up information, while others just tried submitting without them. We could resolve this issue by adding (Required) in the placeholder text, or we labels with asterisks could be re-added.
- The icons on the upper left hand corner (Home, Add Document) were hard to locate, and took a long time. One user went to the company details page to add a document, while the majority eventually found the add document button. To fix this issue, it would make sense to move the logo to the top-left corner and move all the other buttons to the top right corner creating a navigation bar. Since most sites use this design, it will be easier for users to find them.
- It was not apparent what the "home" icon did for one user, and the thought the "logout" icon was to get back to the main page. One solution would be to replace the home icon with the Logo and have the logo link back, or to add a back icon on the bottom of the page like some sites.
- The dialog alerting users about unsaved data, confused most users while others just ignored it and clicked through. One possible solution would be to save changes on leaving the page, or to just not save it. The alert itself didn't seem to help convey that something was unsaved.
- "Details" link was
One user thought the editable text boxes were confusing. (Could you clarify this)
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.