Redesigning a candidate management experience of 58k+ monthly active users — and learning, the hard way, what it takes to ship change at scale.
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.
| Role | Sole product designer — discovery through post-beta recovery |
|---|---|
| Team | Product manager · research team · two front-end teams (10 engineers) · back-end team |
| Owned | Problem framing, interaction design, prototyping, the assumption-vs-reality analysis, and the opt-in rollout |
| Information architecture | Defined after extensive testing with the research team |
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. Internally, we call it the “nuclear reactor.”
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 redesigned layout as it reached the open beta — the first version everyone saw.
What changed: a unified candidate view, a fully responsive layout, and a clearer information architecture.
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 cross-job Candidates page (a global list of everyone in the database) — before touching the "nuclear reactor": the per-job pipeline where recruiters spend most of their day.
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 (product satisfaction).
…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 lot 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."
Most users edit fields back-to-back — ~66% moved straight on to a second field within a minute, and 43% to a third — so a pop-up for every field taxed a genuinely common flow.
We tested whether a simpler, more versatile structure made information easier to find across Profile, Timeline, Communication, Evaluation and Comments — then shipped it.
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.
The new structure shipped, and the one-week-after survey came back positive:
Based on ~190 responses in the week after launch; ongoing in-product feedback has stayed in a similar range. The rollout itself was designed as carefully as the feature: a control group and a real, opt-in choice for users.
Where the pipeline & profile landed after the post-beta improvements — and the decisions behind them.
The launch hit satisfaction hard — then the fixes brought it back, and it held.
| At launch | ~10 pt PSAT drop — a two-year low |
|---|---|
| Recovery | Back to pre-launch levels in ~3 months |
| Today (H1 2026) | Core SMB segments in the low-80s, up ~7 pp YoY |
A run of fixes — defaulting to the profile, a lighter full-page layout, and a responsive design down to ~1340px — pulled sentiment back to pre-launch levels within a quarter and quieted the UI complaints. It has held since; the later SMB gains reflect more than this redesign alone.
Leading signals moved with it: fewer tab switches, more time on the candidate, and higher inline-field completion.
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.