Content Guidelines

Content Guidelines

Content Guidelines

Our guidelines for creating content that is easy to understand, user-focused, and concise.

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 VM

  • Plural 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?



Help make this page more useful.

Help make this page more useful.

Help make this page more useful.

Help make this page more useful.