ZipRecruiter
•
2020
For job seekers, the job card is a key element in the ZipRecruiter interface, but functionally, it presented several issues; it was difficult to read, reuse, and test. I led the effort to improve the job card from usability and system perspectives.
Lead Product Designer
System Design
User Interface Design
Nishok Chetty, Product Manager
Gerald Burns, Engineer
Ben Geller, Research
Mrinalini Garg, Analytics
The job card had glaring usability issues and needed to be rebuilt for each new placement, an inefficiency we hoped to correct. Could we redesign the job card to not only improve usability, but also promote consistency and enable powerful testing?
Some of our highest traffic pages, like Suggested Jobs and Search Results, displayed lists of hundreds of job cards. The cards gave the user a compact preview of a job and some even allowed users to apply directly with one tap.
Our database is made up of millions of jobs from hundreds of different sources, each returning different data than the last. While perfectly formatted jobs exist, a more characteristic job was one with a long title and missing information like a logo or perks.
While this doesn't look terrible, it's uncommon for a job to have clean and complete data.
A more realistic job.
We had spent years tolerating the suboptimal design and were ready for a change. There was a laundry list of usability and visual issues that needed to be addressed;
Long job titles were truncated after 34 characters, a low limit considering the amount of employers that stuff their job titles with superfluous keywords.
Because company names and locations shared the same line, long company names often truncated cities and states, key factors for determining if a job is a good fit.
Missing “perk” elements, like salaries, benefits, and job types, occupied valuable real estate with the useless fallback label: “Not Listed.”
Dismissing a job, an action that simply hides the card with CSS, utilized prime space and made adding other, more useful secondary actions a game of Tetris.
Font sizes and weights blurred together, and our use of grey text didn’t abide by the WCAG color contrast guidelines, making it difficult for people with low vision to read the card information.
The overuse of borders and dividers added a lot of visual weight to the page. This extra weight looked even heavier on desktop, where 4 or more cards could be displayed side-by-side in each row.
Hovering on a card underlined the job title and nothing else, a small visual cue for a relatively larger hover area.
The card hadn’t been turned into a component, so reusing it was tedious and inefficient for engineers and a contributor to technical debt. This led to inconsistencies in the card across pages. Users could save and report jobs on some pages, but not others.
Because of the card’s rigid design, testing which information we showed was time-consuming and required significant resources. The job card contents had been the same since its inception with no real reason as to why.
Several of the issues stated above were based on my intuition and understanding of best practices, but others came directly from our research. Job seekers who reported jobs cited a lack of information as a top reason.
After digging in with user interviews, Ben, our research lead, learned that job seekers were frustrated by cut off job titles and locations. They loved our 1-Tap Apply feature, but felt some jobs didn’t have enough substance for them to confidently use it. This was especially true for job seekers in trucking and healthcare, as hiring managers in those industries tended to stuff job titles with keywords.
We aimed to improve the job card's usability upfront and systemize the design for added testing capabilities. We also hoped to use the project as a starting point for improving our process of implementing reusable components across our product ecosystem.
Because our job data can be very inconsistent, I designed the job card as it’s own mini system, giving internal elements their own full-width vertical space. This allowed each element to dynamically grow or hide depending on its contents and the data available to us. It also gave us the flexibility to easily add, reorder, or remove internal elements in future tests.
The flexible system allowed us to show full job titles and company names by wrapping longer strings. I aligned every element to the left for faster scanning and set a clear typographic hierarchy by tweaking font sizes and weights for added emphasis on the job’s most important details.
Performing actions from the job card had previously been inconsistent. Some cards allowed users to save and report jobs, while others only allowed for the dismissal of jobs. I tucked all actions into an expandable menu, giving users access to the same actions from every placement. Further, this solution was fluid enough to accommodate new actions later on if we needed them.
We updated our grey text values to comply with the WCAG color contrast guidelines. This prompted a wider color audit and later, a dramatic change to our color palette, including our primary brand green.
I started explorations by critically thinking about the types of information that are important to our users, but was met with resistance because of time and engineering constraints. I pivoted to restructuring the information that was already there in a way that would enable us to easily test contents later.
Here’s a look at some of the versions along the way:
Working with front-end to implement the new job card exposed holes in our outdated design system process. Because of our product organization’s habit of moving quickly and A/B testing everything, many front-end engineers avoided spending the time to create and document a component before it actually proved successful. This was reasonable, but added to ZipRecruiter’s technical debt. Once a test variant won, we resolved to it quickly and moved on.
I organized meetings with front-end and design stakeholders to figure out how we could combat this issue. We decided to build in time to componentize winning variants and formed a team to take a more wholistic approach to improving our design system workflow. I could speak more to how we’re approaching our design system, but I’ll save that for another time.
With a temporary solution in place, I documented the new job card system and helped stress test the component before finally testing it with job seekers.
We tested the new card design on the Suggested Jobs page first and planned to roll it out to other placements with a win. The A/B test revealed that the new card design significantly outperformed the old with a 10% lift in clicks and a 6% lift in applications, a substantial win for what was on the surface, a simple visual UI update.
Based on the agreement we made with front-end, the card was componentized and extended to its different placements. It performed similarly in its other placements and even better on iOS and Android, lifting applications by 7% and 8%, respectively.
The job card redesign improved our job seekers’ overall experience by making jobs easier to consume—first on Suggested Jobs and later across our entire product suite. Personally, this project gave me some valuable insights:
By systemizing the job card design, I was able to create capabilities for our product management team that would outweigh the initial benefits of simply improving the visual design and hierarchy of the card.
It’s important to be able to adapt to new constraints and moving targets. Building products is rarely cut and dry. As teams work alongside each other, things can change and that’s okay. Changing my angle from what to include to how to include steered the job card to where it is today.
Communicating well and involving the right stakeholders early on can pay huge dividends. In the process of redesigning the job card, I saw an opportunity to improve the way we utilize design systems. Through good communication, I was able to get buy-in and kick off what would be the start of a more mature design system process.
