Design
USER ACCOUNT
In the final design, we added a login (with registration for new users) because of feedback we wanted to give users of students they’ve emailed before. We needed this specific to user so we created accounts.
MAIN PAGE
This is the main page of the search system.
In regards to the placement of everything, we hadn’t received any negative feedback and so although we’ve gone through iterative changes, the mains earch page layout has not changed much.
SEARCH INPUT
A lot of the feedback we received from the heuristic evaluation and user testing was that the autocomplete for the search did not do what users expected. Originally we had autocomplete filled with choices to suggest what the user meant. For example when the user typed in “6.813, 6.02” it would drop down with choices of either “6.813 OR 6.02” and “6.813 AND 6.02”. We presented that functionality in a different way (explained below) and left autocomplete to just complete the classes which is what our users expected with autocomplete.
To address the issue of unclear search requirements, we then moved everything to a pop-up that allowed users to select what they meant.
This is now used to clarify symbol confusions: using commas, spaces or such. We realize we still needed this functionality is some form, so we decided to separate it from the autocomplete function otherwise the list of suggestions would be growing exponentially.
HIDE
Another feature we had was the ability to “hide” a student from the list of matches. We added this capability for users who just wanted to clean up the students they had to look through.
We went to several iterations until we gave enough feedback to users. We had the “Undo” button on the top for the most recent “Hide” action. We also had a counter of how many students were hidden at a time on the top right. And clicking that button (which was only enabled when there was at least 1 student hidden) would pop up with a list of students that the user can now restore.
MATCH FILTERING/SORT
From user testing, we received feedback that called for being able to filter by year as well as a more clear way of sorting students. So we added settings that allow user to customize what they see.
One thing we could never get around was a way to distinguish all of the capabilities available, where users can 1. Hide 2. See Details and 3. Email. Only 1 and 2 are available student by student with just one click. Where for 3, emailing, users need to select a student and then click the email function. This is an advantage for users who like to email several students at once and so can go through and continue selecting students in between other actions. The problem is this is a tradeoff for users who like emailing student by student and sometimes is confused by the need to select one student then email, and repeat this process for each student.
The email pop-up hasn’t changed much either but we do make the subject and message fields required in order to send. There is also explicit feedback that what a user types will be saved and then closed with the “Save and Close” button.
Now, not only is there feedback that the email has been sent successfully, but the system also tracks when was the last time a student was emailed. This is the reason why we added the user accounts mentioned above. 
Implementation
Evaluation
Our target user population is professors, administrators and project leads who need to fill positions with qualified and fitting MIT students. We tried to select our users to have different backgrounds. User 1 is an administrator who looks for a variety of students, from all different majors depending on the temporary position she’s looking to fill. User 2 is a MIT professor who works with Media Lab and the Department of Urban Studies and Planning and generally looks for Course 6 students. User 3 is a project lead who works to search for engineering students to fit the program she oversees, generally Course 2 and 6.
Briefing Used
You have been selected to try out a new search system for UROP candidates. You are Professor Smith and you are looking for a UROP student for your project.
1: Register and log in with a email
2: Search for students who have the classes and skills you think they should have.
-Try different combinations until you find what you deem fitting students.
Suggestions:
1. 6.005 or 6.813, and 11.127 with Java or C++ skills
2. 6.813 and 6.01 or 6.02 with big data or Javascript or JQuery skills
3. 2.001 or 2.002, and 2.006 with CAD or AutoCAD, and Solidworks skills
3: Look through some students
4: Hide a few students from the list
5: You change your mind so restore a few
6: Select and email a few students about interview times
Usability Problems
1. Catastrophic: “Resume” button was intended to show a student’s Résumé but a user could think it means resume back to the search screen. (User 1)
Solution: Change the button to display text “Résumé”.
2. Catastrophic: Searching for multiple “and” and “or” in one clause results in one suggestion repeated several times. (User 2)
Solution: Re-examine parser and suggested terms.
3. Major: When new users register an account, the previously entered information is stored in the text field.
Solution: Clear the text fields for registering a new account. (User 1,2,3)
4. Major: If the requirements text field is empty, there is still a popup of Suggested Values.
Solution: Do not have the popup or have it say “You didn’t enter anything!” (User 1,2)
5. Major: User didn’t realize the need to select a student and then e-mail. (Users 1,2)
Solution: Consider that with the hide functionality, the “Email Students” button could be clicked to default email all the students that match. Consider changing the “Email X students” button to say “Email X selected students”.
6. Major: Users don’t have an efficient way of emailing all students that match besides selecting them all one by one. (User 1,3)
Solution: Have a “Select All Students” button.
7. Major: User could not find documentation for learnability. (User 3)
Solution: Consider putting together a “Help” section for website capabilities.
8. Minor: User was misled by “Showing 40 matches” when only 6 were visible at a time. (Users 1,3)
Solution: Consider removing “Showing” or changing it to say “Showing 6 of 40 matches”.
9. Minor: Users can get confused with the inconsistency of having to select a student and then perform the Email action whereas the Hide action can be performed with or without selecting a student. (User 1,3)
Solution: None because of the tradeoff in scenarios where users need to hide in the middle of selecting students to email. Users can’t have freedom to change their minds in the middle of selecting students to e-mail.
10. Minor: Users didn’t know what to expectin clicking the gear icon. They understood it was settings of some somrt but didn’t know if it was view settings, search settings, or other miscellaneous settings. (Users 2,3)
Solution: Adding text to say “Filter/Sort Settings”
11. Minor: Search input beginning with “or” or “and” does not add the respective “or” or “and” clause, but always returns as an “and” clause. (User 2)
Solution: Have the parser account for the case of having an “or” clause before classes.
12. Minor: Users are not stopped in their search when the requirements return no results because they missed the feedback in the match results. (User 3)
Solution: Consider preventing users from adding more requirements if current requirements return none until the user updates the requirements to allow for more matches.
13. Cosmetic: User understands “Courses” requirement to mean either Course as in major or Course as in class. (User 3)
Solution: Consider either using “Classes” or “Subjects” or both.