Tone of voice
The way we write is an expression of who we are. It’s a reflection of our brand and the values we uphold as a company. Our voice should be consistent throughout the customer journey. Tone is how we adjust our voice to different situations. This guide covers both.
#Using the Siteimprove voice
Siteimprove’s voice is: empowering, personable, insightful, clear (EPIC). These qualities define the content on our website – and should also be apparent in every interaction users have with the platform.
Even the smallest piece of microcopy can influence the way customers use and perceive our products. It’s therefore important to keep the Siteimprove voice in mind no matter what you’re writing content for.
#Empowering
We want users to feel confident and in control. Our job is to deliver the information and guidance they need to work effectively in the platform.
- Be helpful, but not overbearing.
- Make sure the next step is always clear.
- Recognize that not every user is an expert.
- Stay focused on user goals and keep our ego in check.
#Personable
We keep things professional, yet friendly. We write conversationally, as if speaking face-to-face with the user. We offer help when needed, but never impose it.
- Be empathetic and encouraging, without being patronizing.
- Use “you” when referring to the user.
- Always use inclusive language.
- Never scold users for not living up to our standards.
#Insightful
We’re digital experts who recognize that our users are busy people. We’re selective about the information we put in front of them, and always relate it back to user goals.
- Be precise, but not excessive when explaining things.
- All killer – no filler.
- Avoid ambiguity and uncertain language (“possibly”, “seems”, “quite”).
- Get to the point quickly, and never lose sight of the bigger picture.
#Clear
Our solutions speak for themselves — we don’t need to use fancy words and phrasing in order to impress users.
- Write for scanning.
- Use simple, clear language that anyone can understand.
- Minimize the use of jargon and made-up terms.
- Consider our international audience (avoid idioms, regional expressions, and terms that might not translate well).
#Setting the tone
While our voice stays the same, we adapt our tone to reflect what the user is doing and how they might be feeling. For most common tasks, our tone is unobtrusive and part of a seamless experience.
This section features tone guidelines for the following UX scenarios:
- Standard UX microcopy
- Issues and issue descriptions
- Errors and warnings
- Progress and congratulations
- Encouraging action
- Help content for complex workflows
- Introducing changes and new features
#Standard UX microcopy
#Possible emotional states
All the emotions.
#Do's and Dont's
Be human.
Overcomplicate things with technical language and jargon.
Be plain and direct.
Be wordy or grand.
Provide clear information for users to carry out tasks and reach their goals.
Overload the interface with information that isn’t relevant to the task.
Use simple explanations so even the least-technical user can understand what to do (or know who to delegate to).
Make up terms for things if there’s already an industry term for it.
#Issues and issue descriptions
#Possible emotional states
- Curious
- Concerned
- Uncertain
- "Just trying to do their job"
#Do's and Dont's
Be authoritative.
Be authoritarian or demanding.
Use short and scannable sentences. Divide longer content up.
Use jargon without good reason.
Explain industry terms and acronyms the first time you use them on a page.
Be vague — not every user understands the implication of an issue.
Be concise — always choose clarity over brevity.
Go into too much detail in the platform - if it’s a really complex topic, link out to the help centre or other relevant resources.
Focus on why resolving the issue is important and how to do it.
Just say it's something we've detected.
#Errors and warnings
#Possible emotional states
- Confused
- Frustrated
- Anxious
#Do's and Dont's
Clearly explain how to solve the problem.
Make things sound scary or dramatic — “fatal error”.
Apologize when the error is our fault.
Blame or shame the user if it's their fault.
Be brief — one or two lines is usually enough.
Attempt to explain system errors, unless it will help Support.
Use a neutral tone - be mindful the user could be stressed or confused.
Be silly or playful — especially if it means the user has lost work “Oops!”
#Progress and congratulations
#Possible emotional states
Our solutions speak for themselves — we don’t need to use fancy words and phrasing in order to impress users.
- Confident
- Satisfied
- Motivated
#Do's and Dont's
Thank users for doing “extra” work, like providing feedback.
Over-congratulate — this can come across as patronizing (“You edited your settings - great job!”).
Be clear that an action has been completed.
Take credit for users' work — “we did it!”.
Be specific about what has happened — “widget added to dashboard”.
Be ambiguous about something happening — “Added”.
#Encouraging action
#Possible emotional states
Our solutions speak for themselves — we don’t need to use fancy words and phrasing in order to impress users.
- Curious
- Uncertain
- Purposeful
#Do's and Dont's
Use verb-led commands (e.g. “Do this” or “Create this”).
Overload the interface with information that isn’t relevant to the task at hand.
Be positive and inspire users to try new things.
Use too many call-to-actions on one page.
Explain the benefits of doing something and include a clear next step.
Leave the user hanging.
Limit the number of tooltips in the interface - there is such thing as too helpful.
Use content or walkthroughs to explains calls to action - this undermines the design.
#Help content for complex workflows
#Possible emotional states
- Uncertain
- Confused
- Frustrated
#Do's and Dont's
Be clear and to the point.
Present too much information at once.
For longer content, use headings to help users scan for answers.
Hide mission-critical information in tooltips, or in disappearing modals or Learn components.
Use Pendo tutorials for step-by-step instructions.
Use if-statements or ask rhetorical questions.
Link out to the Help Center if it’s an especially tricky subject.
Be silly or patronizing.
Be consistent with the terms used in the interface.
Assume the user is technically skilled.
#Introducing changes and new features
#Possible emotional states
- Unaware
- Excited
- "Just trying to get on with things"
#Do's and Dont's
Focus on how it will help users achieve their goals.
Go overboard with clichés and marketing spiel.
Present a clear next step.
Focus too heavily on how its built, or be too self-congratulatory (“we’ve designed this brilliant new thing”).
Be positive and enthusiastic about the benefits.
Say something is easy or simple to do - this a subjective judgment.
Keep it succinct - be respectful of users' time.
Force users to engage - we may be preventing them from completing their goals.