ClearCo: rebuilding a research and design team for agents

When I joined ClearCo, design ended with a file handed to engineering. Research happened when somebody had time, with no protocols and no agreed way to write down what we heard. Accessibility problems surfaced months after the decisions that caused them.

A year later, designers and product managers ship features in the production monorepo every day, through the same review gate as the engineers. Something a customer says on a Tuesday call can be in front of them the week after.

Design, research and accessibility are mine. Most of what follows is not about models. It is about what a team has to become before a model is any use to it.

Underneath it sit fourteen applications in human capital management, four industry-specific tenants and nine personas, running and under test at the same time. I drove it from a blank repository. The personas run from recruiters who live in the product eight hours a day to frontline employees who open it four times a year on a phone. A team handing over drawings has no way to check even one of them.

Persona and tenant are things you change, not things you rebuild for, so any combination is one dropdown away from being looked at — including by the person whose job it describes.

Everyone is an engineer who designs and makes quantifiable decisions

Not a change of tools. A change of standing.

The goal was never to turn designers into engineers. It was to take out the handoffs that stopped anyone owning the outcome. Telling a traditional UX team to design in code would have failed on its own. So it started in a sandbox: the real design system on fake data, where nothing could reach a customer. Three months later everybody had moved into the monorepo.

I underestimated that part for longer than I should have, because from where I stood the change was obviously good. Asking people who are expert at their work to be beginners in public, in a system where being wrong leaves a permanent record with their name on it, is not a tooling problem. Six things made it work.

The designer who picks a gray that fails contrast finds out from the build, in the minute they picked it. It used to surface eleven months later, in an audit note to a team that had not chosen it.

Shipping the foundations

We started from no shared specifications at all. Fourteen products, and no agreed answer to what a button was.

A design system program is usually a two-year argument with nothing delivered in month two. I ran it as four deliveries instead, each useful before the next one started: a tokens repository, the legacy product restyled in those tokens, the component library as versioned packages, and the boilerplate.

The first landed in thirty days. The restyle reached customers within weeks.

The material is dull on purpose: Style Dictionary for the tokens, Mantine under the components, Storybook where people read them, axe in the pipeline. What we argue about is what the system should refuse to do.

The boilerplate took two weeks, mostly with an AI agent. Two days after I showed it, somebody copied it into their own repository without being asked. That is the only adoption signal I have ever trusted.

Figma went from the center of the work to almost unused. We cut that bill by 60% and moved the difference into AI tokens.

Behavior written down before it is built

Testing is part of designing here, not a pass afterward. For the interactions that matter, the expected behavior gets written down before the feature counts as finished. That means keyboard paths, where focus lands next, the accessibility requirements for the pattern, each component state, and the workflows that keep regressing.

If an interaction matters, a person should not be the only thing that can check it.

What did research look like before?

Informal. Whoever had time, however they felt like doing it, with nothing written down afterwards that anybody else could use.

Working product now goes in front of customers every week, usually well before it is polished.

Build, use, observe, learn, improve.

Sessions run on the product itself, with persona and tenant set to the person in the room, so nobody is asked to imagine the rest of their own job.

Research sits with me now, and it is getting protocols for the first time. There is one route for whatever customers tell us, whether that turns up in a session, a support ticket, a call with customer success, or a question put to product education.

I cannot separate what those sessions changed from what we would have found later on our own. What I can point at is the cadence, and the decisions that moved in the room.

What AI actually exposed

AI did not replace any of this. It exposed every part of the design process that had never been made explicit.

Every process has parts nobody wrote down. They stay invisible until something that cannot ask you a question tries to follow them.

An agent that needs a fact it does not have will not ask for it. It invents a token, a spacing scale, a component that looks right and shares nothing with ours — confidently, across every file it touches.

So I made three things true before an agent was allowed near the design system. Readable: a specification, not a reference. Testable: a test is something to satisfy, not to interpret. Checkable: drift guards fail the build instead of filing a ticket.

With those in place it runs end to end: research, specification, tests, design, implementation, review, help, release. Product help comes out of the same scenarios the feature was designed against. An agent writes the article and drives a browser for the screenshots. Product education edits that draft instead of writing a manual against a launch date.

Where this goes is not my invention. Josh Bersin's HR 2030 (opens in a new tab) blueprint argues agentic HR is a new business system rather than HR with AI added on top, and forecasts HR headcount falling 30 to 50 percent this decade. I do not have to believe the forecast to take the design problem seriously. If what is left of a recruiter's day is mostly judgment, the product cannot stay a dense surface they filter by hand first.

What stays a person's call

The harder half of this is deciding where it stops, and we are still deciding.

Some of this work is a judgment with somebody's name on it: what a rejection says to a candidate, whether a recommendation belongs on the screen at all. The complexity you cannot remove is usually somebody's payroll regulation, union agreement or accommodation.

Accessibility is the clearest case, and what makes me careful about it is that it looks automatable. In the pipeline, axe catches the contrast failure, the missing label and the control with no name. It will also pass a screen that is entirely compliant and unusable with a screen reader. Somebody has to sit down with the assistive technology and say whether the thing actually works. The more of a screen a model draws, the more I want a person in that chair.

I cannot tell you we have drawn every one of those lines in the right place. We have moved several of them more than once, and we are not finished moving them.

None of it was in reach a year ago

2025 was rough. What fixed it was not a better model. It was a team that kept learning and stayed narrow while it did.

Thirty days, two weeks, three months to the monorepo: none of it was in reach a year ago. All of it is ordinary now.

We stopped sending each other pictures of our software. We started sending each other the software.

You do not transform a design team by asking it to move faster. You change what it is able to own. Everything here came from one move: shortening the distance between deciding something and finding out whether it was right.