Product copy

Copy is part of the design system: the same words for the same concepts, everywhere. This page is the canonical writing reference for every user-facing string in Hightouch — labels, buttons, errors, empty states, dialogs, toasts. It supersedes the UX Writing Guide in Notion, its prior home.

Use it as a reference, not a rulebook to memorize. When a rule and clarity conflict, choose clarity.

#Voice & tone

Voice is our always-on personality; it doesn't change. Tone flexes with the moment but always sounds like the same product. We are the confident, clear guide for modern marketing and data teams — authority without arrogance, leading by showing rather than boasting.

Talk to users, not about them: you far more than we. Reserve "we" for things Hightouch does on the user's behalf ("We'll notify you when it's done").

#Principles

• Clarity over cleverness. Users scan; the clearest version wins, even if it's less catchy.
• Guide, don't lecture. Give the next recommended step, not a lesson.
• Show the value. Tie actions and features to a concrete outcome.
• Sound human. Contractions are welcome, passive voice is rare. Write the way you'd explain it to a colleague.
• Be consistent. Same concept, same word, every time.

#Mechanics

• Sentence case, everywhere — buttons, headings, menu items, labels. Capitalize only the first word and proper nouns.
• Active voice, second person. "Map your fields", not "The user maps fields."
• No trailing punctuation on buttons, labels, menu items, field labels, or single-line empty states. Periods only on full sentences in help text and body copy.
• Exclamation points almost never. They read as hype.
• Oxford comma: "Sources, models, and syncs." Ampersands are fine in tight labels ("Review & launch"); use "and" in sentences.

#Terminology

One concept, one word — and the capitalization is part of the word.

Common product nouns are lowercase mid-sentence. Capitalize them only at the start of a sentence or as a standalone label or page title ("Syncs" in the nav).

Proper feature names are always capitalized, mid-sentence or not: Customer Studio, Ad Studio, Lifecycle Studio, Context Hub, Decision Engine (plural "Decision Engines" for the section), Match Booster, Identity Resolution, Agentic Marketing Platform. Exception: Lightning engine — "engine" is a descriptor and stays lowercase.

How we refer to people: the person using Hightouch is "you" (or a specific role — marketer, analyst, admin); avoid the generic "users" in-product. Their end-customers are "customers" or "profiles" — never conflate the two. Groups are "your team" or "your workspace".

#UI patterns

Every element has a job: headings orient, labels name, descriptions clarify, CTAs drive action, feedback confirms. Write the shortest text that still does the job.

#Page titles & headings

Page titles are usually the plural noun for the object: Syncs, Audiences, Models. Headings describe the task, not the machinery.

#Labels & placeholders

Labels name the field; they aren't instructions. Placeholders show a realistic example — never a restatement of the label, and never the only place required information lives (it disappears on focus).

#Descriptions & help text

One sentence where possible (~200 characters). Explain the why and how, not just the what. Cut filler: simply, easily, please, just.

#Tooltips

Keep to ~120 characters / 2 lines. Add information the label can't fit — never repeat it. Period only if it's a full sentence. On truncated text, auto-show the full value on hover.

#Buttons & CTAs

Action verb + object, 2–3 words, sentence case, no trailing punctuation. Prefer Create over Add when starting something new. In wizards, use descriptive step CTAs instead of "Next". Secondary/cancel on the left, primary or danger on the right — components like Confirmation Dialog own this placement themselves; it's a layout default, not copy to hand-fix.

#Links

Link on meaningful text — never "click here" or a bare URL. For docs, prefer "Learn more in docs" or link the specific concept ("Read the migration guide").

#Form validation

Required fields follow "[Field] is required" — capitalized field name, no period. State the rule and the bounds so the fix is obvious. Show errors inline, next to the field, after the user leaves it.

#Empty states

Explain why it's empty and what to do next — a first-run opportunity, not a dead end. Title is scannable; body points to the next action. Distinguish a filtered result from true emptiness: "No audiences match this filter", not "No audiences".

#Error messages

Two tiers, two tones:

• User-fixable (bad input, expired credentials): be specific, name the cause, give the next step. Calm, not blaming.
• Unexpected / system: brief apology, a retry, and a path to support. Never dump a raw error code as the whole message.

Whatever the tier: own the problem, stay calm, and offer a way forward. Link to docs or support when it helps.

#Toasts

Toasts confirm that something happened — keep them to a title, adding a short detail line only for errors. Success is past tense with no period. Reserve toasts for outcomes the user can't otherwise see.

#Confirmation & destructive dialogs

• Title: imperative, names the object — "Delete sync", not "Delete this sync?"
• Body: state the consequence, then standardize on "This can't be undone." If deleting one thing deletes others, list them.
• Confirm button: the verb, danger variant — "Delete", never "OK" or "Yes". Cancel on the left. High-risk actions require type-to-confirm.
• Discard changes: "Are you sure? You'll lose any unsaved changes." with "Discard changes" / "Keep editing".

#Status labels

One consistent word per state — the app's existing status vocabulary is authoritative, so match it rather than inventing synonyms or copying a list from a doc (including this one). Pair every badge with a tooltip that explains the state in one sentence. Sync success reads as Healthy — framing sync state as ongoing health, not a one-time "Success". Use US spelling: Canceled, not Cancelled.

#Loading & progress

Describe in-progress work with a gerund: Querying, Processing, Detecting changes. Name each phase of a multi-phase operation — and where useful, explain what it's doing and why it might be slow ("Executing query — running in your warehouse to pull rows. Speed depends on warehouse load."). For long AI or compute steps show elapsed time and a plain status. Never leave a silent spinner.

#Numbers & dates

Lowercase am/pm, no space. Always show the time zone on timestamps, and expose the exact timestamp on hover for relative dates. Avoid numeric-only formats (05/04/2025) — they're ambiguous across regions.

#Writing for AI

AI features are held to the same voice, plus rules that build trust: capable and honest, never magical.

• Describe what the AI does for the user, not how clever it is.
• Keep the user in control: AI suggests and drafts; the user decides. Make it obvious that output is editable and reversible.
• Don't over-anthropomorphize — the agent is a tool, not a colleague with feelings.
• Action labels are verbs: Generate, Regenerate, Suggest, Improve. Not "Do it" or "Magic".
• Prompt placeholders show a real example of what to type, not "Enter your prompt".
• Be upfront when output is AI-generated and when a human should verify it — don't bury it.
• Agent surfaces carry the standard disclaimer: "Agents can make mistakes and use is subject to the AI terms. Double-check responses."
• AI-generated media carries a visible "Contains AI-generated content" label and a machine-readable tag in the file's metadata.
• Progress is plain and honest: "Thinking…", then concrete milestones and elapsed time. No fake precision.

#Accessibility & inclusivity

• Aim for a ~Grade 8 reading level unless an advanced term is essential.
• Gender-neutral language ("they"). Avoid idioms that don't translate.
• Never rely on color alone — pair it with text or an icon.
• Every icon-only button needs an accessible label — a verb + object naming the action ("Delete sync", not "Trash icon"), matching the visible tooltip when there is one.
• Alt text states the purpose, never "image".
• Prefer wrapping over truncation. When you must truncate, always reveal the full value on hover. Middle truncation (acme-…-production) keeps the meaningful ends of long identifiers visible, but it needs a custom helper — a nice-to-have, not the default.

#Length quick reference

#Words we avoid

#Pre-ship checklist

• Sentence case, no stray Title Case
• Product terms match the terminology tables, capitalization included
• Buttons are verb + object, no trailing punctuation
• Errors name a cause and a next step
• Destructive dialogs state the consequence and "This can't be undone."
• No banned words
• Reads clearly at a glance — no jargon the audience won't know
• AI output is disclosed and editable where relevant