# Tone How Tempo's voice adjusts for success, progress, warnings, errors, and actions that can't be undone. ## Overview The [Voice](/docs/foundations/content/voice) stays the same everywhere. Tone shifts with the reader's situation: a confirmed payment needs a short acknowledgement, and a failed one needs a cause and a next step. Match the tone to the stakes. The more money or access an action affects, the plainer and more specific the words should be. ## How Tempo Sets Tone Tempo's [developer docs](https://tempo.xyz/developers) handle high-stakes topics without raising their voice. Product screens follow the same habits: * **Outcomes are stated, not celebrated.** A guide says a payment completes or a receipt is available, and moves on. * **Protections read as guarantees.** Spending limits and fee sponsorship are described by what Tempo rejects and what a fee payer can't do. * **Finality is a plain fact.** The docs say a refund is a new transfer, not a reversal, and that a revoked key's past payments stay final. * **Limits come with their scope**, such as a feature that runs only on a devnet until a named network upgrade. | Situation | Paraphrased in product terms | | ---------- | ----------------------------------------------------------------------------- | | Success | Payment sent | | Protection | This key can spend up to 100.00 USDC a day. Payments above that are declined. | | Finality | Payments are final. To return funds, send a new payment. | | Limitation | Configurable accounts run on devnet only until the T14 network upgrade. | ## Tone by Situation | Situation | Tone | Example | Component | | ------------ | ----------------- | ------------------------------------ | ------------------------------------------------- | | Routine | Neutral, brief | Settings saved | `Toast` with `intent: 'neutral'` | | Success | Factual, brief | Payment sent | `Toast` with `intent: 'positive'` | | In progress | Specific | Confirming payment… | `Button` with `loading`, `Spinner` | | Warning | Calm, specific | Network fees are higher than usual. | `Callout` with `intent="warning"` | | Error | Direct, helpful | Enter an amount up to 1,250.00 USDC. | `Field.Error`, `Callout` with `intent="negative"` | | Irreversible | Serious, explicit | Revoke this API key? | `AlertDialog` with a `negative` `Button` | ## Success Say what finished in a few words, usually a noun and a past-tense verb: Payment sent, Key created, Webhook deleted. Add the amount or recipient when it confirms the right thing happened, such as 250.00 USDC sent to 0x3c44…93bc. * Use a `positive` `Toast` for a result that needs nothing more from the reader. * Leave out congratulations, exclamation marks, and emoji. A payment is an expected outcome, not an achievement. * Confirm only what the network has confirmed. Show a pending state until the transaction confirms. ## In Progress Name the step that is running, such as Confirming payment or Creating key, and end a status label with an ellipsis (…). Set `loading` on the button that started the action, so the label and the busy state stay in one place. When a step takes longer than a few seconds, say what the reader is waiting for and whether they need to stay on the page. ## Warnings A warning describes a risk before it happens. State the risk and how to avoid it once, beside the content it affects. Don't escalate a warning into an error to get attention. **Do:** State the risk and what to check in one or two plain sentences. **Don't:** Shout, stack exclamation marks, or use the `negative` intent for a warning. * Use a `warning` `Callout` for a risk tied to a field or section, and a `warning` `Banner` for a condition that affects the whole product, such as degraded network performance. * Put the severity in words. `intent` color alone doesn't reach every reader. * Show a warning only when the reader can act on it. A warning on every screen stops being read. ## Errors An error says something didn't work. Stay neutral, lead with the fix, and give the cause when it helps the reader choose what to do. [Writing Style](/docs/foundations/content/writing-style#structure-error-messages) sets out the structure. * Don't apologize at length, blame the reader, or make light of the failure. * Show errors that block a payment inline, with `Field.Error` or a `negative` `Callout`. A `Toast` dismisses itself before some readers can act on it. * Keep the reader's input. Say what to change rather than clearing the form. ## Irreversible Actions Sending a payment, revoking an API key, and deleting a webhook can't be undone. Use a serious, explicit tone that names exactly what happens, as the docs do when they describe finality. * Title the `AlertDialog` as a question with the verb and the object, such as Revoke this API key? * Describe the consequence in `AlertDialog.Description`, such as Apps that use this key stop working. * Repeat the verb on the confirm button, such as Revoke key, and label the other button Cancel. * For a payment, the review screen is the confirmation. Show the amount, recipient, and network fee, and say once that payments are final. See [Destructive Actions](/docs/patterns/destructive-actions) for the full flow. ## Where the Sources Differ | Topic | What the sources do | Product screens | | -------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------- | | Speed | tempo.xyz says stablecoins settle instantly. The developer docs give measured finality instead. | Say when a payment is confirmed. Don't promise instant. | | Generic errors | Tempo Wallet's fallback error message ends with an exclamation mark. Neither site uses one. | No exclamation marks, in errors or anywhere else. | ## Related * [Voice](/docs/foundations/content/voice) for the character behind every tone * [Writing Style](/docs/foundations/content/writing-style) for message structure * [Feedback and Status](/docs/patterns/feedback-and-status) for choosing a feedback component * [Errors and Validation](/docs/patterns/errors-and-validation) for form errors * [Destructive Actions](/docs/patterns/destructive-actions) for confirmations