Back to Details

ux-writing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

UX Writing

UX Writing

Write clear, concise, user-centered interface copy (UX text/microcopy) for digital products and experiences. This skill provides frameworks, patterns, and best practices for creating text that helps users accomplish their goals.
撰写清晰、简洁、以用户为中心的界面文案（UX text/microcopy），用于数字产品及用户体验。该技能提供框架、模式与最佳实践，帮助创作用户达成目标所需的文本。

When to Use This Skill

何时使用该技能

Use this skill when:
  • Writing interface copy (buttons, labels, titles, messages, forms)
  • Editing existing UX text for clarity and effectiveness
  • Creating error messages, notifications, or success messages
  • Designing conversational flows or onboarding experiences
  • Establishing voice and tone for a product
  • Auditing product content for consistency and usability
在以下场景使用该技能：
  • 编写界面文案（按钮、标签、标题、提示、表单）
  • 编辑现有UX文案，提升清晰度与有效性
  • 创作错误提示、通知或成功提示
  • 设计对话流程或引导体验
  • 确立产品的语气语调
  • 审核产品内容的一致性与可用性

Core UX Writing Principles

核心UX写作原则

The Four Quality Standards

四大质量标准

Every piece of UX text should be:
  1. Purposeful — Helps users or the business achieve goals
  2. Concise — Uses the fewest words possible without losing meaning
  3. Conversational — Sounds natural and human, not robotic
  4. Clear — Unambiguous, accurate, and easy to understand
每一段UX文案都应符合：
  1. 目标明确 —— 帮助用户或企业达成目标
  2. 简洁凝练 —— 用最少的文字传递完整信息
  3. 口语化表达 —— 听起来自然、人性化，而非机械生硬
  4. 清晰易懂 —— 含义明确、准确，易于理解

Key Best Practices

关键最佳实践

Conciseness
  • Use 40-60 characters per line maximum
  • Every word must have a job
  • Break dense text into scannable chunks
  • Front-load important information
  • Eliminate deadwood phrases ("in order to" → "to", "due to the fact that" → "because", "at this point in time" → "now")
  • Replace phrasal verbs with direct verbs ("find out" → "discover", "set up" → "configure", "carry out" → "perform")
  • Avoid stacking modifiers — one adjective is usually enough
Clarity
  • Use plain language (7th grade reading level for general, 10th for professional)
  • Avoid jargon, idioms, and technical terms
  • Use consistent terminology throughout
  • Choose meaningful, specific verbs
  • Avoid discriminatory or exclusionary language (gendered defaults, ableist idioms, culturally specific metaphors)
Conversational Tone
  • Write how you speak
  • Use active voice 85% of the time
  • Include prepositions and articles
  • Avoid robotic phrasing
User-Centered
  • Focus on user benefits, not features
  • Anticipate and answer user questions
  • Use second-person ("you") language
  • Match user's language and mental models
简洁性
  • 每行最多40-60个字符
  • 每个词都必须有实际作用
  • 将密集文本拆分为易于扫描的小块
  • 重要信息前置
  • 删除冗余短语（将"in order to"改为"to"，"due to the fact that"改为"because"，"at this point in time"改为"now"）
  • 用直接动词替换短语动词（"find out"改为"discover"，"set up"改为"configure"，"carry out"改为"perform"）
  • 避免堆砌修饰词——通常一个形容词足够
清晰度
  • 使用平实语言（面向普通用户的内容为7年级阅读水平，专业内容为10年级）
  • 避免行话、习语与技术术语
  • 全程使用一致的术语
  • 选择有意义、具体的动词
  • 避免歧视性或排他性语言（性别默认表述、歧视残疾人的习语、特定文化隐喻）
口语化语调
  • 像日常说话一样写作
  • 85%的内容使用主动语态
  • 包含介词与冠词
  • 避免机械生硬的表述
以用户为中心
  • 聚焦用户收益，而非产品功能
  • 预判并解答用户疑问
  • 使用第二人称（"你"）表述
  • 匹配用户的语言与思维模式

UX Text Patterns

UX文案模式

Apply these common patterns for interface elements.
将以下通用模式应用于界面元素。

Titles

标题

  • Purpose: Orient users to where they are
  • Format: Noun phrases. Page titles, modal/dialog titles, and menu/navigation items use title case (see Capitalization below for title-case mechanics). Lower-level headings (H3+), figure captions, callouts, and table titles use sentence case.
  • Types: Brand titles, content titles, category titles, task titles
  • Examples:
    • Page title (title case): "Account Settings", "Your Library", "Run Payroll"
    • Lower-level heading (sentence case): "Recent activity", "Bank account details", "Tax withholdings"
  • 目的：帮助用户明确当前位置
  • 格式：名词短语。页面标题、模态框/对话框标题、菜单/导航项使用标题大小写（标题大小写规则见下方"大小写规范"）。低层级标题（H3及以下）、图表说明、提示框、表格标题使用句子大小写。
  • 类型：品牌标题、内容标题、分类标题、任务标题
  • 示例：
    • 页面标题（标题大小写）："Account Settings"、"Your Library"、"Run Payroll"
    • 低层级标题（句子大小写）："Recent activity"、"Bank account details"、"Tax withholdings"

Buttons and Links

按钮与链接

  • Purpose: Enable users to take action
  • Format: Active imperative verbs, sentence case
  • Pattern: 
    [Verb] [object]
  • Examples: "Save changes", "Delete account", "View details"
  • Avoid: Generic labels like "OK", "Submit", "Click here"
  • 目的：支持用户执行操作
  • 格式：主动祈使动词，句子大小写
  • 模式：
    [动词] [宾语]
  • 示例："Save changes"、"Delete account"、"View details"
  • 避免：通用标签如"OK"、"Submit"、"Click here"

Error Messages

错误提示

  • Purpose: Explain problem and provide solution
  • Format: Empathetic, clear, actionable
  • Pattern: 
    [What failed]. [Why/context]. [What to do].
Error Message Types
Validation Errors (Inline)
  • Show as user completes field or on blur
  • Brief, specific guidance to correct input
  • Pattern: 
    [Field] [specific requirement]
  • Examples:
    • "Email must include @"
    • "Password must be at least 8 characters"
    • "Choose a date in the future"
  • Timing: Real-time or on field exit
  • Location: Below or beside the field
System Errors (Modal/Banner)
  • Show when backend operations fail
  • Explain what happened and why
  • Pattern: 
    [Action failed]. [Likely cause]. [Recovery step].
  • Examples:
    • "Payment failed. Your card was declined. Try a different payment method."
    • "Couldn't save changes. Connection lost. Reconnect and try again."
    • "Upload failed. File is too large. Choose a file under 10MB."
  • Timing: Immediately after failure
  • Location: Modal dialog or prominent banner
Blocking Errors (Full-screen)
  • Prevent continued use until resolved
  • Clear explanation of blocker and resolution
  • Pattern: 
    [What's blocked]. [Why]. [Specific action needed].
  • Examples:
    • "Update required. This version is no longer supported. Update now to continue."
    • "Subscription expired. Your account is paused. Renew subscription to restore access."
    • "Verification needed. Confirm your email to access features. Check your inbox."
  • Timing: On app launch or feature access
  • Location: Full screen or large modal
Permission Errors
  • Explain benefit before requesting permission
  • Pattern: 
    [User benefit]. [Permission needed].
  • Examples:
    • "Get notified when orders ship. Enable notifications."
    • "Find nearby stores. Allow location access."
    • "Back up your photos. Grant storage permission."
  • Timing: When feature is first used
  • Location: In context of the feature
What to Avoid
  • Technical codes without explanation ("Error 403")
  • Blame language ("invalid input", "illegal character")
  • Robotic tone ("An error has occurred")
  • Dead ends (error with no recovery path)
  • Vague causes ("Something went wrong")
  • 目的：解释问题并提供解决方案
  • 格式：共情、清晰、可操作
  • 模式：
    [失败内容]。[原因/背景]。[解决方案]。
错误提示类型
内联验证错误
  • 在用户填写字段时或失去焦点时显示
  • 简短、具体的修正指引
  • 模式：
    [字段] [具体要求]
  • 示例：
    • "Email must include @"
    • "Password must be at least 8 characters"
    • "Choose a date in the future"
  • 时机：实时或字段失去焦点时
  • 位置：字段下方或旁边
系统错误（模态框/横幅）
  • 后台操作失败时显示
  • 解释发生的问题及原因
  • 模式：
    [操作失败]。[可能原因]。[恢复步骤]。
  • 示例：
    • "Payment failed. Your card was declined. Try a different payment method."
    • "Couldn't save changes. Connection lost. Reconnect and try again."
    • "Upload failed. File is too large. Choose a file under 10MB."
  • 时机：操作失败后立即显示
  • 位置：模态对话框或显眼的横幅
阻塞性错误（全屏）
  • 问题解决前阻止用户继续使用
  • 清晰说明阻塞原因及解决方法
  • 模式：
    [阻塞内容]。[原因]。[所需具体操作]。
  • 示例：
    • "Update required. This version is no longer supported. Update now to continue."
    • "Subscription expired. Your account is paused. Renew subscription to restore access."
    • "Verification needed. Confirm your email to access features. Check your inbox."
  • 时机：应用启动或访问功能时
  • 位置：全屏或大型模态框
权限错误
  • 请求权限前先说明用户收益
  • 模式：
    [用户收益]。[所需权限]。
  • 示例：
    • "Get notified when orders ship. Enable notifications."
    • "Find nearby stores. Allow location access."
    • "Back up your photos. Grant storage permission."
  • 时机：首次使用功能时
  • 位置：功能相关的上下文环境中
需避免的情况
  • 仅显示技术代码无解释（如"Error 403"）
  • 指责用户的语言（如"invalid input"、"illegal character"）
  • 机械生硬的语调（如"An error has occurred"）
  • 无解决路径的错误提示
  • 模糊的原因说明（如"Something went wrong"）

Success Messages

成功提示

  • Purpose: Confirm action completion
  • Format: Past tense, specific, encouraging
  • Pattern: 
    [Action] [result/benefit]
  • Examples: "Changes saved", "Email sent", "Profile updated"
  • 目的：确认操作完成
  • 格式：过去时态、具体、鼓舞人心
  • 模式：
    [操作] [结果/收益]
  • 示例："Changes saved"、"Email sent"、"Profile updated"

Empty States

空状态

  • Purpose: Guide users when content is absent
  • Types: First-use, user-cleared, error/no results
  • Format: Explanation + CTA to populate
  • Example: "No messages yet. Start a conversation to connect with your team."
  • 目的：内容缺失时引导用户
  • 类型：首次使用、用户清空、错误/无结果
  • 格式：说明文字 + 填充内容的CTA
  • 示例："No messages yet. Start a conversation to connect with your team."

Form Fields

表单字段

  • Labels: Clear noun phrases describing input ("Email address", "Phone number")
  • Instructions: Verb-first, explain why information is needed
  • Placeholder: Use sparingly, only for standard inputs like "name@example.com"
  • Helper text: Static, on-demand, or automatic based on importance
  • 标签：清晰描述输入内容的名词短语（如"Email address"、"Phone number"）
  • 说明文字：以动词开头，说明收集信息的原因
  • 占位符：谨慎使用，仅用于标准输入（如"name@example.com"）
  • 帮助文本：根据重要性设置为静态、按需显示或自动显示

Notifications

通知

  • Purpose: Deliver timely, valuable information
  • Types: Action-required (intrusive), Passive (less intrusive)
  • Format: Verb-first title + contextual description
  • Example: "Update required. Install the latest version to continue."
  • 目的：传递及时、有价值的信息
  • 类型：需操作（强干扰）、被动（弱干扰）
  • 格式：动词开头的标题 + 上下文描述
  • 示例："Update required. Install the latest version to continue."

Formatting & Style Conventions

格式与风格规范

Capitalization

大小写规范

  • Sentence case (default): Body text, descriptions, helper text, error messages, success messages, tooltips, placeholder text, button labels, lower-level (H3+) headings, figure captions, callouts, table titles
  • Title case: Page titles, modal/dialog titles, menu and navigation items, form field labels
  • All-caps: Reserved for short overline / eyebrow labels (≤3 words) that sit above a heading or metric — e.g., stat-card section headers like 
    EMPLOYEES
    , 
    TOTAL PAY
    , 
    LAST UPDATED
    , category tags over KPI values — and for acronyms (
    PDF
    , 
    URL
    , 
    API
    , 
    EIN
    , 
    SSN
    ). Trimble's own product surfaces use this treatment for short category overlines; it's an intentional typographic signal, not shouting. Do not use all-caps for prose, button labels, error messages, page titles, tabs/menu labels, or any string longer than ~3 words — beyond that length readability drops sharply and it reads as shouting.
Title case mechanics (applies wherever title case is used):
  • Capitalize the first and last word of the title regardless of part of speech.
  • Capitalize all adjectives, adverbs, and nouns.
  • Capitalize all pronouns (including "it").
  • Capitalize all verbs, including the verb "to be" in all forms (is, are, was, has been, etc.).
  • Capitalize "no", "not", and the interjection "O".
  • Do not capitalize articles ("a", "an", "the") unless first or last in the title.
  • Do not capitalize coordinating conjunctions ("and", "or", "nor", "but", "for", "yet", "so") unless first or last in the title.
  • Do not capitalize "to" (with or without an infinitive) unless first or last in the title.
  • Do not capitalize prepositions (e.g., "in", "on", "at", "by", "of", "with") unless first or last in the title.
Examples:
  • "Run Payroll for the Pay Period"
  • "Add a New Employee"
  • "How to File Quarterly Taxes"
Lista interpretations of edge cases:
  • "Coming soon" is the canonical future-feature label everywhere it appears (badges, callouts, copy). Even when used in a title-cased context, write it sentence case per the 
    lista-ui-conventions
    rule. Do not expose milestone granularity ("Coming at Beta", "Coming at GA") in user-facing strings.
  • Dropdown action items (imperative-verb items inside a button-triggered menu, e.g. 
    "Add employee"
    , 
    "See payroll runs"
    , 
    "Export report"
    ) are treated as buttons → sentence case, not as static navigation menu items. Prism's "menu items use title case" rule applies to navigational menus (side nav, breadcrumbs, top-level nav links pointing to pages), not action menus.
  • Buttons that reference a named page (e.g. 
    "Go to Setup Wizard"
    , 
    "Back to Payroll Hub"
    , 
    "Open Time Review"
    ) preserve the page name's title case while the surrounding button copy stays sentence case. The page name is a proper noun in this context.
  • 句子大小写（默认）：正文、描述、帮助文本、错误提示、成功提示、工具提示、占位符文本、按钮标签、低层级（H3及以下）标题、图表说明、提示框、表格标题
  • 标题大小写：页面标题、模态框/对话框标题、菜单与导航项、表单字段标签
  • 全大写：仅用于短overline/眉标（≤3个词），置于标题或指标上方——例如统计卡片的章节标题如
    EMPLOYEES
    、
    TOTAL PAY
    、
    LAST UPDATED
    ，KPI值上方的分类标签——以及缩写词（
    PDF
    、
    URL
    、
    API
    、
    EIN
    、
    SSN
    ）。Trimble旗下产品将此格式用于短分类眉标，这是有意的排版信号，并非大声叫嚷。请勿在散文、按钮标签、错误提示、页面标题、标签/菜单标签或长度超过约3个词的文本中使用全大写——超过该长度后可读性会急剧下降，且会被视为叫嚷。
标题大小写规则（适用于所有需使用标题大小写的场景）：
  • 无论词性如何，标题的第一个词和最后一个词首字母大写。
  • 所有形容词、副词、名词首字母大写。
  • 所有代词（包括"it"）首字母大写。
  • 所有动词，包括动词"to be"的所有形式（is、are、was、has been等）首字母大写。
  • "no"、"not"以及感叹词"O"首字母大写。
  • 请勿将冠词（"a"、"an"、"the"）首字母大写，除非是标题的第一个词或最后一个词。
  • 请勿将并列连词（"and"、"or"、"nor"、"but"、"for"、"yet"、"so"）首字母大写，除非是标题的第一个词或最后一个词。
  • 请勿将"to"（无论是否与不定式连用）首字母大写，除非是标题的第一个词或最后一个词。
  • 请勿将介词（如"in"、"on"、"at"、"by"、"of"、"with"）首字母大写，除非是标题的第一个词或最后一个词。
示例：
  • "Run Payroll for the Pay Period"
  • "Add a New Employee"
  • "How to File Quarterly Taxes"
Lista对边缘情况的解释：
  • "Coming soon" 是所有场景下（徽章、提示框、文案）规范的未来功能标签。即使在需使用标题大小写的场景中，也需按照
    lista-ui-conventions
    规则使用句子大小写。请勿在面向用户的文本中暴露里程碑粒度（如"Coming at Beta"、"Coming at GA"）。
  • 下拉操作项（按钮触发菜单中的祈使动词项，如
    "Add employee"
    、
    "See payroll runs"
    、
    "Export report"
    ）视为按钮→句子大小写，而非静态导航菜单项。Prism的"菜单项使用标题大小写"规则适用于导航类菜单（侧边栏导航、面包屑、指向页面的顶级导航链接），而非操作菜单。
  • 引用命名页面的按钮（如
    "Go to Setup Wizard"
    、
    "Back to Payroll Hub"
    、
    "Open Time Review"
    ）保留页面名称的标题大小写，而按钮其余文案使用句子大小写。在此场景下，页面名称视为专有名词。

Numbers and Dates

数字与日期

  • Use numerals, not words ("12" not "twelve") — saves space and scans faster.
  • Spell out the month in dates: "August 5, 2025" or "5 August 2025" — never "8/5/2025" or "8.5.2025" (ambiguous across locales).
  • Spell out day of the week and month; abbreviate only when space is constrained (e.g., tables, mobile): "Sat., Jan. 24".
  • Avoid ordinal suffixes in dates: write "August 5", not "August 5th"; write "May 1", not "May 1st".
  • Year ranges use a hyphen with the full year on both sides: "2015-2016", not "2015-16" and not "2015 to 2016".
  • 使用阿拉伯数字，而非单词（如用"12"而非"twelve"）——节省空间且更易扫描
  • 日期中月份需拼写完整：如"August 5, 2025"或"5 August 2025"——切勿使用"8/5/2025"或"8.5.2025"（不同地区含义模糊）
  • 星期和月份拼写完整；仅在空间有限时缩写（如表格、移动端）："Sat., Jan. 24"
  • 日期中避免使用序数后缀：写"August 5"，而非"August 5th"；写"May 1"，而非"May 1st"
  • 年份范围使用连字符，两侧均为完整年份：如"2015-2016"，而非"2015-16"或"2015 to 2016"

Tense

时态

  • Prefer past tense over present perfect for status messages: "File uploaded" not "File has been uploaded"
  • Present perfect adds words without adding meaning in most UI contexts
  • 状态提示优先使用过去时态，而非现在完成时：如"File uploaded"而非"File has been uploaded"
  • 在大多数UI场景中，现在完成时会增加字数但无额外意义

Abbreviations

缩写词

  • Only use abbreviations your users will immediately understand (common: PDF, URL, ID)
  • Spell out on first use if there's any doubt, then abbreviate after: "application programming interface (API)"
  • Latin abbreviations (e.g., i.e., etc.) — use proper punctuation: period after each letter, comma before and after in a sentence
  • When in doubt, spell it out
  • 仅使用用户能立即理解的缩写词（常见的如PDF、URL、ID）
  • 如有疑问，首次使用时拼写完整，之后再使用缩写：如"application programming interface (API)"
  • 拉丁语缩写（如i.e.、etc.）——使用正确标点：每个字母后加句点，句子中前后加逗号
  • 如有疑问，拼写完整

Voice and Tone

语气语调

Voice (Consistent Brand Personality)

语气（一致的品牌个性）

Voice is the consistent personality of the product. Establish voice using:
  • Concepts: 3-5 key brand principles/values
  • Voice characteristics: Descriptive adjectives for each concept
  • Do/Don't examples: Concrete examples showing voice in action
See references/voice-chart-template.md for creating a voice chart.
语气是产品的一致个性。通过以下方式确立语气：
  • 核心概念：3-5个关键品牌原则/价值观
  • 语气特征：每个概念对应的描述性形容词
  • 示例指引：展示语气应用的具体示例
创建语气图表可参考references/voice-chart-template.md。

Tone (Adaptive to Context)

语调（根据上下文调整）

Tone is how voice adapts to specific situations. While voice remains constant, tone shifts based on user context and emotional state.
Tone Variables
  • Purpose: Why user is seeing this text (information, action, confirmation)
  • Context: What user is trying to do (learning, completing task, recovering from error)
  • Emotional state: How user likely feels (frustrated, excited, confused, cautious)
  • Stakes: Impact of the action (low: changing theme, high: deleting account)
Tone Adaptation by User Emotional State
Frustrated (errors, failures, blockers)
  • Empathetic and solution-focused
  • Acknowledge the problem without blame
  • Provide clear recovery path
  • Example: "Payment failed. Your card was declined. Try a different payment method."
Confused (first use, complex features)
  • Patient and explanatory
  • Break down steps clearly
  • Provide context and guidance
  • Example: "Connect your bank to see spending insights. We'll guide you through it."
Confident (routine tasks, return visits)
  • Efficient and direct
  • Minimal explanation
  • Quick confirmation
  • Example: "Saved"
Cautious (high-stakes actions, data loss)
  • Serious and transparent
  • Clear consequences
  • Respectful of user's decision
  • Example: "Delete account? You'll lose all data and this can't be undone."
Successful (completions, achievements)
  • Positive and encouraging
  • Proportional to achievement
  • Brief celebration
  • Example: "Profile updated. Your changes are live."
Tone Adaptation by Content Type
Error messages: Empathetic, reassuring, solution-focused
  • Never blame user
  • Explain what happened
  • Provide clear next step
Success messages: Positive, specific, encouraging
  • Confirm what happened
  • Proportional to action importance
  • Brief and clear
Instructions: Clear, direct, helpful
  • Front-load key action
  • Explain why when needed
  • Use simple steps
Onboarding: Inviting, encouraging, concise
  • Welcome without overwhelming
  • Focus on value
  • Celebrate early wins
Confirmations: Serious, transparent, respectful
  • Clear about consequences
  • No manipulation
  • Easy to back out
Empty states: Hopeful, actionable, guiding
  • Explain why it's empty
  • Provide clear next action
  • Keep encouraging tone
语调是语气在特定场景下的适配。语气保持一致，而语调会根据用户上下文与情绪状态调整。
语调变量
  • 目的：用户看到这段文字的原因（信息传递、操作引导、确认）
  • 上下文：用户正在尝试完成的任务（学习、完成任务、从错误中恢复）
  • 情绪状态：用户可能的感受（沮丧、兴奋、困惑、谨慎）
  • 风险等级：操作的影响（低风险：更改主题；高风险：删除账户）
根据用户情绪状态调整语调
沮丧（错误、失败、阻塞）
  • 共情且聚焦解决方案
  • 承认问题但不指责用户
  • 提供清晰的恢复路径
  • 示例："Payment failed. Your card was declined. Try a different payment method."
困惑（首次使用、复杂功能）
  • 耐心且具解释性
  • 清晰拆解步骤
  • 提供上下文与指引
  • 示例："Connect your bank to see spending insights. We'll guide you through it."
自信（常规任务、回访）
  • 高效且直接
  • 最少的解释
  • 快速确认
  • 示例："Saved"
谨慎（高风险操作、数据丢失）
  • 严肃且透明
  • 清晰说明后果
  • 尊重用户的决定
  • 示例："Delete account? You'll lose all data and this can't be undone."
成功（操作完成、成就）
  • 积极且鼓舞人心
  • 与成就程度匹配
  • 简短庆祝
  • 示例："Profile updated. Your changes are live."
根据内容类型调整语调
错误提示：共情、安心、聚焦解决方案
  • 绝不指责用户
  • 解释发生的问题
  • 提供清晰的下一步操作
成功提示：积极、具体、鼓舞人心
  • 确认已完成的操作
  • 与操作重要性匹配
  • 简短清晰
说明文字：清晰、直接、有帮助
  • 重要操作前置
  • 必要时说明原因
  • 使用简单步骤
引导流程：友好、鼓舞人心、简洁
  • 欢迎但不过度干扰
  • 聚焦价值
  • 庆祝早期成果
确认提示：严肃、透明、尊重
  • 清晰说明后果
  • 不使用诱导性语言
  • 易于取消操作
空状态：充满希望、可操作、具引导性
  • 说明空状态原因
  • 提供清晰的下一步操作
  • 保持鼓舞的语调

Editing Process

编辑流程

Edit UX text in four phases:
分四个阶段编辑UX文案：

Phase 1: Purposeful

阶段1：目标明确

  • Does text help user achieve their goal?
  • Does text serve business objectives?
  • Is value to user clear?
  • Are concerns anticipated and addressed?
  • 文案是否帮助用户达成目标？
  • 文案是否符合业务目标？
  • 用户能清晰看到价值吗？
  • 是否预判并解决了用户顾虑？

Phase 2: Concise

阶段2：简洁凝练

  • Remove unnecessary words
  • Combine redundant information
  • Ensure every word earns its space
  • Front-load important concepts
  • 删除不必要的词
  • 合并冗余信息
  • 确保每个词都有存在的意义
  • 重要概念前置

Phase 3: Conversational

阶段3：口语化表达

  • Read aloud—would you say this?
  • Use active voice (unless passive is clearer)
  • Include natural connecting words
  • Avoid corporate jargon
  • 大声朗读——你会这么说吗？
  • 使用主动语态（除非被动语态更清晰）
  • 包含自然的连接词
  • 避免企业行话

Phase 4: Clear

阶段4：清晰易懂

  • Use specific, accurate verbs
  • Maintain consistent terminology
  • Test readability (Hemingway Editor, Flesch-Kincaid)
  • Ensure unambiguous meaning
  • 使用具体、准确的动词
  • 保持术语一致
  • 测试可读性（使用Hemingway Editor、Flesch-Kincaid工具）
  • 确保含义明确无歧义

Workflow

工作流程

  1. Understand context
    • User goals and needs
    • Business objectives
    • Technical constraints
    • Emotional state of user
  2. Draft content
    • Start with conversation (what would you say?)
    • Apply appropriate pattern
    • Consider voice and tone
    • Front-load important information
  3. Edit iteratively
    • Phase 1: Purposeful
    • Phase 2: Concise
    • Phase 3: Conversational
    • Phase 4: Clear
  4. Test and measure
    • Review with team
    • Test with users when possible
    • Measure task completion, comprehension
    • Iterate based on feedback
  1. 理解上下文
    • 用户目标与需求
    • 业务目标
    • 技术限制
    • 用户的情绪状态
  2. 撰写初稿
    • 从对话开始（你会怎么说？）
    • 应用合适的模式
    • 考虑语气语调
    • 重要信息前置
  3. 迭代编辑
    • 阶段1：目标明确
    • 阶段2：简洁凝练
    • 阶段3：口语化表达
    • 阶段4：清晰易懂
  4. 测试与衡量
    • 团队评审
    • 尽可能进行用户测试
    • 衡量任务完成率、理解度
    • 根据反馈迭代

Accessibility in UX Writing

UX写作中的无障碍设计

Writing accessible content ensures all users, including those using assistive technology, can understand and interact with your product.
撰写无障碍内容确保所有用户（包括使用辅助技术的用户）都能理解并与产品交互。

Core Accessibility Principles

核心无障碍设计原则

Screen Reader Optimization
  • Label all interactive elements explicitly ("Submit form" not just "Submit")
  • Write descriptive link text ("Read pricing details" not "Click here")
  • Structure error messages to work with screen readers (error + field label read together)
  • Use ARIA labels when visual context isn't sufficient
Cognitive Accessibility
  • Target 8-14 words per sentence (8 words = 100% comprehension, 14 words = 90%)
  • Break complex information into scannable chunks
  • Use clear headings and logical hierarchy
  • Provide consistent, predictable patterns
Multi-Modal Communication
  • Don't rely on color alone to convey meaning
  • Pair visual indicators with text ("Error: Email required" with red icon)
  • Provide text alternatives for icons and images
  • Ensure sufficient color contrast (WCAG AA minimum: 4.5:1)
Plain Language for All
  • Target 7th-8th grade reading level for general audience
  • Define technical terms when first used
  • Avoid idioms, metaphors, and cultural references
  • Use common, everyday words
屏幕阅读器优化
  • 明确标记所有交互元素（如"Submit form"而非仅"Submit"）
  • 撰写描述性链接文本（如"Read pricing details"而非"Click here"）
  • 结构化错误提示以适配屏幕阅读器（错误信息与字段标签一起朗读）
  • 当视觉上下文不足时使用ARIA标签
认知无障碍
  • 目标句子长度为8-14个词（8个词=100%理解率，14个词=90%理解率）
  • 将复杂信息拆分为易于扫描的小块
  • 使用清晰的标题与逻辑层级
  • 提供一致、可预测的模式
多模态沟通
  • 不单独依赖颜色传递信息
  • 视觉指示器搭配文本（如"Error: Email required"搭配红色图标）
  • 为图标与图片提供文本替代方案
  • 确保足够的颜色对比度（WCAG AA最低标准：4.5:1）
面向所有人的平实语言
  • 面向普通受众的内容目标为7-8年级阅读水平
  • 首次使用技术术语时进行定义
  • 避免习语、隐喻与文化引用
  • 使用常见的日常词汇

Accessible Pattern Examples

无障碍模式示例

Buttons
  • ❌ Poor: "Submit" (context missing for screen readers)
  • ✅ Good: "Submit application"
Links
  • ❌ Poor: "Click here for more information"
  • ✅ Good: "Read our privacy policy"
Error Messages
  • ❌ Poor: Red text showing "Invalid"
  • ✅ Good: "Error: Email must include @" (with error icon)
Form Labels
  • ❌ Poor: Placeholder-only fields
  • ✅ Good: Visible label + optional placeholder
按钮
  • ❌ 不佳："Submit"（屏幕阅读器缺失上下文）
  • ✅ 良好："Submit application"
链接
  • ❌ 不佳："Click here for more information"
  • ✅ 良好："Read our privacy policy"
错误提示
  • ❌ 不佳：仅显示红色文字"Invalid"
  • ✅ 良好："Error: Email must include @"（搭配错误图标）
表单标签
  • ❌ 不佳：仅使用占位符的字段
  • ✅ 良好：可见标签 + 可选占位符

UX Text Benchmarks

UX文案基准指标

Use these research-backed metrics to create effective UX text.
使用这些有研究支持的指标创作有效的UX文案。

Sentence Length Targets

句子长度目标

By Content Type
  • Buttons/CTAs: 2-4 words ideal, 6 word maximum
  • Titles: 3-6 words, 40 characters maximum
  • Error messages: 12-18 words (including solution)
  • Instructions: 20 words maximum, 14 ideal
  • Body copy: 15-20 words per sentence average
  • Notifications: 10-15 words for title + body
Comprehension Rates
  • 8 words or fewer: 100% user comprehension
  • 14 words or fewer: 90% user comprehension
  • 25 words: Maximum before significant comprehension drop
按内容类型划分
  • 按钮/CTA：理想为2-4个词，最多6个词
  • 标题：3-6个词，最多40个字符
  • 错误提示：12-18个词（包含解决方案）
  • 说明文字：最多20个词，理想为14个词
  • 正文：平均每句15-20个词
  • 通知：标题+正文共10-15个词
理解率
  • 8个词或更少：100%用户理解率
  • 14个词或更少：90%用户理解率
  • 25个词：理解率显著下降前的最大值

Character and Line Length

字符与行长度

Optimal Ranges
  • Line length: 40-60 characters for maximum readability
  • Button labels: 15-25 characters
  • Page titles: 30-50 characters
  • Notification titles: 35-45 characters
最优范围
  • 行长度：40-60个字符（可读性最高）
  • 按钮标签：15-25个字符
  • 页面标题：30-50个字符
  • 通知标题：35-45个字符

Reading Level Guidelines

阅读水平指南

By Audience
  • General public: 7th-8th grade (Flesch-Kincaid)
  • Professional tools: 9th-10th grade
  • Technical products: 10th-11th grade
  • Specialized fields: 11th-12th grade (only when necessary)
Testing Tools
  • Hemingway Editor: Highlights complex sentences
  • Readable.com: Provides multiple readability scores
  • Microsoft Word: Built-in Flesch-Kincaid scoring
按受众划分
  • 普通大众：7-8年级（Flesch-Kincaid标准）
  • 专业工具：9-10年级
  • 技术产品：10-11年级
  • 专业领域：11-12年级（仅必要时使用）
测试工具
  • Hemingway Editor：高亮复杂句子
  • Readable.com：提供多种可读性评分
  • Microsoft Word：内置Flesch-Kincaid评分功能

Common Mistakes to Avoid

需避免的常见错误

  • Using passive voice excessively
  • Generic button labels ("Submit", "OK")
  • Blaming users in error messages
  • Overly clever humor in serious contexts
  • Inconsistent terminology
  • Hidden instructions or explanations
  • System-oriented language vs. user language
  • Too many words (not concise enough)
  • Robotic, corporate tone
  • Relying on color alone for meaning
  • Writing inaccessible link text ("Click here")
  • 过度使用被动语态
  • 通用按钮标签（如"Submit"、"OK"）
  • 错误提示中指责用户
  • 在严肃场景中使用过度巧妙的幽默
  • 术语不一致
  • 隐藏的说明或解释
  • 面向系统的语言而非用户语言
  • 文字过多（不够简洁）
  • 机械生硬的企业语调
  • 单独依赖颜色传递信息
  • 撰写无障碍性差的链接文本（如"Click here"）

Quick Reference

快速参考

Sentence case: "Save your changes" (not "Save Your Changes")
Active imperative for buttons: "Delete account" (not "Account deletion")
User-focused: "Save time with shortcuts" (not "We offer shortcuts")
Specific verbs: "Delete" (not "Remove" when permanently deleting)
Front-loaded: "Password must be 8 characters" (not "Must be 8 characters for your password")
句子大小写："Save your changes"（而非"Save Your Changes"）
按钮使用主动祈使句："Delete account"（而非"Account deletion"）
以用户为中心："Save time with shortcuts"（而非"We offer shortcuts"）
具体动词："Delete"（永久删除时而非"Remove"）
重要信息前置："Password must be 8 characters"（而非"Must be 8 characters for your password"）

Style references

风格参考

External references this skill is grounded in (consult these for any case the skill doesn't cover):
  • Modus Style Guide — Trimble's design-system writing rules (the canonical source for Modus-branded products).
  • The Chicago Manual of Style — fallback for grammar, punctuation, and citation questions.
  • The Merriam-Webster Dictionary — fallback for spelling and word choice.
Lista Payroll inherits Prism's writing conventions, which are themselves aligned with Modus. When this skill conflicts with 
lista-ui-conventions
(e.g. "Coming soon" copy), the Lista rule wins.
本技能基于以下外部参考资料（本技能未覆盖的场景可参考这些资料）：
  • Modus Style Guide —— Trimble的设计系统写作规则（Modus品牌产品的权威来源）。
  • The Chicago Manual of Style —— 语法、标点与引用问题的备用参考。
  • The Merriam-Webster Dictionary —— 拼写与用词选择的备用参考。
Lista Payroll继承了Prism的写作规范，而Prism的规范与Modus保持一致。当本技能与
lista-ui-conventions
冲突时（如"Coming soon"文案），以Lista的规则为准。

Resources

资源

This skill includes:
  • references/accessibility-guidelines.md: Comprehensive guide to writing accessible UX text for all users
  • references/voice-chart-template.md: Template for creating a product voice chart
  • references/content-usability-checklist.md: Comprehensive checklist for evaluating UX text quality
  • references/patterns-detailed.md: Extended examples of UX text patterns in different voices
  • examples/real-world-improvements.md: Before/after transformations with detailed analysis and scoring
  • templates/error-message-template.md: Fillable template for writing effective error messages
  • templates/empty-state-template.md: Guide for creating helpful empty states
  • templates/onboarding-flow-template.md: Framework for designing clear onboarding experiences
本技能包含：
  • references/accessibility-guidelines.md：为所有用户撰写无障碍UX文案的全面指南
  • references/voice-chart-template.md：创建产品语气图表的模板
  • references/content-usability-checklist.md：评估UX文案质量的全面清单
  • references/patterns-detailed.md：不同语气下UX文案模式的扩展示例
  • examples/real-world-improvements.md：包含详细分析与评分的前后对比案例
  • templates/error-message-template.md：撰写有效错误提示的可填写模板
  • templates/empty-state-template.md：创建实用空状态的指南
  • templates/onboarding-flow-template.md：设计清晰引导流程的框架