Guidelines

When writing UX copy for Iterable, our goals for capitalization are:

• Clarity: make our app easy to read, friendly, and consistent
• Make it easy to do the right thing (PMs, writers, designers, and engineers should rarely have to make a judgement call about capitalization — these choices should be unambiguous).
• Give weight to Iterable's significant features, so that they stand out appropriately.

We generally prefer sentence case, because:

• It's easier to read
• It's easier to spot proper nouns
• It's friendlier

However:

• There are some places where title case should be used — primarily, for page headers (and links to those pages), and for named features.

And, finally:

• Clarity wins. We can make exceptions where needed.

These points come from this article, which describes tradeoffs between sentence case and title case.

 

Feature names

Formal vs informal feature names

Before a feature is released, the PMM team decides on its name.

All features have names—sometimes informal, sometimes formal. For example, "Catalog" and "Brand Affinity™" are formal feature names; "data feeds" is an informal feature name.

To decide whether a feature should have a formal or informal name, PMM considers things such as:

• Is it a name we might trademark?
• Is this a unique competitive advantage, or a table stakes offering?
• If this has a name, will it be easier for the customer to understand?
• Is it a "common name" (something you might actually just happen to say, if you didn't know the name) like "send time optimization"—or is it something that has more of a branded feel, like "Predictive Goals?"
• Even if it is a "common name," is it directly comparable to a "named" feature offered by a competitor? For example, we have "Channel Optimization" (not heavily branded), but Braze has "Intelligent Channel" (branded).
• E.g., Channel Optimization is channel optimization (Iterable)
• E.g., Intelligence Channel is channel optimization (Braze)
• Will customers stack our feature up against a specific feature that a competitor offers? For example, "Predictive Goals" vs "Predictive Cohorts."

Casing for feature names

• For named features (formal names), always use title case.
• Examples:
• "To understand how engaged your contacts are with your brand, check out their Brand Affinity™ score."
• A checkbox for enabling Send Time Optimization on a campaign:
• "[ ] Enable Send Time Optimization" (if it's a named feature)
• "[ ] Enable send time optimization" (if it's not a named feature)
• For naed features (formal names), use title case when referring to the overall feature ("Predictive Goals"), but not when referring to the feature's items ("a predictive goal", or a button that says "New predictive goal").
• Similar examples:
• Catalog (feature) / a catalog (an instance of that feature)
• Workflows (feature) / a workflow (an instance of that feature)

Resolving ambiguity

If there's ambiguity about whether a word references a feature ("Catalog") or an item related to the feature ("a catalog"), use your discretion—but keep clarity in mind, and prefer sentence case where possible.

Formal feature names (incomplete list)

• Brand Affinity™
• Catalog
• Workflow Studio

Informal feature names (incomplete list)

• data feeds
• system webhooks
• snippets

 

Page titles

Use title case for page titles (top-level headings). Even if the page title corresponds to a feature that has an informal name—when sentence case is normally the rule—use title case.

This rule applies no matter how "deep" the page is within its containing feature.

For example, the top-level "Workflows" page should use title case, but so should the "Edit Workflow" page (which you get to by clicking a button on that top-level "Workflows" page).

The idea is to always use title case for a page name, no matter if it's the "top-level" feature page or not.

This is true for page titles, but not for modal/window titles. Modal and window titles should be sentence case.

Nav links

Use title case any time you're linking, by name, to a page in the app (from global nav, or anywhere else).

Link casing should match page casing, and page casing should use title case. This means the page, and links to it, should use title case.

Because of this, all global nav items should use title case. This  will prevent those menus from having some "Title Case" and some "Sentence case," which will just look... broken.

 

Breadcrumbs

In modernized UI, breadcrumbs are all caps. If this changes, it may make sense to have the breadcrumb use title case (to match the pages they're linking to).

In non-modernized UI, breadcrumb casing should match the case of the page they're linking to (which should be title case, since pages should use title case for naming).

 

Events, metrics and webhooks

Use sentence case for metric names, event names and webhook names. However, as always—don't let clarity suffer. In a given situation, use title case if needed to improve the clarity.

On a menu (or other control), capitalize the first word of the event, metric, or webhook name:

• E-mail click
• Push open
• Total push holdouts
• Unique email clicks
• SMS received

In a sentence, use lower case as normal:

• You'll see an email click event.
• This will not create a push open event.

 

Pendo guides

For Pendo guide titles, use title case. Pendo guides align closely to marketing material, which uses title case for titles and headers.

For help figuring out how to properly title case a piece of text, check out capitalizemytitle.com (use the AP tab).

 

Example

This Pendo guide correctly uses title case for its header.