Buttons and fields

Prev Next

This article provides specific naming conventions and best practices for naming buttons and fields in the user interface (UI). Adhering to these guidelines ensures consistency, clarity, and usability across all UI components.


General principles

1. Clarity and simplicity

  • Use straightforward language that users can understand without explanation.

  • Avoid technical jargon unless absolutely necessary.

2. Consistency

  • Use consistent terminology across the platform.

  • Maintain uniform capitalization, punctuation, and tense.

3. Action-oriented labels

  • Button names should clearly indicate the action they perform (e.g., “Save changes,” “Upload file”).

  • Field labels should specify what information the user should provide (e.g., “Email address,” “Article title”).

4. Brevity

  • Use concise language; avoid unnecessary words.

  • Limit button names and field labels to under 3 words wherever possible.

5. Accessibility

  • Ensure the names and labels of UI components are intuitive and inclusive, adhering to Web Content Accessibility Guidelines (WCAG).


Guidelines for buttons

1. Action-first phrasing

Use verbs that describe the action, followed by any necessary context.

Examples:

  • Recommended: “Save draft”, “Create category”

  • Not recommended: “Draft save”, “Category create”

2. Consistency in tense

Use present-tense verbs for immediate actions.

Examples:

  • Recommended: “Submit request”

  • Not recommended: “Submitted request”

3. Affirmative and direct

Avoid vague language like “OK” or “Done” unless it’s part of a multi-step process.

Example:

  • Step 1: Enter workspace details
    Button: Next (affirmative and direct)

  • Step 2: Configure permissions
    Button: Next (affirmative and direct)

  • Step 3: Review and confirm
    Button: Done (acceptable because it completes the final step)

4. Contextual labels

Include context where actions may be ambiguous.

Example:

  • Recommended: “Delete article”

  • Not recommended: “Delete”

5. Punctuation

Do not use ending punctuation for buttons.

Example:

  • Recommended: “Save changes”

  • Not recommended: “Save changes?”


Guidelines for fields

1. Descriptive labels

Field names should clearly describe the expected input.

Example:

  • Recommended: “Search term”

  • Not recommended: “Enter text”

2. Use sentence case

Capitalize the first letter of the first word.

Example:

  • Recommended: “Full name”

  • Not recommended: “full name”

3. Avoid abbreviations

Spell out words unless the abbreviation is universally understood.

Example:

  • Recommended: “Application Programming Interface (API)”

  • Not recommended: “API”

4. Placeholder text

Use placeholder text to provide input examples or instructions.

Example:

5. Mandatory fields

Add indicators (e.g., “*”) to mark required fields and include a tooltip or message explaining their necessity.

6. Avoid questions

Use labels instead of asking questions.

Example:

  • Recommended: “Email address”

  • Not recommended: “What is your email?”

7. Align with user expectations

Use industry-standard names where applicable.

Example:

  • Recommended: “Password”

  • Not recommended: “Account key”

8. Group related fields

Use section headings for better organization (e.g., “Article details,” “Category settings”).


Examples of buttons and field names

Element

Recommended

Not recommended

Submit button

“Submit request”

“Submit”

Cancel button

“Cancel upload”

“Cancel”

Search field

“Search articles”

“Search”

Input field

“Email address”

“Enter email”

Placeholder text

“e.g., johndoe@document360.com

“Enter text”


Consistency checklist

Before naming a button or field, ask:

  1. Is the name clear and self-explanatory?

  2. Does it follow the verb + object pattern for actions?

  3. Is it aligned with the organization’s terminology?

  4. Does it adhere to accessibility standards?

  5. Is it consistent with other buttons and fields in the UI?