summary

Twine is a workforce analytics tool used by HR leaders and executives within companies. Twine gives managers a centralized place to review new hires, recruiting efforts, retention, and analyze data in novel ways. Twine is venture backed and was a YCombinator company.

role

I consulted as a product designer for Twine over several months as they searched for full-time candidates.

Recruiting Deep Dive

Introduction

Twine wanted to launch a new section of their tool centered around recruiting. We began the project by brainstorming potential views that might be useful to customers and then narrowed the scope, working valuable interfaces into a logical navigation structure. Given the broad scope of the project, I started by wireframing the team’s ideas in Balsalmiq, did several iterations there as we collaborated on the optimal UX, and then moved to visual design in Sketch.

Designs

All designs I show for this project were created by me, except for the navigation bar in the visual designs, which was inherited from a previous designer. Below are some selected wireframes followed by the final round of visual designs for comparison.

Recruiting home

The main page shows an overview of the entire company’s recruiting efforts. The gallery below shows some of the primary iterations we went through on the way to a final design. The main differences between the wireframe screens is what content is shown where as well as different UX considerations. Here are some key decisions we made for the final design with rationale:

1. At the top, we included having a filter with visible options, rather than a search bar that allows to build filters because we wanted to clearly expose what’s possible to new users.

2. The summary view is interesting, but the real tactical value for managers comes when they are looking at a filtered view, like a department. So, just below the filters, we show some suggested filters that users can click to apply based on what we think may be most valuable to them.

3. The individual filter suggestions I initially had the bottom were simplified (removed pipelines), moved to the top as mentioned above, and were replaced with the most recent individual requisitions (job postings) in the company, providing for a fast deep dive that skips the step of filtering first and clicking through a requisition there.

Single requisition pipeline

Once a user finds a job posting (requisition) they’re interested in, they can click through to see a Kanban-style pipeline showing where candidates are in the process. Below are a few versions I iterated on with the team, with the final visual design on the right (last one). We started by trying to show the pipeline, some stats, and the Kanban board, but quickly realized this was an overwhelming amount of information. After reviewing with the team and showing to customers, we ultimately discovered just the Kanban view alone was most valuable, as we have many of these other stats at the department and company-wide requisitions views.

configure funnel stages

One key component of being able to deliver summary application funnels for users is mapping the stages for each job posting to a general stage. Different jobs have different application processes. An engineer might have multiple phone screens and a take home test before being invited onsite whereas a customer success representative might just have one phone screen before coming onsite. Creating your own summary stages at the company and department level let you see generally how hiring is progressing, without being confused by the myriad of different processes between jobs.

To make this possible, I designed a configuration step where you’re able to create a new “pipeline” with stages you create and then assign steps from individual job postings to. A user can have multiple pipelines and then switch between these on a summary view. They might have a “general” pipeline that they want to use at the company-level and then department specific pipelines they want to use when looking at that deeper level.

The first screen is an initial wireframe for visualizing different pipelines, designed to let users easily reorder funnel stages. The drawback of this design is it requires users to hit that gear icon to configure each pipeline, which isn’t the most obvious, and this design also breaks down if there are many pipelines, leading to a potentially large amount of horizontal scrolling.

The second design below is an improvement. I saw the opportunity to break the first screen out into an additional step. First providing users with a list of pipelines, which they can create / edit / delete, and then leaving the actual configuration in the screen behind that.

The third design was a first pass for the configuration screen. The interaction is drag and drop for moving recruiting stages from the left into pipeline stages on the right. The problem with this screen was that the layout doesn’t work well enough for this data. It’s interesting to show pipelines stages as top to bottom, but then adding recruiting stages under each header leads to an awkward and unordered overflow in each section. Especially as the user adds many items, which I learned would be more realistic.

The fourth design is the final design for the configuration step after the user chooses a pipeline. This design takes helpful elements from previous versions and incorporates the full complexity of real-world data, including usability tweaks to assist in workflows, like “select all” and “clear all” options.