The Four Pillars of UX Copy

Relevant: It must confine itself to the immediate context.

Intelligible: It must be easy to understand and contextualize without specialized knowledge and should not cost the user significant time or cognitive effort to read.

Direct: It must be simple and light, informing the user directly without metaphors or colloquialisms.

Minimalist: It must be acutely aware of the real estate it will occupy in an interface or on an element and justify its size and content.

Content Guidelines


Voice and Tense

Use the active voice and present tense for all in-Editor copy unless absolutely necessary. Avoid using conditional language unless the item or process requires it.
General copy must be written to be understandable by those with a low reading level / familiarity.

Use the second person to address user choices. Do not use the first person, and avoid using third person unless absolutely necessary (in such circumstances use gender-neutral language).

UI must be referred to by its label.

Spelling and Formatting

Use US English conventions for the spelling of words and phrases.

Use proper noun capitalization for direct references to component names and interfaces.

Always capitalize the word “Editor” when referring to the Unity Editor.

Avoid using acronyms if possible. All acronyms must be prefaced or contextualized by appearing fully written on first appearance, immediately followed by a parenthetical listing the acronym.

  • Exceptions: Interfaces or workflows which provide heavy context to the acronym’s identity prior to the instance.


Do not use colloquialisms, layman’s terms, or other indirect means of referencing actions, items, or processes.

Copy should be written in complete sentences and fully convey the necessary information for each instance.

Text should be maintainable; avoid using information that may be deprecated quickly, such as version numbers, unless it’s absolutely necessary or it relates to the beginning of a subject. Instead, use a more general alternative like “latest build” if possible or clearly call out the listed version as the initial release.

Images should be avoided unless absolutely necessary and must always contain descriptive text indicating their content, as well as alt-text.

Good UX writing must

Provide direct, clear information with minimal need for additional context.

Require minimal technical knowledge unless absolutely required.

Provide descriptive actionable decisions on commands.

Provide necessary elaboration on commands that: 1) Invoke a process or require additional actions. 2) Are destructive in nature.

Use consistent in terminology and language.

Important questions to keep in mind

Can someone understand the information within the immediately accessible context? Users must be able to identify the meaning of the information or choices with relative ease, even when returning to the text. Users must also be able to identify the nature, identity, and context of a command by its label unless substantial external context is provided.

Does the content of the message address what the user needs to know about a subject? The message must clearly indicate the nature of the subject (e.g., the cause of the problem). The wording of the message must not be ambiguous and should avoid the possibility of being misconstrued. If the subject of message has a clear means of resolution it should be offered to the user.

Does the content of this message require specialized knowledge or does the message contain ambiguous information? While some information will require specialized knowledge, it is important to provide the novice user with an intelligible and decipherable meaning. Avoid acronyms unless absolutely required or if substantial identifying information exists either on-screen or contextually. Example: Using the acronym DOTS to refer to the Data-Oriented Technology Stack is fine if the user is already in the DOTS Editor and has already been presented with the full text and acronym parenthetical “Data-Oriented Technology Stack (DOTS).”

Is the content accessible? Ensure that the wording of content can be accurately read by screen readers.

Is the content displayed at a proper size? Ensure the design and display of text is correct: This responsibility does not fall uniquely on the designers and developers.

Does the content concern an important, non-reversible, or destructive action? For actions that have a lasting impact or may have unintended consequences, it is advisable to highlight the nature of the action or process and to consider including a confirmation dialog.

Formatting Guidelines

When giving file path directions through a menu in Unity or in the PC, always use a single right-pointing angle bracket with a space on either side.

Menu Items must always be displayed in bold.

Menu Directions should be indicated through right-pointing angle brackets on either side of each step.

UI must be referred to by its label and should indicate its component type when necessary for clarity.

Component references (Buttons, Checkboxes, etc.) should appear bolded.

Keyboard key names must be capitalized.

Numbers should be spelled out from one through nine, and numerals should be used for any number greater than nine except in the following circumstances: 1) Measurements and calculations must be expressed as numerals. (Example: “5MB” not “five MB”). 2) Instances where the numbers appear as numerals in the Editor or in a script (Example: “Set the value to 0 or 1”).

Indicate the root folder in file paths/directories with slashes between each folder.

Folder names appearing in file paths/directories that are user-dependent must be expressed inside square bracket

File and folder names must be written in italics.

File extensions must not be formatted.

URLs must be formatted in PascalCase (UpperCamelCase).

In-Editor UX Copy


General Controls

General controls that have labels must clearly indicate the nature of their usage, where the labels provide sufficient information for a user to identify an element’s purpose or identity within the immediate context of its interface.

Control copy should front-load the objective of an action where applicable.


Button text must directly indicate the action being performed and must avoid vague or ambiguous language.

Buttons which initiate an action must be clearly labeled with text that states what action will be executed. This includes confirmation buttons that initiate a process or action, which must clearly imply the outcome.

  • Example: A confirmation button for a modal dialog regarding the execution of a build request should use the text “Build” or “Build Project” to clearly indicate the action will be performed on click.

  • Example: A modal warning dialog which contains a button to continue initiating a process must clearly indicate that the process will be continued. Avoid ambiguous text like “Got it.” or “Ok”.

Destructive elements must always clearly state the implications of their actions.

  • Example: A confirmation button for a modal dialog regarding the deletion of a project file should use the text “Delete Project” instead of vague text like “Ok” or “Confirm” to reassert the user intent.

For more information on buttons that appear in specialized contexts, such as Dialogs and Wizards, see the sections below.

Choice Elements

Label text on or beside choice elements must clearly indicate the context for the available choices in the element.

For elements that open nested menus or interfaces, for example the Collab or Account dropdowns in the Main Toolbar, the on-element label should indicate the nature and context of the embedded interface.


Tooltips are an embedded method of providing the user with top-level contextual information as to the identity and usage of an element. They supply relevant information without the need to navigate away from the workflow or reference external resources.

The content included in a Tooltip can vary depending on the element type and location as noted below.


Tooltips for Tools should include relevant hotkey commands; these must appear as a unique line of text that is visually separated from the overview text.

Settings Elements

Tooltips that appear on setting-based elements like Dropdowns and Pop-ups must provide the user with identifying information on the element’s purpose as well as sufficient information to contextualize user choices within the framing.


Dialogs are informational windows that provide users with important information regarding processes, choices, or updates.


Dialogs should front-load important identifying information such as their nature or context. An effective Dialog clearly informs the user of its purpose, while avoiding unnecessary information. Content must adhere to standard UX Copy guidelines.

When a Dialog’s context relates to a larger process, or a context-sensitive scope of action, it should alert the user to relevant information that may be otherwise undiscoverable. This includes providing the user with a likely means of resolution when a clear course of action is available or inform them of what the action does not encompass for destructive actions like removing a project from the Hub (Example: Remove project from Hub dialog : “This will not delete the files from your computer”).

When a Dialog contains or requires choices, context must be indicated in the header or the body of the Dialog. If the Dialog has dense content, the nature of the choice must be indicated at the bottom of the body in a separate line. The user must be able to quickly identify the nature of the available choices and resolve the Dialog without significant effort.

Dialog-closing elements, including response options, must always be placed at the very bottom of the Dialog window, below all other response options.

Response Options

Response options can either be simple choices like “Confirm” and “Cancel,” or complex actions like continuing to another dialog or window. These often appear as buttons on the dialog.

Response options for dialogs must be direct and clear: Standard confirmation and cancelation responses are preferable for simple Dialogs.

For simple choices, use descriptive, active verbs. If the process requires further elaboration, cannot provide sufficient context for simple response options, or initiates additional processes non-standard responses indicating the nature of the choice should be used.

These other response options must adhere to the following guidelines

Be direct: Avoid using two- and three-word responses.

Use active language: Indicate the action that will be performed.

Indicate the nature of the response
, and if the response opens an additional window, indicate so with an ellipsis (...).


Wizards provide guided walkthroughs for complex processes or setups and help break down workflows into unique pieces that address individual steps.

In writing copy for Wizards, it’s important to consider both the individual cards that cover each step and the Wizard as a whole. Each card should address a unique step and provide the necessary context for decisions or actions therein, building the user’s understanding during the workflow.

Wizards must front-load identifying information that can be used to identify which step the user is currently performing in a process. They should also separate high-level informational text to increase its visibility.

Wizards with multiple cards must indicate advancement controls (such as “Next” and “Back” buttons) with clear labels. Initiation controls must use active language and be labeled with the action they perform (for example, “Create Ragdoll” in the Ragdoll Wizard). Avoid vague or general words like “Ok” or “Done.”