Use active voice in most cases and use passive voice sparingly.
In an active sentence, it's clear who's doing what. The actor is the subject, and the subject of the sentence is doing something.
At times, active voice can come across too harshly. In these cases, use passive voice. This separates the actor from the action enough to soften a sentence.
In a passive sentence, action is being taken upon the subject.
You can usually reframe a message to focus on the object, or on the actions someone could take, as another way to avoid passive voice.
Use contractions to sound more conversational and natural.
Use commonly understood contractions to keep sentences from feeling out-of-touch, robotic, or overly formal.
Some common contractions:
Use simple verb tenses: past, present, and future. Simple tenses are used to describe actions without specifically stating whether the actions are completed or ongoing.
If any of the following comes before the verb in a sentence, it’s not simple tense:
If the verb in a sentence ends in “-ing,” it’s not simple tense.
Use sentence case across all Adobe product experiences.
When to use sentence case:
Use title case only when it clarifies that we’re speaking about a specific, official entity (such as a title or name). Title case is often a marker of formality in English, and overuse can cause users stress by implying formality or officialness where it doesn’t exist.
Use all caps sparingly.
When to use all caps:
All caps should never be used to emphasize a point.
We avoid speaking as our users. In nearly all situations, we aim to be conversational and talk to the user — not as them. Any exceptions depend on situational needs for sensitivity and clarity.
Most of the time, use second person (you, your, you’re) to address users and services.
Use first person (me, I, my) only in these situations:
In most situations, Adobe doesn't need to know or assume the gender of our users. So when we refer to users, we use singular they.
We don’t use “he/she” or “(s)he” — those are clunky and they exclude users who identify outside of the male/female binary.
Use any of these variants of they in their proper grammatical contexts:
Don't use ampersands (&) in UI copy. Use the word “and” instead.
Ampersands aren’t as accessible for people using screen readers. They also bring attention to the conjunction, which is the least important part of a sentence.
Refer to AP style when dealing with possessive plurals or possessive apostrophes on words ending with “s.”
Do not use apostrophes in place of quotation marks.
Use the serial comma, also known as the Oxford comma. This means providing a comma before the “and” when listing multiple items in a sentence (e.g., “Bacon, lettuce, and tomato”).
If you find that you're using a lot of commas in a sentence, try to remove some. Or, try splitting up the sentence with periods or em dashes. Overusing commas or relying on them to lengthen sentences diminishes readability.
Use ellipses when truncating text in small spaces, and when communicating progress of a process (e.g., “Signing out…”). This can also be used as a form of iconography when providing an affordance for things like More menus.
Make sure to use the Unicode form of an ellipsis to ensure readability for screen readers.
Do not use exclamation marks. They are difficult to localize and easy to overuse.
For bulleted and numbered lists, use periods at the end of each list item only if you need to make them complete sentences. If one item in the list needs an ending period, then use periods at the end of all items. In all other cases, lists do not use periods.
Short, direct sentences within UI components, such as toasts and notifications, don’t need periods.
Do not use periods in headers or buttons.
Question marks are the only kind of punctuation we use in UI-specific headers.
Use rarely. Do not use when directly referring to interface elements (see our Typography page for guidance on using bold text to do so).
Do not use semicolons. If you need a break in a sentence, you can use periods, commas, or occasionally em dashes.
Do not use any emoji in UI language. Emoji are difficult to localize, tend to diminish readability and comprehension, and often convey tone that can be inappropriate depending on certain situations.
Use em dashes rarely, and add spaces between them and their surrounding words (e.g., "Shaken — not stirred").
En dashes and hyphens do not need spaces surrounding them.
Use K for thousands, M for millions, B for billions, capitalized, no periods. Include a space between the number and the unit of measurement (e.g., "71 M records found").
For full sentences where measurements or other numbers are present, use AP style and spell out the unit of measurement (e.g., 2 points, 2 picas, 2 pixels, 2 megabytes).
Similarly, use AP style when abbreviating measurements or time. Make sure there’s a space between the number and the unit of measurement (e.g., 2 pt, 2 MB, 2 min, 2 hr).
Use Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec (no periods).
Use Sun, Mon, Tue, Wed, Thu, Fri, Sat (no periods).
Use sec, min, hr (singular, no periods, no comma; e.g., 1 hr 21 min).
Use lowercase am and pm indicators without a preceding space, unless you’re describing 24-hour time (e.g., 17:15).
Use the numerical form of $1.00 when formality is needed, or when the number is dynamic and might include cents.
Use the number form of $1 when you need a more casual, neutral tone or if there is a space constraint and you can round off to the nearest dollar.
Use the international abbreviation for the currency when you need to disambiguate types of currency (e.g., "$100 USD equals $138.21 SGD").
Use a comma to offset groups of three digits, for readability:
But for the best readability, when citing large, round numbers, spell out the word:
Spell out zero and one, but use the numerals for all other numbers.
Don’t spell out zero and one when telling time, presenting a series, or providing a timestamp.
If you’re mentioning currency or time alongside other types of numbers, spell out the number to make the currency or time more prominent.
Use the percent symbol (%) instead of spelling out the word "percent."
The date formats you use will depend on your product. Some experiences might require the full format, where others might require something more compact:
Additionally, dates are often localized. For example, in Europe and the UK, the previous date example would be written:
Work with a localization expert to localize dates and times for your product’s specific cases.
For a timestamp in a video editor where precision is needed, go by hour, then minute, then second, following this formula: HH:MM:SS.
In a tutorial playlist, for example, less detail is needed. If the video is less than an hour long, omit the hours.
Avoid time zones unless absolutely necessary — if possible, dynamically convert to the user’s time zone.
Use lists to break down complex ideas and make them more readable and scannable. You can also use them to make parallel choices easy to compare.
Use an introductory phrase with a colon to lead into the list, and write each list item so it works with that phrase.
Phrase your list items to be consistent with each other as much as possible. This helps with comprehension and readability.
Some things to keep in mind when writing lists:
Capitalize the first letter of each list item and use sentence case.