Product and UX Content

UX Content Brief

Define a user task, interface context, constraints, states, evidence, risks, terminology, and successful behavior before writing product copy.

Free editable Markdown · Content designers, product designers, and product managers · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

User and task

Feature, surface, and release: [Enter]
User and account state: [Describe]
Prior event or entry point: [Enter]
Primary task: [One action or decision]
Motivation and concern: [Evidence]
Permissions, plan, locale, device: [Enter]
Consequence of error: [Describe]
Successful end state: [Observable behavior]

Product and evidence

Product behavior source: [Requirement/owner/version]
Research evidence: [Finding/reference]
Support or analytics evidence: [Enter]
Terms and definitions: [Approved list]
Policy, privacy, legal, or safety requirement: [Enter]
Technical constraints and variables: [Enter]
Unknown questions: [Question/owner/date]

State content map

Duplicate for each state.

State and trigger: [Default / Loading / Empty / Error / Denied / Success]
User question: [What must they understand?]
Available actions: [List]
Required message: [Facts, condition, recovery]
Primary label or text: [Draft]
Alternative route: [Enter]
Owner and evidence: [Enter]

Quality and release

Voice and terminology: [Enter]
Length and layout constraints: [Enter]
Accessibility requirements: [Enter]
Localization and variable notes: [Enter]
Required reviewers: [Product / Engineering / Privacy / Legal / Other]
Prototype test task: [Enter]
Implemented QA: [States/devices/assistive technology]
Success and recheck trigger: [Define]

How to use this template

Define the user situation, task, prior state, consequence, and observable completion.
Map the full flow and all default, transitional, error, denied, and success states.
Collect product behavior, research, terminology, policy, and technical evidence.
Specify copy requirements, constraints, reviewers, accessibility, localization, and tests.
Approve the implemented content and monitor whether users understand and recover.

Define the user state and task precisely

Describe what happened before the interface appears, what the user knows, what they are trying to accomplish, and what they may fear or misunderstand. Record account state, permissions, plan, locale, device, time pressure, and consequence where relevant. Avoid demographic assumptions that do not change the task. Name the system's true behavior and the successful end state. “Write onboarding copy” is too broad; “help a first-time workspace owner invite one teammate without exposing an email address to the wrong workspace” gives the team decisions it can evaluate.

Map content to behavior and evidence

List every state: default, loading, partial, empty, permission denied, validation failure, system failure, irreversible confirmation, success, and return visit. For each, define the choice the interface offers and the information needed before action. Use current product requirements, prototypes, research, support themes, policy, and technical constraints as evidence. Mark unknown behavior instead of inventing it in copy. A message promising that data is “saved” must correspond to an actual persistence event. Terms should match the product and help content, with definitions or tooltips where necessary.

Establish quality and decision ownership

Specify voice, length, localization, variables, responsive space, accessibility, legal or privacy review, and experimentation limits. Define success through task comprehension, completion, error recovery, and trust—not only clicks. Assign decisions: product owns behavior, engineering owns system states, qualified teams own policy claims, and content owns language within those facts. Plan prototype and implemented testing with relevant users. After release, monitor repeated errors and support feedback and reopen the brief when product behavior or user needs change.

See the fields in context

Fictional example: invite a teammate

HarborBoard and every permission, state, and message below are invented.

User: A fictional workspace owner who has not invited anyone before.
Task: Send one invitation to the correct workspace and understand when access begins.
Risk: The user may think entering an email grants immediate access; imaginary behavior requires acceptance first.
States: Default, invalid email, already a member, send failure, sent, and expired invitation.
Success copy: Confirms the destination address, states that access starts after acceptance, and offers a safe revoke path.

Frequently asked questions

How is a UX content brief different from a page brief?

It centers on behavior, interface states, decisions, variables, constraints, and recovery inside a product flow.

Should final copy be written in the brief?

Draft candidates can clarify requirements, but approve wording in context after product behavior and layouts are stable enough to test.

Who owns an error message?

Content can own wording, but product and engineering must establish the cause, state, available recovery, and technical behavior.

When should the brief be reopened?

On changed behavior, audience, permissions, policy, terminology, localization, research, or recurring error evidence.