David R. Eicke

Context

What's Handshake? Handshake is a three-sided platform for early-career talent. The first side is students. Our overarching mission is to help students and recent grads find and get those first few jobs or internships to start their career. Second side: universities. We partner with over 800 schools, serving as the tech engine of their Career Services departments. Third side: employers. (This is what I work on.) We help companies find and recruit the best early talent based on their specific needs.

"Your Schools": In Handshake's early days, the team received some complaints from recruiters that there was too much noise in the product, with data and applications coming in from all the schools company-wide, when they only cared about the few schools they themselves were responsible for. So to make their lives easier, we built something called "Your Schools". This enabled recruiters to create a list of the schools they were focused on and use it as a filtering mechanism. It was built to be a global toggle.

Approvals: Handshake partner schools need to approve individual employers before those employers are allowed to post jobs that are visible to their students on Handshake. This is to limit fraudulent posts and protect students from scams.

Phase One: Visibility & Cleanup

There were a lot of problems to solve here. So we decided to do it in waves. First up: visibility issues (and some UI cleanup). Here's what we had in place:

As you can see, there were two tabs: Your Schools and Add Schools. Having these two tabs and only these two tabs gave users a mental model like this:

In actuality, though, there are three layers. The schools in our network, the schools who've approved your company, and, within those, the schools you want to work with as an individual. So we wanted to figure out how to communicate this to recruiters.

To help recruiters understand this structure, we wanted to reflect it in the UI. That's why we went with these three tabs, reflecting the three states/levels schools could be in. We also renamed Your Schools to Favorites, "your" being an ambiguous word that could mean 'belonging to you" or "belonging to my company" just as easily. We'd also figured out by this point that, for some users, "Favorites" was going to be just one of many lists of schools. More on that later.

"Your Employer's Schools" was our biggest change, though, allowing individuals to see, for the first time, a list of schools where their company was approved.

We also took the opportunity to update the front-end code to React and the UI to match our design system and the card-based layout in the rest of the newer parts of the product.

Phase Two: Smart School Selection (Premium)

We'd heard from our Support staff that customers often asked about which other schools they should be recruiting from. They wanted to know where they could find more of the students they were looking for (or just more schools in their area).

So, we decided to embed our Student Search functionality into school-searching process. The idea was that recruiters could specify what criteria they were searching for in students, and we could tell them which schools had the most of those students matching their criteria.

Originally, we'd had a simplified version of this student search nested in the sidebar of our schools page. It would add a column to the table of schools and sort on itself. This way, recruiters could see a rank list of which schools had the most students with an engineering major, for example.

This did well in prototype testing. However, we hit some technical constraints around the way the database was structured, and we realized we couldn't build it as designed.

After talking through what we could do, we actually came upon a solution that we think might be better, and also less hidden away.

We decided to add a new tab to the mix called "School Explorer" where the entire page is dedicated to the search for schools containing the most students meeting a certain set of employer preferences.

I'm proud to say this feature has shipped! In the second image below, you can see that I've filtered down to discover that the school on Handshake with the most "Design & Applied Arts" majors is DePaul. I would not have guessed!

The reception of this feature has been overwhelmingly positive, both from end customers and our sales team.

Phase Three: School Lists (Premium)

Throughout our product, there are several places where recruiters will add a list of schools--when they're creating a segment, when they're choosing which schools to post a job at, when they're deciding which schools to invite to a virtual event, etc.

Unfortunately, there has never been any way to do this other than selecting them one-by-one from a type-ahead dropdown. So the team decided to try creating saved School Lists, usable throughout the product.

The initial questions we had were:

What kind of criteria would people use to form their lists?
Would people be interested in seeing their coworkers' lists?
How many lists might people/companies make?

We were able to get educated guesses about the first question via our Support team, who'd, again, been working with them every day. But for the other items, we had to interview some customers.

My PM and I came up with a list of questions to ask in each interview, and I created a rough prototype to test some ideas with.

We discovered quite a few interesting things by asking "expectation" questions like these.

For example, we discovered that people expected to be able to use school lists as a sort of "jumping-off" point for sending Campaigns. We would've never thought of adding that functionality otherwise.

Through the interview portions, we found was excitement about the idea of quickly populating forms on Handshake with saved lists of schools, but the really interesting stuff had to do with teams. Most people we spoke with didn't think recruiters would really have much reason to have visibility into other recruiters' lists. However, one customer expressed a desire to keep all the lists centralized. This led us to a Spotify-esque solution, which allows recruiters to add other recruiters' lists to their own set of lists (while not allowing modification).