Our UX writing style follows our in-product voice principles.
These guidelines apply to text in U.S. English, our source language for writing in-product content. Defer to component-level style guidance when needed, and keep in mind that in-product language is internationalized according to specific locale standards and style.
We use Associated Press (AP) style for in-product UX writing, with any exceptions noted on this page.
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:
In general, 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:
Punctuation marks are an essential part of language, and they extend beyond running text. They appear in code, mathematical equations, keyboard shortcuts, file names, and more. When there are established conventions for such contexts, punctuation marks should follow those conventions.
In general, don’t use punctuation marks in place of words (e.g., "&" instead of "and" or "@" instead of "at"). And, don’t use them as design elements, or for anything purely stylistic in purpose.
For punctuation within blocks of code, use the Code typography component to differentiate the code from other written text.
Don’t use ampersands (&) in UI copy. Instead, use the word “and.”
Ampersands aren’t as accessible for people using screen readers. They also bring attention to the conjunction, which is the least important part of the sentence.
Don’t use apostrophes (') in place of quotation marks.
When pluralizing singular and plural words, add apostrophe-"s" when there’s no "s" at the end. For plural nouns that end with "s," add only an apostrophe.
For any other specifics on possessive apostrophes, refer to the AP style handbook.
Use asterisks ( * ) or "(required)" to establish form fields as required. Don’t use asterisks to denote anything as optional.
Make sure to use the Spectrum asterisk icon that comes built in with the design components — not the text form of an asterisk within the label string.
Don’t use asterisks in running text or labels when parentheses or a tooltip would suffice.
Don’t use the at sign (@) in place of the word "at."
Don’t use brackets ([] {}) in UI copy or running sentences. Instead, use parentheses ( ( ) ).
Use colons (:) when introducing lists of items or steps in a workflow. The lists and steps should be introduced on new lines.
Don’t use a colon at the end of a label for a form field. The design component should already communicate the relationship between the label and the input.
When listing things, use the serial comma (also known as the Oxford comma). This means providing a comma before the word “and” when listing multiple items in a sentence.
If you’re having to use a lot of commas in a sentence, consider whether you can split the sentence up with periods or em dashes.
In general, use ellipses (…) when truncating text in small spaces.
Use an ellipsis at the end of the text to communicate the progress of something that is in process, such as a waiting or loading state.
Don’t use an ellipsis in a call-to-action on a button to communicate that there’s a page or action beyond the button.
For hint text, if an action starts a process, use an ellipsis at the end of the text (e.g., “Add names or email addresses…”).
For menu items, adding an ellipsis at the end of the menu item will depend on if your product is using a native (OS-level) pattern or not. For a native menu that your product is adding to, defer to the native pattern. For a menu that doesn’t follow a native pattern, only prompt text (ghost text) should use an ellipsis. A menu item does not need an ellipsis, even if the item is an action.
If you need to directly refer to a UI element whose name ends with an ellipsis (e.g., “Find…“) in running text, drop the ellipsis: “Use Find to search the database.”
When using an ellipsis on a More menu, don’t use it as part of a string, and make sure to use the appropriate icon.
Don’t use emoji in any interface language.
Emoji often convey tones that may be inappropriate in certain contexts. They’re also difficult to localize, and tend to diminish readability and comprehension.
Don’t use an equals sign (=) in place of the word "equals," and don’t use this as shorthand for "meaning," "means,” or "is."
Don’t use exclamation marks (!) since they are difficult to localize and easy to overuse.
When communicating navigation, such as in breadcrumbs, use the "chevron" icon built into the component, not the greater than symbol.
Don’t use the greater than and less than symbols to communicate steps in a flow — use bulleted or numbered lists instead.
Don’t use these symbols to replace the words "greater than" or "less than." And don’t use them to accent or decorate a word.
Use em dashes (—) to separate distinct but related thoughts. Include spaces before and after the em dash.
Use en dashes (–) for number ranges and lengths of time, with no spaces before or after the en dash. Don’t use them when paired with the words “from” or “between.”
When needing to show gaps in data in a table, use an en dash to represent null, unavailable, or inapplicable values.
Use hyphens (-) between words, and with no spaces before or after the hyphen.
Don’t use the minus sign (-) in place of the word “minus,” “without,” “less,” “negative,” or other words related to subtraction.
Use parentheses ( ( ) ) to provide supplementary context.
Don’t use parentheses in simple tooltips. In rich tooltips, they can indicate keyboard shortcuts. Don’t use brackets in place of parentheses.
In the majority of cases, don’t use periods (.) or any other punctuation on the end of bulleted or numbered lists. If one list item is a complete sentence, then it would end with a period (or question mark). In this case, use periods at the end of all items.
Don’t use periods at the end of short, direct phrases within UI components (e.g., toasts, notifications).
Don’t use periods in headers or buttons.
Don’t use plus signs (+) in place of the word "and," bullet points, or as any other design elements.
Don’t use plus signs when indicating there is more of something available.
When writing titles, questions marks (?) are the only acceptable punctuation mark to include.
Avoid using question marks to ask rhetorical questions.
Use quotation marks (“”) only when quoting someone’s words.
Don’t use them when directly referring to interface elements. See the Typography page for guidance on using bold text to do so.
Don’t use backward slashes, and don’t use a forward slash ( / ) to combine words or ideas. This comes across as noncommittal, and affects comprehension and clarity. Instead, use the words “and” or “or.” Don’t use “and/or.”
Don’t use the vertical bar (|) in running text. Avoid using it to divide information in places other than webpage titles tags and footer info. It shouldn’t be used for purely stylistic or decorative purposes when blank space between items is sufficient.
When you use the vertical bar, use an icon and not its text form. Additionally, make sure you change its name in JAWS to “Pause” for proper accessibility.
Use abbreviations consistently throughout your experience to help with predictability and usability. When writing string descriptions or alt text, be sure to write the full word so that the content can be properly localized and so screenreaders will read the actual word instead of spelling out the abbreviation.
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 as singular, no periods, no comma, and with a space in between the number and the unit of time (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."
Date formatting is contextual, and it will depend on your product and use case. Different kinds of date formatting can be used for standalone strings in running text or for strings in more data-rich views.
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 U.K., the previous date example would be written:
For U.S. English, you can also format dates as MM-DD-YYYY, using the numeral for the month instead of the word. Use a 2-digit format (including a 0, even with single digit months and days). The 2-digit format also helps make it easier to parse and compare multiple dates, especially in tables or lists:
Work with a localization expert to localize dates and times for your product’s specific cases.
Learn more about the formatting for abbreviating dates (months and days) in the Abbreviations section.
Learn more about the formatting for abbreviating time (hours, minutes, seconds, and am and pm indicators) in the Abbreviations section.
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.