A UX writing system in Claude that learns from corrections

A UX writing system (some call it a content design system) keeps everything your team needs to write product copy in one place: rules, brand voice, patterns and examples. I build mine in Claude, in five layers. At the top are the rules, which always take priority. At the bottom is a memory that collects corrections and turns the ones that keep coming back into new rules.

I first shared this system on LinkedIn in August, in Czech. Here it is in more detail, with sample files and an answer to a question from the comments: will the team use it?

Why do teams keep arguing about copy?

Any AI can write decent copy these days. Yet design and product teams still argue about copy more than about anything else. That’s because several people have a say in every piece of text, and each of them guards a different set of rules:

• the UX writer: writing guidelines and content design patterns,
• marketing: the tone of voice guide,
• product: the glossary and terminology,
• proofreading: grammar and punctuation.

In the past, either everyone wrote their own way, or a UX writer sat on the team and every word had to go through them. Then everyone waited for that one person. Today, product people are expected to handle copy themselves. But someone busy building a product can’t keep dozens of pages of rules in their head. So I put the rules into a system that remembers them for the whole team and learns from what people correct.

What’s inside a UX writing system?

The system has five layers, and each one does one job. At the top are the rules, which hardly ever change. At the bottom is the memory, which changes every day.

• CLAUDE.mdRulesVoice, formatting and glossary. Claude reads them before every piece of copy.always takes priority
• voice-chart.mdBrand personalityHow the brand sounds in the app, in notifications and in emails.
• patterns/Copy patternsA pattern for every type of copy: buttons, error messages, forms.
• skills/ActionsWrite copy, check the tone, run an audit, log a fix.
• memory.mdMemoryA log of fixes that new rules grow out of.learns from fixes

CLAUDE.md: the rules that always take priority

CLAUDE.md is the brand’s constitution. In a few lines, it describes the brand voice, the formatting rules and a glossary of words to use and avoid. Claude reads it on its own whenever it starts working, so nobody has to paste it in. If anything else in the system contradicts it, CLAUDE.md wins.

# Brand rules
This file takes priority over everything else.

## Voice
- Short and to the point. One sentence, one idea.
- Say “you”, never “the user”. When something fails, no jokes.

## Glossary
- sign in (not log in)
- card (not payment method)

## Formatting
- Amounts: €1,290
- Dates: 12 March 2026

voice-chart.md: the brand’s personality in depth

The voice chart describes how the brand sounds in different channels and situations. In the app it keeps things shorter than in an email, in a notification it says the most important thing first, and it only jokes where a joke fits. Every situation comes with examples of what to do and what to avoid. You can tune one message by tone and channel yourself on the sound check on my homepage.

patterns/: a pattern for every type of copy

In the patterns folder, every type of copy has its own file: buttons, error messages, forms, notifications, empty states, onboarding. A pattern sets out how the copy is built, how long it can be and what never goes in it, plus five to ten good examples. When a new type of copy comes along, you add one file.

# Error message
When: something went wrong and the user can fix it.
Structure: what happened, what the user can do, a button with the next step.
Length: headline up to 40 characters, body up to two sentences.
Never: “Error!”, “invalid input”, an error code without an explanation.

## Do
Your payment didn’t go through, and your money hasn’t gone anywhere.
Check your card details and we’ll try again.
[Try again]

skills/: actions the system can run

Skills are actions you start with a single command. The system then carries them out by the rules:

• microcopy-gen writes copy from the pattern and offers two or three options.
• tone-checker compares a text with the rules and, for every slip, says what’s wrong and how to fix it. It doesn’t rewrite anything on its own.
• audit goes through all the copy in the product at once and sorts the problems from the most serious.
• learn logs every fix someone makes into the memory.

memory.md: the memory that rules grow out of

Every fix, decision and exception goes into the memory, with a date and context. That’s how the system notices when the team keeps fixing the same thing.

# Fix log
12 Aug | toast | “Successfully saved” → “Saved” | product designer
19 Aug | toast | “Your changes were successfully saved” → “Changes saved” | UX writer
26 Aug | email | “We have successfully received your payment” → “We’ve got your payment” | product manager
  3× the same fix: warning, a rule is probably forming: “don’t write successfully”

How does the system learn from fixes?

Every fix moves the system a step forward:

• Someone on the team rewrites copy the system wrote.
• The learn skill logs it in the memory: when, in which piece of copy and who made it.
• When the same fix shows up a third time, the system flags that a rule is probably forming.
• After the fifth fix, the person responsible approves the rule and the system writes it into CLAUDE.md for good.

So only what proves itself again and again, and what a person approves, makes it into the rules. One-off fixes stay in the memory. With every sprint, the system gets more in tune with the language of your product, and the same mistakes come back less and less.

Why is it built this way?

• One source of truth. The rules live in one place with a clear priority. Documentation, Figma and the opinion of whoever saw the copy last stop contradicting each other.
• Separate roles. Each layer does only its own job, so you can grow the system piece by piece without breaking the rest.
• Layered by how often things change. What rarely changes sits at the top, what changes daily sits at the bottom. The rules stay clear even as the memory grows.
• Learning from practice. Feedback is part of the system from day one. The more the team uses it, the better it gets.

All my clients get the same skeleton. What differs is how detailed the rules are. A small product needs three patterns, a big one has dozens.

Will your team use it?

On LinkedIn, someone asked me how many brands can roll out a system like this and stick to it. In their experience, it often ends with only the person who built the tool using it. That happens when the system lives with one person. To keep that from happening, I watch three things:

• The system lives where the team writes. It sits in a shared project that everyone who writes product copy can access.
• It has an owner. One person approves new rules, usually a UX writer or a product manager. Without an owner, the system goes stale within a few months.
• It starts small. CLAUDE.md and three patterns for the copy the team writes most are enough to begin with. More patterns come when someone needs them.

You can tell the system works by looking at the memory. In the first weeks, lots of fixes pile up. Then there are fewer, because the repeated ones have become rules.

How to start

The smallest working version has four parts:

• CLAUDE.md with the voice, glossary and formatting. It usually grows out of guidelines you already have.
• A voice chart for two or three channels, with examples of what to do and what to avoid.
• Three patterns: an error message, a button and a notification, each with five to ten examples.
• An empty memory.md and the learn skill that logs fixes into it.

Add the rest when you need it.

You ask, I answer

Does it work in ChatGPT or Gemini too? The skeleton carries over. The rules go into the project instructions, and the voice chart, patterns and examples go into files. Actions and memory work differently there, though, so someone has to log the fixes by hand.

Do I need a developer? No. It’s all plain text files in Markdown, with headings and bullet points. Anyone who can write guidelines can write them.

Who looks after the system? One owner who approves new rules. Once a quarter, they go through the memory and the patterns and remove whatever no longer applies.

Won’t the system learn mistakes too? That’s why nothing gets into the rules on its own. A fix only becomes a rule when it keeps coming back and a person approves it.

How big a system do we need? It depends on the size of your product. A small one gets by with CLAUDE.md and three patterns. A big one has dozens, plus a glossary for every market.

I build systems like this with product teams as part of my UX writing work.