Skip to main content

Writing Guidelines

Clear, consistent, and thoughtful writing helps users understand and trust our products. These guidelines ensure our voice remains authentic and our messaging stays user-focused.

Voice & Tone

Our Voice

Waypoint's voice is consistent across all touchpoints. It's who we are.

Clear

We explain complex concepts in simple terms without dumbing them down

Confident

We're authoritative without being arrogant, knowledgeable without being condescending

Human

We write like people, not robots. Conversational but professional

Our Tone

Tone adapts to context. It's how we express our voice in different situations.

Success Messages

Encouraging

Celebrate wins without being cheesy

"✓ Component published successfully"

Error Messages

Helpful

Explain what went wrong and how to fix it

"Unable to save. Check your connection and try again"

Onboarding

Welcoming

Guide without overwhelming

"Let's get you started. First, choose a template"

Technical Documentation

Precise

Accurate and concise, but still approachable

"The variant prop accepts: 'primary' | 'secondary' | 'ghost'"

Content Principles

1. Start with the User Need

Every piece of content should answer: "What does the user need to know or do right now?"

Don't

"Our revolutionary AI-powered system utilizes advanced algorithms..."

Do

"Get instant answers to your questions"

2. Be Concise, Not Terse

Cut unnecessary words, but keep warmth and personality. Brevity shouldn't feel cold.

Don't

"File uploaded."

Do

"Your file uploaded successfully"

3. Use Active Voice

Active voice is clearer and more direct. It helps users understand who's doing what.

Don't

"Your password was changed by you"

Do

"You changed your password"

4. Front-Load Important Information

Put the most important info first. Users scan—they don't always read everything.

Don't

"To proceed with deleting this project, you'll need to confirm..."

Do

"Delete project? This action cannot be undone"

Button & CTA Guidelines

Best Practices

  • Use verbs that describe the action

    "Save changes" not "OK"

  • Keep it short (1-3 words)

    "Create project" not "Click here to create a new project"

  • Match button hierarchy to importance

    Primary button for primary action, secondary for alternatives

  • Be specific about outcomes

    "Delete 3 items" not just "Delete"

Avoid

  • • "Click here"
  • • "Submit"
  • • "OK" / "Yes" / "No"
  • • "Learn more" (without context)
  • • Technical jargon

Prefer

  • • "Get started"
  • • "Save changes"
  • • "Cancel" / "Delete project"
  • • "View documentation"
  • • Clear, simple language

Error Messages

Anatomy of a Good Error Message

1

What happened

Clearly explain what went wrong in plain language

2

Why it happened

Help users understand the cause (if it's not obvious)

3

How to fix it

Provide clear next steps or actions

Poor Error

"Error 403: Forbidden"

Technical, unhelpful, leaves user confused

Good Error

"You don't have permission to view this project. Request access from the project owner."

Clear problem, obvious next step

Formatting & Style

Capitalization

  • •
    Sentence case for everything

    Buttons, headings, labels, navigation—all sentence case

    "Create new project" not "Create New Project"

  • •
    Proper nouns get capitals

    Waypoint, Cohere, product names

Punctuation

  • •
    No periods in buttons or short labels

    Save the periods for complete sentences

  • •
    Use contractions

    "Don't" not "Do not" — sounds more natural

  • •
    Oxford comma for lists

    "Design, develop, and deploy" for clarity

Numbers & Dates

  • •
    Spell out one through nine

    Use numerals for 10 and above

  • •
    Use relative time when appropriate

    "2 minutes ago" is friendlier than "2:43 PM"

Writing Checklist

Before publishing any content, ask yourself: