We Never Actually Adopted Structured Content

Becky Alice Head

6 min read

·

Jun 2, 2026

--

Listen

Share

Not Really…

Press enter or click to view image in full size

Here’s a thing people in CMS and design systems circles say a lot: “We work with structured content.”

Here’s what they usually mean: they replaced a WYSIWYG text editor with a slightly smaller text editor inside a JSON field called bodyContent.

That’s not structured content. That’s a blob with better PR.

A Brief History of Blobs

Era 1: The WYSIWYG years

Content lived on pages. Pages were the unit of thinking. You opened a CMS, typed into a big box, added an image, clicked publish. Content and layout were one thing, fused together, unportable, completely unaware of any other surface it might ever need to appear on.

No reuse. No system thinking. Fast and intuitive, which is why we loved it and why it scaled terribly.

Era 2: Headless CMS arrives

We were going to fix all of that. Content models. Schemas. Fields. APIs. Content separated from presentation. Reusable anywhere. The pitch was genuinely good.

What actually happened:

Hero:
  - title
  - subtitle
  - image
  - CTA
  - bodyText (rich text, no constraints, go wild)

We took our big blobs and gave them field names. We still designed the page first. We still wrote copy to fit the layout. Then someone with good intentions reverse-engineered it into a schema in an afternoon. And everyone called it structured content and went back to their desks.

The mental model never changed. The blob just got a label.

What Content-First Actually Means

Not “write copy before designing UI.”

That’s the version that makes UX people rightfully annoyed, because early UX work is exploratory. It’s spatial, it’s iterative, it’s inherently visual. Telling a UX designer to not think about layout until the content model is finalized is like telling someone to describe a song before they’ve heard it.

What content-first actually means is this:

Define the smallest meaningful unit of content before anything visual exists.

Not a hero section. Not a promotional block. Not a “flexible content area.”

A unit of meaning. Something with a single purpose, a clear intent, a name that isn’t just the layout it lives in.

The difference looks like this.

UI-shaped thinking:

Hero:
  - heading
  - subheading
  - image
  - button text

Content-shaped thinking:

Value Proposition:
  - audience
  - problem
  - promise
  - differentiator
  - proof_point
  - tone

But how does copy actually get from those fields to a hero heading? Three ways, depending on your stack:

Direct mapping. The simplest version: your component just reads the fields. heading = promise, subheading = problem. No generation, no AI. Just a different projection of the same data onto a different shape.

Rule-based rendering. A function takes the structured fields plus a surface type and produces copy constrained by format rules. An email subject pulls from problem with a 60-character limit. A paid ad concatenates promise and proof_point. The rules are explicit; the content is the same data.

AI-assisted with guardrails. For surfaces that need natural language (chatbot responses, long-form ad copy), AI takes the structured fields as input and generates prose. But the fields act as constraints. The AI can’t hallucinate a different value prop because the source fields are the prompt. If proof_point says "14 weeks," the output says "14 weeks."

Here’s a concrete example. One Value Proposition, five surfaces, zero re-authoring:

Value Proposition:
  audience:       "Engineering leaders evaluating headless CMS"
  problem:        "Your content is trapped in page layouts"
  promise:        "Content that works everywhere, authored once"
  differentiator: "We treat content as data, not documents"
  proof_point:    "Migrated 3 CMS platforms in 14 weeks"
  tone:           "confident-peer"

From that single object:

• Hero: heading = promise, subheading = problem, CTA references differentiator
• Email subject: “Your content is trapped in page layouts” (straight from problem)
• Paid ad: “Content that works everywhere. Migrated 3 CMS platforms in 14 weeks.” (promise + proof_point)
• Chatbot: tone-adapted summary pulling from all fields, constrained by tone register
• Sales deck: title slide = promise, supporting bullets = problem, differentiator, proof_point

The hero copy isn’t missing from the Value Proposition schema. It’s derived from it. The schema is upstream of every surface, including the hero.

The first example only works as a hero. The second works as a hero, a PDP, an email, a paid ad, a sales deck, a chatbot response. Same content, infinite surfaces.

That’s the point. That’s what we never actually built.

And Then AI Showed Up

AI made this problem both worse and impossible to ignore.

AI loves blobs. It defaults to paragraphs. It fills space instead of defining purpose. If you give it a loose prompt (“write a hero for a skincare brand”) it will give you something that sounds plausible, renders fine in a mockup, and is completely useless as a content system. You can’t reuse it. You can’t query it. You can’t run it through logic. It’s just… vibes in a text field.

And because AI can generate convincing vibes at incredible speed, you can now build an entire product worth of blob-shaped content in a day. The system has never looked more finished and been more brittle.

This isn’t an AI problem. AI is just a mirror. It shows you, at scale, what your actual content practices look like when the friction is removed.

The Real Process (Not the Aspirational One)

Here’s what the actual workflow looks like when you’re trying to do this correctly, and I mean trying, because it’s genuinely hard:

1. Start with intent. What are you actually trying to communicate? Who to? What do you want them to do or feel or know?
2. Do loose UX. Sketch flows. Rough structure. This is not wrong. UX exploration is allowed and necessary. Don’t let anyone tell you otherwise.
3. Extract structure. This is the step that almost never happens. Take what you designed and named and convert it. Blobs become fields. Sections become entities. Vague labels (“description,” “content,” “text”) get replaced with purposeful ones. This is the discipline that most teams skip under deadline pressure.
4. Map structure back to UI. Now build components. Now the component is an implementation of a content model, not a prison the content has to fit into.
5. Iterate. Content changes, model updates, UI adjusts. In that order.

The enforcer rule, if you need one: every interface must resolve into a structured content model before it ships. Visual exploration is fine. Shipping a blob is not.

Why This Is Actually Hard

You’re fighting three things simultaneously:

Tools. Most UX tools are layout-first by design. Figma is not a content model. It’s a picture of a content model, if you’re lucky.

Habits. Designers, developers, content strategists: everyone has spent their entire career learning to start with the page. Reversing that is cognitively expensive and professionally weird.

AI. Which, left to default behavior, will generate the path of least resistance every single time, which is always a blob.

You’re not failing to adopt structured content because you’re bad at your job. You’re failing because every incentive in your environment is against it.

The Actual Problem

We don’t have an AI slop problem.

We have a structural discipline problem that AI made impossible to ignore.

The solution isn’t to ban AI from content workflows, or to insist nobody design a wireframe until the schema is perfect. The solution is to treat “extract structure” as a real, mandatory step. Not a thing that gets backfilled in a sprint or skipped entirely because it’s not on the ticket.

The blob has always been there. It has always been the failure mode. We just couldn’t see it clearly until something started generating a thousand of them an hour.

About the Author

Becky Head is a Principal Product Manager focused on CMS platforms, design systems, and composable commerce. She spends an alarming amount of time thinking about structured content, metadata, governance, and why most organizations still treat content like blobs instead of systems.

Have a different perspective? Found a flaw in the argument? Been through a similar migration? Reach out or comment. The best ideas usually emerge from conversations with people who have the scars to prove it.