> ## Documentation Index
> Fetch the complete documentation index at: https://content-designer-ux-writing-skill-26.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# UX patterns

> Common UX text patterns for interface elements including buttons, error messages, success messages, empty states, and form fields.

UX text patterns provide tested, reusable structures for common interface elements. Following these patterns ensures consistency and helps users understand what to expect.

## Titles

**Purpose:** Orient users to where they are

**Format:** Noun phrases, sentence case

**Types:**

* Brand titles ("Settings", "Dashboard")
* Content titles ("Your library", "Recent orders")
* Category titles ("Account", "Privacy")
* Task titles ("Create new post", "Edit profile")

### Examples

<CodeGroup>
  ```text Good theme={null}
  Account settings
  Your library
  Create new post
  ```

  ```text Poor theme={null}
  SETTINGS
  Library Page
  Post Creation
  ```
</CodeGroup>

<Tip>
  Use sentence case for all titles: "Account settings" not "Account Settings"
</Tip>

## Buttons and links

**Purpose:** Enable users to take action

**Format:** Active imperative verbs, sentence case

**Pattern:** `[Verb] [object]`

### Examples

<CodeGroup>
  ```text Good theme={null}
  Save changes
  Delete account
  View details
  Download report
  ```

  ```text Poor theme={null}
  OK
  Submit
  Click here
  Click here for more information
  ```
</CodeGroup>

<Warning>
  Avoid generic labels like "OK", "Submit", or "Click here". They lack context and don't work well with screen readers.
</Warning>

### Button length targets

* **Ideal:** 2-4 words
* **Maximum:** 6 words
* **Character count:** 15-25 characters

## Error messages

**Purpose:** Explain problem and provide solution

**Format:** Empathetic, clear, actionable

**Pattern:** `[What failed]. [Why/context]. [What to do].`

Error messages adapt based on type and severity:

<Accordion title="Validation errors (inline)">
  **When to use:** Show as user completes field or on blur

  **Pattern:** `[Field] [specific requirement]`

  **Examples:**

  * "Email must include @"
  * "Password must be at least 8 characters"
  * "Choose a date in the future"

  **Timing:** Real-time or on field exit

  **Location:** Below or beside the field
</Accordion>

<Accordion title="System errors (modal/banner)">
  **When to use:** When backend operations fail

  **Pattern:** `[Action failed]. [Likely cause]. [Recovery step].`

  **Examples:**

  * "Payment failed. Your card was declined. Try a different payment method."
  * "Couldn't save changes. Connection lost. Reconnect and try again."
  * "Upload failed. File is too large. Choose a file under 10MB."

  **Timing:** Immediately after failure

  **Location:** Modal dialog or prominent banner
</Accordion>

<Accordion title="Blocking errors (full-screen)">
  **When to use:** Prevent continued use until resolved

  **Pattern:** `[What's blocked]. [Why]. [Specific action needed].`

  **Examples:**

  * "Update required. This version is no longer supported. Update now to continue."
  * "Subscription expired. Your account is paused. Renew subscription to restore access."
  * "Verification needed. Confirm your email to access features. Check your inbox."

  **Timing:** On app launch or feature access

  **Location:** Full screen or large modal
</Accordion>

<Accordion title="Permission errors">
  **When to use:** When requesting device permissions

  **Pattern:** `[User benefit]. [Permission needed].`

  **Examples:**

  * "Get notified when orders ship. Enable notifications."
  * "Find nearby stores. Allow location access."
  * "Back up your photos. Grant storage permission."

  **Timing:** When feature is first used

  **Location:** In context of the feature
</Accordion>

### What to avoid in error messages

<Warning>
  Never use these in error messages:

  * Technical codes without explanation ("Error 403")
  * Blame language ("invalid input", "illegal character")
  * Robotic tone ("An error has occurred")
  * Dead ends (error with no recovery path)
  * Vague causes ("Something went wrong")
</Warning>

## Success messages

**Purpose:** Confirm action completion

**Format:** Past tense, specific, encouraging

**Pattern:** `[Action] [result/benefit]`

### Examples

<CodeGroup>
  ```text Good theme={null}
  Changes saved
  Email sent
  Profile updated
  Photo uploaded
  ```

  ```text Poor theme={null}
  Success!
  Done
  OK
  Complete
  ```
</CodeGroup>

<Tip>
  Use past tense to confirm the action is complete: "Changes saved" not "Saving changes"
</Tip>

### Length targets

* **Simple actions:** 2-3 words ("Changes saved")
* **Complex actions:** 4-6 words ("Profile updated. Your changes are live.")
* **Maximum:** 10-15 words total

## Empty states

**Purpose:** Guide users when content is absent

**Types:**

* First-use (never had content)
* User-cleared (user removed all content)
* Error/no results (search or filter returned nothing)

**Format:** Explanation + CTA to populate

### Examples

<CodeGroup>
  ```text First-use theme={null}
  No messages yet. Start a conversation to connect with your team.
  ```

  ```text User-cleared theme={null}
  Your inbox is empty. All caught up!
  ```

  ```text No results theme={null}
  No results for "coffee shops". Try a different search term.
  ```
</CodeGroup>

<Note>
  Empty states should always include a clear next action. Don't leave users stuck.
</Note>

### Structure

1. **Headline:** Explain why it's empty (3-6 words)
2. **Description:** Provide context (8-12 words)
3. **CTA:** Clear action to populate (2-4 words)

## Form fields

Form fields need multiple text elements working together:

<Accordion title="Labels">
  **Purpose:** Describe what input is needed

  **Format:** Clear noun phrases

  **Examples:**

  * "Email address"
  * "Phone number"
  * "Date of birth"

  **Best practices:**

  * Always visible (not hidden as placeholder)
  * Sentence case
  * No punctuation at end
</Accordion>

<Accordion title="Instructions">
  **Purpose:** Explain why information is needed or how to format it

  **Format:** Verb-first, clear purpose

  **Examples:**

  * "We'll use this to contact you about your order"
  * "Choose a password with at least 8 characters"
  * "Enter your code in the format: XXX-XXX-XXX"

  **Display:**

  * Static (always visible) for important requirements
  * On-demand (tooltip/help icon) for optional context
</Accordion>

<Accordion title="Placeholder text">
  **Purpose:** Show format example for standard inputs

  **Format:** Example, not instruction

  **Examples:**

  * "[name@example.com](mailto:name@example.com)"
  * "555-123-4567"
  * "MM/DD/YYYY"

  **Best practices:**

  * Use sparingly
  * Never replace labels
  * Only for standard, recognizable formats
</Accordion>

<Accordion title="Helper text">
  **Purpose:** Provide additional guidance or constraints

  **Format:** Brief, specific

  **Examples:**

  * "Maximum 160 characters"
  * "Only letters and numbers allowed"
  * "This will be visible to other users"

  **Timing:**

  * Static for important information
  * Dynamic (on focus) for helpful hints
</Accordion>

## Notifications

**Purpose:** Deliver timely, valuable information

**Types:**

* Action-required (intrusive, demands attention)
* Passive (less intrusive, informational)

**Format:** Verb-first title + contextual description

### Examples

<CodeGroup>
  ```text Action-required theme={null}
  Title: Update required
  Body: Install the latest version to continue.
  ```

  ```text Passive theme={null}
  Title: Message received
  Body: Jane sent you a message.
  ```
</CodeGroup>

### Structure

1. **Title:** Action or event (3-6 words)
2. **Body:** Context and details (8-12 words)
3. **CTA:** Optional action button (2-4 words)

### Length targets

* **Title:** 35-45 characters
* **Body:** 10-15 words
* **Total:** 15-20 words maximum

<Warning>
  Don't overuse action-required notifications. Too many interruptions train users to ignore all notifications.
</Warning>