UKG: ten designers and researchers, one portfolio
I ran design and research across the whole UKG portfolio and Great Place To Work — 5,000 organizations, 15 million employees. A study we commissioned found the product served the easy customers well and the hard ones badly. That set the next two years.
- Role
- UX manager — design and research across the portfolio
- Year
- 2018–2023
- Built with
- Design leadership, Research, Information architecture, Accessibility, Design systems
Five years, ten designers and researchers, across the whole UKG portfolio and Great Place To Work. HR, payroll, recruiting, onboarding, performance and workplace culture analytics, used by about 5,000 organizations and 15 million employees.
Partway through, Ultimate Software and Kronos merged. Two mature product organizations, two design systems, two sets of conventions, and two sets of customers each certain theirs was the right one.
The finding I let the team go get
Our researchers went at the recruiting customer base properly: 184 participants from 148 companies, 201 job statements, sixteen interviews.
The most satisfied customers turned out to be the smallest. Simple hiring, 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 paying for it.
A finding is only worth commissioning if you will let it be insulting. That one set what my team worked on for the next two years.
Scheduling looks like a form and behaves like a constraint solver
Who is qualified to interview for this requisition. Who is free. When the candidate is free. Who has been trained, who is still shadowing, who has already taken three interviews this week. All of it moving while the recruiter works.
The panel we drew is the reduction. A candidate, a date, and a calendar connection so availability comes from the source rather than a copied-in email.
Then a message field, because the last mile of scheduling is always a human sentence to a nervous person.
The judgment is in what is not on the screen. Every extra control is a recruiter deciding something the system already knew.
A builder where the third screen is the first screen
Candidate cultivation is for the people not ready to apply, which at enterprise scale is most of them. A campaign builder has to be obvious empty and powerful three steps later, and those pull against each other.
So the chrome never changes. A rule is a chip between two messages. Adding a step inserts a row rather than opening a settings panel. The empty state is the same design holding one message.
Every new capability arrives as another instance of something already on screen, or it does not arrive. Get that wrong and the empty state and the expert state drift into two products.
Navigation for a suite that outgrew its map
The structure that comfortably held twelve destinations was holding sixty, and the people who had used it daily for a decade had muscle memory built on the old shape.
I had three models drawn against each other, each in more than one state, because a navigation model is only as good as its second screen.
- The legacy pattern, annotated with what was wrong: it did not scale, and its accessibility problems were structural rather than cosmetic.
- Our design language system's common navigation — correct on paper, and a paradigm shift for everyone who already knew where things were.
- A hybrid, left navigation for high-level content and tabs beneath it. Less pure, and the one I proposed.
A navigation proposal that does not name who it hurts is not a proposal, it is an advert.
Draw the option you intend to reject at the same fidelity as the one you want. It is slower, and it is the only kind of proposal that survives the people who have to live in the result.
What these drawings do and do not show
They show how each problem was framed, which options went side by side, and the costs we annotated on the ones we rejected.
They do not show what shipped. I have no numbers here I can stand behind, and a sketch dressed in an outcome it did not earn is worth less than a sketch.
The analytics work the team did is in Great Place To Work Hub.
The lesson I have been answering ever since
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 behavior into the shared components.
Which is where I watched the pattern fail. A shared library exists, teams consume it, and somebody hits a problem while building a screen and fixes it locally because that is the fast path. The shared thing never learns.
Multiply that by ten teams over five years. The suite ends up consistent on paper and divergent in practice, with the accessibility debt spread so evenly that no single team owns any of it.
Everything I have built since is an answer to that: the design system in code, contribution as cheap as consumption, drift flowing back upstream as a pull request.
I did not learn what breaks a design system from a small one. I learned it from a suite big enough that the breakage was structural, slow and nobody's fault.