Context
Different recruiting tools had grown up around different parts of the workflow, each with its own structure, behaviours and dependencies. Recruiters and sourcers moved between them constantly, working the same task across products and losing context every time they switched.
The wider ambition was one product that could support different recruiting roles by sharing the same underlying building blocks.
Problem
The challenge was not simply moving features into a new interface.
Copying the existing tools would also copy the structures and inconsistencies we were trying to move away from. But redesigning everything at once was not realistic either: legacy products were still in use, dependencies remained active and several product areas had to move in parallel.
We needed to decide what should stay familiar, what could change along the way, and when a temporary fix was safer than holding out for the ideal solution.
Approach
I started by looking across the existing products for repeated behaviours, inconsistencies and places where moving between tools interrupted the user journey. I worked with product managers and the UX research team to understand the evidence already available, technical dependencies and the priorities shaping the roadmap.
From there, three things happened at once: migrating the priority workflows, improving the product areas already in active use, and turning repeated product decisions into shared patterns.
We did not try to define the final product or a complete design system upfront. Product work and system work evolved together.
The legacy products couldn’t be the blueprint
I treated the legacy products as evidence of what recruiters needed to do, rather than as screens to reproduce. That distinction shaped every migration decision — what stayed familiar, what changed, and how much of the old structure was worth carrying forward.
Requisitions
Requisition detail still depended on Digital Recruiting, which split the experience across products.
For Requisitions, that meant exploring what recruiters actually needed to understand and act on inside AMS One, rather than copying the existing screen. We preserved behaviour where migration risk was higher and reconsidered the structure where carrying the legacy forward would create longer-term problems.
Candidate Profile
Candidate Profile needed to work differently. Recruiters often needed candidate information while already working inside another workflow, without losing their current context.
We designed candidate information at two levels: a quick view for accessing the essentials in context, and a dedicated profile when deeper review was needed. This also supported a clearer distinction between Candidate — the person — and Application — that person’s progress for a specific requisition.
Finding what the workflows could share
Different products had evolved different ways of representing similar recruiting concepts — candidate information, application stages, secondary statuses, table, pipeline and kanban contexts, templates. My job was to work out what could become shared product structure without removing the flexibility recruiters needed.
As more product areas moved into AMS One, the same needs started appearing in different workflows. At that point, solving each screen independently stopped making sense.
Applications
Several legacy tools represented candidate status differently, and carrying those differences into AMS One would have carried the inconsistency too. Instead, I worked towards a shared set of primary application stages, with secondary statuses flexible enough to fit different recruiting contexts. The same model could then support tables, pipelines and kanban views without needing a different structure for each one.
Forms
Forms appeared across Briefing, Job Advert, Screening and other areas. Building each one separately would have repeated the same configuration rules and behaviours, so we separated the reusable template from the form completed inside a workflow. Administrators could manage the structure while recruiters used it in context.
Design System
The same product work also showed us what the design system actually needed to support. The first foundation was deliberately transitional rather than an attempt to predict every future requirement upfront.
Accessibility was part of that foundation from the start. We set WCAG AA as the standard, and it shaped how shared components, interaction states and patterns got defined across the product. As patterns got tested in real product areas, the decisions that kept repeating became clear enough to turn into shared rules. I led the direction and review of the design system, while coordinating another designer working across much of the system UI and component work.
Building AI into a workflow people already used
Briefing introduced a different product question: how could we add AI without moving recruiters into a separate AI experience?
We explored AI inside the existing briefing flow. The experience included consent, call upload and transcription, generated content and human review. A rerun could replace AI-generated content while preserving the recruiter’s own edits.
What this enabled
AMS One gave the team a clearer direction — from several recruiting tools towards one modular product — and let priority workflows move incrementally without treating the old structure as the model for what came next.
Candidate/Application, shared stages and Template/Form provided clearer structures that could work across different workflows. At the same time, real product work gave the design system concrete contexts to learn from rather than asking the team to predict every future need upfront.
The project reinforced two ideas for me: a migration does not always need to move directly from the old state to the ideal state, and the strongest system patterns are often the ones that have already survived real product work.