At the end of last year, a group of us from Etch attended Converge 2024. One of my favourite talks was “Pattern-based text: Increase usability and reduce cost” by Torrey Podmajersky. You can check out some of the other talks we enjoyed in our round-up blog article from the conference.
Podmajersky’s talk showed how content patterns can be used within design systems to improve UX copy and make it more consistent and effective. These patterns can serve as mini templates, helping designers and developers create clear, user-friendly content.
Inspired by this approach, I read Podmajersky’s book, Strategic Writing for UX. Since we loved the template-based approach, I combined lessons from both her talk and book to develop a set of UX writing patterns for common components.
These patterns can be used directly within design system story examples to transform UX writing into a simple “fill-in-the-blank” process. While ensuring copy still uses usability best practices.
Titles
Brand Name Titles are used to set the context of the experience itself, for example most apps will have the app title in the top menu on the home page.
{Brand Name} ⇒ ’Etch’
Content Titles are used when the title is set based on the page content, e.g. for a blog article. These can be set by the page’s author or auto-generated based on the content.
{Name of content area or item} ⇒ ’About our team’
Task Titles are used for pages (or often modals) where an action can be completed by the user. The title should act as instruction for the task the user can complete on the page.
{Verb} [the] {Noun} ⇒ ’Create an Account’
Ambiguous Task Titles are used when there are multiple different actions that can be completed within a single page. Aim to encapsulate all of the pages options into a singular title, to reassure the user they are in the correct place.
{Verb} [the] {Noun} ⇒ ’Edit your Settings’
{Noun} ⇒ ’Settings’
Buttons
Buttons should be:
- Recognisable
- Specific
- Only one or two words long
- Use words people would actually say in conversation
- For icon only buttons: the aria text should follow the same rules and pattern
{Verb} [the {Noun}] / {Verb} ⇒ ’Add Payment Method’
Menu Buttons should be as short as possible, preferably one word.
Group of [Nouns or Verbs] ⇒ ‘Home’, ‘News’, ‘Contact’, ‘About’
Single Action Buttons are for pages (or often modals) where a single action can be completed by the user. The title and button should always work together, this consistency and specificity reduces confusion.
Title: {Verb} [the] {Noun} ⇒ ‘Create an Account’
Button: {Verb}{Noun} ⇒ ‘Create Account’
Descriptions
Descriptions should be less than 50 characters wide (3-6 words) and 3 lines long, for faster comprehension
They should avoid asterisks, as they can imply the main text isn’t fully honest, therefore breaking user trust.
To do X, {Verb} [the] {noun} ⇒ ‘To use your student discount, please sign in with valid student email address.’
{Verb}ing [the] {noun} helps you do X ⇒ ‘Adding you home through multi-cover helps you save money on your insurance.’
If X happens, you’ll see Y ⇒ ‘If your train is cancelled, you’ll get a notification before the specified departure time.’
Empty States
Empty states are often forgotten during content design, but are usually the first version of a page the user will see. Where possible aim to either solve the user's problem or teach them how to.
Solvable Empty States: Most of the time empty states are used before a user has completed a particular simple action. In these cases guide the user to complete said action.
Title: {Verb} [the] {noun} ⇒ ‘Upload a Photo’
Description: To do X, do Y ⇒ ‘To view your photos, first upload one.’
Button: {Verb} ⇒ ‘Upload’
Unsolvable Empty States: Sometimes a user isn’t able to do anything to solve an empty state; in these cases explain when the empty state will change and what it will change to.
Title: {Area name} or omit ⇒ ‘[username]’
Description: If X happens, you’ll see Y ⇒ ‘When [username] adds an image, you will be able to view it here.’
Controls
Controls, such as checkboxes, sliders and radio buttons, are normally made up of two pieces of text to consider: Name and State.
State text is often invisible, but will still be read by screen readers. Even when state text is not controlled directly by the developer, it is still important to consider whether it makes sense when paired with the control's name.
Name: {Noun} / {Verb} {noun} ⇒ ‘Save Route’
State: {Noun} ⇒ ‘Checked’ / ‘Unchecked’
Text Input Fields
Form fields can utilise: labels, hints, and pre-filled text.
The easiest way to get correct information from users is to pre-fill inputs, but this only works if you have the likely information already.
For labels and hints, there are several good options:
- Name of the information to be entered
- Example of the information to be entered
- Verb-first instruction about entering information
- Guidance for how the person can be successful
It is normally best to be consistent with the choice of these options. But clarity trumps consistency, so if breaking from the pattern will lead more users to successful then break the pattern.
{noun} / {Verb} [the] {noun} ⇒ ‘First Name’ / ‘Confirm Password’
Transitional and Confirmation Text
Never leave a user hanging in a loading state without explanation. For short loading states, loading animations might suffice but using transition text is a more universally accessible option.
Text is accessible to screen readers and reassures all users that they are waiting for the action they are expecting. The more specific loading text is, the more reassuring it can be to the user.
Most of the time it is obvious to a user when a transition state is complete because they receive the result of the action or are moved onto the next step. Sometimes, though, it can be reassuring to get a confirmation text.
Confirmation messages should use the past tense, to confirm the thing has happened.
Transition: {Verb}ing [the] {noun}[…] ⇒ ‘Saving your Document…’
Confirmation: {Verb}ed [the] {noun} / {Noun} {verb}ed ⇒ ‘Document Saved’
Notifications
Notifications are interruptions, so they should:
- Have value
- Be urgent (or at least time appropriate)
- Communicate there value at a glance
- Include the first action a person needs to take to realise that value
To do X, {Verb} the {noun} ⇒ ‘To buy your next pass, update your credit card’
{Verb}ing [the] {noun} helps you do X ⇒ ‘Update your credit card to keep using one tap booking’
Errors
Error messages require user empathy to focus on helping the user do what they want to do.
To maintain trust, avoid assigning blame to the user, even if they did something wrong, who will blaming them help?
Inline Errors: These advice a user to make a correction e.g. how to fix a phone number format. Always try to keep them as brief as possible. Inline errors rarely need to be ‘polite’, there is no need to add please or sorry
{Verb} [the] {Noun} ⇒ ‘Enter your first name’
Detour Errors: Sometimes when there is an error, you can’t keep the user within their current journey and must detour them to address the error. Normally in these cases more detailed instructions and context are required to unblock the user.
Title: {Verb} [the] {Noun} ⇒ ‘Enter the coupon code again’
Description: Because of {problem name}, do X. ⇒ ‘The code you entered doesn’t exist, check the code and try again.’
Button: {Verb} [the {Noun}] ⇒ ‘Enter Code’
Blocking Errors: When moving forward isn’t possible, make that clear to the user.
Title: {Problem name} ⇒ ‘Unable to connect to the server’
Description: Because of {problem name}, you can’t X [until Y happens]. ⇒ ‘There is an issue connecting to our server. You are currently unable to view [username]'s profile.’
Further Reading
If you're interested in learning more about this approach, I highly recommend reading Strategic Writing for UX by Torrey Podmajersky. It’s a great resource for understanding how to craft effective UX copy at scale.