Here you can see how I applied my design process to an entire iterative design project, from need-finding to a high-fidelity prototype. Myself and two other graduate students at UC Berkeley iterated upon a previous design prototype we had created for one of our classes. The final result is Seek, the job-finding app: a solution to the cumbersome job application process that new college graduates face every day.
This project begins from the prototype below, already created to answer the questions of “How can we make job applications more fun” and also “how might we store user’s application data for more efficient use?” We had previously arrived at this prototype knowing that users wanted to be able to send out a lot of applications in a short time, be able to set up a profile only once so they wouldn’t have to fill out repetitive and redundant info, and hear more feedback throughout the application process. The final iterations detailed below built upon the previous knowledge we had from the construction of this prototype.
We began by interviewing a wide range of people currently going through the job application process. We did this to get a sense of a variety of different needs before honing in on a specific target group. We made empathy maps to summarize each of the initial interviews and used these to identify trends to be able to focus in on the particular group of job applicants which we felt was the most in need.
Referencing the empathy maps from our initial round of interviewing above, we felt that entry-level job applicants were the most likely to be sending out a very high volume of applications. We felt that this target group would benefit most from an efficient job application app.
Once we had identified a target group after our initial interviews, we interviewed one more soon-to-be college graduate as well as a former college recruiter to try and see how we could formulate our app to be efficient from both the applicant’s as well as the recruiter’s side. You can see the empathy map for the college recruiter below.
Through these interviews we were able to confirm a lot of the insights from the applicant’s side that we had seen in our previous iteration, such as:
Because we also opened up our need-finding to job recruiters, we were able to see what they needed from a job application app as well. The interview with the recruiter revealed that recruiters have to deal with far more applications than they did in the past, and that feedback is also where many recruiters struggle.
After evaluating all of the info we gained from our need-finding interviews, we flared out to come up with a long list of potential questions we could address before focusing in on three:
Afterward we then flared out again to propose solutions to each one of these questions, then decided to focus in on one solution for each ‘how might we’ and make a prototype for each.
We utilized parallel prototyping, as research has shown that this method of prototyping often produces the best outcomes.
We began with some initial sketches and brainstorms of what we could add/accomplish from both the applicant and the recruiter’s sides. We realized that it may be difficult to decrease response times of companies, so we decided to implement a filter option where users could filter job openings by average response time of the company. So if a user is concerned about response times, they can set their filter lower to hide companies that tend to take a long time to respond, thereby decreasing the time it takes to receive feedback.
On the employer’s side, we ultimately decided that we would decrease the visibility of an employer’s job posting if they were not responding to applications, incentivizing them to reply more hastily.
Again, we began with low-fidelity sketches that had sort of a grid style – something where we could display some info about each participant so that the recruiter could see a large volume of applicants at once, but still have the option to click into their profile and chat with the applicant.
We iterated on this design in the medium-fidelity prototype by implementing a filter option and a sidebar containing current job postings, and included some info such as a percent match and top skills so that the recruiter could see a good snapshot of the applicants at a glance. This prototype allows recruiters to see concise lists of interested applicants. The recruiter can also change tabs to see applicants that they’ve already accepted and quickly message these applicants to set up initial interviews. They can also apply filters to the applicant pool to prioritize different qualities in interested candidates.
For this prototype we added features to both the recruiter and applicant sides to see what feedback would be needed to improve the applicant side while not adding extra burden on the recruiters. One key feature we added is the ability for recruiters to quick-select their feedback with the option to leave more detailed comments. This served to make the feedback process easier for the recruiter, increasing the probability that they would leave feedback for the benefit of the applicant.
Another feature we implemented was a timeline in the application process with which the applicant could check their application status. The important part was that people know if their application was received and/or considered, as well as if it was accepted or rejected.
We performed 3 user tests total in order to answer our three how might we’s that we created our prototypes to answer.
For this first user test, we wanted to gauge which of the above prototypes allowed the recruiter to process the highest volume of applicants in the most efficient manner. We had a former college recruiter walk through various tasks using both interfaces.
For the interface on the right, we asked the recruiter to navigate to interested applicants, click on a user to get more info and then express interest in that user, change the job filters, and open chats with different candidates.
The recruiter liked the filter options and liked that applicants were separated by how well they fit the job posting. She was also a fan of the chat feature and thought it would be useful for scheduling initial interviews and phone screenings, but that email would need to be transitioned into later in the process as more people got involved. Her favorite feature was the percent match that displayed for each applicant. She said that over time if the feature was reliable that it could save her a lot of time. However, she noted that the open roles aren’t the best thing to see when the application opens, because as a recruiter it’s their job to know the job descriptions. She also noted that the candidate screens could be displaying more people than they currently are.
For the interface on the left, we asked the user to attempt to figure out why the visibility of their job posting had gone down and to attempt to remedy that, and then to open a candidate’s info page and express interest in them.
The recruiter thought that decreasing the visibility of the job application if they’re not responding was a clever way to ensure that companies reply to applicants. She also liked the layout and found it easier to digest and navigate than the interface on the right. She thought it made it very easy to go through a large volume of applicants, because she would click into each user profile regardless of how much info we presented in the summary card. Additionally, she noted that it was very easy to interpret the approve/deny buttons due to the symbols and color scheme.
For the applicant’s side of things, we asked the participant to first set a filter to only show companies that respond within a maximum of two days. We then had them view communications with companies that they’d previously applied for.
We gathered that there should be a filter option for average response time, not just for maximum response time. Additionally, the participant stated that the option to adjust the filter with the scale was nice, but suggested potentially a manual number input as well. The user also stated that we were missing a way to organize the chats with different companies, and that that would be a useful feature to add.
From the recruiter’s perspective, we ran the same test as we did in the first user test so that we could compare results between them.
The feedback was similar in that for the interface on the left, the user stated that they liked the way it was structured and that the flow was very intuitive. And for the interface on the right, they stated that it was a little bit too cluttered, although they did like the side bar containing the list of job postings. Overall, the takeaway from the recruiter side of this user interview was that we should keep the interface as simple as possible and have more advanced functionalities available through menus or toolbars that can be clicked.
For our final user test, we tested a web interface of the application against the phone interface to see if we could gain any important insights that we couldn’t have on the phone app. For the web interface, we asked the user to explore job postings and navigate to an application that has been submitted. We then had them navigate to an old application. Then for the phone application we asked the user to navigate through the app and indicate interest in a company.
The user said that for the web interface, they really liked the internal forward feature because recruiters already do that, and suggested that it would be good if the applicant got a notification if their application was forwarded. They also appreciated the timeline feature and the fact that there was feedback included on declined applications. However, the user preferred positive feedback over negative feedback in order to know what to highlight to future recruiters and find better fits for jobs in the future.
For the phone application, the user liked being able to filter through which types of jobs showed up because it helps applicants sift through jobs that they’re qualified for. However, they stated that the tags were slightly confusing and could be more customizable.
Overall takeaways from the last user test included that even easy, low-fidelity feedback from the recruiter on strengths and weaknesses is good. Additionally, knowing that the application has been seen/reviewed by a recruiter helps the applicant feel better. And finally, that a swiping ‘match’ where they actually apply for the job might not be as effective as swiping ‘networking’, where they are simply expressing interest in the job.
Once our user tests were completed, we were tasked with identifying the best parts of each of the three prototypes to include in our final high-fidelity prototype. This proved to be fairly difficult, as finding an interface that was efficient from both the applicant’s and the recruiter’s side was no easy task. The two seemed to be intertwined in a push-pull relationship, where it was hard to improve the efficiency of one side without damaging the efficiency of the other. We had to find the perfect medium point that took both sides into account in order to create an optimally efficient job application app that was user-friendly on both the recruiter and the applicant side. I believe our finished product does just that.
Building off the previous iteration from module 2 as well as feedback from our most recent user tests, applicants swipe right or left to indicate interest in a company, providing a fast, efficient way for users to get their profiles out to a large amount of companies in a short amount of time. For this iteration we added a bar at the bottom of the screen that indicates how long the company typically takes to respond so that the user knows what to expect in terms of response time. There is also a messages tab where users can see messages they’ve received from different companies and use this to communicate once the companies have reached out.
From our user testing we knew that the filter option for company response time was received very well by users, so we chose to implement it in our final design. Users can simply go into their profile and adjust their filter options, and the app will only show companies that respond within a given time frame. There are also other filter options to choose from, such as distance radius, benefits, and job type.
The user can also see a list of all jobs that they’ve applied to and see a small note about their application status for each one. We implemented this application visibility after receiving lots of feedback from users about wanting to know where in the application process they stood and that they appreciated being able to see if their profile had been viewed. It all ties back into increasing feedback for the applicant.
New to this iteration is a process for the recruiter’s side, which was not implemented in the prototype we began with. From our interviews and user testing we knew that the recruiter preferred the very minimalistic, no-nonsense layout that you see above. All of the positions are listed and are easy to click into, but there is not unnecessary information about the job positing that the recruiter should already know. But perhaps the biggest thing is that we were told that a recruiter would not want to be on their phone swiping through an app while at work, so there would need to be a web interface for the recruiters. So of course we accommodated for this in our design.
From the user testing with the recruiter we knew that limiting the visibility of a post is a very good way to incentivize someone to respond to applicants. And the recruiter also indicated that she liked that our web page notified the recruiter when this occurred so that they could quickly work to amend the issue.
You can also see that we retained the estimated fit algorithm that suggests how good of a match a particular applicant will be, but we didn’t include much else in terms of info on the main applicant page. This is because our user tester informed us that as a recruiter, she would click into every applicant profile regardless of how much info we showed on the main screen, so there was no use in trying to put too much info and clutter the screen.
We were also told that the ability to undo mistakes was crucial as a recruiter. And what’s more is that we were informed that a database of rejected candidates is also necessary to an operation of this sort. The recruiter informed us that often someone won’t be a good match for the position they applied to, but they may still be an interesting candidate that may fit well for another position. For this reason it’s important to keep track of who has been rejected, so we added a tab where the user can click into all rejected candidates to view their profiles and chat with them.
The recruiter can also click into any one of the interested applicants to see a short summary of their profile, with the option to download their resume if they need to find out more information. The estimated fit algorithm got a lot of positive feedback, so that is of main emphasis on the profile page. Additionally, we gathered that the most important things to include in a quick snapshot look at an applicant are relevant skills, education, and the most recent job experience, so we included all of those on the screen as well. All of these features are present in order to save the recruiter time so they don’t have to parse through an entire resume if someone doesn’t appear to be a good match.
We were also told that the ‘check mark’/’red ex’ motif was a good way to represent accepting and denying an application, as they’re fairly universally recognized symbols. So we chose to stick with that representation throughout the user flow.
Finally, we included a chat function so that the recruiter can reach out to applicants directly within our app without having to fuss with email or other contact information in the initial stages. We were told that a chat function within a job-screening-esque application such as this would be a very useful feature for scheduling initial interviews or sending out coding challenges. However, we were told that the chat function would only come in handy for the first stages of the application and that it would need to switch to email eventually as more teams/people got involved with the application process. This could be something to adjust moving forward – we could focus on making our application recruiter-friendly for the entire recruitment process, from application to offer.
That concludes the high-fidelity prototype! We aimed to produce a highly efficient way for users to apply for jobs and get prompt feedback, and I believe we did that. The process is quick and easy for applicants, and efficient for recruiters so that applicants don’t have to worry about not hearing back or not getting feedback.