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.
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.
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
Palestine
Thailand
Vietnam
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.