Leading a strategic pivot from custom showcase to documentation built to scale, and to power AI.
By the time V4 started, the documentation team was already 8 to 10 people and I had been leading it for a while. V4 is the current chapter of that work. A new major version of Veneer always meant a new version of the site, but two things turned this one into more than a version upgrade: the team had become a bottleneck for the whole design system, and AI had changed how people interact with design systems, how they design, and how they build.
The second one is a strategic position rather than a technical one. AI is already how a growing number of designers and developers reach for a system, and a design system that resists that will lose adoption to one that doesn't. So we decided to support it. In practice that means two things: documenting the internal AI tooling we've built, and writing documentation an AI can interpret accurately rather than approximately.
I'm not a formal people manager, but I own how this team works. That means the process, the roadmap, and the decisions about who does what, across a team spanning design, content writing, development, and QA. I've also had direct input into who joined it, interviewing candidates as the team grew. My own time splits roughly evenly between hands-on design, planning and prioritization, and representing the site's direction to Veneer leadership and the teams who depend on us.
V4 has stretched all of that. The migration is long and repetitive, and repetitive work over months is a motivation problem before it's ever a scheduling one. Four disciplines are working on the same pages at the same time. Every page needs a judgment call about whether it carries over or gets rewritten. And none of it can interrupt V3, which stays live and maintained throughout, because the teams using it today can't be left waiting for us to finish.
Supernova changed the shape of the team on top of that. The old boundaries were clean: developers built pages, writers wrote, designers designed. Publishing directly blurs them. People are now doing work that used to belong to someone else, which is faster and also an easy way to lose track of who owns what. Keeping that clear, without pulling the boundaries back into place and losing the speed, is a real part of the job right now.
Most of it comes together in the roadmap. I built ours around two things at once: our own priorities, and where every other team stood in their work. Documentation can't be written ahead of the thing it documents, and it loses most of its value if it lands long after. Sequencing our work against other teams' actual progress, rather than against what we wished we could get through, is what keeps a migration this size from producing pages nobody can use yet.
V4 was happening regardless. A new major version of Veneer meant a new version of the site. What was open was what we'd build it on.
Two constraints shaped the answer. The first was external: we were losing access to Sanity, the CMS V3 ran on, for cybersecurity reasons. Whatever we did next, it wasn't going to be there.
The second was ours. The team had become a bottleneck for the entire design system.
The cause was a dependency chain. The site consumes Veneer's packages, and we wanted it running the most recent release at all times, so the documentation always matched what people were actually building with. That meant waiting for Veneer to release, updating our dependencies, and then running our own release. Publishing wasn't something we could just do. Every change, down to a typo, had to ride that cycle.
However well the site was designed, documentation moved at the speed of that chain, and demand had outgrown it.
That reframed the goal. Where V3 was about designing a compelling, custom showcase for Veneer, V4 is about maximizing the volume and completeness of documentation, even if that means less custom design polish per page. How much we document and how fast now matter more than bespoke presentation.
The move: migrating to Supernova.io, a CMS built specifically for design systems. Publishing directly, without a release cycle for every change, is the obvious benefit. But what made it the right choice was how it connects to the tools the design system already lives in.
Figma. On Sanity, every Veneer release started a manual chain on our side. Accept the library changes in Figma, comb through the file to find what actually changed, export the visual documentation by hand, upload it to Sanity. Design was as much a bottleneck as the release pipeline, just a quieter one. Supernova connects to Figma directly. On a release we refresh the connection and the libraries, and the updates appear.
Storybook. The old site had a custom-coded interactive demo for every component, plus a property list alongside it. Every Veneer release meant a developer pulling the new packages, checking each demo still rendered correctly, and verifying the properties by hand against what had actually shipped. Supernova generates both from Storybook, so the demo and its properties are correct by construction rather than by inspection.
Put together, that's the actual argument for the migration. The team wasn't slow, and no one discipline was the problem. Documentation was pinned to manual work at three separate points, and each one had to be redone every time the design system shipped.
V4 needed a new information architecture, for three reasons.
Veneer is no longer platform-centric. V3's structure was organized around platforms because that's what the system was at the time. V4 is universal, so an architecture built to separate platforms was solving a problem that no longer existed.
The most-used page was too far away. Components is the single most visited page on the site, and reaching it took more clicks than it should have. An architecture that makes the most common destination hard to reach is working against the majority of its traffic.
One of our labels wasn't landing. "Foundations" is near-universal across design systems as the grouping for design language, tokens, and similar. User research showed it didn't mean anything to the people using it. We removed the grouping entirely rather than rename it, because the research suggested the problem was the category, not the words attached to it. Our content strategist and I wrote about that finding in Design Systems: We Have a Naming Problem, published on HP Design's Medium publication.
I worked through the naming and grouping with him. He isn't a designer or a developer, which is exactly why it worked. The two of us have opposite blind spots: I know what the system contains and can't easily unsee the words we've always used for it, and he reads those words the way someone encountering them for the first time does. "Foundations" only survives that long in an industry where everyone already knows what it means.
Rather than assume the new structure was better, we brought in our team's UX researcher, who built a custom study for this case. The IA was tested and validated before launch, so the structure was confirmed against how people actually navigate rather than against how we expected them to.
In parallel with our work, another team is building Veneer MCP, which will let people query Veneer through AI rather than searching the site themselves. Our documentation is the data behind it. Whatever we write is what the AI will answer from, and whatever we leave vague is what it will guess at.
That changes what "done" means for a page. A person skimming documentation fills gaps with judgment and context. A model doesn't. It needs the thing stated, in a structure it can parse, without the implicit knowledge a designer at HP would already have. Documentation that reads fine to a human can still be a poor source of truth.
Alongside that, we're documenting the internal AI tooling we've built, so the tools people are already reaching for are covered by the system rather than sitting outside it.
Scaling volume hasn't meant cutting corners on quality. Content writers still pair directly with subject matter experts to draft documentation, so what changed is the development bottleneck, not the bar on accuracy.
Alongside the migration and IA work, I'm designing a hotsite: a focused microsite timed to the V4 launch, showing the Veneer community what's new, why it matters, and what the new look and feel actually looks like. It's early in development, spanning hands-on design work as well as directing others on the team where needed.
None of what's above is what users care about. Nobody adopts a design system because its documentation moved to a better CMS. What they want to know is what V4 gives them that V3 didn't.
That matters more here than it would for a routine update, because moving to V4 isn't automatic. Consuming teams have to migrate themselves, on their own time, against their own roadmaps. So the hotsite isn't announcing something, it's asking dozens of teams to take on work. That only happens if the case is clear enough to justify the cost, and compelling enough that people want to be on the new version rather than feeling obligated to get there eventually.
Which is the same argument V3's site made for V3: a design system's own work is the strongest evidence for using it.
The hardest part of V4 has been letting go of V3. I spent five years on a site designed page by page, and the version replacing it will be more uniform and less bespoke by design. That's the right call, because what limited Veneer was never how the documentation looked. But it isn't a neutral one, and I'd be lying if I said it was easy to make about my own work.
The rest I don't know yet. Whether teams migrate on their own time, whether the new architecture holds up once it's carrying everything, whether writing documentation for AI to read turns out to mean what we currently think it means. Those answers come after launch, and some of them will take a year.
What I'm confident about is the process rather than the outcome. This time the architecture was tested before it shipped instead of after. The naming came from research rather than from what the industry has always called things. The tooling was chosen for what it removes, not for what it adds. If parts of this turn out to be wrong, I'd rather find out having been deliberate about it, and V3 already taught me that finding out is the job.