Creating Style Guides

I built the first UX writing style guides at two companies, setting standards, unifying voice, and scaling content. This project includes examples from both iHerb and Exodus.

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

Here’s an example of the thoughts going through my head when I see messy content that needs a style guide:

Goals

  • Create a single source of truth for UX writing and unify content

  • 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 met with designers, marketing writers, 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.

  • These images are just a few selected examples of the proposed guidelines.

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

  • A glossary for common terms such as “wallet” and “private keys” so they were translated consistently.

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)

Previous

Settings Update