UKG: five years inside an HCM suite

Five years at UKG, leading experience design for Talent — the People Products group covering HR, recruiting, onboarding, performance and employee perception — inside an HCM suite serving around 5,000 organisations and 15 million employees. I led a team of ten designers and researchers.

I joined Ultimate Software on the recruiting team. Partway through, Ultimate and Kronos merged to become UKG, which meant two mature product organisations, two design systems, two sets of conventions and two sets of customers who each believed their version was the right one. The "cross-platform rebrand" on my resume is that: carrying an experience through a merger without letting accessibility be the thing that gets dropped while everyone argues about navigation.

That scale changes the nature of the work in a way that is easy to underestimate until you are inside it.

What enterprise HCM actually demands

Most design advice assumes you can simplify. At this scale you frequently cannot, because the complexity is not decoration — it is somebody's payroll regulation, somebody's union agreement, somebody's accommodation.

So the discipline is different. The question stops being "how do we make this simpler" and becomes "how do we make something genuinely complicated feel navigable to a person who uses it for twenty minutes a week, and fast to a person who lives in it eight hours a day." Those are different people and the same screen.

Three things I would hold onto from that period.

Consistency has a cost, and you have to name it. When I put navigation models side by side for UKG Pro, the house pattern from Ignite — the design language system — was correct on paper and marked with the thing that actually decides the argument: it is a paradigm shift for people who have had the old shape in muscle memory for a decade. A navigation proposal that does not say who it hurts is not a proposal, it is an advert.

Accessibility at this scale is a systems problem, not a screen problem. Fifteen million employees means every disability is represented many times over, and no amount of per-screen remediation keeps up. What moves the number is getting the behaviour into the shared components, which is the argument I have been making in one form or another ever since.

The interesting problems are workflows, not features. Scheduling an interview looks like a form and behaves like a constraint solver: who is qualified to interview, who is free, whether they are still shadowing, whether they have already taken three this week, all while availability shifts underneath the recruiter.

And the research kept saying the same uncomfortable thing. A jobs-to-be-done study our researchers ran across the recruiting customer base — 184 participants from 148 companies, 201 job statements, sixteen interviews — found that the most satisfied customers were the ones from smaller organisations with simpler hiring processes and little need for reporting or analytics. Read plainly, that says the product served the easy cases well and the hard ones badly, and the hard ones were the enterprise accounts. Findings like that are only useful if you let them be insulting.

The two pieces with the most in them

Great Place To Work Hub — mapping demographic data against employee belonging sentiment, so leaders could see where their organisation was actually failing people rather than where they assumed it was. It ends on hiring funnel analysis broken down by gender and ethnicity: 326 applications narrowing to 8 hires, with the share of men rising at every stage. Putting that in front of the person who runs the hiring process is a design decision with teeth.

Recruiting workflows and navigation — the UKG Pro navigation study, the interview scheduling panel, and a candidate cultivation campaign builder for the majority of candidates who are not ready to apply yet. Written up separately and not published yet, because the sketches evidence the thinking and I want the outcomes beside it before it goes out.

I also carried the HCM experience through a cross-platform rebrand without losing accessibility ground, which sounds like housekeeping and is in fact where most accessibility gains quietly disappear.

What I took with me

The pattern I now build deliberately, I first watched fail here.

A shared component library exists. Teams consume it. Someone finds a problem while building a screen, fixes it locally because that is the fast path, and the shared thing never learns. Multiply by ten teams over five years and you have a suite that is consistent on paper and divergent in practice, with accessibility debt distributed so evenly that no single team owns any of it.

Everything I have built since — putting the design system in code, making contribution as cheap as consumption, letting drift flow back upstream as a pull request — is an answer to a problem I first understood properly at this scale.

Which is the argument for spending years inside one large product. You do not learn what breaks a design system from a small one. You learn it from a suite big enough that the breakage is structural, slow, and nobody's fault.