Jon Meyers | Senior Content Design and Publishing Manager

That means frameworks, workflows, governance, and AI tooling that let teams ship clear, consistent content at scale. Content design stops being a review step at the end of every project and starts being the structure that shapes how the work gets done.
In practice: Operating model design, knowledge base authoring, prompt and golden set curation.
My work focuses on how content behaves across UI, help, AI systems, and customer messaging: how it adapts to user context, supports decision-making, and stays coherent across surfaces a customer encounters over the course of a single task.
In practice: Orchestrated messaging systems, content patterns embedded in design systems, voice consistency across products.
Content design authored into AI agents, knowledge bases queried by both humans and machines, self-serve content patterns for designers and PMs. Standards embedded in workflows scale further than standards held in any one person's head. The goal isn't to centralize content design. It's to put content design judgment everywhere it needs to be.
In practice: The content design behind AI agents, knowledge bases queried by both humans and machines, self-serve content patterns for designers and PMs.
My work is centered on helping users quickly answer the three questions every interaction asks: what happened, why it matters, and what to do next. Whether the surface is a UI string, a help article, or an AI-generated insight, the goal is the same. Reduce cognitive load and let the user act.
In practice: Error messaging that names the recovery path, tooltips that clarify meaning at interaction, insights that lead with the takeaway.

Designing content systems for products and the teams that build them

The gist

My work runs in two directions: I design the frameworks that scale content quality, and I write the strings, principles, and patterns teams ship every day.

Increasingly, that means being honest about which parts of the work belong to humans, which belong to AI tooling, and which belong to a real-time conversation between the two. That boundary is the thing most content design orgs are still figuring out, and a lot of my recent work has been about working it out in practice.

INTO THE CASE STUDIES

I design the systems that produce content, not just the outputs.

Content isn't a layer on the product. It's part of the product.

The goal is to put content design judgment everywhere it needs to be.

Most content problems are decision problems in disguise.

Designing content systems for products and the teams that build them

The gist

My work runs in two directions: I design the frameworks that scale content quality, and I write the strings, principles, and patterns teams ship every day.