From content designer to content architect

In July 2025, I published this article in UX Content Collective about governance and AI content strategy. It was about where the discipline was headed and what the content design roles of the future might look like.

I wrote about a role I called the Content Architect, a strategic function responsible for defining, scaling, and governing content systems and standards. It’s a role that would leverage AI to automate routine content tasks—freeing up focus for strategy, experimentation, and innovation. I was writing about a hypothetical future.

Almost a year later, that future is my job title. This is the story of how that happened and what building it from scratch looks like.

The seed I planted 5 months ago

About five months before my manager made anything official, I started a conversation. I’d been keeping tabs on where content design was heading—at Clover and across the industry—and I kept arriving at the same conclusion.

The traditional model of content designers embedded in product teams, writing copy flow by flow, isn’t built to last. AI was accelerating design velocity. Teams were becoming leaner and leaner. The demand for content was outpacing the supply of people who could produce it quickly and consistently.

I pitched my manager on a different kind of content function. Not hiring more writers. The idea was to build a content system, a foundation the whole product team could write on top of. Voice standards, AI-assisted tooling, pattern libraries, decision frameworks, and all the rest of it. The kind of system that would enable a product designer to make confident content decisions without waiting for a content designer to have bandwidth.

Although my manager was interested, the timing wasn’t right. So I kept building, kept writing, and kept making progress—if only for my own selfish reasons. I got my hands dirty with AI tools, wishfully thinking they’d eventually become the backbone of something real. By the time the org was ready, I wouldn’t be starting from scratch, I thought.

A leadership mandate as catalyst

The moment that accelerated everything wasn’t a conversation I was a part of. It was a directive from the powers that be. Designers shouldn’t be pushing pixels, and content designers shouldn’t be writing content.

The focus should be on patterns, frameworks, and systems—the infrastructure layer that makes execution faster and scalable. I had been making that argument for 5 months. Now it was coming from the top.

Not long after my manager got the mandate, the conversation I’d been quietly keeping alive became something real. The design org was restructuring. Two of our three content designers would be moving into different roles. And I would step into a new role—one that hadn’t existed at Clover before. I would be the Content Design Architect. The role I had written about as a future possibility was suddenly mine to define and build.

What the role actually means

The title is new, but the underlying problems are not.

Content at Clover has standards. What it doesn’t have is a way to make them stick consistently. The guidelines exist, they just don’t live anywhere designers and engineers actually work, and they were never successfully socialized. Good judgment still depends on individual expertise and access to the right person at the right time.

That’s a fragile system. And it only works when you have enough content designers to be that person. And we no longer do.

The simplest way I can describe this role is that the output is infrastructure, not copy. My job isn’t to author content. It’s to architect the foundation that makes consistent content possible at scale. What I’m building has three layers:

1. Foundation: Voice model, UX writing principles, tone guidance, and codified decision trees that define what good content means and gives designers a basis for judgment.
2. Tooling: AI prompt systems, Figma-integrated pattern libraries, string repositories, and content components that make the foundation actionable in the workflow designers are already in—including, eventually, code-level guidelines baked into the engineering pipeline.
3. Infrastructure: Review processes, quality signals, and escalation paths that maintain the quality bar without routing everything through one person, which is me.

The system is designed to make the right content decision the path of least resistance. It’s not the forced choice; rather, the easy one.

The part nobody talks about

Every org that attempts this kind of shift will encounter the same tension I’m navigating. The system doesn’t exist yet, but the need is immediate.

Product designers who have never owned content are now being asked to own it. They’re doing it with good intentions and real uncertainty, in the middle of sprints that don’t pause for infrastructure to catch up. The gap between what the system can offer today and what the team needs today is real, and it falls on me to bridge it without becoming the “help desk” I’m trying to replace.

This is the invisible challenge in any systems-related role. The infrastructure you’re building is supposed to reduce the load on you personally. But until it’s mature enough to carry that load, you have to carry it yourself. The discipline is in building the system anyway—treating every one-off question as a signal about what the system is missing, not just a problem to solve at that moment.

It requires a different relationship from being helpful. In a traditional content design role, helping means writing good copy for a designer who needs it. In this role, helping means building the thing that means they won’t need to ask next time.

The “good enough” mindset

There’s a very critical mindset shift that has to happen before the system can truly work, and it’s one of the harder ones to make if you’ve spent your career caring deeply about the content design craft.

In a traditional content design model, you aim for 100%. You have limited coverage, so every surface you touch gets your full attention and judgment. The standard is high because the volume is manageable.

AI tooling and a content system changes that equation entirely, but only if you’re willing to let them. Instead of covering a handful of areas at 100%, you can reach surfaces you never could before at a standard that’s good enough to ship. The output isn’t perfect. It’s consistent, on-brand, and reaching surfaces that previously never had a content designer’s eye on them at all.

That’s not a compromise. That’s a different kind of win.

The hardest part isn’t building the system. It’s convincing yourself—and the people around you—that good enough everywhere is more valuable than perfect across a fraction of it. A product that’s consistently good everywhere is more trustworthy than one that’s occasionally perfect and inconsistent everywhere else. Breadth is the better outcome.

What I got right and what surprised me

When I wrote about the Content Architect role last year, I got the strategic shape of it right. Systems thinking. AI leverage. Standards that scale. The responsibilities I described in that article map pretty closely to what I’m doing now. What I underestimated was the human dimension.

Building a content system isn’t just a design and engineering problem. It’s a change management problem. Product designers are being asked to take on a craft and a responsibility they weren’t hired for, without a reduction in the scope of work they were already doing. That’s a real ask. The system only works if designers trust it, use it, and feel supported by it.

The most important infrastructure I’m building isn’t a prompt library or a Figma component. It’s trust. And trust requires presence, patience, and a recognition that the people using your system are doing their best with something genuinely new.

Where does this go next?

I’m only a few weeks into a new role that will likely take a few years to fully realize. Soon, the pilot will be underway with several designers. Portions of the foundation layer have been built—like Clover’s voice model, content principles, and glossary have been codified; what I’m doing now is making them designer-usable, machine-readable, and engineering-ready.

The next chapter is scale. Moving from one pilot team to the full design org. Then from design into engineering, where content linting, component-level standards, and continuous integration can make the quality bar structural rather than aspirational.

Beyond that, what’s the longer horizon? A system that holds across multiple surfaces, multiple channels, and markets where consistency isn’t just desirable—it’s the product. And if it works the way I believe it can, content quality at Clover stops being a function of how many content designers are in the team. It becomes a property of the system itself.

An honest reckoning

I wrote about this future with a lot of confidence. Now living inside it, I have more questions than answers. Whether the system will hold. Whether designers will trust it enough to use it well and consistently. Whether the metrics will prove the value before someone decides the experiment is over. 

Building something that hasn’t been built before is humbling. The strategy is clearer than the execution, and the execution is exponentially harder than what the strategy suggests. But I’d rather be inside that uncertainty than writing about it from a safe distance.