Atlas ATS
How we designed a new applicant tracking system where AI agents save recruiters' time - from product strategy to agent concept.
Atlas is a recruitment tech company that runs a job board - a website where employers publish job postings and candidates apply. The company offered a simple, free tool for viewing applications, but it was too basic. Bigger clients kept switching to competitors with full applicant tracking systems (ATS) - software that manages the whole hiring process, from receiving applications to making an offer.
Atlas decided to build something more ambitious: a product where AI agents take over the repetitive work that eats recruiters' time. This was the key idea and the main innovation on the market - not AI as a marketing label, but agents built into the recruiter's daily workflow.
I was part of the expert team shaping this product from day one.
- Team - a small group of senior experts: product, design, engineering, business.
- Format - weekly, multi-hour strategy workshops where we defined the product concept, direction, and priorities.
The core of this project was the weekly workshop rhythm. Every week, the expert team spent several hours in one room working through product strategy: what this ATS should be, who it serves, and where AI genuinely helps. Between workshops, smaller groups explored specific topics and brought conclusions back to the table.
Our decisions were grounded in three types of research:
- Competitive research - qualitative studies of three different ATS products, desk research, deliberately different from each other in size, target clients, and approach. This gave us a real map of the market instead of one reference point.
- Internal research with recruiters - interviews with people who run recruitment every day. This is where we learned which tasks actually consume their time.
- Prototype testing - we didn't settle big design debates by opinion. When the team disagreed on a direction, we built prototypes and tested them with users.
The research gave us clear personas with very different needs.
This split shaped the whole product: one system, but different views and permissions per role.
This was the most important design work of the project. The question we kept asking: where does a recruiter lose time, and can an agent take that work over? Every agent had to answer a real problem from our research - no agent just because AI is trendy. I owned the concept and interaction design for each agent below, translating the team's research findings into specific product decisions.
The product launches in two versions. Both follow the same flow underneath - create the recruitment, define details, build the job posting, set up the form, publish. The difference is who they're built for and how much of that flow the user controls.
As the senior product designer on this, I led the desk research, competitive analysis, detailed feature breakdowns across both plans, and built interactive AI prototypes to test the key assumptions with real users.
- Four fixed recruitment stages - set automatically, not configurable,
- Default application form - customization available as a paid add-on,
- Domain job board posting creator embedded in the interface - no leaving the tool,
- Publishing to domain job board only - the recruitment project is created automatically in the background,
- Candidates tied to the job posting they applied to - no standalone database.
- Multipublishing across many job boards, with unique tracked links per platform,
- Fully customizable application form - own questions, own stages,
- A real candidate database - candidates persist beyond a single job posting,
- Recruitment templates - reusable setups instead of rebuilding each time,
- Advanced reporting across all recruitment projects,
- Confidential recruitment and candidate shortlists,
- System-level add-ons - bought once, applied to every project,
- Full automation of all of the above.
The simplest way to read it: freemium is the standard way to hire; self-service (PRO) is what the same company needs the moment its hiring gets more complex than the defaults can handle.
The two segments don't just need different features - they think in opposite directions, so each plan got its own entry point into the same underlying flow.
Freemium is posting-first. The user comes to publish a job posting and goes straight into the domain creator, embedded in the interface. While they build the posting, the system quietly assembles everything else: a recruitment project with the four default stages, the standard application form, publication settings. When the ad goes live, a working ATS is simply there - the user never had to set it up.
Self-service is recruitment-first. The user starts by creating the recruitment: defining its stages, team, and permissions, customizing the application form. Only then do they build one or more job postings on top of it and decide where each one publishes - which job boards, with which content, tracked per source. The posting is a consequence of the recruitment, not the other way around.
Instead of forcing one flow on both groups, we treated the two entry points as hypotheses and tested them with prototypes.
This work took the product from an ambitious idea - AI agents handling recruiters' repetitive tasks - to a concept validated through research, competitive analysis, and prototype testing with real users. The agent roles, the two business models, and the core recruitment flow all held up under that testing.
The next phase is build: taking these validated concepts from prototype into the actual product, with the same close collaboration between design, engineering, and user feedback that shaped this stage of the work - and continuous testing with users across all segments.