The problem
UI copy is easy to take for granted, until you map out everything it takes to write it well. At Index Exchange, the Design and Technical Writing teams own every word that appears in the product: buttons, tooltips, error messages, empty states, all of it. Good UI copy is concise and consistent. It anticipates confusion, reduces friction, and helps users complete tasks without getting stuck.
But writing it on-brand meant checking four different sources every time, each one more specific than the last:
Company Style Guide
The company-wide writing standards
Confluence
UI Content Guide
Design team's style guide for the UI
Figma
Design Kit
Design team's component documentation
Figma
Standard Error Messages
Exact wording
Spreadsheets
That's a lot of surface area to check and to maintain. Guidance drifted out of date as the product evolved, gaps went undocumented, and finding the right rule meant hopping between Confluence, multiple Figma files, and several spreadsheets. I set out to fix that by building our first Claude Skill.
What's a Claude Skill?
A Skill is a set of instructions stored in a file that tells Claude how to approach a specific type of task. They're a natural fit for work governed by established standards that need to be consistently referenced and followed, which made UI copy an ideal first Skill for the design team to explore.
My process
Here's how I built it:
- 1.Audit and consolidate. I gathered every source of UI copy guidance: the Style Guide, Content Guide, Design Kit, and spreadsheets. Claude Skills require markdown, so I couldn't keep the source material in its original formats — I consolidated everything into a Word document and spreadsheets that I could eventually upload into Claude.
- 2.Update for current standards. Much of the guidance predated recent feature and pattern work, so this wasn't a copy-paste job. I reviewed it against our latest product patterns, proposed updates, and wrote new guidance to close known gaps.
- 3.Review with stakeholders. I ran the updated content through three rounds of review with the Design team, then a final round with the Technical Writing team, to make sure it reflected both current standards and how each team actually worked.
- 4.Package it as a Skill. Once the content was solid, I fed it into Claude to help structure it into Skill format. I'd expected this to be the hardest part. Every example I'd seen beforehand was dense with markdown and complex structuring. It turned out to be the easiest. I described what I wanted, pasted in the source material, and Claude flagged gaps and proposed a structure. I was using the Skill to look things up before I'd even finished building it.
What it's made of
The Skill has two parts:
- The Skill file — high-level guidance (voice, tone, grammar conventions, when to capitalize, how to write for specific UI components), capped at 500 lines
- Reference files — the granular stuff that belongs in a spreadsheet, not a paragraph: exact error message wording, product names, and vocabulary
That split mattered. Anything list-like or highly specific lives in the references; the Skill file itself stays high-level and readable.
Takeaways for anyone building their first Skill
- 1.Keep it high-level. Skills max out at 500 lines. Fine-grained details like lists, exact wording, and spreadsheets belong in reference files, not the Skill itself.
- 2.Watch for over-editing. Claude will trim aggressively to stay within limits, and that can quietly change meaning. Keep your original draft to check against.
- 3.Start using it before it’s "done." I was querying the Skill for lookups while I was still building it. The productivity gain shows up immediately, not just at launch.