Redesigning the main component for jobs

About the company

Torre.co is a job matching network startup focused primarily on remote jobs, with over 1.5M users. It has a powerful matching algorithm that uses 121 different factors to determine if a person’s genome is a good fit for a job and vice versa.

Hypothesis

If we clean up our job post cards by leaving only the necessary information and if we make one replicable component for all scenarios, we will reduce the cognitive load for our users and save a lot in future engineering hours.

Understand the opportunity

During routine value tests, users complained about how we presented jobs to them. Full-screen job posts (once they were open) were easy to understand. But the summarized version of job posts, presented in cards, was too dense. Users didn’t know where to direct their attention.

The most important part of the project would be to decide what information should be included in the preview cards and which could be left out. I would have to make those calls and design the cards considering our (new at the time) neumorphic design style.

There was another important issue to resolve with this design. I would have to create the card as a standardized component that could work the same way in the different screens and use cases. That meant four different scenarios, all responsive.

The card would have to work on the job search page (the one shown above), on a page called subtorres where they had traditionally been posted as part of a list, within job posts as “suggested similar jobs”, and within email job alerts.

What should we remove?

In order to decide what information would stay on the job preview cards, I interviewed 10 active job seekers in Torre and asked them to re-organize the elements listed in the cards starting with the most important information for their job hunt.

Based on the results I got from these interviews, on the opinion of key stakeholders, and on my own gut, I determined what would stay

The following is the list of what should be on the preview cards. Green meant very important, orange was a nice to have, and red would most likely have to go:

1. Job title
2. Company or job poster
3. Monetary compensation
4. Type of job (Full-time, part-time, or flexible)
5. Location
6. Profile picture
7. Match and rank information
8. View button (CTA)
9. Like and dislike buttons
10. Skills required
11. Refer button
12. Hide button
13. Team members
14. Days left before the job closed
15. Questions and comments asked about the job
16. “Signaled by you” banner
17. “Quick Apply” tag
18. “Ask a question” button

My threshold for card space was being able to show at least two job posts on the smallest possible mobile screen we typically designed for. This should make the experience of scrolling through jobs less tiresome and help users get faster to the jobs they actually were interested in.

Design

A lot of tinkering and stakeholder lobbying went into getting this done. The easiest way to begin was to build the smallest card necessary and see what would fit in there. But as we reviewed each iteration, different business needs kept surging and made me reconsider the structure of the card.

For the first iteration (see above) I pitched a fully clickable card without any CTA button. I was betting on the neumorphism to provide enough texture and serve as CTA in itself.

This was eventually refuted during a quick session of testing. Users were much more likely to click if they saw the evident CTA. So, I was corrected.

Another controversial decision for this iteration was the removal of the match and rank speedometer icons. The matching and ranking system was a very important feature in Torre and we wanted to expose users as much as possible to it. However, in my pursuit of simplicity, I proposed we kept that information for the full job post.

From our Job Poster team, we received a request to add a brief description that would be required of every company posting jobs in Torre. In order to do this, I proposed a standardized description of up to 120cc (up to two precious lines on the cards) and it was added to the company onboarding.

Removing the likes and dislikes button was a tougher choice but after several discussions with our head of algorithms, Roy Ten Berge, we decided the data being gathered was not adding sufficient value to our models in order to pay for that mobile screen real estate.

The “end” result

So, we went from 17 elements on the original card to just 6 in our first iteration. After a few subsequent rounds of designs, and stakeholder interviews, we ended up with a card that contained up to 12 elements (depending on the context) but was significantly smaller than the original.

In the following GIF you can check out the different elements added for different scenarios. All within the same component. A much more scalable solution than what our engineers were working with before.

You may have noticed another significant change I made to the cards during this project that I haven’t discussed: The colors. The reasoning behind this will require a different case study because it’s a long story.

But, in essence, it relates to the speedometer icons that show the user how they match the requirements of the job and how the job matches with their personal preferences. Each card has the accent color chosen by the company to fit their brand the closest.

Note that the GIF below is framed within a small Android screen. This was used as an example to keep in mind all of our user base when determining the size of the cards.

Usability testing and Analysis

A few weeks after the changes had been released, we conducted a series of 10 interviews with Torre active job seekers. The purpose was to make sure the new design was being understood as intended and to find out what users thought about it.

The overall reaction from users was great. Nine out of 10 users were promoters (they gave it an eight or more out of 10) for the usability-oriented questions.

Also, stakeholders who were asked reported being very happy with the new changes. Especially technical ICs who could see how this would reduce a lot of redundancy in future updates.