Arc XP LogoArc Design System
v2.3.0
GuidesPatternsComponentsIcon libraryTokensRelease notes
Github repo
Arc XP LogoArc Design System
v2.3.0
Copy standards
Copy/contentDate and timePhysical addressSearch field
Experiences
ArchivingDrag and dropElevationEmpty stateFile uploadForm validationNotificationsPage layoutPaginationRevision historySkeleton page
Foundations
ColorLinksSpacingTypography

Copy/content

Copy is everywhere throughout the Arc platform. The words we use on our screens are critical to helping our users do their jobs every day with ease and efficiency.

Copy is found in:
  • Product names
  • Buttons
  • Form fields
  • States
  • Modals
  • Notifications/snackbars
  • Tool tips
  • Dates/Time
  • Directions
This documentation is a reference for writing interface copy, including, but not limited to: designers, product managers, and translators.

#General guidelines

#Voice, or core personality

Our voice should stay consistent no matter the audience. As Arc’s user base becomes larger and more diverse, it is increasingly more important to define our voice, or core personality. Examples of personality traits: professional, sassy, confident, encouraging. Questions to consider as we aim identify and define Arc’s voice:
  • What are Arc’s values?
  • Who are our users?
  • How do we want our users to perceive Arc? feel about Arc?
  • How do we make sure our voice is able to address a global audience?

#Tone, or mood

Our tone of voice changes depending on the content and the context. For example, instructions for a certain part of the interface may have a more authoritative tone (mood), while a welcome screen or modal may have a celebratory tone (mood). It’s important to note that we keep in mind our tone, especially with the range of languages and cultures of our customers across the globe. Below are general guidelines to keep in mind while writing copy.

#Be brief, but informative

  • Avoid extra words
  • Avoid repeating words

#Be conversational

  • Make users feel at ease
  • Our users are under pressure and need to meet deadlines

#Use simple language

  • Keep in mind that most of our users are non-technical users
  • Avoid technical language and jargon; keep acronym usage to a minimum
  • Avoid cultural slang and clichés
    • Expressions like “under the hood,” “at the end of the day,” and “thinking outside the box” don’t add meaning to your copy and may cause challenges for translation

#Be inclusive

  • Keep accessibility and internationalization in mind. Arc serves a wide range of users of all abilities, languages, and cultures.
  • Avoid ableist language (words or phrases that may be prejudice and exclude people with disabilities)
  • Try to use verbs that are agnostic of medium (“Choose” instead of “Click”)
  • Be mindful of where you place copy in relation to interface components

#Writing guidelines

#Capitalization/case

Use sentence case: capitalize the first letter of the first word only (with the exception of certain names and words that require a capital first letter). 'Capitalization Example'

#Titles and headings

  • Keep to a single line
  • Try to limit to 3-5 words
'Title Example 1' 'Title Example 2'

#Buttons and links

  • Use an action verb
  • Try to limit to 1-3 words
'Title Example 2'

#Spelling

Spell out words out and avoid abbreviations where you can.

#Sentences

Be inclusive, action-oriented, and write in an active voice.
  • Empower the user to take an action.
'Title Example 2'
  • Avoid making the user feel that they did something wrong.
'Title Example 2'

#Always start with what is important.

  • Front-load copy with the most important information.
  • Let the user know what is happening in their state and what they can do.
  • Avoid “word clusters” or extra and unnecessary words
'Title Example 2'

#Numbers

Use numeric values instead of spelling out numbers. 'Title Example 2'

#Time format

We currently allow admins to set the time for the organization to be based on the user’s browser time OR an organization-wide timezone.

#Testing copy

#Read it out loud

  • Does it sound like something a person would say? Is it too familiar or too technical?

#Empathize with a user

  • Keep Arc user personas in mind as you write (personas section to come)
  • Will users have to read something multiple times to understand what is happening and what to do?

#Run it by your team

  • Design, Product, Engineering during review sessions
  • Customer Success Team (who work on the frontlines with our users across the globe)

#Test with users when possible

  • Use realistic copy and content when reviewing a feature or functionality
  • Use your best judgement as to whether you directly ask the user for copy feedback
Copyright 2021 Arc XP