# Voice

The character Tempo products keep in every string, from a balance to an error.

## Overview

Voice is what stays the same across Tempo products. [Tone](/docs/foundations/content/tone) is how that voice adjusts to the moment, such as a confirmed payment or a failed one.

People use Tempo products to move real money. Every string should help them answer three questions: what is happening, what it costs, and what happens next.

These guidelines describe how Tempo already writes on [tempo.xyz](https://tempo.xyz) and in the [developer docs](https://tempo.xyz/developers) (docs.tempo.xyz redirects there), then apply it to product screens.

## How Tempo Writes

Read across Tempo's site and docs, the writing has a consistent shape:

* **It leads with a verb.** Guide titles and actions are imperatives, such as Send a payment, Add funds, and Check the balance.
* **It defines before it explains.** A concept page opens with one sentence that says what the thing is, then lists its parts.
* **It states rules as facts.** Limits and protections read as what Tempo checks, enforces, or rejects, not as warnings.
* **It gives numbers instead of adjectives.** A transfer's fee appears as a cost in dollars, not as cheap or low.
* **It names availability plainly**, such as beta, preview, or devnet only, along with what changes it.
* **It keeps sentences short**, often one clause, and joins lists with a serial comma.
* **It never uses exclamation marks.** The developer docs also avoid hype words.

### From the Docs to the Interface

Each habit carries over to a product screen. These examples paraphrase the docs' style in interface terms.

| The docs                                 | A product screen                                                       |
| ---------------------------------------- | ---------------------------------------------------------------------- |
| Title a guide with the task it completes | Title the screen Send, and label its button Send payment               |
| Define a concept in one sentence         | An access key lets an app pay from your account, up to a limit you set |
| State a protection as a fact             | Fee payers can cover your network fee. They can't move your funds.     |
| Give a cost as a number                  | Network fee: $0.0003                                                   |
| Name a limit and where it applies        | A Testnet only tag on a feature                                        |
| Say plainly what an operation doesn't do | Payments are final. To return funds, send a new payment.               |

## Principles

### Be Clear

Name the action, the amount, and the recipient in plain words. Use the terms people already use for money, such as send, balance, and fee. Keep protocol terms for developer surfaces, where readers expect them.

* Put one idea in each sentence, and lead with the part that matters most.
* Prefer a familiar word to a technical one. The [Word List](/docs/foundations/content/word-list) names the preferred term for each concept.
* Define a necessary technical term in one sentence the first time it appears, as the docs do, then use it consistently.

**Do:** Describe a payment with the words people use for money, and format each value with `Amount` or
`Hex`.

**Don't:** Show protocol fields, base units, or gas parameters on a payment review.

### Be Precise

Money leaves no room for approximation. Show every amount with its unit, quote the network fee before someone confirms, and name each state exactly.

* Show the exact amount that moves on review screens and receipts. Round only in lists and summaries.
* Use Sent, Received, or Confirmed only after the network confirms the transaction. Until then, say Pending.
* Give concrete times and limits, such as Expires in 10 minutes, rather than soon or shortly.

### Be Calm

Moving money is stressful, so write steadily. State a risk once, where it applies, and say how to avoid it. Leave out exclamation marks, capitals for emphasis, and interjections such as Oops.

When something fails, say what happened and what to do next. Then stop.

### Be Respectful

Address the person using the product as you, and call their money your balance. Don't blame them for an error, and don't joke about money. Explain a step once, then keep the explanation out of the way for people who already know it.

### Inform, Don't Sell

The reader of a product screen has already chosen Tempo. Replace claims such as instant, effortless, or free with the fact they stand for, such as the fee amount or who pays it.

## Voice at a Glance

| Tempo sounds        | Tempo doesn't sound        |
| ------------------- | -------------------------- |
| Direct              | Curt or cold               |
| Precise             | Technical for its own sake |
| Calm                | Casual about risk          |
| Confident           | Promotional                |
| Helpful when needed | Chatty                     |

## Where the Sources Differ

The marketing site and the developer docs share these habits but not every choice. Product screens follow the docs where they differ.

| Topic                 | tempo.xyz                                                        | Developer docs                                                              | Product screens                              |
| --------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------- |
| Register              | Speed and scale claims, such as moving money at "internet speed" | Measured, specific claims, such as "sub-second finality"                    | State facts. Leave claims to marketing.      |
| Addressing the reader | You and your in calls to action                                  | Mostly bare imperatives, with the developer's customers in the third person | Address the person using the product as you. |

## Developer Surfaces

Products for developers, such as API key management or a performance dashboard, keep the same voice with a technical vocabulary. Use protocol terms such as TPS, gas, block, and RPC where readers expect them, and spell out anything specific to Tempo.

For example, a payment app says Network fee where a benchmark dashboard says gas/s.

## Related

* [Tone](/docs/foundations/content/tone) for adjusting the voice to success, errors, and warnings
* [Writing Style](/docs/foundations/content/writing-style) for labels, messages, and capitalization
* [Word List](/docs/foundations/content/word-list) for preferred terms
* [Payments](/docs/patterns/payments) for review and confirmation screens