Redesigning a candidate management experience of 58k+ monthly active users — and learning, the hard way, what it takes to ship a redesign at scale.
The candidate pipeline is where recruiters live. It's the screen that lists candidates for a job and shows each profile side by side — and it carries more traffic than anything else we build.
When we mapped every action in the product against how often it's used and how many people touch it using the Red Routes matrix, the candidate pipeline dominated the top-right corner: the things people do always, and that most or all customers rely on. That's a thrilling place to improve — and a terrifying place to break. Every design decision here is multiplied by millions of clicks a month.
Gathering pain points, customer interviews, endless iterations, an alpha release and a closed beta — all to reshape the screen recruiters use most.
Left: the layout recruiters had used for years. Right: the redesign that went through alpha and closed beta before reaching everyone.
A redesign this central can't run on opinion. We looked into qualitative and quantitative signals from the first sketch to the open beta.
We'd done the research. We were confident. Then the open beta went live — and the feedback landed like a punch.
“It is useless. I hate it.”
— one of the 1,719 feedback responses we received
We had tested extensively — so why the backlash? Three things we hadn't weighted heavily enough:
Despite all the interviews and testing, day-to-day use of a product is different. People behave in the flow of real work, not in the frame of a study.
To experiment safely, we rolled the redesign out first in a less-used area (the Candidates page) before touching the "nuclear reactor" — the candidate pipeline's job view.
Because the redesign was already live on the Candidates page, the beta for the candidate pipeline became available without an opt-in. Users were switched over without choosing to be — which caused frustration and even a drop in PSAT.
Improve the candidate pipeline & profile in the weeks and months after the beta release — recover trust and make the screen genuinely better.
Using user feedback and multiple data sources — quantitative and qualitative: recordings, interviews, analytics — we identified real pain points and real user needs. With plenty of ups and downs.
…along with our mood. Each fix moved the needle — some down before they went up. Here's the ride, one problem at a time.
Our first big surprise came from a question we thought we already knew the answer to: how much screen space do recruiters actually have?
Most of our users work on big monitors, so they have a full and clear view of the candidate list and profile.
Most users do have big monitors — but they multitask, running several apps in separate windows (e.g. Candidate profile next to Google Meet during interviews). The effective window is much smaller than the screen.
Three sources pointed the same way: Hotjar feedback, session recordings, and analytics on window width vs. screen size.
"Struggle to see the entire layout on a small laptop screen."
"There isn't much screen left to look at each candidate."
"The new format can't handle different page sizes."
The single most common window width was a modest 1340–1559px — not the expansive canvas we'd designed for. Nearly half of all sessions ran below 1560px wide.
Sometimes a helpful idea is too clever. Our "smart" default for the profile tab is a case in point.
If someone has already viewed a candidate's details once, next time they'd rather land on the Timeline to see all the latest activity.
"Smart" system behaviour is hard for users to understand and predict — and unpredictability creates frustration.
"I dislike how, when you click on a candidate profile, it takes you straight to the Timeline tab."
"You need to go back to the Profile tab to remember the CV & the candidate most of the time."
Analytics backed the complaints: tab navigation went up and time-on-candidate went up — people were doing extra work to get back to the view they actually wanted.
A pattern that feels fine once can become punishing at scale. Editing custom fields in a modal was exactly that.
Editing a field in a modal is quick and intuitive — one modal is OK.
Most users edit custom fields one after another — for example completing several during an interview. One modal becomes a looot of modals, and the flow falls apart.
"Fill out custom fields without having to click each one and respond in a pop-up window. I fear this will take much more time when custom fields are used to pass quick information from recruiters to hiring managers."
"They use custom fields for evaluation — too many clicks, they lose the flow during the interview."
A funnel of users filling in a 2nd & 3rd field within one minute confirmed it — the biggest drop-off happened right after the first answer.
The climb continues. We're testing whether a simpler, more versatile structure makes information easier to find across Profile, Timeline, Communication, Evaluation and Comments.
Offering a simple & versatile structure will make finding information easier.
Three groups — a control group, an optional pilot (10%) and a forced pilot (5%) — with opt-in and opt-out of the feature available throughout.
This time, the rollout itself is designed as carefully as the feature — with a control group and a real choice for users.
Everything above distilled into five principles I'll carry into the next redesign.
Build a habit of testing — and test in live environments whenever you can. Studies don't fully predict real use.
Design not only the new feature, but the way it's introduced to users. Consistent, opt-in patterns matter as much as the UI.
Tracking a feature after launch is vital to see how it really performs — the work isn't done at ship.
A single source can't tell the whole story. Data triangulation — quant plus qual — is the way to go.
Take feedback with a grain of salt: disappointed users are far more likely to speak up than happy ones. Weight it, don't just count it.