Building Branch’s AI UX Writing System

Reviewing a single line of UX writing could take 20 minutes of a design review. We would discuss what sounded right while also finding inconsistent casing for the same component across different screens in the app.

The goal was to standardise UX writing: consistent tone and casing, grounded in the product and market, and aligned with Branch’s brand principles. Teams needed to reach that standard without repeatedly spending review time deciding what worked and what did not.

I took ownership of the project from discovery through implementation, with substantial help from colleagues.

I started by looking at the workflows people already used. Colleagues turned to Gemini, ChatGPT, Claude, Perplexity and Google Search. Each approach produced an answer, but there was no shared knowledge base or set of component rules governing those answers.

At the start, the documented UX-writing guidance was the brand principles. The product and component context needed to apply them consistently had not been assembled into a common reference.

Copy for the same feature could differ in tone or casing between India and Nigeria, without consistently following Branch’s principles. I needed a common set of rules that also accounted for each market’s products and terminology.

Other product designers helped me collect and clean documentation for the features in their markets. They wrote product overviews and the steps within each flow. This became the core product-context dataset supplied to the LLM: what a feature did, what the person was trying to achieve and what happened at each step.

We then agreed that the writing rules needed to be defined within the design-system components. A button, input label and error-message body serve different purposes. Each needed its own guardrails so the LLM could apply the relevant rules to that part of the interface.

Together, we documented each component’s category, use case, tone, character limit, word count, sentence phrasing, casing, punctuation, applicable principles, good and bad examples, and rationale. The final v7 reference defined 30 component types and 45 text positions.

For a Primary Button, for example, the documented guidance specified:

This gave the LLM a specific contract for the component. The product context determined the action; the component rules determined how to write it.

This was new territory at Branch. I had to determine how an existing LLM could interpret a screen, find the applicable Branch guidance and follow the component rules in its response. I researched the major LLMs and reviewed literature on how they were built, then structured the operating guide and reference data around that workflow.

I developed an algorithm for the writing workflow: identify the context, select the relevant guidance, generate copy, check it and resolve any conflicts. The operating guide defined that sequence, while JSON reference files supplied the component, market, brand and validation rules.

The first harness was a ChatGPT Custom GPT. We moved to a Claude Project after the team found Claude stronger for the writing task. I continued refining the instructions and reference data through seven versions.

The iterations progressively made the component definitions more complete, the constraints more explicit and the validation more thorough.

1. V1

   Assembled the initial brand, market and component references. Thirty component types were listed, with populated text-position rules for twelve.

2. V2

   Added rule precedence and seven lint checks.

3. V3

   Linked component rules to writing principles and consolidated the market structure.

4. V4

   Defined text positions across all components, structured character, word and line limits, and expanded component inference and mapping.

5. V5

   Reduced hard minimum constraints and added ordered alternatives when copy could not fit a component’s limits.

6. V6

   Expanded lint to fifteen checks, standardised naming and market-term validation, and introduced an operating guide.

7. V7

   Aligned conflicting List definitions, specified styling for all forty-five text positions, expanded lint to thirty checks, and added generation patterns and checks against copying examples verbatim.

Colleagues used CopyGPT through a chat harness. They sent a request with text or an app screenshot, supplied missing context when asked, and refined the proposed copy through follow-up messages.

I designed the v7 operating guide to instruct the LLM to identify the screen context, select the applicable Branch rules, generate copy and validate it before responding. The sequence below shows that algorithm.

Resolving conflicting rules

v7 followed market requirements → component rules → brand defaults → inference fallbacks. If necessary guidance cannot fit, shorten first, propose a supported alternative and revalidate; the team decides component changes and unresolved constraints. The following scenarios illustrate that policy.

Examples of how the LLM resolves conflicts

I packaged the workflow as a Claude Skill so every team could use the guidance within Claude Chat. The package contained a main SKILL.md instruction file and six Markdown references for components, markets, brand, lint, component recognition and flows.

The Skill instructions directed the model to identify the request and select the references it needed. This made the shared product context and component guardrails available within colleagues’ existing AI workflows, across projects and chats.

I collaborated with one product manager and one engineer from each market to work through the app’s UX writing. We sent screenshot batches to CopyGPT, then recorded the original copy, proposed copy and rationale in a shared Google Sheet.

We reviewed the recommendations against the product context and agreed writing rules. The engineers implemented the changes that passed review, and we recorded the outcomes in the tracker before moving to the next batch.

The product team implemented 1,778 copy changes. The cross-market summary also recorded 530 screen-flow appearances reviewed and 4,390 UI component instances audited. These totals cover India, Kenya and Nigeria; Kenya and Nigeria figures include directional estimates.

The detailed India tracker contains 617 implemented component entries whose text changed. Comparing the original and implemented text shows the scope of those changes:

Eight implemented India tracker entries. PAN rows show the empty and already-filled states. Reasons are paraphrased. Final v7 rules explain aligned guidance; the tracker does not identify which version generated each historical change.

Richer context requires better documentation

The LLM needed more than writing rules. It needed to understand each market’s products, features and flows. Building that context meant collecting information and writing detailed documentation with other product designers. The richer and more specific that context became, the better the model could match its writing to the product and market. That documentation was a core part of building CopyGPT.

The model needed a consistent vocabulary

The first component rules we created as a team lived in Google Sheets. We used “header” and “body” for an Accordion, but “title” and “description” for a Text Block. My first attempt at the algorithm failed repeatedly because the LLM struggled to connect those equivalent labels to the right rules. I had to clean the data and standardise the names for equivalent text positions, so the algorithm and references used a consistent vocabulary.

Writing the algorithm and assembling the JSON references made the project clearer: I could see where the data and instructions needed attention.

Clarity came from doing the work

Before I started building, I spent too long researching and trying to resolve the uncertainty on paper. Writing the algorithm and assembling the JSON references made the project clearer: I could see where the data and instructions needed attention. I learned to approach ambiguity by building a first version, then using what it revealed to decide what to do next.

Try the live CopyGPT demo, powered by Claude Sonnet 5.5 and the complete v7 operating guide and JSON references.

Paste one piece of UX writing or attach an app screenshot. CopyGPT identifies the component, asks for essential missing context and proposes one rewrite using Branch’s brand, market and component rules.