Design

Our user interface shifted over time, to become a resume builder that allows users (international students new to the world of resumes) to follow three steps to building the perfect resume that they need to land the job or internship that they are hoping for.

The first step is to input information about themselves, including biographic information, education experience, work experience, and  leadership experience. Each text box has an example of what should be typed, and a helpful hint sometimes pops up if it is needed. Users can add, edit, and delete experiences as they desire. In this portion of the project, the users can put in all of their past experiences. They can later decide which ones to use. This idea is helpful if a user hopes to make multiple different resumes each with different content, they can choose what to keep and what to remove. We initially considered making this part less structured and allowing users to store in this part any thing that they wanted, whether it be a youtube link, pictures, or something else. As we went about the project, we learned early on that people wanted a more structured opening page, where they were told exactly what they needed and how they needed to type it in. The paper prototype showed us that people want the ability to add, delete, and edit on every level. We thought that they should be able to add more experiences in any category, but people also wanted the ability to add or remove comments.

The next step actually involved building a resume. We started with the idea that a resume may contain everything possible and then people can remove what they want. We soon decided that this does not make sense. The process should be one where users build their resumes from scratch, so we decided on a drag and drop interface, where people could drag items from one side of the screen and drop them on the other side. Initially, we allowed users to add whatever they wanted. But then we decided that the resume should be restricted to one page. Thus, we allowed users to make the one page resume, and when the resume was full, they could not add anything more. The paper prototyping showed us that the drag and drop interface was a good idea, but the exact implementation details were only fleshed out when we implemented the interface, and the problems did come out until the heuristic evaluation and user testing. The heuristic evaluation told us a lot about our alignment, and how the page should feel. The user testing showed us exact problems that were more than about look (as described in the user testing section). One issue we found was with how we indicated where one could drag and drop.

The third and the final step was to view the list of made resumes, save them as downloadable PDF’s, and share them  Each resume has three buttons: “Edit”, “Save PDF”, and “Make Public” which makes the resume publicly viewable to recruiters. We did not know exactly where “Edit” should take you, but after asking people in the paper prototyping session, we learned that edit should take you back to the second page. We debated for a long time what the “Make Public” button should be. We thought that it could be a share box, like Google Docs has, which allows you to email your resume to someone. We also thought that it could have a drop down menu asking you what companies you want to share with (and any company on that list had a recruiter who was looking at IvyPlusResumes). Lastly, we thought we could have a button, that when clicked, allowed any recruiter on IvyPlusResumes to look at your resume, We asked users in the paper prototyping session what they wanted, and the third option was the most desirable, so that is what we went with.

Implementation

We used twitter bootstrap to actually develop the UI. We used jQuery UI for some aspects of our implementation, especially involving the dragging, dropping, and sorting features. Our choice to use these well-tested universal frameworks was to ensure consistency among widgets in our design, improve readability using the adaptive layout, and to give us more freedom on tackling our design specific UI challenges. Our initial UI (that was never seen past our eyes) involved making everything from scratch, but we soon realized that in doing that, not everything was consistent, which we learned was a large usability issue. Switching to bootstrap was the crucial decision we made relating to the UI, because by doing that, we had a framework from which to build a consistent, well aligned UI.
We used the Django Python framework for the website backend. This allowed us to handle user authentication, save the complete log of biographic/education/work/leadership details for a user, and select a subset of these details for each resume.
The only issue we found where the implementation and UI did not work together, was in relation to sorting resume items. When we set up our database, sorting items in the resume did not work, because our database was not set up to maintain a sorted list of resume items. However, we felt that the sorting was important enough that we made the appropriate database changes. Also, we could not how to implement a good pdf downloader of the resume, so we implemented a poor resume download that had the correct content and downloaded a pdf, but with the wrong formatting.

Evaluation

We conducted our user test by finding international students at MIT who were new to making a resume. We told each user that this was a new service to help international students who had not built a resume before to build their resumes. We took them to the registration page and told them to please register and start. We asked them to talk through their use of the product, highlighting issues they encountered. We said that if they were not sure what to do, they should try something and then go forward and see what happened. We believed that our UI and hints should guide the process, and that there should not be any experience or instructions needed beforehand. Notes from each of the 4 interviews. We had two freshmen and one sophomore (all who had not built a resume before), and one graduate student who started this year at MIT. We tried to get students from a variety of countries. Each user is listed by his/her country, along with the usability problems found in their session.

Australia

• Wanted to put both MIT course numbers and names under relevant coursework
  • Severity - Cosmetic
  • Solutions - Not necessary, MIT-specific problem
• Confused about whether or not the first task was part of the registration process
  • Severity - Cosmetic
  • Solutions - Pre-populate some fields (e.g. email address); include some feedback at the top of the first page after a new account registration

• Considered moving from Task 2 to Task 3 via the top navigation instead of the “Save” button
  • Severity - Minor
  • Solutions - Some kind of pop-up that prompts the user to save; scroll the page down to the current “Save” section
• The window wasn’t wide enough for the tooltip on page 3
  • Severity - Minor
  • Solutions - Expand the window if possible; open the tooltip to the left only if there is not enough space to the right
• Maybe wanted to share other people’s resumes, community of international students
  • Severity - N/A
  • Solutions - Not a UI consideration, but an interesting concept

Palestine

• Add N/A (Not Applicable) for date selection to graduation year in case of users who are graduate students
  • Severity - Minor
  • Solutions - Adding logic and make UI dynamic to fit this need
• Minimize (or collapse) already filled forms to improve the readability in the first page.
  • Severity - Cosmetic
  • Solutions - Add a collapse/expand buttons for each filled group in the info page.
• Split name into first name/last name to avoid different international naming schemes (in which names may be very long)
  • Severity - Cosmetic
  • Solutions - replace the name field with first name and last name fields
• Really liked the grayed out examples in the input texts before text in entered.
  • Severity - Good
• Tries to sort categories in the resume page (Education, Work, and Leadership),  but it was not possible
  • Severity - Minor
  • Solutions - Add sortability functionality to these categories within the resume
• The “Save Resume” field is placed in the very bottom of the resume page, and so it is very easy to miss it and move to another page with the created resume unsaved
  • Severity - Major (Safety)
  • Solutions - Either detect changes and prevent the user from going anywhere unless “Save Resume” is clicked, or place the save resume at the top for example
• Add a “justify” text property to the displayed text in the resume 
  • Severity - Cosmetic
  • Solutions -  Add CSS property for justify.
• Capitalize fields in case they were typed in lowercase . 
  • Severity - Minor 
  • Solutions - Parse texts and capitalize the parts that need to be capitalized.
• Show scroll only when needed
  • Severity - Cosmetic

Thailand

• Hit backspace when not in a text box and page went back in browser
  • Elaboration - The user tried to hit backspace when not in a textbox and was taken to previous page in the browser. He then came back to the page without using the forward button and lost some work.
  • Severity - Major
  • Solutions - Autosave every few seconds or set the page such that backspace when not in a textbox does nothing.
• No work experience
  • Elaboration - User had no work experience, and he did not like that there was a box asking him to fill in something that he did not have
  • Severity - Cosmetic
  • Solutions - Remove “Work Experience” boxes and let users add more if they desire
• Make sure all text is properly capitalized
  • Severity - Minor 
  • Solutions - Parse text and make sure the text at the beginning of each section is capitalized.
• Not sure what trash can on resume page would do
  • Severity - Minor
  • Solution - Allow user to drag options off the resume as you allow them to drag on (this is what the user tried to do first)
• Confused on how many items to add to resume
  • Elaborating - The user only saw “drag and drop” once per section. After the user dropped an item on the resume in each section, there were no more “drag and drop” boxes. Thus the user thought there should only be one item per section. (The user had never built a resume and thus did not know what resume needed).
  • Severity - Minor
  • Solution - Always have a “drag and drop” box if there is room to add something else to the resume
• “Love the drag and drop”
  • Severity - Good
• “So easy to use”
  • Elaborating - The user said that the product was extremely easy to use, and even though he had never made a resume before, he was able to make one that he would like to use in 15 minutes. He asked when we would make this product available so that he could actually use it.
  • Severity - Good
• "I think you just made people lazier." (Saying that people do not have to learn how to make a resume)
  • Severity - Good

Vietnam

• Editing on resume desired (does not want to have to go back to the first page to edit content)
  • Severity - Cosmetic
  • Solution - Text on resume could be editable
• Wizard look confusing (unsure if after “Save and Continue is clicked, one can return to that step in the process or not”)
  • Severity - Cosmetic
  • Solution - Remove numbers from each step (1, 2, and 3)
• “Resume Name” not seen (user clicked “Save Resume” without seeing naming possibility)
  • Severity - Cosmetic
• Solution - Do not let user “Save Resume” if “Resume Name” textbox is empty
  • “It’s so fast”
  • Good
• “I really like that it formats for you”
  • Good

Reflection

During this process, our group learned many different things. Firstly, we learned that multiple stages of testing before the product is even build can allow you to solve many of the issues that arise. All three of us have worked on multiple projects where we have made design documents, built a product, and tested and iterated. By that time, we were often reluctant to make drastic changes. But because we spent a lot of time building the product before we actually build it, we had already made a lot of the drastic changes we would have had to make, just before we had invested a lot of time and resources instead of after.

Also, thinking about the UI the whole time made us have a better product than we otherwise may have. In other projects, we have often started by building an acceptable UI, just so we could get a working project. The problem was, once we had a working product we found it very difficult to revamp the UI because we were already thinking that the UI would look something like what was already there.

The paper prototyping exercise was very useful to us all. It allowed us to think about the flow of the web application without worrying about extraneous details like how exactly the buttons would look. Another thing it allowed us to do was to design what we wanted and not what we knew how to do. By that, we mean that we paper prototyped without deciding if an action was feasible or not. Thus when it came time to build the product properly, we tried to build the product similar to our final paper prototype. If we had started to build without the paper prototype, we may not have been so motivated to make features like drag and drop work. However, after we saw that everyone loved and intuitively understood the drag and drop features, we decided to make it happen, and we did. Thus the paper prototyping made us more ambitious than we would have imagined that we would have been. The paper prototyping was also nice because it allowed us to try out multiple things, such as what the “Make Public” button should do.

The heuristic evaluation was helpful to us because we had been looking at our product so much that there were some details that we missed. We tried to get the prototype to a final stage (at least on the front end) before the heuristic evaluation. This meant that the issues that the evaluation found (there were a lot) were not things we noticed, which strengthened our product a lot, as we could test it before we added all the backend parts to the project, in which case we were likely to not make drastic changes after that (unless we realized they were necessary).

If we had the time, we would have done another round of paper prototyping. That would have taken away some of the questions that came up as we built the product. Also, we would have liked to have a few rounds of user testing (as we had to do for this assignment). We feel like we got a lot from the users and we plan to do more user testing after this project ends.

If we were to do this project again, we would have divided up the work better. At times, one person knew about one part of the codebase and thus worked on that part more than the others. It would have been nice if we could have properly devised a plan to split up the development of the project so that all members of the team could be working at all times, and one person was not waiting on another. We understand that this is not an easy task, but we would have liked to organise the development process better. That said, we felt like we worked well as a team and were able to deliver when necessary.