Candidate Lists

Candidate Lists

Unifying search, filters and talent pools

Pinpoint ATS

Role

Lead Designer

Tools

Figma, FigJam, Linear, Notion

Year

2026

01.

Introduction

Pinpoint ran two separate places to find candidates: an All Candidates search and a standalone Talent Pipeline, each with its own search implementation. I led the merge into a single surface end to end - framing the problem, prototyping the directions, running the research, taking the work through design crits, and writing the spec engineering built from.

This case study is about one slice of that work - how you create a list - because it turned out to be the moment that decided whether the whole thing felt trustworthy or frightening. It's live design work, still in flight; what's settled is the flow below and the reasoning that got there.

02.

The Problem

Once search and filters were merged, a list was simple on paper: some saved candidates, an optional set of criteria built of search and filters, and two toggles providing the automations of adding new matches and removing non-matches. Powerful, and quietly alarming.

In early sessions, the create screen tried to show all of that at once - keyword search, filters, name, toggles - on first land. Recruiters told us it felt cluttered, and several couldn't find where to create a list at all. Worse, the toggles carried real consequences that the interface never made legible.

The Tell:

people toggled criteria off - not because they understood what it did, but because they were scared of what it might do. They were reducing risk, and ending up with a list they hadn't meant to build.

That was the real problem. Not layout. Fear of consequence at the moment of creation.

03.

Challenge

How do you let someone define a list - a genuinely capable, rule-driven object - without making them feel lost, and without handing them enough rope to quietly break their own data?

I didn't want to argue my way to the answer. I built it.

04.

Building to think

I prototyped five full approaches to list creation and walked them end to end in a design crit rather than debating them abstractly:

I didn't want to argue my way to the answer. I built it.

05.

Decisions

Request Reference

Ship a focused MVP, validate fast.

The first version gave recruiters structured reference requests - customisable templates, configurable fields, and packaged reference requests that enforced the right mix before moving forward. Once we saw real usage, we layered in time-based validation, confirming references cover required periods.

Audit Logs

Status is the product

The audit trail wasn't a nice-to-have for enterprise clients - it was the feature. Compliance-conscious hiring teams needed a complete record of every request, response, and status change. I designed the status system first and built the entire UI around it.

Candiate Portal

Give candidates visibility, reduce admin chasing.

Once a candidate submits referee details, they get a persistent link to track progress themselves. If a referee goes quiet, the candidate can follow up directly - removing a whole category of back-and-forth from the recruiter's plate.

Email - Reference Request

Design for the reluctant referee.

Some referees won't click an unknown link. We added a reply-to email field - referees could respond directly or attach a reference on company letterhead, captured in Pinpoint either way. A small decision that removed a meaningful drop-off at the most fragile part of the flow.

06.

Handing it to engineering

Deciding the flow is only half the job; the other half is making it survive the build. I owned the spec and tickets myself, to one rule: point engineers at the source of truth, don't transcribe it - restating a decision is how a spec and a design quietly drift apart and contradict each other months later.

07.

Running the research, not just sitting in it

The first round had been unmoderated, and it produced "don't like it" with no why - useless for a decision this subtle.

So I switched to moderated sessions and ran them as a loop, not a batch: redesigning overnight and re-testing the same areas the next day, so each session's findings steered the next session, not just the next design pass. That tighter loop is what surfaced the fear-driven toggling a one-shot study would have averaged away.

08.

Outcome

The feature launched to enterprise clients first, then rolled out across the wider customer base - replacing email and spreadsheets with a structured, embedded workflow.

Candidates

4.5k

4.5k

Candidate submissions

Candidate submissions

References

14k

14k

References completed

References completed

Completion Rate

81%

81%

Referee forms completed

Referee forms completed

Repeat usage

78%*

78%*

Companies that have run 10+ references

Companies that have run 10+ references

Statistics taken 9 months from release

Request Reference

Reference Setup

Submit Reference

09.

Reflection

The referee form and the admin dashboard needed completely different design philosophies - one needed to disappear, the other needed to give control. Trying to serve both with the same approach would have produced something mediocre for everyone.

It also reinforced my approach to MVP scope: knowing which 20% delivers 80% of the value - and being precise about what you're deferring and why.