Defining UX writing and product content guidelines
About the project
Pantheon is a SaaS platform for website hosting and development.
Pantheon designers and engineers needed a shared source of truth for UI copy and in-product messaging. Without this asset, the team risked inconsistencies and misspellings, which hurt the company’s credibility. Work was delayed whenever a team member needed to track down an answer about grammar or formatting.
Create a set of content guidelines to make language, style, vocabulary, tone, and voice more consistent throughout our product.
Research comes first
Every good project starts with research. Before defining Pantheon’s content guidelines, I did the following:
Content guidelines can be expansive and comprehensive, but the Pantheon teams helped me identify a few areas that were highest priority: Voice and tone in the product and style and grammar rules.
Defining voice and tone
Pantheon’s brand team had recently completed an exercise to define brand personality and voice. We use the Pantheon brand voice across all channels—marketing, customer communications, sales presentations, in-product messaging, etc.
I think of the brand like a person. A person has the same voice all of the time, but their tone changes depending on the situation.
Similarly, we must adjust tone to account for specific use cases and match where our audience is at in their journey. This mean defining a specific voice and tone for product content.
The tone in the product should be different than the tone used in marketing.
After defining voice and tone, I needed to shift gears and focus on creating Pantheon’s in-house writing rules. These rules standardize usage and formatting for the words within our product.
The in-house rules are based on our product user needs. For ex: We do not include periods when writing a time (9 am) because we often have space limitations within the product UI, and the periods are not necessary for comprehension.
For writing questions that are not covered by our in-house rules, we default to using what is recommended by the Chicago Manual of Style. We chose Chicago style because it is extremely detailed and well-suited for technical writing.
Popular style guides like Chicago Manual and AP Style did not fit our product and content needs exactly. However we can use one as a starting point and develop in-house rules as needed.
Sharing early and often
When presenting a guideline or rule, it is helpful to explain the guideline AND provide examples.
The product content guidelines are now part of Pantheon’s design system. We consider it to be a living document, as we add more guidelines and build out more details (ex: error messages).
For the rollout, I worked with the design systems team to communicate to all of the engineering squads via Slack channels and stand-ups. We leveraged a company All Hands meeting to inform other departments, and we included it in an internal newsletter.