Context
AMS One was not a redesign of a single product. Different recruiting tools had grown around different parts of the workflow, with their own structures, behaviours and dependencies. Recruiters and sourcers had to move between products while working on the same task, losing context along the way.
The wider ambition was to create one product environment that could support different recruiting roles through shared building blocks and behaviours.
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 during migration and where an intermediate solution was safer than the ideal future state.
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, the work developed across three connected streams: migrating priority workflows, improving active product areas, 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.
Product migration
Migration decisions depended on the part of the product.
Requisitions
Requisition detail still depended on Digital Recruiting, which split the experience across products.
Instead of using the existing screen as the blueprint, I explored what recruiters needed to understand and act on inside AMS One. 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.
Reusable patterns
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
The inherited recruitment statuses were too limited for the range of workflows AMS One needed to support. They evolved towards shared primary stages with more flexible secondary statuses. The same model could then support tables, pipelines and kanban views without creating a different workflow model for each surface.
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. WCAG AA was established as the expected standard, influencing how shared components, interaction states and patterns were defined across the product. As patterns were tested across real product areas, repeated decisions became clearer and stable enough to turn into shared rules. I led the direction and review the design system, while coordinating another designer working across much of the system UI and component work.
AI
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 established a clearer direction from several recruiting tools towards one modular product. Priority workflows could move incrementally without making the legacy structure 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.