Creating Style Guides
I built first-ever UX writing style guides at two companies to set standards, unify voice, and scale content.
Since my strategy was similar iHerb and Exodus style guides, the project shows examples from both.
Problem
Inconsistent voice, tone, capitalization and terminology
No clear rules for UI components
Localization challenges when translation providers changed (e.g., different levels of formality used for the same language)
Review process slowed by subjective feedback
Previous copy would often get lost (no SOP for saving previous versions)
Ineffective writing such as “To view the full list, click here” and unclear CTAs
Goals
Create a single source of truth for UX writing and unify content with it
Make it easier for anyone to write in the brand voice
Reduce errors and inconsistencies
Improve translation efficiency and accuracy
Solution
Audit: I reviewed existing product content, identified recurring issues, and documented the different types of components used.
After auditing the content, I also met with designers, marketers, PMs, engineers, and support teams to align on needs and existing concepts of the brand’s voice and style. Below are pages from a pitch deck about shifting iHerb’s content from title case to sentence case capitalization. They agreed and I made the updates in the CMS.
I shared a similar pitch deck at Exodus, however, it wasn’t as successful as design leaders decided it was too big of an undertaking at the time. They were convinced it was correct, but wanted to do it later.
Part of the reason I was confident shifting a company’s capitalization is because years prior the Samsung UX writing team had shifted their capitalization, so I was able to see how it was done. However, the changes at Samsung were mostly automatic, whereas with iHerb, I had to make hundreds of manual changes in their CMS, which took a few days.
Guidelines: I created rules for voice, tone, grammar, terminology, and reduced-English patterns for non-native speakers
Component standards: Documented patterns for buttons, modals, error states, etc.
These rules of thumb got the attention of the VP of Engineering at Exodus at the time. It was deemed a powerful cheat-sheet that helped people around the company refer to best practices.
I don’t have documentation of the translation style guides, but I also created translations style guides for 8 languages to translate Exodus for the first time. Basically, I created a simplified version of the English style guide, then added in specifics that are more relevant for translation, such as:
Formality
Date and time formats
glossary for common, important terms such as “wallet” and “private keys” so they were translated consistently in each language.
I used AI to help me do this, then had internal employees who were native speakers of each language to QA the guides I created. Then, the translation vendor also had a look in case they had feedback. This saved us money since we didn’t have to pay the translation vendor to complete the translation style guides.
Result
Content became consistent and on-brand
Reduced review time and fewer disputes
Lower localization costs and faster translation
Style guide adopted as a living document and referenced across teams daily (and inspired the support team to create their own version of the style guide)