...

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.

...

• 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.

...