Coople applicant tracker

Discovery began with grounding the team in the lived experience of the three audiences this product had to serve: Operations, Companies, and Workers. I ran a round of interviews with each group to surface the real frictions in their day-to-day — the unspoken workarounds, the moments of confusion, the steps that quietly stretched into hours. Alongside the qualitative work, a 617-respondent survey gave us a quantitative read on employment context and intent, so the patterns we heard in conversation could be sized against the broader user base.

From there, I mapped the competitive landscape — pulling apart applicant tracking and recruitment tools across HR, staffing, and marketplace categories to understand the mechanics each had converged on (and the ones they hadn't). The audit produced a wall of annotated flows that the team could reference when debating specific interaction patterns later.

With the external picture in place, I ran prioritisation workshops with Product Managers across three business lines — CH Ops, UK Ops, and Marketplace — to consolidate the problems we'd uncovered into a single ranked backlog. To pressure-test the resulting flows against system reality, I joined event modeling sessions with engineers, walking through each scenario (Create Assessment, Start Application with and without pre-screening, Move Candidate, CV screening, Failing the video interview stage, Comment) until edge cases and dependencies were visible to everyone in the room.

In parallel, the PM and I agreed on three metrics that would tell us whether the redesign was actually working: time spent processing a single applicant, percentage of fully staffed jobs, and a worker-matching quality score. Those numbers became the anchor for every later trade-off.

With the discovery findings in hand, the next step was translating constraints into structure. I started on paper, sketching the main ideas before committing any of them to pixels — quick passes through layout, hierarchy, and stage transitions, each annotated with what worked and what didn't. The sketches let me move fast across the problem space without getting attached to any single direction.

From the sketches I built out four distinct concepts in higher fidelity, each pulling on a different mental model for how recruiters might triage candidates: a horizontal pipeline with stage columns, a vertical stage list with an inline detail panel, a flat candidate list with stage filters, and a hybrid combining the pipeline and the detail panel side-by-side. I walked the PM through all four in design review, working through the trade-offs of each — density, scannability, stage-change ergonomics, fit with the underlying data model — and we narrowed to the two strongest directions.

Those two went into a working session with the Operations team. Rather than presenting and asking for opinions, I had them interact with each concept in turn and talked through the process in detail — where they paused, what they expected to happen next, what they couldn't find. The verdict was clear: concept one, the vertical stage layout with drag-and-drop, mapped most closely to how they actually move candidates through the pipeline today.

From there, refinement was driven by a series of follow-up calls with PM, Developers, and Operations to pressure-test the details: filtering behaviour, the matching score visualisation, multi-select for bulk actions, and the interview-stage filters. Each conversation produced concrete adjustments — what should be visible at row level vs. on the detail panel, where filters belonged in the layout, and how the matching score should be expressed without crowding the row.

Once the prototype was stable, I ran another round of testing — this time task-based, asking users to complete real applicant-management flows end-to-end. All participants successfully completed the tasks, which gave us enough confidence to lock the IA and move into final design.

Throughout the whole arc, I kept the work visible in design reviews — collecting structured feedback from managers, product owners, and other stakeholders across a Liked / Ideas / Challenges / Questions board so that input was captured and resolved rather than lost between meetings.

The pipeline view became the system's primary surface — a single screen where every applicant for a job lives in a stage column, and movement between stages is a direct manipulation rather than a status-field edit. It mirrors the way recruiters already describe their work and collapses three legacy tools' worth of context-switching into one canvas.

Each stage expands into a row-level list with the actions recruiters reach for most — Move forward, Reject, Watch video — surfaced on hover instead of buried in a menu. A checkbox column enables bulk processing for higher-volume roles, and a matching score on every row keeps candidate ranking visible without forcing recruiters into a separate view.

Video screening is decision-heavy, so it earns its own overlay rather than inlining a player into the row. Recruiters can step through each question, download the recordings, leave private notes, and decide the candidate's next stage — all from a single surface, with the pipeline still in place behind it.

Comments live in a dedicated panel — attributed and timestamped — rather than as ad-hoc text on the row. Operations and recruiters work the same candidates across the funnel, so a chronological thread is the smallest reliable unit of shared context between them, and the panel makes it easy to pick up wherever the previous teammate left off.

A one-week diary study with six recruiters validated the IA before lock. Findings drove two refinements: SLA badges moved from row-end to row-start to read in left-to-right scan order, and stage transitions gained an explicit confirmation step after testers consistently triggered them by mistake.

Two challenges shaped most of the design decisions on this project — one rooted in the differences between our two user audiences, and one in fitting the right amount of information into a single screen.

Coople Applicant Tracker serves two distinct audiences: Companies clients, who post jobs themselves, and Coople Operations — our internal team supporting enterprise clients. Their workflows diverge in meaningful ways.

Due to legal constraints, Companies can't save worker information, download interview videos, or view candidate documents — restrictions that don't apply to Operations. Rather than collapse both audiences into a single compromised flow, I designed two parallel experiences tailored to each platform's actual permissions and needs.

Stretching the pipeline across too many columns hurt both readability and responsiveness. To keep the view clear, I capped the layout at eight columns — a deliberate trade-off that reduces cognitive load without sacrificing the insights recruiters rely on, and gives the layout room to adapt across screen sizes.

In practice, most jobs consist of three to four stages, so the eight-column ceiling rarely feels restrictive.

This was a project where the central problem was reconciling two distinct user types — Operations and Companies — whose needs differed enough to shape almost every decision in the final interface. The lesson that stuck: when audiences diverge that sharply, parallel flows beat a unified one that compromises for both.

Each step extends the platform with a way to create offers directly from the pipeline, and lets workers sign them inside the Coople jobs app — closing the loop between recruiter decision and worker commitment without leaving the product.

Offers creation moves the contract step into the surface recruiters already work in. A single offer is authored once, scoped with visibility and project flags, and attached to as many companies and shifts as the role demands — no separate tool, no copy-paste between systems.

Signing closes the loop on the worker side. Once the recruiter sends the offer, it arrives in the Coople jobs app with the schedule and rates already in place; the worker reviews, signs with a finger, and the electronic signature carries the same legal weight as a handwritten one — so the contract is binding the moment they tap Sign.