APPLICANT TRACKING SYSTEM · B2B SAAS
Xseed.AI renders the same screen differently depending on who’s logged in. Three roles, with the recruiter split into admin and view access. One screen renders four ways, and engineers build a permission gate for each. I designed those screens in Figma, then wrote the React that shipped them.
ADOPTED BY
tCognition’s in-house staffing team
TEAM
11-person team
TIMELINE
Jan 2023 to Apr 2024, 16 months
TOOLS
Figma · React · TypeScript · JavaScript · Material UI · Jest
COMPANY
tCognition LLC, a 175-person IT staffing firm on 4 continents
STATUS
Shipped B2B product
THE CHALLENGE
Three roles share one hiring loop and see different slices of it.
An applicant tracking system covers the whole loop: post a job, source candidates, move them through stages, submit them to a client, onboard the hire. A design file organized by feature hides the thing engineers actually build against, which is the role.
THE SOLUTION
Hand off by role, then build from components that hold every state.
I organized the Figma handoff by role and access level, built the component library the screens are assembled from, wrote frontend-ready specs, and converted them into production React.
roles
screens
Forty-eight desktop screens on the recruiter handoff page alone, from login validation to the templates master.
components
filter states
Components on the design-system page, and the job list’s filter panel drawn seven times as variants of one component.
An applicant tracking system with three front doors.
Xseed.AI is tCognition’s applicant tracking system, and the firm’s own staffing team adopted it. Recruiters post jobs with scraped enrichment, parse resumes, rank candidates with ML, schedule interviews, manage offers and onboarding, and read analytics. Candidates register, build a profile, upload a video resume and track their applications. Admins manage users and roles, plus the integrations with MSP and VMS platforms.
I joined in January 2023 as a final-semester intern and the role converted to full-time. For sixteen months I sat between the designers and the codebase, in person in India. tCognition already had a product-requirements process and I worked inside it. React and TypeScript on the front, Material UI for the components, Spring Boot services behind.
I worked across the recruiter and candidate surfaces. The file structure and the component library are the parts I can walk through page by page.
Everything in the file follows one loop.
Create a job in three steps: job details, hiring workflow, attract candidates. Source candidates into pools, then move each one through the pipeline from Applied to Submitted to Client. The pipeline reads back on the job page.
The hiring workflow step is where the role model shows. Each person on a job’s hiring team carries an access level, job admin, edit access or access requested, and the stages are an editable list with a default set to fall back on.
Figure 1. The hiring workflow step of the new-job wizard. Access is set per person, and the process is a list the recruiter edits, with a default to fall back on.
One page per role and access level.
Engineers build a permission gate, then another. A file grouped by feature makes them answer the same question on every screen: which of these does a view-access recruiter get?
I organized the handoff so each role and access level had its own page, with a templates master and a mid-fidelity work-in-progress page kept away from handoff truth. The recruiter admin page holds the login flow with every validation state, the job list, the new-job wizard, the job workflow and the candidate views, with redlined spacing specs beside the screens they describe. An engineer building a gate opens one page and sees everything that role sees.
The structure I turned down
One page per feature with role annotations. It reads well for designers and badly for the person implementing a gate.
Figure 2. The file’s pages panel in Figma: one page per role and access level, with the mid-fidelity work in progress kept apart.
Design it, then find out what it costs.
Because I wrote the React as well, the handoff shortened. I’d design in Figma, then implement or pair on the same screens, with WCAG 2.1 AA contrast and keyboard patterns carried through the component library into every recruitment module.
Contrast, focus order and keyboard paths were decided in the component, so every screen inherited them. Building my own designs changed how I designed. A state that looks free in Figma can cost a network request or a refactor. Knowing that, I started drawing the states an engineer needs annotated and leaving out the ones the component already answers.
One component carries all of its states.
An engineer gets one component with every state it can be in, and builds from that.
Two screens I can point to. The job listing carries its filter sets as variants of one component, so the filter panel, the applied-filter chips and the empty state come from the same source. The candidate detail carries an embedded resume viewer, a pipeline stage bar and the save and submit actions, again as one component with variant properties.
Figure 3. The job list’s empty state, one of seven filter states drawn as variants of the same component.
Figure 4. The candidates view: pools, bulk actions and skill tags on every row. Every control on it comes from the library.
410 components, six type sizes, one primary ladder.
For states to live in variants, the library had to hold them properly.
Buttons with default, hover and pressed states, inputs with validation, table atoms, pagination, the top action bar, filters, checkboxes, step tabs and modals, plus a preloader. Six type sizes at four weights. A seven-step primary ladder and four secondary colors for status.
- Button (default, hover, pressed)
- Input (validation)
- WYSIWYG toolbar
- Navigation L1 / L2
- Table cell
- Table header
- Pagination
- Top action bar
- Filters
- Checkbox / Radio
- Column chooser
- Step tabs
- Add member
- Modal
- Preloader
- Icons
Shipped in React, with me on both the spec and the code.
The role-based file plus the shared components meant a new module could start from the library and the right handoff page.
Clarification messages from engineering after each handoff dropped. I didn’t count them, so I keep that directional.
If I were measuring it now, I’d track clarification messages per sprint against the months before the library, time to first screen for a new module, and an accessibility audit pass rate across modules. The library followed AA patterns, and no module had a formal audit.
Where the direction changed.
Sitting next to designers is where my direction changed. I’d watch a real recruiter frustration turn into a simple screen through a series of small, careful decisions, and I wanted to make those decisions as well as build them.
I left in April 2024 for the MS in User Experience at Arizona State.
Project takeaways.
Anchal Nagdev