Standards for all UI labels, helping teams create cohesive experiences within the Clear 3.0 design system.

voice-tone-language-label-guidelines.md

ClearCompany Label Standardization Guidelines

Overview

These guidelines establish standards for all UI labels within ClearCompany's Clear 3.0 design system. Consistent labeling builds user trust, reduces cognitive load, and improves overall usability.

Accessibility & Inclusion

Standardized labels are fundamental to creating accessible, inclusive software for all users. These guidelines support:

• Users with cognitive disabilities who benefit from consistent, predictable patterns and clear, plain language
• People with attention or memory challenges who rely on recognizable terminology and logical grouping
• Neurodivergent users who process information differently and benefit from explicit, unambiguous labels
• Users with visual impairments who use screen readers and other assistive technologies
• People with intersectional disabilities who face multiple barriers to access

By following these standards, we create products that are not just usable, but truly accessible to the diverse workforce using our HCM platform. Making these thoughtful content decisions benefits everyone—creating interfaces that are more intuitive, reducing cognitive load, and making workplace tasks more efficient for all users regardless of ability.

How to Use This Guide

This document serves as the definitive resource for all text elements in ClearCompany's user interface. Here's how to use it effectively:

When to Reference These Guidelines

• During new feature design: Consult relevant sections before creating wireframes or mockups
• During UI reviews: Use as a checklist to evaluate designs before implementation
• When writing product copy: Ensure terminology aligns with our standards
• During implementation: Developers should reference for correct labeling patterns
• During QA: Test that UI elements follow these guidelines

How to Resolve Conflicts

When guidelines seem to contradict each other:

1. Prioritize accessibility over style preferences
2. Consider user context (e.g., HR professionals vs. employees)
3. Consult the design systems team when unclear
4. Document exceptions with rationale

Quick Decision Framework

When facing a new labeling decision not covered in these guidelines:

1. Is there a similar pattern elsewhere in the product? → Follow that pattern
2. Does one option clearly benefit accessibility? → Choose that option
3. Is one option more concise without losing clarity? → Choose that option
4. Document your decision and consider updating these guidelines

Table of Contents

1. Plain Language Guidelines
2. Text Foundations
   • Capitalization
   • Punctuation
   • Truncation
   • Examples & Lists
   • Standardized Terminology
   • Typography
   • Contrast Guidelines
3. UI Element Guidelines
   • Form Labels
   • Form State Indicators
   • Button Labels
   • Two-Action Buttons
   • Navigation Labels
   • Table Headers
   • Error Messages
4. Action Verb Standards
   • Primary Actions
   • Navigation & Discovery
   • Search vs. Find
   • System Configuration
   • HR-Specific Actions
   • Integration & Data Sync
5. Visual Design Considerations
   • Text Alignment
   • Button Placement
   • RTL Support
   • Spacing & Placement
   • Internationalization
6. Implementation & Governance
   • Adding New Labels
   • Reviewing Existing Labels
   • Label Pairs & Relationships
   • Contribution Guidelines
   • Decision Trees
7. Appendices
   • Quick Reference Guide
   • Glossary of Terms
   • Visual Examples

---

1. Plain Language Guidelines

Core Plain Language Principles

Plain language makes content accessible to all users, including those with cognitive disabilities and non-native speakers. Follow these principles:

1. Use everyday words

   • Replace complex HR jargon with simpler alternatives
   • "End" instead of "Terminate"
   • "Start date" instead of "Commencement date"
   • "Pay" instead of "Compensation"
   • Provide a glossary for necessary technical terms

2. Write concise sentences

   • Aim for 15-20 words maximum per sentence
   • One main idea per sentence
   • Break complex processes into steps
   • Cut unnecessary words ("in order to" → "to")

3. Use active voice

   • "Submit your timesheet by Friday" not "Timesheets should be submitted by Friday"
   • "The manager approves requests" not "Requests are approved by the manager"
   • "You need to complete this form" not "This form needs to be completed"

4. Address the user directly

   • Use "you" and "your" to engage users
   • "Download your tax forms" not "Tax forms can be downloaded"
   • "Choose your benefits" not "The employee should choose benefits"

HR-Specific Plain Language Applications

Context	Instead of	Use
Benefits descriptions	"This PPO plan features a $500 deductible with 80% coinsurance after deductible is met."	"With this plan, you pay the first $500 of medical costs. After that, you pay 20% and the plan pays 80%."
Policy statements	"Violation of the attendance policy may result in disciplinary action up to and including termination."	"If you don't follow the attendance policy, you may receive warnings or eventually lose your job."
Performance feedback	"Demonstrates exceptional interpersonal communication capacities within cross-functional teams."	"Clearly explains technical concepts to team members from different departments."
Time & absence	"PTO accrual is prorated based on FTE status with bi-weekly accrual allocation."	"You earn time off with each paycheck. Part-time employees earn time off at a reduced rate."

Readability Guidelines

• Target a 6th-8th grade reading level

  • Aiming for an 8th-grade reading level or lower ensures that our content is accessible to the widest possible audience, including users with cognitive disabilities and non-native speakers.
  • Use readability formulas to check (Flesch-Kincaid, SMOG)
  • Test content with representative users
  • Apply the "reading aloud" test

• Format for scannability

  • Break content into chunks with descriptive headings
  • Use bulleted lists for multiple items
  • Bold key information sparingly
  • Maintain adequate white space

Word Substitution List

Instead of	Use
Commence	Start or Begin
Utilize	Use
Terminate	End
Modification	Change
Remuneration	Payment
Implement	Put in place
Facilitate	Help
Personnel	People, employees
Inquire	Ask
Sufficient	Enough
Prior to	Before
Subsequent to	After
Regarding	About
Demonstrate	Show
Expedite	Speed up

Plain Language Checklist

Before finalizing any UI text, check that it:

• Uses "you" and "we" (not "the user" or "the system")
• Avoids unnecessary jargon and technical terms
• Keeps sentences under 20 words
• Uses active voice
• Groups related information together
• Puts important information first
• Uses simple, everyday words
• Achieves 8th-grade reading level or lower
• Uses consistent terminology
• Includes clear next steps

UX Rationale

Plain language benefits all users by:

• Reducing cognitive load
• Increasing task completion rates
• Decreasing support requests
• Improving accessibility for users with cognitive disabilities
• Supporting non-native speakers
• Building trust through clarity

2. Text Foundations

2.1 Capitalization

Global Capitalization Rules

ClearCompany uses sentence case for all UI elements unless specifically exempted:

• Capitalize only the first word in the label
• Capitalize proper nouns
• Capitalize acronyms

UI Element	Correct (✓)	Incorrect (✗)
Page titles	People directory	People Directory
Section headers	Time off requests	Time Off Requests
Button labels	Add team member	Add Team Member
Form labels	Work email	Work Email
Menu items	Performance reviews	Performance Reviews
Tab labels	Job details	Job Details
Table headers	Hire date	Hire Date

Exceptions to Sentence Case

The following elements do NOT follow sentence case rules:

1. Product name: Always "ClearCompany" (never "Clearcompany")
2. Feature names: Branded features maintain their official capitalization
   • "TalentWall™" (not "Talentwall")
   • "ClearText™" (not "Cleartext")
3. Proper nouns: Always capitalize
   • "Export to Excel" (not "Export to excel")
   • "Google Calendar integration" (not "Google calendar integration")
4. Acronyms: Always use all caps with no periods
   • "PTO requests" (not "Pto requests" or "P.T.O. requests")
   • "ATS settings" (not "Ats settings")

2.2 Punctuation

Periods

• Do not use periods at the end of labels, headings, or button text
• Use periods at the end of complete sentences in helper text, error messages, and descriptions

Colons

• Do not use colons after form labels
• Use colons in section headers when introducing a list or related items

Question Marks

• Use question marks only for actual questions
• Avoid turning non-question labels into questions

Exclamation Marks

• Use exclamation marks sparingly and only for positive messages
• Appropriate: "You received a shout out!"
• Inappropriate: "Job failed to save!"
• Never use multiple exclamation marks

Context	Correct (✓)	Incorrect (✗)
Form label	Phone number	Phone number:
Button	Save changes	Save changes.
Section header	Team members	Team members:
Dialog title	Delete this record	Delete this record?
Actual question	Remember this device?	Remember this device
Celebration	Congratulations!	Congratulations
Error message	Unable to save changes	Unable to save changes!

2.3 Truncation

WCAG Compliance & Accessibility

• Primary rule: Avoid truncation whenever possible

  • Truncation can create accessibility issues for screen readers
  • Hidden content may contain important information users need
  • WCAG guidelines recommend providing access to complete text

• If truncation is necessary:

  • Ensure complete text is available through an accessible method
  • Provide tooltips, expandable elements, or "more" buttons
  • Make sure truncation pattern is visually obvious
  • Ensure screen readers can access the full text content

Truncation Indicators

When truncation cannot be avoided:

• Use an ellipsis (...) to indicate truncated text
• Place the ellipsis at the end of truncated text (no space before)
• Do not use other indicators like ">" or "-"

Element-Specific Guidelines

UI Element	Primary Approach	Alternative for Space Constraints
Button labels	Do not truncate	Use shorter text instead
Form labels	Do not truncate	Use shorter text instead
Navigation items	Do not truncate	Use icons or abbreviate thoughtfully
Page titles	Do not truncate	Rewrite to be more concise
Table headers	Do not truncate	Use abbreviations with tooltips
Table cells	Wrap text by default	If needed: truncate with tooltip showing full text
Card titles	Wrap text by default	If needed: truncate with tooltip showing full text
Tooltips	Do not truncate	Split into multiple lines
Dropdown items	Do not truncate	Adjust width or use wrapping

When Truncation Is Unavoidable

If space constraints make truncation necessary:

1. Preserve the beginning

   • Truncate from the end to preserve the most important information
   • Example: "Annual Performance Review for..." (not "...Review for Marketing")

2. Account for responsive layouts

   • Set appropriate truncation points for different screen sizes
   • Consider alternative layouts before resorting to truncation

3. Provide access to full text

   • Always provide a way to view the full text (tooltip, expanding element, etc.)
   • Ensure tooltip or expanded text is keyboard accessible
   • Truncated items should have a tooltip showing the full text on hover

4. Respect word boundaries

   • Truncate at word boundaries when possible
   • Example: "Marketing Operations..." (not "Marketing Opera...")

2.4 Examples & Lists

Using "e.g." vs. "Example:" vs. "For example:"

Use This	When to Use	Example
"For example:"	In regular text paragraphs or at beginning of sentences	"For example: Add team members from the People page."
"Example:"	Before a standalone example, especially in instructions	"Example: team@clearcompany.com"
"e.g."	In parentheses or in space-constrained UI elements	"Select a file type (e.g., PDF, DOCX)"

List Endings and "etc."

1. Avoid using "etc."

   • Be specific about what you're listing
   • If more items exist, say "and more" or "and others"
   • For dynamic content, use "[number]+ more" format

2. Complete lists do not need special endings

   • For comprehensive lists, do not add "etc." or similar phrases
   • Example: "Acceptable file types: PDF, DOCX, XLSX"

3. Partial lists should indicate continuation

   • For non-comprehensive lists, indicate there are more items
   • Use "such as" at the beginning rather than "etc." at the end
   • Example: "You can import data from various systems such as ADP, Workday, and BambooHR"

List Formatting

1. For short lists (2-3 items)

   • Use commas between items
   • Use "and" before the final item
   • Example: "Includes phone, email, and address"

2. For longer lists (4+ items)

   • Use bullet points for better readability
   • No punctuation at end of list items unless they are complete sentences
   • Capitalize the first word of each bullet point

3. For procedural steps

   • Use numbered lists
   • Each step should begin with an action verb
   • End each step with a period

2.5 Standardized Terminology

Technology Terms

Use This	Not These	Notes
Email	E-mail, e-mail, EMail	No hyphen, lowercase 'e'
Text message	SMS, txt, text msg	Use "Text message" in UI, "Text" for buttons
Website	Web site, web-site, site	One word, lowercase 'w'
Login (noun), Log in (verb)	Log-in, SignIn	"Use your login" vs. "Log in to your account"
Username	User name, user-name	One word
Password	Pass word, pass-code	One word
Homepage	Home page, Home-page	One word
Internet	internet, web	Capitalize 'I'
Wi-Fi	WiFi, Wifi, wifi	Hyphenated with capital 'W' and 'F'
URL	Url, url, web address	All caps
PDF	Pdf, .pdf, pdf file	All caps
CSV	Csv, .csv, csv file	All caps
XLSX	Xlsx, .xlsx, Excel file	All caps for file extension

Communication Terms

Context	In UI	In Buttons	In Instructions
Email communication	"Email"	"Send email"	"We'll email you"
Text messaging	"Text message"	"Send text"	"We'll text you"
In-app notifications	"Notification"	"View notifications"	"You'll be notified"
System alerts	"Alert"	"View alerts"	"You'll receive an alert"

2.6 Typography

Font weights

• Form labels: Regular weight
• Button labels: Medium weight
• Page titles: Semibold weight
• Error messages: Regular weight

2.7 Contrast Guidelines

WCAG Compliance for Text Labels

To meet accessibility standards, all text labels must meet the following contrast requirements:

• WCAG AA compliance (minimum requirement):

  • Normal text (under 18pt): 4.5:1 contrast ratio
  • Large text (18pt or 14pt bold and larger): 3:1 contrast ratio

• WCAG AAA compliance (preferred when possible):

  • Normal text (under 18pt): 7:1 contrast ratio
  • Large text (18pt or 14pt bold and larger): 4.5:1 contrast ratio

Label Contrast by Context

UI Element	Minimum Contrast	Rationale
Form labels	4.5:1	Critical for form completion
Button text	4.5:1	Essential for interaction
Navigation labels	4.5:1	Core wayfinding elements
Helper text	4.5:1	Provides necessary context
Placeholder text	4.5:1	Should not be low contrast
Error messages	4.5:1 (not just relying on color)	Must be perceivable to all users

Disabled State Guidelines

• Disabled controls: Maintain 3:1 minimum contrast ratio
• Disabled text: Should be visibly different but still readable
• Do not use color alone: Use other visual indicators (e.g., strikethrough, opacity)

Contrast Testing

• Use tools like Contrast Checker, Stark, or WebAIM to verify ratios
• Test in both light and dark modes if applicable
• Consider users with low vision or color vision deficiencies
• Test in various lighting conditions on mobile devices

UX Rationale

High contrast between labels and backgrounds ensures:

• Better readability for all users
• Accessibility for those with visual impairments
• Usability in varying lighting conditions
• Clearer hierarchy of information

3. UI Element Guidelines

3.1 Form Labels

Input Field Labels

1. Use nouns or noun phrases

   • "Job title" (not "Enter job title")
   • "Start date" (not "When does the job start?")

2. Be consistent with possessives

   • Either use: "Employee's manager"
   • Or: "Employee manager"
   • Don't mix approaches

3. Avoid articles

   • "Phone number" (not "The phone number")
   • "Home address" (not "Your home address")

4. Group related fields with subheadings

   • "Contact information" section with "Email", "Phone", etc.
   • "Work details" section with "Department", "Title", etc.

Form Field Examples

Field Type	Good Label Example	Bad Label Example
Text input	"First name"	"Enter your first name here"
Email input	"Work email"	"What is your work email address?"
Phone input	"Mobile phone"	"Cell phone number"
Select menu	"Department"	"Select a department"
Date picker	"Start date"	"When will they start?"
Checkbox	"Send welcome email"	"Would you like to send a welcome email?"
Radio buttons	"Employment type"	"Please select employment type"
Text area	"Additional notes"	"Enter any additional notes here"

3.2 Form State Indicators

Reset/Clear Button Guidelines

• Label options:

  • Use "Reset" for returning a form to its initial state
  • Use "Clear" for emptying all form fields
  • Use "Reset to defaults" for restoring system default values

• Visibility rules:

  • Show "Reset" button only when form values have been changed
  • Hide or disable "Reset" when form is in its initial/default state
  • Position "Reset" at the end of the button sequence (farthest from primary action)

• Visual treatment:

  • Use lower visual prominence than primary/secondary actions
  • Consider using text-only button styling without background
  • Use neutral color treatment (not error/destructive colors)
  • Add confirmation for destructive reset actions on complex forms

Form Change Indicators

• Field-level indicators:

  • Highlight changed fields with subtle visual indicator
  • Example: Light yellow background or left border indicator
  • Include visual return-to-default action when appropriate

• Form-level indicators:

  • Show "You have unsaved changes" message when form state changes
  • Position message near form actions or as a persistent notification
  • Trigger confirmation dialog when navigating away with unsaved changes

• Section-level indicators (for multi-section forms):

  • Indicate which sections contain changes in navigation/overview
  • Example: Add dot indicator to section tabs with modifications

Autosave Indicators

• For forms with autosave:
  • Show "Saving..." status during save operations
  • Confirm "Changes saved" after successful save
  • Indicate "Unable to save" when autosave fails
  • Always provide manual "Save" option as fallback

Examples

Context	Button Set Example (LTR)	Note
New form	"Create" → "Cancel"	No reset needed for new forms
Edit form (unchanged)	"Save" → "Cancel"	Reset hidden as no changes made
Edit form (changed)	"Save" → "Cancel" → "Reset"	Reset appears when changes detected
Multi-action form	"Save" → "Save and continue" → "Cancel" → "Reset"	Complete button order example
Destructive action	"Delete" → "Cancel"	Destructive action as primary when it's the form's purpose

3.3 Button Labels

Primary Action Buttons

1. Use verb + noun format

   • "Schedule interview" (not just "Schedule")
   • "Add team member" (not just "Add")
   • "Create job" (not just "Create")

2. Keep labels concise

   • Aim for 1-3 words
   • Maximum 4 words for complex actions

3. Be specific about the action

   • "Save changes" (not just "Save")
   • "Submit request" (not just "Submit")

Confirmation Buttons

1. Make the consequence clear

   • "Yes, delete account" (not just "Yes" or "Delete")
   • "No, keep editing" (not just "No" or "Cancel")

2. Use standard pairs consistently

   • "Save" / "Cancel"
   • "Submit" / "Back"
   • "Approve" / "Decline"
   • "Yes" / "No" (only for true yes/no questions)

3. Position consistently

   • Primary action on right (or bottom on mobile)
   • Secondary/cancel action on left (or top on mobile)

Button Examples by Context

Context	Primary Button	Secondary Button
Form editing	"Save changes"	"Cancel"
Multi-step process	"Continue" or "Next"	"Back"
Final step submission	"Submit"	"Save as draft"
Destructive action	"Delete permanently"	"Cancel"
Approval workflow	"Approve"	"Decline"
Adding items	"Add [item]"	"Cancel"
Creating new objects	"Create [object]"	"Cancel"

3.4 Two-Action Buttons

When to Use Two-Action Buttons

Two-action buttons combine related actions into a single button when:

• The actions naturally occur together
• Users commonly want to perform both actions in sequence
• Screen space is limited

Two-Action Button Patterns

1. Use "and" to join actions

   • "Save and continue" (not "Save & continue" or "Save, continue")
   • "Approve and notify" (not "Approve & notify")

2. Follow verb + conjunction + verb format

   • "Save and close" (not "Save and closing")
   • "Add and create another" (not "Add and creating another")

3. Place the primary action first

   • "Save and continue" (primary action is saving)
   • "Submit and clear form" (primary action is submitting)

4. Keep it concise

   • Maximum 4 words total
   • Consider using a single action button with secondary follow-up when text would be too long

Common Two-Action Button Examples

Context	Recommended Button Label	Alternative Approach
Form completion	"Save and continue"	Two separate buttons: "Save" and "Continue"
Multiple additions	"Add and create another"	Add checkbox: "Create another after adding"
Review approval	"Approve and notify"	Two-step process with confirmation screen
Document handling	"Sign and send"	Linear workflow with separate steps
Form reset	"Submit and clear"	Two separate buttons: "Submit" and "Clear form"

Two-Action Button Layout

• Use standard button styling
• Do not separate the actions visually
• Consider using a split button for distinct but related actions (primary action on main button, secondary on dropdown)

3.5 Navigation Labels

Main Navigation

1. Use clear, concise nouns

   • "People" (not "People Management")
   • "Jobs" (not "Job Requisitions")
   • "Time off" (not "Leave Management")

2. Avoid action verbs in navigation

   • "Reports" (not "View Reports")
   • "Settings" (not "Configure Settings")

3. Be consistent with categorization

   • Group similar items together
   • Use subnavigation for related features

Standard Navigation Labels

Category	Recommended Label	Avoid These
People management	"People"	"Employees", "Personnel", "Staff"
Recruitment	"Recruiting"	"Talent Acquisition", "Hiring"
Job management	"Jobs"	"Positions", "Requisitions"
Performance	"Performance"	"Reviews", "Evaluations"
Time off tracking	"Time off"	"Leave", "PTO", "Vacation"
Reporting	"Reports"	"Analytics", "Insights", "Metrics"
User preferences	"Settings"	"Preferences", "Options", "Configuration"
Main view	"Dashboard"	"Home", "Overview", "Summary"

3.6 Table Headers

Table Column Headers

1. Keep headers concise

   • One or two words when possible
   • Use nouns or short noun phrases

2. Be consistent with related tables

   • Use the same terminology across similar tables
   • Maintain consistent order where appropriate

3. Avoid abbreviations unless space-constrained

   • "Department" (not "Dept.")
   • Exception: Common abbreviations like "ID" are acceptable

Standard Table Headers

Context	Recommended Headers	Notes
People tables	"Name", "Job title", "Department", "Location", "Status"	Use consistent order
Job tables	"Job title", "Department", "Location", "Status", "Open date"	Match people table pattern
Candidate tables	"Name", "Job applied for", "Status", "Application date"	Keep hiring focus
Time off tables	"Person", "Type", "Dates", "Duration", "Status"	Focus on key information
Task tables	"Task", "Assigned to", "Due date", "Priority", "Status"	Action-oriented

3.7 Error Messages

Error Message Patterns

1. Be specific about the problem

   • "Enter a valid email address" (not just "Invalid input")
   • "Password must be at least 8 characters" (not "Password too short")

2. Suggest how to fix it

   • "Enter a date in MM/DD/YYYY format"
   • "Choose a start date that's before the end date"

3. Use a consistent tone

   • Helpful without blame
   • Clear without being technical

Standard Error Messages

Context	Recommended Message	Avoid
Required field	"This field is required"	"You must enter this field"
Invalid email	"Enter a valid email address"	"Email validation failed"
Password requirements	"Password must include at least 8 characters, one uppercase letter, and one number"	"Password does not meet complexity requirements"
Invalid date	"Enter a valid date in MM/DD/YYYY format"	"Date validation error"
Future date required	"Enter a date in the future"	"Past dates are invalid"
Numeric field	"Enter numbers only"	"Non-numeric characters detected"
File upload size	"File exceeds the 5MB limit"	"File size validation failed"
Server error	"Something went wrong. Try again or contact support."	"Server error 500 occurred"

4. Action Verb Standards

4.1 Primary Actions

Use This	Not These	Context	Example
Add	Insert, Create, New	Adding a single item to a list or collection	"Add team member"
Create	Generate, Build, Make	Creating a complex object from scratch	"Create job posting"
Edit	Modify, Change, Alter	Standard action for making changes	"Edit profile"
Update	Refresh, Revise	Making changes to existing data, especially scheduled ones	"Update tax information"
Remove	Take away, Exclude	Reversible actions	"Remove from team"
Delete	Erase, Eliminate	Permanent deletion actions	"Delete record"
View	See, Show, Display	Examining content without editing	"View report"
Save	Store, Preserve	Storing changes	"Save changes"
Submit	Send, Transmit	Formal processes and approvals	"Submit request"
Approve	Accept, Authorize	Authorization workflows	"Approve time off"
Decline	Reject, Deny	Negative response to requests	"Decline request"
Cancel	Abort, Quit	Stopping a process	"Cancel interview"

4.2 Navigation & Discovery

Use This	Not These	Context	Example
Search	Lookup, Query	Server-side queries of entire database	"Search people"
Find	Locate, Filter	Client-side filtering of already loaded data	"Find in this list"
Filter	Narrow, Refine	Refining current results using specific criteria	"Filter results"
Browse	Explore, Navigate	Category-based discovery	"Browse templates"
Sort	Order, Arrange	Changing display order	"Sort by name"
Open	Launch, Access	Opening documents or detailed views	"Open profile"
Download	Get, Retrieve	Getting files from the system	"Download report"
Upload	Attach, Add	Adding files to the system	"Upload document"
Import	Bring in, Transfer in	Bringing external data into the system	"Import candidates"
Export	Send out, Transfer out	Taking data out of the system	"Export to Excel"
Sync	Synchronize, Connect	Automatic data integration between systems	"Sync with ADP"

4.3 Search vs. Find

Technical Implementation Differences

Search:

• Makes calls to the server/database
• Queries the entire dataset on the backend
• Used for comprehensive data exploration
• Typically requires clicking a search button or pressing Enter
• May take time to return results
• Example: "Search all candidates in the system"

Find:

• Filters through already-downloaded data in the browser
• Operates on the client side only (no server calls)
• Provides immediate results as you type
• Limited to data already loaded on the page
• Example: "Find in this table" or "Find on page"

This technical distinction creates a meaningful difference that users can learn to recognize:

• Use "Search" when the action will query the full database
• Use "Find" when the action will filter data already visible or loaded

4.4 System Configuration

Use This	Not These	Context	Example
Set up	Install, Initialize	Initial configuration processes	"Set up account"
Configure	Customize, Adjust	Complex system adjustments	"Configure workflow"
Settings	Preferences, Options	User or system configuration areas	"Email settings"
Enable	Turn on, Activate	Turning features on	"Enable notifications"
Disable	Turn off, Deactivate	Turning features off	"Disable integration"
Connect	Link, Join	Connecting to external systems	"Connect to Slack"
Disconnect	Unlink, Detach	Removing connections	"Disconnect account"

4.5 HR-Specific Actions

Use This	Not These	Context	Example
Hire	Onboard, Bring on	Adding someone to the company	"Hire candidate"
Assign	Allocate, Designate	Giving responsibilities	"Assign reviewer"
Schedule	Book, Plan	Setting up time-based events	"Schedule interview"
Complete	Finish, Conclude	Marking a process as done	"Complete training"
Request	Ask for, Apply for	Asking for approval	"Request time off"
Review	Evaluate, Assess	Examining someone's work	"Review performance"

4.6 Integration & Data Sync

Data Integration Actions

Use This	Not These	Context
Sync	Synchronize, Push, Pull	Use for bidirectional automatic data exchange
Push to [system]	Send to, Upload to	Use for one-way data transfer to external system
Pull from [system]	Get from, Import from	Use for one-way data transfer from external system
Connect	Integrate, Link	Initial setup of integration
Disconnect	Unlink, Remove	Removing an integration

Integration Status Terms

Use This	Not These	Context
Connected	Integrated, Linked	System is successfully integrated
Disconnected	Unlinked, Removed	System is not integrated
Syncing	Synchronizing, In progress	Data sync is currently in progress
Sync failed	Error, Not synced	Data sync encountered an error
Last synced: [time]	Updated, Refreshed	When data was last successfully synced

Here's the continuation of the markdown code: markdown#### Integration Examples

Integration Type	Example Button Label	Example Status
HR System Integration	"Sync with ADP"	"Last synced: Today, 2:15 PM"
Calendar Integration	"Connect to Google Calendar"	"Connected"
Single Sign-On	"Set up Okta SSO"	"Active"
Job Board Integration	"Push to Indeed"	"10 jobs synced"

5. Visual Design Considerations

5.1 Text Alignment

Default alignment

• Left-align most text elements in LTR (left-to-right) languages
• Right-align most text elements in RTL (right-to-left) languages
• Follow the natural reading direction of the language

Element-specific alignment

UI Element	LTR Alignment	RTL Alignment	Notes
Page titles	Left	Right	Follow reading direction
Section headers	Left	Right	Follow reading direction
Form labels	Left	Right	Stack above fields
Form fields	Left internal alignment	Right internal alignment	Text inside input fields
Button labels	Center	Center	Centered regardless of language direction
Menu items	Left	Right	Follow reading direction
Table headers	Match column content	Match column content	For text: follow reading direction
Table data cells	• Text: Left • Numbers: Right • Dates: Left • Status: Left	• Text: Right • Numbers: Left • Dates: Right • Status: Right	Maintain consistent internal alignment for data types
Checkbox/radio labels	Right of control	Left of control	Label is on reading side of control
Tooltips	Left	Right	Follow reading direction
Error messages	Left	Right	Follow reading direction
Notifications	Left	Right	Follow reading direction

Special considerations

• Numbers and currencies:

  • LTR languages: Right-align numbers and currencies
  • RTL languages: Left-align numbers and currencies
  • Exception: Keep currency symbols in their conventional position relative to the amount

• Mixed content:

  • When mixing LTR and RTL content, use Unicode bidirectional algorithm
  • Set the primary direction based on the predominant language
  • Allow embedded content to follow its natural direction

Responsive alignment

• Maintain consistent alignment patterns across screen sizes
• Consider full-width buttons with centered text on mobile
• Stack elements vertically rather than changing alignment on small screens

5.2 Button Placement

Standard Form Button Alignment

• Primary alignment rule: Align buttons to the natural starting position

  • LTR languages: Left-align buttons
  • RTL languages: Right-align buttons

• Rationale for starting-side alignment:

  • Improves accessibility by maintaining consistent focus flow
  • Provides predictable tab order navigation
  • Reduces cognitive load by maintaining reading flow
  • Ensures buttons are immediately visible without scrolling
  • Supports screen reader and keyboard navigation patterns

Button Placement by Container Type

Container Type	Button Alignment	Notes
Standard forms	Left in LTR, Right in RTL	Follow form's reading direction
Modal dialogs	Left in LTR, Right in RTL	Group together at natural starting position
Side drawers	Left in LTR, Right in RTL	Position at bottom of drawer, aligned to start
Wizards/multi-step forms	Left in LTR, Right in RTL	Next/Back buttons grouped at start position
Full-page forms	Left in LTR, Right in RTL	Align with form fields, at start position
Inline forms	Left in LTR, Right in RTL	Keep adjacent to last field
Cards	Left in LTR, Right in RTL	Position at card bottom, aligned to start

Button Order

For groups of buttons, always maintain this sequence from primary action to secondary/tertiary:

• LTR: Primary action → Secondary action → Tertiary action → Destructive/Reset action

  • Example: "Save" → "Save and continue" → "Cancel" → "Reset form"

• RTL: Destructive/Reset action ← Tertiary action ← Secondary action ← Primary action

  • Example: "Reset form" ← "Cancel" ← "Save and continue" ← "Save"

The primary action should always be positioned closest to the content, while potentially destructive actions like "Reset" should be positioned farthest away to prevent accidental clicks.

Special Cases

• Confirmation dialogs: Primary action (default) always first in reading order, regardless of whether it's a positive or negative action
• Split buttons: Maintain alignment with standard buttons
• Icon-only buttons: When used in toolbars, center the toolbar itself, but left-align buttons within it in LTR (right-align in RTL)
• Responsive considerations: On very narrow screens, consider stacking buttons vertically with primary action on top

Discouraged Patterns

• Avoid right-aligned buttons in LTR interfaces (except in specific justified cases)
• Avoid centered button groups as they:
  • Create inconsistent tab order
  • Float away from related content
  • Make scanning more difficult
  • May create uneven whitespace
• Avoid splitting positive/negative actions to opposite sides of containers
• Avoid inconsistent button alignment across similar components

5.3 RTL Support

Mirroring principles

• Mirror all directional UI elements:

  • Navigation flows right-to-left
  • Icons that imply direction (arrows, etc.)
  • Progress indicators move right-to-left
  • Accordion and dropdown indicators point left

• Do NOT mirror:

  • Brand logos
  • Product names
  • Numbers
  • Third-party content that doesn't support RTL
  • Media controls (play button still points right)
  • Charts and graphs (maintain conventional orientation)

Icons and visual elements

• Use direction-neutral icons when possible
• Mirror directional icons (back/forward, previous/next)
• Position visual elements to support the reading flow
• Ensure icons with text maintain proper spacing in both directions

Testing RTL layouts

• Test with actual RTL language content, not just mirrored LTR
• Verify text doesn't overflow containers
• Check spacing and alignment of all elements
• Test interactive elements work properly in RTL context

5.4 Spacing & Placement

1. Form field labels

   • Position above the input field
   • Maintain 8px spacing between label and field

2. Button labels

   • Center text within buttons
   • Allow adequate padding (min 16px horizontal)

3. Table headers

   • Left-align headers that align with left-aligned content
   • Center or right-align headers above centered or right-aligned content

5.5 Internationalization

Beyond RTL Support

While RTL Support covers specific right-to-left language considerations, internationalization encompasses broader challenges:

Text Expansion & Contraction

• Design for text expansion: Allow 30-40% extra space for labels in languages that expand
  • German, Finnish, and Dutch typically require more space than English
  • Russian, Portuguese, and French can expand 15-30%
• Contraction considerations:
  • Japanese, Chinese, and Korean often require less space than English
  • Design should handle both extremes without breaking

Language-Specific UI Considerations

Language Characteristic	Design Consideration	Example
Compound words	Provide adequate width for very long single words	German: "Mitarbeiterzufriedenheitsumfrage" (employee satisfaction survey)
Word order variations	Use placeholder tokens instead of hardcoded strings	"{user} invited {recipient}" vs "{recipient} was invited by {user}"
Grammatical gender	Avoid gendered language when possible	Use "they" instead of "he/she"
Plural forms	Account for languages with multiple plural forms	English: "1 item" vs. "2 items" Polish: "1 pozycja", "2 pozycje", "5 pozycji"

Translatable vs. Non-Translatable Terms

Never translate:

• Product name "ClearCompany"
• Branded feature names
• Technical standards (API, HTML, etc.)

Always translate:

• Navigation items
• Button labels
• Error messages
• Helper text

Internationalization Testing

• Test with pseudo-localization
• Verify line breaks occur at appropriate points
• Check text doesn't overflow containers
• Ensure adequate spacing between characters
• Test with actual translations, not just pseudo-text

Format Considerations

Format Type	Internationalization Approach
Dates	Use locale-aware formatting, not hardcoded patterns
Times	Support both 12-hour and 24-hour formats
Numbers	Account for different decimal and thousands separators
Currency	Format according to locale with appropriate symbols
Phone numbers	Support international formats and country codes
Addresses	Accommodate different address formats by country

UX Rationale

Proper internationalization ensures:

• Users worldwide receive equally usable experiences
• Interface elements don't break across languages
• Information is presented in culturally appropriate ways
• Localization can happen efficiently without redesign

6. Implementation & Governance

6.1 Adding New Labels

1. Check the dictionary first

   • Review this guide to see if an appropriate term already exists
   • Use existing patterns whenever possible

2. Follow the patterns

   • Apply the same grammatical structures
   • Maintain consistent capitalization and punctuation

3. Submit for review

   • Have new labels reviewed by the design system team
   • Document all new terms

6.2 Reviewing Existing Labels

1. Regular audits

   • Scheduled reviews of UI labels across the platform
   • Prioritize high-traffic areas

2. Consistency checks

   • Compare similar features for terminology alignment
   • Check capitalization and punctuation standards

3. User feedback incorporation

   • Address user confusion about labels
   • Test alternative labels with users when needed

6.3 Label Pairs & Relationships

Action Pairs

Use consistent terminology for opposing actions:

Positive	Negative	Example Context
Add	Remove	Team members
Create	Delete	Jobs
Enable	Disable	Features
Show	Hide	Details
Approve	Decline	Requests
Connect	Disconnect	Integrations
Lock	Unlock	Accounts
Start	Stop	Processes

Status Terms

Use these consistent status terms across the platform:

Status	Meaning	Example Context
Active	Currently in use	"Active jobs"
Inactive	Not currently in use	"Inactive users"
Draft	Not yet published	"Draft job posting"
Published	Publicly visible	"Published reports"
Archived	Stored but not active	"Archived candidates"
Pending	Awaiting action	"Pending approval"
Approved	Received positive response	"Approved time off"
Declined	Received negative response	"Declined requests"
Completed	Finished process	"Completed tasks"
Overdue	Past deadline	"Overdue reviews"

Time Periods

Use these consistent time period terms:

Use This	Not These	Context
Today	Current day	Time references
Yesterday	Prior day	Time references
Tomorrow	Next day	Time references
This week	Current week	Time periods
Last week	Previous week	Time periods
Last 7 days	Past week	Reports and filters
Last 30 days	Past month	Reports and filters
Last quarter	Previous quarter	Financial periods
Year to date	YTD	Financial periods

6.4 Contribution Guidelines

How to Contribute to These Guidelines

The ClearCompany Label Standardization Guidelines are a living document that evolves with our product and industry best practices. Here's how to contribute:

Proposing Additions or Changes

1. Identify the need:

   • Inconsistent patterns in the product
   • Missing guidance for a common scenario
   • Accessibility improvements
   • User feedback indicating confusion

2. Research your proposal:

   • Check if existing guidelines already address the issue
   • Research accessibility implications
   • Consider internationalization impact
   • Gather real-world examples

3. Submit a proposal using the template:

   • Problem: What issue does this solve?
   • Proposed guideline: Clear, actionable guidance
   • Rationale: Why this is the best approach
   • Examples: Before/after or good/bad examples
   • Alternatives considered: What other options exist

4. Submit via GitHub:

   • Create a pull request with your changes
   • Tag relevant team members for review
   • Include any supporting research or evidence

Review Process

1. Design Systems team reviews all proposals for:

   • Alignment with existing guidelines
   • Accessibility compliance
   • Technical feasibility
   • User experience impact

2. Feedback is provided within two weeks

3. Once approved, changes are incorporated into the guidelines

4. Major revisions require UX leadership approval

Quality Standards for Contributions

Good guideline additions should be:

• Clear and concise: Easy to understand and implement
• Actionable: Provides specific guidance, not just principles
• Consistent: Aligns with existing patterns and guidance
• Evidence-based: Based on research, testing, or established best practices
• Inclusive: Considers diverse user needs and contexts
• Practical: Easily applied by designers and developers

Contribution Examples

Strong contribution:

"Add guideline for confirmation messages to require specific action name rather than generic 'Yes', supported by usability testing showing 28% reduction in errors."

Weak contribution:

"We should make buttons look better by using nicer labels."

6.5 Decision Trees

When to Use These Decision Trees

The following decision trees help resolve common labeling dilemmas when multiple valid options exist. Use these flowcharts when guidelines don't provide a clear single answer.

Button Label Decision Tree

Is this a primary action?
├── Yes → Does it modify data?
│   ├── Yes → Use verb + noun (e.g., "Save changes")
│   └── No → Is it a navigation action?
│       ├── Yes → Use verb + destination (e.g., "Go to dashboard")
│       └── No → Use clear action verb (e.g., "Continue")
└── No → Is it a cancellation action?
├── Yes → Use "Cancel" (not "Back" or "Return")
└── No → Is it a secondary positive action?
├── Yes → Use descriptive action (e.g., "Save as draft")
└── No → Use clear, specific label (e.g., "Learn more")

Truncation vs. Abbreviation Decision Tree

Can the content fit without modification?
├── Yes → Use complete text (preferred solution)
└── No → Is it a critical UI element (e.g., navigation, button)?
├── Yes → Can you rewrite to be more concise?
│   ├── Yes → Rewrite with shorter phrasing
│   └── No → Are there common abbreviations for terms?
│       ├── Yes → Use standard abbreviations with tooltips
│       └── No → Consider UI redesign to accommodate
└── No → Is it supplementary content?
├── Yes → Can you use progressive disclosure?
│   ├── Yes → Show partial content with "More" option
│   └── No → Truncate with ellipsis + tooltip
└── No → Truncate with ellipsis + tooltip

Form Label Style Decision Tree

What type of form field is this?
├── Text input for names/titles → Use noun phrase, no articles
├── Checkbox → Use affirmative statement
├── Radio buttons → Use option name only, not full question
├── Dropdown → Noun phrase that completes the question
└── Date/time → Be specific about format expectations
Is this a required field?
├── Yes → Add required indicator after label text
└── No → Don't mark as optional unless ambiguous
Does it need explanation?
├── Yes, complex → Add helper text below
├── Yes, simple → Add brief inline help icon
└── No → Keep label only

Error Message Decision Tree

What kind of error occurred?
├── Validation error → Be specific about requirements
├── System error → Explain what happened + next steps
└── Permission error → Explain who can perform this action
Is there a clear fix?
├── Yes → Include specific action to resolve
└── No → Provide support contact information
Is this blocking progress?
├── Yes → Use prominent error styling
└── No → Use less disruptive warning style

7. Appendices

7.1 Quick Reference Guide

Essential Label Standards at a Glance

Capitalization

• Use sentence case for all UI elements
• Capitalize only: first word, proper nouns, acronyms
• Example: "Add team member" (not "Add Team Member")

Text Formatting

• No periods at end of labels, headers, or buttons
• Use sentence case for all UI text
• Avoid exclamation points in error messages

Button Patterns

• Use verb + noun: "Create job" (not just "Create")
• Align to natural reading start (left in LTR, right in RTL)
• Order: Primary → Secondary → Tertiary → Destructive/Reset

Form Labels

• Use noun phrases: "Job title" (not "Enter job title")
• Position above input fields
• Show "Reset" only when form has been modified

Action Verbs

• Add (single items) vs. Create (complex objects)
• Search (server-side) vs. Find (client-side)
• Remove (reversible) vs. Delete (permanent)

Error Messages

• Be specific: "Enter a valid email address" (not "Invalid input")
• Suggest solutions: "Choose a start date before the end date"
• Avoid blame: "We couldn't find that account" (not "You entered a wrong account")

Truncation

• Avoid truncation whenever possible (accessibility issue)
• If necessary, truncate at word boundaries with ellipsis
• Always provide full text via tooltip or expanding element

Accessibility

• Ensure 4.5:1 minimum contrast for all text
• Don't rely on color alone to convey meaning
• Keep disabled text readable (3:1 minimum contrast)

Most Common Mistakes to Avoid

1. Inconsistent capitalization across similar elements
2. Using different terms for the same action
3. Making button labels too generic
4. Truncating text without providing access to full content
5. Right-aligning buttons in LTR interfaces
6. Using technical jargon in user-facing messages
7. Writing unhelpful error messages
8. Forgetting to consider text expansion in translations

7.2 Glossary of Terms

The glossary has moved to its own page for easier maintenance and future expansion. Please see the Glossary of Terms for the most up-to-date definitions and terminology.

7.3 Visual Examples

The examples below illustrate key concepts from these guidelines applied to real interface elements. Use these as reference when designing or reviewing UI labeling.

Capitalization Examples

✓ CORRECT CAPITALIZATION
Page title: "Team members"
Button: "Add team member"
Form label: "Job title"
Navigation: "Performance reviews"
Table header: "Hire date"

✗ INCORRECT CAPITALIZATION
Page title: "Team Members"
Button: "Add Team Member"
Form label: "Job Title"
Navigation: "Performance Reviews"
Table header: "Hire Date"

Button Label Examples

✓ GOOD BUTTON LABELS
Primary action: "Create job posting"
Secondary action: "Save as draft"
Destructive action: "Delete account"
Two-action button: "Save and continue"
Confirmation: "Yes, remove access"
✗ POOR BUTTON LABELS
Primary action: "Create" (too vague)
Secondary action: "Draft" (not a clear action)
Destructive action: "Yes" (consequence unclear)
Two-action button: "Save & continue" (wrong format)
Confirmation: "OK" (not specific enough)

Form Labeling Examples

✓ GOOD FORM LABELS
Text input: "First name"
Select menu: "Department"
Checkbox: "Send welcome email"
Date picker: "Start date (MM/DD/YYYY)"
Required field: "Job title *"
✗ POOR FORM LABELS
Text input: "Enter your first name:"
Select menu: "Select a department"
Checkbox: "Would you like to send a welcome email?"
Date picker: "When will they start?"
Required field: "* Job Title:"

Error Message Examples

✓ GOOD ERROR MESSAGES
Required field: "This field is required"
Invalid format: "Enter a valid email address"
Validation: "Password must include at least 8 characters"
Business rule: "Start date must be before end date"
System error: "We couldn't save your changes. Try again or contact support."
✗ POOR ERROR MESSAGES
Required field: "Required field!"
Invalid format: "Invalid input"
Validation: "Password does not meet requirements"
Business rule: "Invalid dates"
System error: "Error 500"

Text Alignment Examples

LTR INTERFACES
Form:          Button placement:
First name     [Save] [Cancel]
Last name
Department     (Left-aligned buttons)

RTL INTERFACES
Form:          Button placement:
שם פרטי        [ביטול] [שמירה]
שם משפחה
מחלקה          (Right-aligned buttons)

Truncation Examples

✓ GOOD TRUNCATION APPROACH

"Annual Performance Review for Marketing..." (with tooltip)
Truncate at word boundary
Ellipsis indicates more content
Full text in tooltip

✗ POOR TRUNCATION APPROACH

"Annual Performance Rev..." (cut mid-word)
"...for Marketing Team" (truncated beginning)
No visual indicator of truncation
No way to see full text

---

ClearCompany Label Standardization Guidelines v1.0 | Last updated: May 21 2025

Feedback from team

• Add truncation guidelines
• Examples guidelines ("e.g." versus "example:" vs adding "etc..."
• Email vs. e-mail
• txt vs. SMS vs Text message

Do we need guidelines for two-action button? As in, "Save and continue"

@mpaiva-cc Under punctuation standards - add exclamation mark

example - appropriate use: "You received a shout out!" inappropriate: "Job failed to save!"

@mpaiva-cc for integrations, for the use case of a file or piece of data that is being "synced" to another tool (example being the hire sync integration for adp)

The closest thing you have in the guidelines is "export" - but to me that sounds more like a manual 1 time sharing of an object to an external source. But should clarify if we want to continue using "Sync" for automations and/or integrations