Interface copy is the short text people act on, such as a button label or an error message. Each kind follows the same pattern on every screen, so the reader learns it once. Write it with Voice and tone and Language and grammar, which this page doesn't repeat.
A label is a verb that says what happens when the reader presses it. Add the thing it acts on when the verb alone could mean more than one thing. Keep it to two to four words.
| Write | Not |
|---|---|
| Save changes | Submit |
| Add ticket type | New |
| Publish event | OK |
| Delete event | Yes |
| Buy tickets | Proceed |
A button that takes money or can't be undone says so on the label.
Do
Put the amount on the button that takes the payment.
Don’t
Don't hide a payment behind a word that sounds like the next step.
A link, or a button with an href, says where it goes, so it makes sense read on its own.
Do
Name the page the reader lands on.
Don’t
Don't make the reader read around the link to learn where it goes.
An icon button has no visible words, so its aria-label carries them. Name the action, not the picture.
<IconButton aria-label='Remove ticket'>
Do
A screen reader says what the button does.
<IconButton aria-label='Bin'>
Don’t
Don't describe the icon. The reader hears what it looks like, not what it does.
A label is a short noun phrase, with no colon and no instruction.
showIndicator on Field.Label marks required and optional fields, so a
label never carries an asterisk.
| Write | Not |
|---|---|
| Enter your email address: | |
| Mobile number | Phone # |
| Ticket type name | Name * |
| Date of birth | DOB |
Use it for a format, a limit, or why we ask. Leave it out when the label says enough.
We text your tickets to this number.
Do
Say why we ask, or the format that works.
Enter your mobile number.
Don’t
Don't repeat the label.
A placeholder disappears as the reader types, so anything they need to remember goes in the label or the helper text.
Use lowercase letters and hyphens.
Do
Show a value the reader could type, and put the rule in the helper text.
Don’t
Don't put the instructions where they vanish on the first keystroke.
Write a checkbox or switch label as a positive statement of what the reader gets.
Do
Ticking the box turns the thing on.
Don’t
Don't make the reader untangle a negative to know which way to tick.
An error says what went wrong and how to fix it, next to the problem. Field.ErrorText holds an error in a value, and a Callout holds one about a page or a step. The error text guideline on Language and grammar sets its shape: a whole sentence with a full stop.
Start with what to do, because the reader can see which field it's on. When the value looks right but isn't, such as an expired code, say what's wrong first.
| Write | Not |
|---|---|
| Enter an email address. | Email is required. |
| Enter a mobile number like 0400 000 000. | Invalid phone number |
| Choose at least 1 ticket. | Quantity must be greater than 0 |
| Choose a date after today. | Date is in the past. |
Describe the problem and the fix, not the reader's mistake.
This code has expired. Ask the promoter for a new one.
Do
Say what's wrong with the code and where to get one that works.
You entered an expired code.
Don’t
Don't make the error about what the reader did.
When Oztix fails, say "we", say what's safe, and give the next step. Leave error codes for the support team.
Do
Take the blame, and tell the reader their work isn't lost.
Don’t
Don't show a code and a sentence that says nothing.
An EmptyState says why there's nothing here and what the reader can do about it.
A title names what's missing. A list that has never had anything, and one a filter or search has emptied, need different words.
| Write | Not |
|---|---|
| No events yet | Nothing to see here |
| No events match your filters | 0 results |
| No orders to refund | Empty |
Put the action that fills the space on a button, and say in the description what it does.
Add a ticket type to start selling.
Do
Point the reader at the one thing that fills the page.
There's nothing here.
Don’t
Don't leave the reader at a dead end.
When a filter or search hides everything, say so, and offer the way back.
Do
The reader knows the events still exist.
Don’t
Don't suggest the events are gone when a filter is hiding them.
A confirmation asks before something that costs money or can't be undone.
Dialog with role='alertdialog' holds it.
The title is a question with the action and the thing it acts on.
<Dialog.Title>Delete Ochre Kite Weekender?</Dialog.Title>
Do
The reader knows what's at stake before reading on.
<Dialog.Title>Are you sure?</Dialog.Title>
Don’t
Don't make the reader hunt through the body for what they're agreeing to.
The description says who it affects, and whether it can be undone, in a sentence or two.
<Dialog.Description>Fans who bought tickets get a refund. You can't undo this.</Dialog.Description>
Do
Name who it affects and say plainly that it's final.
<Dialog.Description>This action cannot be undone. Do you wish to proceed?</Dialog.Description>
Don’t
Don't warn without saying what's lost.
The confirming button uses the title's verb. When that verb is cancel, the other button says what staying put means.
Do
Each button says what it does, even when the action is to cancel.
Don’t
Don't use Cancel and OK when the action is to cancel something.
A Toast confirms something the reader just did, or reports how background work finished. The Toast page says when to use one.
The title names the thing and what happened to it, in the past tense. Leave out "successfully" and the exclamation mark.
| Write | Not |
|---|---|
| Event published | Success! |
| Link copied | Copied to clipboard successfully |
| 2 tickets sent | Your request has been processed |
| Ticket type deleted | Item removed |
A toast's one action is a verb, usually Undo or View.
toast.add({title: 'Ticket type deleted',timeout: 8000,actionProps: { children: 'Undo', onClick: undo }})
Do
The reader can reverse it in one press.
toast.add({title: 'Ticket type deleted',timeout: 8000,actionProps: { children: 'Click here', onClick: undo }})
Don’t
Don't make the reader guess what the button does.
A danger toast follows Errors. The title names what failed, and the description gives the fix.
toast.add({title: "We couldn't export your orders",description: 'Try again in a minute.',intent: 'danger'})
Do
Name what failed and the next step.
toast.add({title: 'Error',description: 'Something went wrong.',intent: 'danger'})
Don’t
Don't report a failure the reader can't act on.