Building a content architect role from scratch

This is the third article in a series about the evolution of my content architect role. Read the first and second installments on UX Content Collective.

In my last article, I wrote about how the content architect role went from a hypothetical future to my actual job title. This one is about what happened next—the unglamorous, essential work of defining a role that didn’t exist before you.

When I started working at Clover, part of what I did during my first 30 days was do a listening tour. That involved meeting with 32 people across ten different functions:

• UX research
• Product management
• Product design
• Engineering
• Data science
• Sales
• GTM
• Channel communications
• Project management
• Tech publications

My goal was to understand our biggest content challenges and opportunities before I formed any opinions about how to solve them. Three themes emerged from my interactions:

1. First, we needed standards and guidelines. There was no unified, documented style guide. Voice, tone, and terminology were inconsistent across the user experience, and without a “source of truth,” teams were left wondering what was allowed and what to avoid. Some team members suspected standards existed somewhere. They just didn’t know where it was.
2. Second, we needed to define our process and engagement. Content was often treated as an afterthought, with feedback routed through designers late in the process. Stakeholders genuinely wanted content designers brought in upstream. But there wasn’t an intake process or engagement model to make that happen.
3. Third, our help content needed an overhaul. It was described as bland and too long for busy merchants to consume, which drove calls to merchant support. The content also lacked modern, engaging elements like images, videos, or interactive flows.

As part of my listening tour recommendations, I also included a forward-looking perspective. It’s an AI-powered vision for content design that uses AI to scale the craft, enforce consistency, and amplify strategic impact. I explicitly identified my areas of interest: Scaling content through AI, codifying content standards at the design-system level, and demonstrating quantitative impact.

I didn’t know it at the time, but I was writing the very first draft of my future job description.

Planting seeds early

When I was interviewing at Clover, I was told that product design would eventually be centralized. At that time, product design was decentralized, with content designers supporting multiple verticals.

When our new head of product design started, I shared my listening tour insights right away and made my case clear. The design team would get far more from me building systems that scale for every designer than from embedding me across multiple verticals to support production work. The argument was simple: One-to-many impact, not just one-to-one.

As I wrote in From content designer to content architect, I pitched the content architect role for five months before it came to fruition. What I didn’t fully unpack in that article is what happens after the pitch lands. That’s what this article is about.

Defining the role before it’s defined for you

When a role is completely new, there’s no playbook, no predecessor, and no institutional memory of what good looks like. Although that may sound liberating, it’s also a very slippery slope. A role without documented clarity can become whatever the loudest stakeholder needs it to be in any given week.

So the first thing I did wasn’t jump immediately into building writing standards or AI tooling. It was ensuring there was clarity in role responsibilities, goals, and strategy—all documented and agreed upon by design leadership and human resources. I wanted mutual clarity, in writing, before the real work even started. That took the form of three artifacts.

Artifact #1: The strategic one-pager

My first order of business was to create a strategic one-pager. One page, on purpose. If I couldn’t articulate the role on a single page (okay, technically, it’s 2 pages), I didn’t understand it well enough yet.

The one-pager covers:

• Why now – the converging forces that made the role possible: AI tooling mature enough to make content systems scalable, a team restructuring, and a leadership mandate to move design up the stack, away from pixel pushing and copywriting, toward patterns and frameworks.
• The problem – content was a craft without a system. Standards existed, but there was no infrastructure to make them stick. Quality relied on individual expertise, rather than shared infrastructure.
• The mandate – build infrastructure, not output.
• The role – architect, not author.
• What the content system is – three layers: A foundation (voice model, writing principles, decision trees), tooling (AI prompt systems with human-in-the-loop evaluation, pattern libraries), and infrastructure (review processes, quality signals, standards enforced in the engineering pipeline).
• What the role is not – this section did more heavy lifting than any other. A tactical production service. A manual review bottleneck. An embedded execution resource. Writing down what you won’t do is how a new role protects itself from becoming the old role with a new title.
• Risks and guardrails – including the one I feel daily: Building the plane mid-flight. The system is being built while designers are actively using interim tooling.
• The rollout and what success looks like – two horizons, with measurable outcomes attached to them.

I’ve published the strategic one-pager framework on GitHub if you want to adapt it for your own role. The one-pager became the anchor for everything that followed. Every subsequent conversation about scope, priorities, or expectations pointed back to it.

Artifact #2: The job description

Once the strategic one-pager was locked down, I proactively raised something with my manager: We needed a formal job description, created and codified with HR. So I set up time with HR to make it happen.

An important thing to mention is that nobody asked me to be proactive. But a role that exists only in a reorg announcement is fragile. A role codified with HR is durable. It survives leadership changes, reorgs, and shifting priorities.

Here’s a few highlights from the job description that capture the shape of the role:

• It’s a strategic systems role, not a tactical authoring role. The primary output is the underlying infrastructure (frameworks, tooling, rubrics) that enables others to write effectively at scale.
• It involves translating voice, writing principles, and standards into AI-assisted workflows, prompt systems, and logical rule sets that designers and engineers use independently.
• It includes defining the standards for AI-assisted and model-generated copy: Establishing prompt templates, tone constraints, quality rubrics, and human-in-the-loop evaluations that define what good looks like for AI output.
• It makes explicit that day-to-day copy authoring is out of scope, with tactical support reserved only for high-priority initiatives and escalation paths.

If your role is new, get it in writing with HR. Not for bureaucratic purposes, but for protection.

Artifact #3: Goals with specificity and milestones

Next came my 2026 goals. Without divulging specifics, they fall into four buckets:

1. Build and launch the content system – the foundation, tooling, and infrastructure that enables product and engineering teams to write well at scale, without a content designer in every room.
2. Make content standards operational, not just documented – evolving guidelines into a machine-readable, AI-ready, enforceable system that serves as a single source of truth.
3. Build production-grade AI content infrastructure – including our AI writing assistant and, eventually, automated quality enforcement.
4. Adopt a content architect operating model – a personal goal to build the technical fluency the role demands: Prompt engineering depth, terminal and Git literacy, and enough engineering fluency to eventually integrate content standards directly into the build pipeline.

For anyone building goals for a new role, here’s something I can’t underscore enough. I intentionally included specific deliverables and dates. Not because I’m a big fan of deadlines, but because I knew concrete goals would then inform my roadmap. When you have vague goals, you get vague roadmaps.

From goals to roadmap

Because my goals had deliverables and dates baked in, the roadmap practically wrote itself. It’s structured as two horizons:

• Horizon 1: Foundation + Bridge. Update content standards, establish governance and quality rubrics, explore AI tooling, and keep interim tooling live while the backbone is built. Building the plane mid-flight, with a bridge holding the team.
• Horizon 2: Scale + Sustain. Extend content standards into engineering, and evolve tooling from interim to integrated. Quality starts to become structural, enforced by a system, not by headcount.

Side note: If you’re paying close attention, you should notice a clear through line. All artifacts are intrinsically connected, with one feeding the next. The listening tour informed the pitch for the content architect role.

The pitch became the strategic one-pager. The one-pager was the foundation for the job description. The job description grounded my goals. The specific deliverables, milestones, and timelines in my goals helped to create the roadmap. None of the artifacts I created was busywork. All of it was intentional scaffolding.

The path I was already on

Even before the role became official, I had already built a custom AI writing assistant (a Google UX Writing Partner Gem) to support my own content work. I was collaborating closely with one of our product designers.

We were in the same office, which made it easy to launch a private pilot together and see how an AI writing partner would actually perform in practice. I also demoed it for our head of design, who immediately saw the potential.

I had no inkling the role would actually materialize. When it came to fruition, it was a genuine surprise. I had spent five months pitching, then quietly accepted that the timing might never be right, and kept building anyway. Partly out of conviction. Partly out of stubbornness. And partly because the work itself was just naturally pulling me forward.

That’s why I was ready when the role arrived; I wasn’t starting from zero. I had a working tool, a pilot under my belt, and proof that designers would actually use it. I had already been on the path. I guess you can say that the title just caught up.

Launching the Gem more broadly across the design org was the logical next step. And that’s where things get interesting, because putting an AI tool in the hands of 26 product designers teaches you things a private pilot or something you read about never could.

What happened next—and what it taught me about designing AI tools for designers, not just with them—is the subject of the next article.