Content guidelines intend to outline the standards for creating clear and consistent communication across all our product flows. It defines the expected voice, tone, and language conventions to ensure alignment across teams and touch points.
Voice
Our brand voice reflects clarity and expertise across all communication/product flows. It provides information in a direct and trustworthy manner. The message remains concise and focused on insight rather than persuasion.
Attributes
Insightful: We communicate information that helps our users understand context, purpose, or impact.
Clear: We use direct and simple language that is easy to read and interpret.
Concise: We deliver only the information needed, without unnecessary detail or repetition.
Trustworthy: We provide accurate and reliable content that our users can trust for decision-making.
Tone
We adapt our tone based on the user’s context while maintaining the core voice. We communicate information in a manner that feels supportive and approachable. The tone prioritizes user understanding always.
Attributes
Honest: We share information in a straightforward and transparent manner, without overstating or overselling.
Conversational: We use natural, everyday language that prioritizes readability and flow while maintaining a professional tone.
Helpful: We support users throughout their product journey by providing clarity, information, and solutions that do not overwhelm and ensure a smooth experience.
Even when we use technical terminology in our content, we ensure it is clear and understandable.
Language
Our content follows U.S. English spelling and grammar conventions. We are in the process of standardizing terminology across all touchpoints to maintain consistency and clarity.
U.S. English (Do) | U.K. English (Don't) |
|---|---|
Color | Colour |
Standardize | Standardise |
✅ Do: Customize the virtualization settings in the Control Panel to optimize your workload performance. The program will analyze usage trends to suggest improvements.
❌ Don't: Customise the virtualisation settings in the Control Panel to optimise your workload performance. The programme will analyse usage trends to suggest improvements.
Voice Structure
We use the active voice for all content by default. This makes communication more direct, easier to read, and quicker to process.
✅ Do: The Nutanix cluster automatically applies security patches during the scheduled maintenance window.
❌ Don't: Security patches are automatically applied by the Nutanix cluster during the scheduled maintenance window.
✅ Do: Security policy created
❌ Don't: The security policy has been created
Grammar Rules
Casing
We use our design components to define the casing. As a rule, we use sentence case for long-form content and title case for short-form content.
We also define the writing rules for each design component on its respective pages.
Sentence case: Configure storage policies for your workloads
Components with long-form content: Alert banners, modal descriptions, inline errors, and tooltips
Title case: Configure Storage Policies For Your Workloads
Components with short-form content: CTA buttons, table titles, tags, page headers, menu, and stepper.
Proper Nouns and Common Nouns
Proper nouns refer to unique and specific entities. They are always capitalized.
Examples: London, Google
Common nouns refer to general concepts or categories. They are not capitalized unless they begin a sentence or are used as a UI label.
Examples: city, company
In the context of Nutanix, proper nouns include product names and branded solutions that are unique to Nutanix. These terms are written in title case.
Examples: Prism Element, Prism Central, Nutanix Disaster Recovery
In the context of Nutanix, common nouns include concepts that are industry-standard and not unique to Nutanix. These terms are written in sentence case unless they appear in UI labels or the Menu.
Examples: recovery plans, protection points, clusters, storage policies, volume groups, virtual machines (VMs)
Over-capitalizing common words and concepts reduces readability. When many words are capitalized, the reader has to work harder to identify what is truly important; this disrupts the flow and often distracts from the main message.
Contractions
We do not use contractions in our content to ensure clarity and reduce misinterpretation for our global audience.
✅ Do: The system cannot detect the network
❌ Don't: The system can’t detect the network
Numbers
We use numbers/digits to improve clarity and reduce cognitive load.
✅ Do: The maximum allowed duration is 6 months
❌ Don't: The maximum allowed duration is six months
Dates
Nutanix maintains extensive logs and tables that record activity across systems.
Using the date format DD MM YYYY provides better readability in these contexts because it presents the day first, followed by the month and year. This reduces ambiguity, improves scanning in tabular formats, and aligns with how dates are commonly referenced.
✅ Do: 14 Jan 2025
❌ Don't: Jan 14 2024 or 14th Jan 2025
Abbreviations for the days of the week:
Monday – Mon
Tuesday – Tue
Wednesday – Wed
Thursday – Thu
Friday – Fri
Saturday – Sat
Sunday – Sun
Abbreviations for the months:
January – Jan
February – Feb
March – Mar
April – Apr
May – leave it as May
June – Jun
July – Jul
August – Aug
September – Sep
October – Oct
November – Nov
December – Dec
When writing a date range, use an en dash (–) with keyboard shortcut Option + Hyphen.
✅ Do:14 Jan 2025 – 25 Feb 2025
❌ Don't: 14 Jan 2025 to 25 Feb 2025
When writing a date range in a sentence, use 'to' and 'from'.
✅ Do: This page is under maintenance from 14 Jan 2025 to 25 Feb 2025
❌ Don't: This page is under maintenance from 14 Jan 2025 – 25 Feb 2025
When writing the day and date, lead with the day to ensure clarity and avoid ambiguity.
✅ Do: Tue, 14 Jan 2025
❌ Don't: 14 Jan 2025 Tuesday
Time
We use the 12-hour clock format.
Include AM or PM for clarity and readability.
Specify the time zone when relevant to the context.
Insert a space between the time and AM/PM.
Use a colon (:) to separate hours and minutes, not a period (.).
✅ Do:10:30 PM
❌ Don't: 22:30 p.m.
When writing a time range, use an en dash (–) with keyboard shortcut Option + Hyphen.
✅ Do: 10:30 PM – 12:30 AM
Time Zones
When writing a time zone, use the appropriate abbreviation and separate it from the time with a space.
✅ Do: 10:30 PM UTC
❌ Don't: 10:30 PM (UTC)
Timestamps
We begin with hours for a duration of up to 23 hours.
After 23 hours, we switch to days.
After 7 days, we use relative or absolute timestamps based on the severity and context of the scenario.
We always present timestamps in a way that avoids pushing our users to calculate the time manually.
We use hours, minutes, and seconds format based on the scenario.
✅ Do:
2 Hours ago
3 Days ago
10:30 PM, 22 Feb 2025
10 h 30 m 40 s
File Formats
We use capitalized file extensions without a leading dot for better readability, flow, and clarity.
✅ Do: Upload a file in CSV format
❌ Don't: Upload a file in .csv format
Periods (.)
We use a period when the text forms a complete sentence. This includes description text, messages, and notifications. We also add only a single space after a period.
✅ Use periods when:
The sentence is long or contains other proper punctuation
There are multiple sentences in a message
A sentence includes a link, but do not hyperlink the period.
❌ Do not use periods for:
Headings and titles
Field labels
Button names
Tooltips
Menu names
Lists made up of sentence fragments or short phrases
The goal is to avoid over-punctuating short UI strings while maintaining proper punctuation for full sentences.
✅ Do: Wait until the AHV installation is complete, and then the nodes will be discovered on Foundation Central.
❌ Don't: Identify scale requirements for the capabilities.
Commas (,)
We use commas to improve clarity and readability. Commas separate items in a list, structure complex sentences, and create natural pauses that help the reader process information.
Use a comma when:
Separating items in a list
Introducing a pause for clarity
Connecting clauses within a longer sentence
Use the Oxford (serial) comma before the final item in a list to avoid ambiguity.
✅ Do: You can use the move tool to migrate files, VMs, and security policies.
❌ Don't: You can use the move tool to migrate files, VMs and security policies.
Semicolons (;)
We use a semicolon to connect two independent sentences that are closely related in meaning when you do not want to join them with conjunctions such as “and” or “but.” A semicolon creates a smooth transition while keeping both ideas distinct.
✅ Do: You can manage virtual machines across multiple clusters using Prism Central; this centralization simplifies operations and reduces overhead.
❌ Don't: You can manage virtual machines across multiple clusters using Prism Central and this centralization simplifies operations and reduces overhead.
Hyphens (-)
We use a hyphen to join words or parts of words when they work together to describe something more precisely. Hyphens create a single, clear idea from multiple terms.
Hyphens are used when the combined words function as an adjective before a noun. When using the same words as verbs, you replace the hyphen with a space.
✅ Do: Scale-out, user-friendly, first-time user
❌ Don't: Scaleout, user friendly, first time user
Exclamation Marks (!)
Exclamation marks are rarely used in Nutanix products and workflows. They introduce unnecessary urgency and can be misinterpreted in technical contexts.
In UI environments, exclamation marks are also avoided because they visually resemble information and error icons, which may lead to confusion or incorrect interpretation.
Brackets ( )
Avoid using brackets to show both singular and plural forms (e.g., VM(s), node(s), item(s)). This creates visual noise and slows down readability.
✅ Do:
Singular version when only one input is allowed
Example: Add a VMPlural when one or more inputs are allowed
Example: Add VMs
Using the plural form in such scenarios allows the user to decide whether to add one or many, without needing bracketed suffixes.
Ampersands (&)
Use “and” instead of an ampersand in most cases to maintain readability and a professional tone.
Ampersands may be used only when:
Space is limited (e.g., table headings, CTAs), or
The term is widely recognized with an ampersand as part of its standard form, e.g. Terms & Conditions
In all other contexts, write out “and”.
Em Dash (—)
The em dash is longer than both the hyphen and the en dash. It is used to insert a break in thought, add emphasis, or provide additional information without disrupting sentence flow. There are no spaces before or after the em dash.
Use an em dash to:
Add emphasis
Insert extra information within a sentence
✅ Do: Nutanix delivers simplicity and performance—without compromise.Keyboard shortcut Shift + Option + Hyphen on Mac and Alt + 0151 on Windows
En Dash (–)
The en dash is slightly longer than a hyphen and shorter than an em dash. It is used to show ranges or to connect contrasting or related concepts. There are no spaces before or after the en dash.
Use an en dash to:
Indicate a range of values (time, distance, numbers)
Show a connection or contrast between two concepts
✅ Do: 2022–2025, East–west traffic
Keyboard shortcut Option + Hyphen on Mac and Alt + 0150 on Windows
Ellipsis (…)
An ellipsis consists of exactly three dots and is used to indicate that a process is in progress and has not yet reached the final state. It communicates continuation without giving a sense of completion.
Use an ellipsis to show:
An ongoing operation
A loading state
A step that is still in progress
✅ Do: Enabling flow… Downloading file…
❌ Don't: Add a period after an ellipsis, and do not use four dots.
Words and phrases to avoid
❌ Don't: Please, successfully, oops, sorry, uh-oh, something went wrong, you shall, you can, are you sure?