This case study is password protected

Founding Practice · TCGplayer (an eBay company)

FOUNDING AN AI-NATIVE CONTENT DESIGN PRACTICE

Hired as the first Content Designer at TCGplayer, I chose to skip the traditional documentation-first approach and instead built the standards directly into an AI tool that teams could use in their day-to-day work.

Company TCGplayer (an eBay company)
Function Content Design (founded the practice)
Product Area Design today · Marketing, CX, Product in scope
Role Lead Content Designer
Stakes / Scale First Content Designer hire · 4–6× project capacity per Content Designer
Key Partners Engineering (build partner), Brand, Product Design, AI/ML, Legal (patent)
Content Coach · In production
Content Coach — TCGplayer's AI-powered Content Design tool. Input panel on the left with function picker, audience selector, project context, component type, length, and prompt; output panel on the right showing processing steps, the generated content, refinement variants, and rationale.

An AI tool that generates component-aware content based on TCGplayer's standards, with outputs tied back to the source guidelines.

A function with no precedent and no scalable way to support it

I joined TCGplayer, an eBay company, as its first Content Designer.

There was no voice and tone, no writing standards, no review process, and no team. The only existing artifact was a brand style guide. eBay had a mature Content Design function, but TCGplayer didn't, and I was the only person hired to establish one.

The conventional path would have been to spend the first year writing documentation (voice and tone, component patterns, working models) in Confluence and Google Docs, then rolling it out through training. But I would have been the only person creating and maintaining it. That approach wouldn't scale. Demand for content was already outpacing what one person could support.

Building a scalable Content Design system and the tool to support it

I built the function as a system from day one, including both the documentation and the tool built on top of it.

Instead of writing standards into Confluence, I wrote them as the training material for an AI tool, the "Content Coach" app. It was the same documentation work, but the output was a system that could draft and review content while reinforcing standards in product context, rather than a static wiki page.

I led the Content Design work, including standards, voice and tone, component rules, prompt structure, and the evaluation rubric. The tool itself was built in close partnership with an engineer who owned the technical build. Both of us were integral; neither could have done it alone.

What I owned

  • The decision to scale through systems, not through a wiki and a queue.
  • Voice and tone, writing principles, and component-level rules for TCGplayer.
  • The full documentation library that grounds Content Coach and provides the source material for the tool.

Built in partnership

  • Content Coach's interaction design, including input structure, output format, component awareness, and refinement options.
  • The research content evaluation rubric for grading outputs against the practice.
  • Atlassian integration design (pulling Jira and Confluence project context into the prompt).
  • The patent application content (filed through eBay's Patent Incentive Program; patent pending).

Skip the analog stage. Write documentation that runs.

The default approach for a new function is to start with documentation: a Confluence space, a tone guide, component patterns, training. I'd seen how that plays out. Documents get written, bookmarked, and rarely used in practice.

I still had to define the standards. So I wrote them once, as training material for an AI tool instead of a static library. The same work that would have lived in Confluence became the foundation for Content Coach.

The first version was intentionally simple: the brand style guide, a small set of component rules, and a basic input and output. That was enough to observe how teams actually used it, including what they asked for, where they got stuck, and where outputs fell short.

From there, the tool evolved alongside the practice. It became component-aware, introduced audience context (Buyer vs. Seller), added structured functions (create, improve, review via Figma link), integrated project context through Atlassian, and added refinement options like "shorter" or "more direct." Each addition required expanding and tightening the underlying documentation.

Adoption came through teaching, not enforcement. I ran sessions and office hours so teams understood how to use the tool, where to trust it, and where to push back. The goal was for Content Coach to be a tutor, not a generator.

4–6×
project capacity per Content Designer

From a 2–3 project ceiling per embedded Content Designer to 12+ in parallel, by supporting draft and review work and freeing Content Designers for strategy and approval.

12+
Projects in parallel per Content Designer (up from 2–3)
6,000+
Strings shipped through Content Coach (and counting)
Patent
Pending. Filed through eBay's Patent Incentive Program
1 → many
From Design to broader adoption across Marketing, CX, and Product

Systemic impact

  • Established TCGplayer's first Content Design standards, voice, and tone.
  • Introduced an alternative to the conventional Confluence-and-training rollout with an AI-native standards system.
  • Took Content Design from a 2–3 project ceiling per Content Designer to 12+ in parallel.
  • Made Content Design accessible to product teams without requiring direct Content Designer involvement for every request.
  • Shipped 6,000+ strings of in-product copy through Content Coach to date (and counting).
  • Filed patent through eBay's Patent Incentive Program (patent pending) on the Content Coach methodology.
  • Established the foundation for cross-functional adoption beyond Design to Marketing, CX, Product, and other teams currently in scope.

What "documentation that runs" actually means

In a Confluence article, voice and tone is bullet points: "be clear, be helpful, be human." That works for a one-time read. It doesn't work as the basis for an AI tool, which needs to know how those principles weigh against each other, how they shift by component, and what to do when they conflict.

So the documentation is structured differently. Voice and tone became guidance with priority rules. Component rules described not just what good writing looks like, but the conditions under which each rule applies (a blocking error and a guidance card both need to be helpful, but not in the same way). Audience definitions carried the context the tool uses to draft for a Buyer or a Seller.

The standards work didn't change. Its structure did. The result is a corpus the tool can reason against, not a wiki page someone has to remember to apply.

Content Coach, built incrementally

Content Coach didn't start as the application you see in the screenshots. The first version was a custom GPT, barely styled, with the brand style guide and a handful of component rules pasted in. I shipped it that simply on purpose. I wanted to see what teams actually asked for, what they trusted, and what they ignored.

The patterns showed up fast. Teams wanted component-aware outputs, project context they didn't have to retype, audience targeting, and refinement options. Each pattern became a feature in the production tool. More importantly, each became another piece of documentation the tool could ground itself in. The outputs are grounded in the practice's specific standards, not generic LLM behavior.

The Content Coach prompt input, a clean field for describing what content is needed, with a 'Create content' button.
The input experience: looks like a chat box, is really the entry point to a structured documentation library.

Even the prompt is a design decision. Teams describe what they need in plain product terms. The structured fields around the prompt translate that description into something component-aware and grounded.

The simplicity is intentional. The complexity lives in the documentation, not the interface.

The original TCGplayer Content Coach GPT, the bare-bones first version built as a custom GPT with the brand style guide and a few component rules, with example prompts like 'Rewrite this error message to follow our guidelines' and 'Draft an empty state message for a seller dashboard.'
Where it started: the original Content Coach as a custom GPT. Same idea, much smaller surface area.

Trust through citations: making AI drafts defensible

Content Coach generates drafts, not finished work. Human review and approval are still part of the process, by design. But for a draft to be useful, the person using the tool has to be able to defend it to their reviewer, and the reviewer has to be able to evaluate it without rebuilding the writing from scratch.

Every Content Coach output includes two things by design. A Rationale that explains the choices behind the writing (why this title, why this CTA, why this length, why this tone). And a Guidelines Referenced panel that surfaces the actual brand documents the output drew from, with relevance scores.

That second piece is the one that changed the conversation. With citations, an output isn't a black-box generation. It's a traceable piece of work tied back to documentation that already has buy-in. The drafter can show where their choices came from. The reviewer can challenge a guideline, not the AI. The tool becomes accountable to the practice the same way a Content Designer would be.

Filed through eBay's Patent Incentive Program

eBay runs an internal Patent Incentive Program. Employees submit ideas, and selected ones are paired with a patent lawyer to file a formal application. My engineering partner and I submitted Content Coach together. It was selected.

The patent (pending) covers the methodology: using a structured documentation library as the source of truth for an AI content tool, with grounded outputs, component awareness, and traceable citations as core mechanics.

The path to filing was its own kind of validation. The decision to build documentation that runs wasn't just a faster way to get the function off the ground. It was distinct enough to be filed through eBay's Patent Incentive Program.

Next project

LOWE'S

View case study