...

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.

...