# Writing Style Rules for capitalization, labels, and messages in Tempo product interfaces. ## Overview These rules cover every string in a product screen: headings, labels, buttons, messages, and empty states. [Grammar and Mechanics](/docs/foundations/content/grammar-and-mechanics) covers numbers, amounts, dates, addresses, and punctuation. The rules follow how [tempo.xyz](https://tempo.xyz) and the [developer docs](https://tempo.xyz/developers) already write. Where those sources disagree, the table at the end of this page says which choice product screens make. ## Use Sentence Case Capitalize only the first word and proper nouns in headings, labels, buttons, tabs, menu items, table headers, and toasts. Tempo's site headings and docs page headings already use sentence case, and it keeps product names and token symbols distinct from ordinary words. **Do:** Capitalize the first word of each heading, sentence, and label. **Don't:** Capitalize every word, in headings or anywhere else in the interface. * Capitalize product names, such as Tempo Wallet and Tempo Explorer, and named standards, such as TIP-20. * Write token symbols exactly as the token list spells them, such as pathUSD and USDC.e. Rewrite a sentence rather than start it with a lowercase symbol. * Don't use capitals for emphasis. Choose clearer words, or use `label.14.strong` sparingly. ## Write Labels ### Buttons Start with a verb and name the object, in one to three words: Send payment, Add funds, Create key, Copy address. The docs label their own steps the same way. The [Button](/docs/components/button#content) page covers button labels in detail. Give one action one label everywhere. The marketing site labels one contact action both Talk with our team and Talk to our team, which is the drift to avoid. ### Form Labels Name the value with a short noun phrase, such as Amount, Recipient, or Memo. Leave out colons and instructions such as Enter your. Put format hints in `Field.Description`, which stays visible while you type. * Use a placeholder only for an example value, such as 0.00. It disappears once you start typing. * Mark the minority case. When most fields are required, label the optional ones with Optional. ### Headings and Titles Name the page or the task, such as Activity, API keys, or Add funds. For a task, start with the verb, as the docs title their guides, such as Send a payment or Check the balance. Write confirmation dialog titles as a question, such as Revoke this key? Leave out end punctuation otherwise, and don't join two phrases with a colon. ### Links Name the destination, such as View transaction or Read the fee guide. A link should make sense on its own, since screen reader users often browse links as a list. Avoid Click here and a bare Learn more. Don't type an arrow (→) after link text, as some docs pages do. Use `Button.Link`, or a `Rows.Row` with `action="navigation"`, which draws its own chevron. ### Tooltips Keep a tooltip to a few words that name or clarify its trigger, such as Copy address. Never put actions or essential details in a tooltip. A definition, such as an info tooltip on a dashboard tile, can be one full sentence. Say what the thing is, as the docs open a concept page: The stablecoin that pays this transaction's network fee. ### Status Labels Use one or two words for a `Tag` or a status column, such as Pending, Confirmed, or Failed. Keep the same word for the same state everywhere in a product. ## Write Messages ### Structure Error Messages Most errors answer three questions in order: what happened, why, and what to do. Lead with the fix when the context already shows what happened, as it does beside a field. | Part | Example | | ------------- | ---------------------------------------------------------------- | | What happened | Payment didn't go through. | | Why | Your USDC balance is lower than the amount plus the network fee. | | What to do | Enter a smaller amount or add funds. | **Do:** Say how to fix the value, with the limit that applies. **Don't:** Show raw error names, codes, or RPC messages as the message. * Describe the problem, not the reader. Write This address isn't valid rather than You entered an invalid address. * Avoid Something went wrong on its own. If the cause is unknown, say what the reader can try, such as Try again in a few minutes. * When support needs a reference, add it after the message as secondary text, such as Reference 7f3a9c. ### Empty States Explain why the area is empty and what to do next, with one primary action that resolves it. For example, title the state No activity yet, explain that transactions appear once you send or receive, and offer Add funds. See [Empty States](/docs/patterns/empty-states). ### Confirmations Title a toast with the outcome in two to four words, such as Payment sent. Add a description only when it carries detail you need, such as the amount. A toast action is a shortcut, so make sure the same task is reachable elsewhere. ## Keep It Short * Put the most important word first. Network fee: $0.0003 scans faster than The fee for this payment will be $0.0003. * Cut filler such as please, simply, just, and successfully. Payment sent says as much as Your payment was sent successfully. * Use you and your for the reader, such as Your balance. Avoid my, which switches the point of view. * Use contractions such as can't, don't, and isn't. The sources mix contracted and full forms, so the table below records the choice. ## Write for Everyone * State the outcome in text. Color and icons in `Callout`, `Banner`, `Tag`, and `Toast` don't reach every reader. * Name an icon-only button by its action, such as Close dialog, with `aria-label`. * Avoid directions that depend on layout or input, such as the button on the right or click. Name the control instead. * Prefer common words to idioms, which translate poorly and confuse readers using a second language. ## Where the Sources Differ | Topic | What the sources do | Product screens | | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | | Heading case | Site and docs page headings use sentence case. The docs home uses Title Case for some section names, and one docs heading capitalizes Tokens in TIP-20 Tokens. The Tempo Performance dashboard mixes both. | Sentence case everywhere. | | Contractions | The docs use can't and cannot about equally, and does not more often than doesn't. Tempo Wallet errors use Cannot. | Use contractions. | | Repeated labels | The marketing site words the same contact button two ways. | One label per action. | | Sign in and out | The docs say sign in. Tempo Wallet pairs Sign in with Log out. | Sign in and Sign out. | | Link arrows | Some docs links end with →. | No typed arrows. Components draw their own chevrons. | | Colon titles | Some docs and site titles join two phrases with a colon, such as the faucet guide's title. | One phrase per title. | ## Related * [Grammar and Mechanics](/docs/foundations/content/grammar-and-mechanics) for numbers, amounts, and punctuation * [Word List](/docs/foundations/content/word-list) for preferred terms * [Button](/docs/components/button) for button labels * [Field](/docs/components/field) for labels, descriptions, and errors * [Errors and Validation](/docs/patterns/errors-and-validation) for when and where to show errors