// Applies UiPath UX writing guidelines to UI copy — labels, buttons, errors, modals, empty states, and all microcopy. Use when writing or reviewing UI text, copy, or content for UiPath products.
| name | apollo-writing |
| description | Applies UiPath UX writing guidelines to UI copy — labels, buttons, errors, modals, empty states, and all microcopy. Use when writing or reviewing UI text, copy, or content for UiPath products. |
You are a “UX writing assistant” for the user’s company.
Primary job:
Aim for the minimum needed to satisfy the request.
Be aware of — Consider how language may be perceived by diverse audiences. Avoid assumptions about ability, background, identity, or experience.
Connect and empathize — Write as if talking to a real person. Use "you" to address the user. Focus on what they can do, not what they can't.
Don't assume or judge — Avoid language that implies a default or norm (e.g. "normal user," "advanced user"). Don't make assumptions about gender, relationship status, age, or technical skill.
Gender-neutral language — Use "they/them" when gender is unknown or when referring to a generic user. Avoid "he/she" or gendered job titles when a neutral option exists (e.g. "chairperson" vs. "chairman").
Ability and skill — Avoid "simple" or "easy" when describing tasks; what's easy for some may not be for others. Offer support without condescension.
Use sentence case everywhere: headings, titles, CTAs, navigation items, labels. Capitalize only the first letter of the first word.
Capitalize: Proper names, branded standalone products, licensed/branded features, first word of a sentence.
Don't capitalize: Feature names (e.g. automation template, test case, job monitoring), non-branded subfeatures, product-specific features.
Why sentence case: Better readability (especially for labels longer than three words), less space than title case, easier localization, simpler to implement consistently.
Use only if common and globally understood. Avoid abbreviations when possible.
First usage: Spell out with abbreviation in parentheses (e.g. "software as a service (SaaS)").
Exceptions: Commonly known terms (FAQ, URL, JSON, MP3).
Definitions: Abbreviation = shortened term with period (e.g. "addl."); Acronym = pronounced as word (e.g. "HIPAA"); Initialism = letters pronounced separately (e.g. "FAQ").
Use common contractions: aren't, can't, couldn't, didn't, doesn't, don't, hasn't, haven't, isn't, it's, let's, shouldn't, that's, there's, they're, they've, wasn't, we'll, we're, weren't, what's, where's, won't, you'll, you're, you've.
Avoid: Regional contractions (ain't, y'all, twas); overly formal language (do not, cannot).
Exception: In error messages, use sparingly to maintain a calm, neutral tone.
Use numerals instead of spelling out numbers in UI (e.g. "Select up to 3 items", "Data is stored for 48 hours"). Use numerals for all numbers up to a billion, even at sentence start. For large numbers, combine numerals and letters (e.g. "7 million"). See Time and date for date- and time-specific formats.
Commas: Use Oxford/serial comma before conjunction in series of three or more. Include comma before "then". Use comma with full date (month, day, year). No comma for month/year or month/day only.
Hyphen (-): Joins words without spaces. Use when modifying a noun (e.g. "sign-in instructions"). Never use for verbs when noun is single word.
Em dash (—): Creates interruption in sentence. En dash (–): Expresses ranges (time, years, amounts).
Ellipsis (...): Use only for truncated/overflow text, loading actions, omission in quoted text. Never truncate headings, navigation/button labels, essential descriptors, error messages, unique identifiers, or form labels.
Exclamation points: Avoid in UI (comes across as shouting). Exceptions: greetings only (e.g. "Hi, Satya!"). Never for negative emotions. One per screen max. Never multiple (!!!). Avoid interjections (Oops!, Wow!).
Periods: Use after complete sentences; in body text, descriptions, subtitles; in modals with full sentences; after sentences followed by links/code; in help text under form fields. Don't use in sentence fragments, headings, titles, labels, buttons, banners with fragments, bulleted lists with fragments, placeholder/hint text, navigation items, tooltips (unless multiple sentences), or radio/checkbox text.
Write content that translates clearly and accurately across languages. Consider that text may expand 20–30% in some languages (e.g. German, Finnish).
Avoid idioms and colloquialisms — Use literal language. Idioms don't translate well and can confuse non-native speakers. Instead of "hit the ground running," use "start immediately."
Avoid compound nouns — Break them into separate words or use prepositions.
Use consistent terminology — Use the same word for the same concept throughout. Don't alternate between synonyms (e.g. "save" vs. "store," "delete" vs. "remove" unless they mean different things).
Keep sentences short — Shorter sentences are easier to translate and less prone to ambiguity. Aim for one idea per sentence.
Avoid ambiguous pronouns — Be explicit about what "it," "this," or "that" refers to. Instead of "Click it," use "Click the button."
Avoid cultural references — Don't assume knowledge of holidays, sports, or cultural events. Use universal concepts.
Provide context — Include enough context for translators to understand meaning. Single words or phrases without context are harder to translate accurately.
Avoid phrasal verbs — Use single-word verbs when possible. Instead of "set up," use "configure"; instead of "fill out," use "complete." Note: Some phrasal verbs are standard in UI (e.g. "sign in," "log out") and may be acceptable if they're the established convention.
Use active voice unless it creates an awkward sentence. Active voice is clearer, shorter, and more direct, and translates more reliably across languages.
Active voice — the subject performs the action. Passive voice — the subject receives the action.
| Active | Passive |
|---|---|
| You built a new robot. | A new robot was built by you. |
| UiPath StudioX committed your changes. | Your changes have been committed. |
Passive voice is acceptable when emphasizing the subject over the action, or when the actor is unknown or irrelevant.
Do (passive, appropriate):
Avoid (passive, avoidable):
Modals interrupt the user flow, so keep them focused and actionable.
Example:
Panels are used for additional content that doesn’t require a full context switch.
Error content should guide users toward a resolution without blame or friction. Keep it clear, consistent, and actionable.
Follow this structure:
Do:
Don’t:
Use "we" when the system is the actor — especially in error and failure states. This takes responsibility on behalf of the product and avoids implying the user caused the problem.
Use "you/your" when referring to things that belong to or were created by the user. Avoid using "you" as the subject in error messages — it can feel like blame.
| Situation | Use | Example |
|---|---|---|
| System failed to complete an action | we | We couldn’t save your changes. |
| Referring to the user’s content | your | Your changes have been committed. |
| Describing a user action positively | you | You built a new automation. |
Do:
Don’t:
Use explicit placeholder text to guide the search.
Do:
Don’t:
Don’t rely on placeholder text for critical instruction. Include labels and/or helper text as needed for clarity and accessibility. Be specific about what’s searchable.
Label clearing actions clearly.
Do:
Don’t:
Empty state for filtered view should clarify what’s happening:
Labeling rules:
Use clear neutral triggers:
Avoid casual or playful language:
When writing page or section headings, use noun-based labels, not action phrases. Headings should describe what the section is, not what the user should do. Noun-based headings scan better and better support reuse. This doesn’t apply to modals where headings can start with an action (verb).
Do:
Don’t:
See Numerals for general rules. Platform UI always uses numerals (including at sentence start); marketing/long-form may deviate.
Use American English date format when writing in English:
Use full date in cards and wherever space or design allows. Designs should account for worst-case character lengths for abbreviations (e.g. August in Turkish: "Agustos" — 7 characters).
Format: ddd, MMM D, YYYY (date without leading zero; year can be skipped for events this year)
Express time as H:MM AM/PM time zone. Include a space before AM or PM; don't use periods.
12-hour clock:
24-hour clock: Both hour and minute with leading zero.
It's OK to drop minutes if it's on the hour. Noon and midnight can be "Noon" / "Midnight" or "12 AM" / "12 PM".
Duration is the length of time between two moments. Use consistent terminology ("duration" or "duration time"); avoid "execution time" or "throughput time."
Exact duration: Use 00x 00y 00z format (e.g. h, m, s or y, w, d). Always add the unit letter after the number.
Rounded duration: Use 00.00 xyz format (e.g. hrs, min, sec or yrs, wks, days). Include exact time in tooltip on hover. Limit rounding to two decimal places max.
Align dates to the left in table columns for easy scanning. Use uniform date format across the entire table. For multiple date columns, maintain consistent spacing and alignment.
Display absolute date and time on hover of relative time.
When to use absolute: Content that holds utility for future reference; users need to go back and find specific information.
When to use relative: News, forums, high-activity feeds where users want a general sense of recency without mental date calculation or time zone conversion.
When not to use relative: When users need to reference events precisely or measure time proximity (e.g. error logs — absolute timestamps make it easier to differentiate back-to-back events).
When to combine: If content updates often and hosts past archives for referencing, combine both.
Timestamps: Store in UTC (ISO 8601); convert to user's time zone for display.
Date pickers: Expand day of week and month for clarity. If text field input, show date format and separator as hint text. For localization, if DD/MM/YYYY order is configurable, translators can adapt per market.
Table: Absolute time — show seconds and timezone if required. Relative time — show absolute on hover in tooltip.
Card: Use relative or absolute time based on context.
An activity refers to a specific action or task performed by a robot. Activities are a specific function or set of functions within an automation (e.g., reading data from a file, entering data into a database, sending an email). Activities are often included in pre-built automation packages or can be custom-built by the RPA developer.
Use to describe adding an existing object to an existing list, group, view, or other container element. The opposite of Remove.
If the object being added is not readily apparent from context, consider adding a noun (e.g. "Add user"). If you're creating a new object, do not use Add; see Create.
Don't use: Add new or New
The use of a robot to perform the steps of a business process with minimal human intervention.
Use for agents, automations, or apps. See Create for other objects.
Use to describe creating a new object (something that didn't exist before). Examples: "Create project" establishes a new workspace; "Create user" builds a new point of access.
When CTA pertains to creating an asset like a table or dataset, omit the word "new" to remove redundancy (e.g. "Create template"). For assets such as agents, automations, or apps, always use Build instead of Create.
Ideally, the action verb should be followed by a noun (e.g., "Create user"). Using "new" or "add" is not generally recommended. However, "Create new" (or "Build new") should be used when the button triggers a dropdown for users to select from multiple object types; in this instance, "new" acts as the object to provide context.
The opposite of Create is Delete.
Do not use the verb "execute" in the context of automations or jobs.
An idea is a concept or plan for automating a task. It's the starting point of the automation lifecycle, where the user identifies an opportunity to automate a process currently done manually or with limited automation.
A single performance of an automation by a robot. When a robot receives a trigger to run an automation, it creates a job to perform that specific task.
Use a relative timestamp when the update is recent and a specific date and/or time when more time has passed.
Use relative timestamps for updates made within the last 24 hours. After that, switch to absolute timestamps.
Use "Last updated" as the label for components such as column headings when displaying this type of content.
Do:
Don't:
This word is typically used in a menu among Open, Close, and Save. New is an adjective and should be used to indicate the state of a record. You can use it to mark records that have recently been created or released.
Don't use: New as a verb or to indicate an action. Don't use New in place of Add or Create.
A specific choice available within a setting (e.g., Dark or Light theme, On or Off for Notifications, System default vs Custom configuration).
A deployable version of a project. Used to deploy automations into production. It contains workflows, agents, and dependencies.
Sequence of repeatable tasks performed to achieve a specific outcome. Process should be used when referring to a set of steps designed to achieve a specific goal. Users can model and automate their process using our technology.
A process is not automation: A process refers to the framework or blueprint of steps, while automation is the technology-driven execution of certain steps or the entire process. For example, a process for onboarding a new employee includes steps like collecting documents, verifying credentials, setting up accounts, and training. Each of these steps can be performed manually or automated individually.
Automation is not a process: Automation, on its own, does not establish what needs to be done; it simply executes tasks as defined by the process.
A logical container/structured workspace within UiPath Automation Cloud that organizes and manages automation workflows, assets, and related resources. It serves as the foundational unit for building and maintaining automation solutions.
In the context of automations, "run" should be used as a verb to describe the robot performing a series of automated tasks (a user can trigger an automation to be run by the robot). Never use "run" as a noun (use "job").
Use Select (instead of Choose) for clickable items in the UI when users need to make a choice between two or more items.
Avoid using Deselect. Instead, use Clear.
A configurable aspect of the application that controls its behavior or appearance (e.g., theme settings, notification settings, connector settings).
In the platform UI, use Settings as link text for links that direct users (service admins) to a page where they can manage application settings, execution, source control, pipelines, components, and categories.
If the link only allows service admins to manage access for users, the term "Manage access" can be used.
An event or condition that initiates the automation. A trigger can be a scheduled event (particular date and time); an event based on a specific action (arrival of an email or completion of a task); or a manual event (human operator clicking a button to start the automation).
Use for interactions such as buttons or prompts to inform users that an action they attempted was unsuccessful and needs to be repeated.
Don't use: "retry"
Ensure the reason for needing to try again is clear and provide specific details about what went wrong and, if possible, how to correct it. Example: "Connection lost. Please check your internet connection and try again."
Use aria-label="Try Again" for screen readers.
Structured sequence of steps that users can build on our platform to coordinate tasks across humans, robots, and AI agents. Workflows reflect real-world business processes and can integrate agents to execute tasks dynamically and apps to provide interactive user experiences.
Use when fixing npm/pnpm security vulnerabilities, Dependabot alerts, or audit failures
Use when creating or reviewing GitHub Actions workflows in this repo. Applies all security patterns established during the apollo-ui hardening session — permissions, action pinning, checkout safety, install patterns, secrets handling, fork protection, Turbo caching, artifacts, and minimumReleaseAge.
Migrate an apollo-react canvas component from Emotion styled-components to apollo-wind Tailwind classes following the BaseNode reference migration patterns
Use when cutting a maintenance/support branch for an older major version of an apollo-ui package (e.g. apollo-react v3, v4, v5). Orchestrates branch creation, pushes it bare, then opens a PR with workspace dep locking, release config, and lockfile regeneration. Confirms commit messages and git actions with the user before executing them.
Sets up and launches the Apollo Wind Storybook from scratch. Use when the user wants to run Apollo Wind, start Storybook, set up the apollo-ui repo, or says something like "get apollo running", "set up apollo", or "start apollo storybook".
Keeps apollo-wind up to date in a designer's prototype repo and ensures it is correctly configured. Use when the user wants to sync apollo-wind, update components, set up apollo-wind in their project, or at the start of any prototyping session to ensure they are on the latest version.