2 Months; Cambridge, MA
To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. The information in this case study is my own and does not necessarily reflect the views of Job Department and Jobcase Inc.
Job Department is a job search website created by Jobcase Inc. designed to target potential applicants by state. The goal of this project was to redesign job post listings so that they are easier to scan and generate a higher click out.
UX Researcher, UX Designer, UI Designer
I was approached by the point Marketing Analyst for the Job Department account to create a better experience for users and make content easily digestible and informative with the intention of creating a higher click through rate to the job posting where users could apply for the job.
Mobile-first Responsive Website
Photoshop, Invision, JIRA
Marketing Analyst, Back-end Developer
The goal of this project was to create a better experience for users by making content easily digestible, and short but informative in order to generate a higher click through rate to the job posting. We were also looking to add both a save and report button to each posting to see if they tested well enough to merit the development costs.
We hoped to create metrics that improved upon the original design, thus all tests were performed against the original design as a control.
The first item we tackled from this request was to test the validity of adding a save button and a report button to each Job Department post. I began my work by researching what our competitors were doing in this space. Indeed, Glassdoor, ZipRecruiter, and CareerBuilder were all offering different ways to “Save A Job” to your profile. However, it seemed that only ZipRecruiter was offering a way to “Report A Job” on their job listings page, most others would offer this option once you opened up the job listing itself.
One of the issues we would run into with Jobcase was that some of the listings are pulled from sites such as Glassdoor so we could not rely on an opened a job posting as the location for “Report A Job”. My Job was to create a non-evasive, non-distracting way to both save and/or report a job without disrupting the flow of content. As a result, I presented the following concepts to the team, and I took this opportunity to present different font layouts as well.
When addressing the "Report A Job" Function I wanted to make sure the process took as few clicks as possible and was nonobstructive to the user. I believe the best way to accomplish this was to have the report function pop up in a modal. The user could then select from our two most common problems, job expiration and job registration, as well as write in their own third response. Once hitting "Report Job Listing" the user receives a thank you message. Keeping this action simple makes the whole process only four clicks deep.
Our next objective was to look at the job post design style as a whole. I again returned to our competitive market to asses how they were listing their jobs. Job postings consisted of the following pieces of information: job title, company, location, description, salary, logos, newness, date posted, save, report, apply, reviews, full-time/part-time, and benefits. Upon conducting user interviews we found that the most relevant pieces of information to people before they clicked through to a job posting were: job title, company, location, salary, date posted.
Date posted was a feature that we knew we could give some love in particular. Upon reviewing our existing design compared to that of our competitors we noticed that we would include the date the job was posted but our competition would show the hours/days from the date posted. Thinking about ease of use and real world dialogue we realized that including the date the job was posted only forced our users into a math problem. In the long run we decided to align with our competitors way of thinking by including the time since the job was posted rather than having them calculate that themselves. This would greatly aid in the scanning and self-validation of the job's usefulness for the user.
One of the most important pieces of the job posting that we needed to keep in mind was the “Estimated Salary and Job Details” button. Normally when a user views the job listing in the returned search results the salary is not displayed, however once the user clicks through to the job posting and then returns to our search results, the “Estimated Salary and Job Details” button is replaced by a green pill button that states the salary. I felt that this was not a great experience because there is no indicator or placeholder that would make you believe that the salary was going to be displayed. I also felt that the user might still miss the interaction when and if (which they might not always do) they return to our search results. As a result I proposed the following designs which highlighted the five pieces of information we felt were the most relevant and included a better way to “show” the salary and still maintain a way to entice users to click through to reveal it. These designs also looked at the weight and hierarchy of the existing posts and attempted to make the information more easily scannable and digestible.
After reviewing these designs we determined that the best next course of action would be to implement these changes in steps. The first step would be to see if our new method of showing salary would prove equal or better results than the current method. Once we determined if this method worked we would then alter the font sizes, weights, and colors to see what performed best.
At this step in the process I moved on to another position.