...
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. unmigrated-wiki-markup 
The first step is to input information about themselves, including biographic information, education experience, work experience, and leadership 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. \[Add ScreenShot for First Page\]
| Wiki Markup |
|---|
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.
\[Add Screenshot for Second Page\] |
| Wiki Markup |
|---|
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.
\[Add Screenshot for Third Page\] |
...