ux-usability-foundations

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

UX Usability Foundations

UX 可用性基础

Purpose

目的

Help an agent make interfaces understandable, usable, forgiving, and aligned with user expectations. Treat usability as product behavior, not surface decoration. The agent should turn unclear or fragile UI into an interface where users can quickly answer: what is this, what can I do here, where am I, what happened, how do I recover, and is this worth the effort?
帮助Agent打造易懂、易用、容错且符合用户预期的界面。将可用性视为产品行为,而非表面装饰。Agent应将模糊或不稳定的UI转化为能让用户快速解答以下问题的界面:这是什么?我在这里能做什么?我当前处于哪里?发生了什么?我该如何恢复?这值得我付出精力吗?

When to use this skill

何时使用此技能

Use this skill when the user asks you to critique, redesign, create, or specify a UI, flow, form, app screen, website, dashboard, onboarding, settings page, checkout, navigation model, state behavior, or component interaction for usability. Use it for affordances/signifiers, feedback, constraints, errors, empty/loading/success states, recognition over recall, task clarity, and frontend behavior.
当用户要求你针对可用性对UI、流程、表单、应用界面、网站、仪表盘、引导流程、设置页面、结账流程、导航模型、状态行为或组件交互进行评审、重新设计、创建或规范时,可使用此技能。适用于affordances/signifiers(功能可见性/指示符)、反馈、约束、错误、空状态/加载状态/成功状态、识别优于回忆、任务清晰度及前端行为等场景。

When not to use this skill

何时不使用此技能

Do not use as the primary skill for deep research operations, brand styling systems, visual polish, typography craft, frontend architecture, or persuasion/growth tactics unless those choices directly affect user understanding, control, or recovery.
除非相关选择直接影响用户的理解、控制或恢复能力,否则请勿将此技能作为深度研究操作、品牌样式系统、视觉打磨、排版工艺、前端架构或说服/增长策略的主要技能。

Core principles

核心原则

  1. Start with goals, not screens. Identify the user’s goal, task, context, and likely knowledge before changing controls or layout. Design requirements describe needs before widgets.
  2. Make the next action obvious. Prefer self-evident interfaces. If the task is inherently novel or complex, make it self-explanatory with structure, labels, examples, and feedback.
  3. Show what is possible. Interactive elements must look interactive. Read-only elements must not look editable. Hidden gestures need visible alternatives.
  4. Match the user’s mental model. Use the concepts, names, and sequence users understand; do not expose database tables, file paths, internal IDs, or arbitrary system states unless users need them.
  5. Favor recognition over recall. Keep needed options, context, examples, and state visible or easy to retrieve.
  6. Reduce work and excise. Remove tasks that serve the system rather than the user’s goal: retyping, transferring data, hunting for controls, configuring obvious defaults, or answering inferable questions.
  7. Guide choices without overloading users. Use progressive disclosure, sensible defaults, grouping, and prioritization.
  8. Give immediate, informative feedback. Every consequential action needs a response that says whether the system received it, what changed, whether waiting is required, and what can happen next.
  9. Prevent errors before explaining them. Use constraints, safe defaults, previews, tolerant input, inline validation, and undo where feasible.
  10. Blame the design, not the user. Errors reveal a mismatch in expectations or an unsupported edge case. Preserve work and guide recovery.
  11. Respect platform and convention. Use familiar patterns when they fit. Break convention only when the user’s goal clearly benefits and the new behavior can be discovered and recovered from.
  12. Accessibility is usability under pressure. Design for perceptibility, operability, simplicity, and forgiveness across varied abilities, devices, literacy, stress, and environments.
See references/principle-cards.md for each principle as a reusable card.
  1. 从目标出发,而非界面。在更改控件或布局前,先明确用户的目标、任务、场景及可能具备的知识。设计需求应先描述需求,再提及组件。
  2. 让下一步操作显而易见。优先选择自明式界面。若任务本身具有新颖性或复杂性,需通过结构、标签、示例和反馈使其具备自解释性。
  3. 展示可行操作。交互元素必须看起来可交互,只读元素不能看起来可编辑。隐藏手势需提供可见替代方案。
  4. 匹配用户心智模型。使用用户理解的概念、名称和操作顺序;除非用户有需求,否则不要暴露数据库表、文件路径、内部ID或任意系统状态。
  5. 优先识别而非回忆。保持所需选项、上下文、示例和状态可见或易于调取。
  6. 减少工作量并剔除冗余。移除服务于系统而非用户目标的任务:重复输入、数据传输、寻找控件、配置明显的默认值或回答可推断的问题。
  7. 引导选择但不过度干扰用户。使用渐进式披露、合理默认值、分组和优先级排序。
  8. 提供即时且有用的反馈。每一个有影响的操作都需要响应,告知用户系统是否已接收、发生了什么变化、是否需要等待以及下一步可执行的操作。
  9. 先预防错误再解释错误。尽可能使用约束、安全默认值、预览、容错输入、内联验证和撤销功能。
  10. 归咎于设计,而非用户。错误暴露了预期不匹配或未被支持的边缘场景。保留用户工作并引导恢复。
  11. 尊重平台与惯例。当熟悉的模式适用时优先使用。只有当用户目标明确受益,且新行为可被发现和恢复时,才打破惯例。
  12. 无障碍设计是压力下的可用性。针对不同能力、设备、读写水平、压力和环境,设计具备可感知性、可操作性、简洁性和容错性的界面。
查看references/principle-cards.md获取可复用的单条原则卡片。

Default recommendations

默认建议

Product goal

产品目标

Default to optimizing the primary user task before secondary business asks. Override only for legal, safety, fraud, privacy, or business-critical requirements. Ask: “Which obligation must interrupt or constrain the primary task, and what is the consequence of hiding or delaying it?”
默认优先优化用户的主要任务,再处理次要业务需求。仅在法律、安全、防欺诈、隐私或业务关键要求下覆盖默认规则。需询问:“哪些义务必须中断或约束主要任务,隐藏或延迟它会有什么后果?”

Audience

受众

Default to motivated but distracted users with average domain knowledge and imperfect memory. Override for trained expert operators using the product frequently under stable conditions. Ask: “Is this primarily for first-time/infrequent users, frequent intermediates, or trained experts?”
默认面向有动机但易分心、具备平均领域知识且记忆不完善的用户。若产品面向频繁使用的训练有素的专家操作员,可覆盖默认规则。需询问:“这主要面向首次/不常使用的用户、频繁使用的中间用户还是训练有素的专家?”

Platform and input

平台与输入方式

Default to platform conventions and support pointer, touch, keyboard, and assistive technology where relevant. Ask when platform/input constraints are unknown.
默认遵循平台惯例,支持指针、触摸、键盘及相关辅助技术。当平台/输入约束未知时需询问。

Information density

信息密度

Default to enough context for recognition and decision-making, while hiding rare advanced controls behind clear entry points. Override for comparison, monitoring, or expert workflows. Ask: “Do users need overview density for monitoring/comparison, or step-by-step focus for completion?”
默认提供足够的上下文以支持识别和决策,同时将罕见的高级控件隐藏在清晰的入口后。若用于对比、监控或专家工作流,可覆盖默认规则。需询问:“用户需要用于监控/对比的概览密度,还是用于完成任务的分步聚焦?”

Navigation

导航

Default to clear location, current object/state, access to major areas, and a visible route back or onward. Override only for intentional guided flows. Ask: “Should users be free to move around, or should this flow intentionally constrain navigation?”
默认提供清晰的位置标识、当前对象/状态、主要区域的访问入口,以及可见的返回或前进路径。仅在有意引导流程时覆盖默认规则。需询问:“用户应自由导航,还是此流程需有意约束导航?”

Labels and language

标签与语言

Default to plain, task-oriented labels from the user’s vocabulary. Ask before using internal, clever, legal, or domain-specific terms.
默认使用用户词汇中的平实、面向任务的标签。使用内部、花哨、法律或领域特定术语前需询问。

Forms

表单

Default to persistent labels, appropriate input types, upfront constraints, inline validation where helpful, preserved data, and a clear primary action. Ask only when density/speed for experts may be more important than first-time clarity.
默认使用持久标签、合适的输入类型、前置约束、有用时的内联验证、保留数据及清晰的主要操作。仅当专家的密度/速度需求优先于首次使用的清晰度时需询问。

Error handling

错误处理

Default to prevention first; if error occurs, explain what happened, why it matters, and how to fix it without losing work. Ask when error details are sensitive, regulated, or security-relevant.
默认优先预防错误;若错误发生,解释发生了什么、为何重要以及如何修复且不丢失工作。当错误细节涉及敏感、受监管或安全相关内容时需询问。

Destructive actions

破坏性操作

Default to visually secondary destructive actions until the final review/confirmation step. Prefer undo for reversible actions; use confirmation for irreversible, costly, legal, or safety actions. Ask about reversibility and harm.
默认将破坏性操作设为视觉次要元素,直至最终确认步骤。可逆操作优先使用撤销功能;不可逆、高成本、涉及法律或安全的操作使用确认机制。需询问操作的可逆性和危害程度。

Feedback and status

反馈与状态

Default to instant receipt feedback, progress for delays, visible completion, and persistent state for long-running or consequential operations. Ask which status changes should interrupt.
默认提供即时的操作接收反馈、延迟操作的进度提示、可见的完成状态,以及长期运行或有影响操作的持久状态。需询问哪些状态变化应中断用户操作。

Accessibility

无障碍设计

Default to WCAG-oriented basics: semantic controls, keyboard operation, focus visibility, programmatic labels, sufficient contrast, no color-only meaning, readable copy, and screen-reader-friendly state updates. Do not override basics.
默认遵循WCAG基础要求:语义化控件、键盘操作、焦点可见性、程序化标签、足够对比度、不依赖颜色传递信息、可读文案、屏幕阅读器友好的状态更新。基础要求不可覆盖。

Required user questions

必问用户问题

Do not ask routine best-practice questions. Ask one focused question only when the answer changes the recommendation:
  • The primary user/task is unclear.
  • The action has safety, financial, legal, privacy, medical, or irreversible consequences.
  • Novices and experts need different behaviors.
  • Platform/input constraints are unknown.
  • Required terminology or compliance copy may apply.
  • The user requests a nonstandard, hidden, or manipulative pattern.
  • There is a real tradeoff between density and clarity or between guided flow and free navigation.
Use this pattern:
js
question({
  question: "What is the primary task this interface must help users complete?",
  recommended_default: "Optimize for the most common successful task first, then make secondary actions available but visually quieter.",
  options: [
    "Complete one focused task",
    "Compare or monitor multiple items",
    "Explore and choose among options",
    "Other / custom"
  ]
})
Use the question-tool-ready prompts in references/decision-prompts.md for the full decision set.
请勿询问常规最佳实践问题。仅当答案会改变建议时,提出一个聚焦的问题:
  • 主要用户/任务不明确。
  • 操作涉及安全、财务、法律、隐私、医疗或不可逆后果。
  • 新手和专家需要不同的行为模式。
  • 平台/输入约束未知。
  • 可能适用特定术语或合规文案。
  • 用户要求非标准、隐藏或操纵性模式。
  • 密度与清晰度、引导流程与自由导航之间存在实际权衡。
使用以下模式:
js
question({
  question: "What is the primary task this interface must help users complete?",
  recommended_default: "Optimize for the most common successful task first, then make secondary actions available but visually quieter.",
  options: [
    "Complete one focused task",
    "Compare or monitor multiple items",
    "Explore and choose among options",
    "Other / custom"
  ]
})
查看references/decision-prompts.md中的问题工具就绪提示,获取完整决策集。

Workflow for critiquing an existing UI

现有UI评审工作流

Inspect in this order:
  1. User goal and task fit.
  2. First-glance comprehension.
  3. Orientation: current place, object, state, and path onward/back.
  4. Action discoverability.
  5. Choice quality and priority.
  6. Labels and language.
  7. Feedback and status.
  8. Error prevention and recovery.
  9. Recognition versus memory burden.
  10. Accessibility and input coverage.
  11. Frontend feasibility and edge states.
  12. Prioritization by task impact, frequency, severity, and fix effort.
Report critique as: highest-impact usability issues, quick wins, behavior/spec details, accessibility notes, and risks/tradeoffs.
按以下顺序检查:
  1. 用户目标与任务适配性。
  2. 第一眼理解度。
  3. 定位:当前位置、对象、状态及前进/返回路径。
  4. 操作可发现性。
  5. 选择质量与优先级。
  6. 标签与语言。
  7. 反馈与状态。
  8. 错误预防与恢复。
  9. 识别与记忆负担对比。
  10. 无障碍设计与输入方式覆盖。
  11. 前端可行性与边缘状态。
  12. 按任务影响、频率、严重性及修复工作量排序优先级。
评审报告应包含:最高影响的可用性问题、快速优化点、行为/规范细节、无障碍设计说明及风险/权衡。

Workflow for creating or improving an interface

创建或优化界面的工作流

  1. Clarify the user, goal, success condition, and risk.
  2. Choose the simplest useful flow.
  3. Map user concepts and vocabulary.
  4. Create visible structure and action hierarchy.
  5. Select standard patterns unless a task reason justifies custom behavior.
  6. Design default, hover, focus, active, loading, success, empty, validation, error, offline, disabled, and permission states.
  7. Add constraints, validation, and recovery.
  8. Support first use and repeated use.
  9. Verify accessibility.
  10. Explain decisions in terms of task progress, cognitive load, expectations, and risk.
  1. 明确用户、目标、成功条件及风险。
  2. 选择最简单的有效流程。
  3. 映射用户概念与词汇。
  4. 创建可见结构与操作层级。
  5. 选择标准模式,除非有任务理由证明自定义行为合理。
  6. 设计默认、悬停、聚焦、激活、加载、成功、空、验证、错误、离线、禁用及权限状态。
  7. 添加约束、验证与恢复机制。
  8. 支持首次使用与重复使用。
  9. 验证无障碍设计。
  10. 从任务进度、认知负荷、预期及风险角度解释决策。

Decision framework

决策框架

Ask yourself:
  1. Is the problem comprehension, choice, control, feedback, navigation, or recovery?
  2. Can the design prevent the problem rather than explain it?
  3. Can the interface use recognition instead of recall?
  4. Can a standard pattern solve this without new learning?
  5. Which elements are primary, secondary, tertiary, or dangerous?
  6. Does the user need more information, fewer choices, or a better sequence?
  7. Will the user notice the state change?
  8. What happens if the user is distracted, rushed, using touch, using keyboard, using assistive tech, or recovering from an error?
  9. What is reversible, costly, or irreversible?
  10. Is this serving the user’s task or the system’s convenience?
自问:
  1. 问题是关于理解、选择、控制、反馈、导航还是恢复?
  2. 设计能否预防问题而非解释问题?
  3. 界面能否使用识别而非回忆?
  4. 标准模式能否解决问题而无需用户学习新内容?
  5. 哪些元素是主要、次要、 tertiary(三级)或危险的?
  6. 用户需要更多信息、更少选择还是更优顺序?
  7. 用户会注意到状态变化吗?
  8. 若用户分心、匆忙、使用触摸、键盘、辅助技术或从错误中恢复,会发生什么?
  9. 哪些操作是可逆、高成本或不可逆的?
  10. 这是服务于用户任务还是系统便利?

Practical rules

实用规则

Obviousness and scanning

直观性与扫视体验

  • Make each screen’s purpose visible in its heading, structure, and primary action.
  • Use descriptive buttons: “Send invoice,” “Save changes,” or “Book appointment,” not “Submit.”
  • Make click/tap targets look like controls without relying on hover.
  • Use headings, grouping, whitespace, and lists so users can scan.
  • Remove copy and decorative elements that compete with the task.
  • 通过标题、结构和主要操作明确每个界面的用途。
  • 使用描述性按钮:“发送发票”“保存更改”“预约”,而非“提交”。
  • 点击/触摸目标需看起来像控件,不依赖悬停效果。
  • 使用标题、分组、留白和列表让用户可快速扫视。
  • 移除与任务竞争的文案和装饰元素。

Affordances, signifiers, and controls

Affordances、指示符与控件

  • Use native controls when behavior fits.
  • Use icons with labels for unfamiliar or consequential actions.
  • Preserve distinctions between links, buttons, selected items, disabled items, editable fields, and static text.
  • Do not hide essential actions behind gestures, long press, hover, or tiny overflow menus unless visible alternatives exist.
  • 当行为匹配时使用原生控件。
  • 不熟悉或有影响的操作使用图标加标签。
  • 保留链接、按钮、选中项、禁用项、可编辑字段和静态文本之间的区别。
  • 除非有可见替代方案,否则不要将必要操作隐藏在手势、长按、悬停或小型溢出菜单后。

Choices and progressive disclosure

选择与渐进式披露

  • Limit initial choices to the current decision.
  • Use safe, likely defaults.
  • Reveal advanced options near the point of need.
  • Use comparison structures when users must choose among similar plans, products, records, or settings.
  • 初始选择仅限制于当前决策。
  • 使用安全、合理的默认值。
  • 在需求点附近展示高级选项。
  • 当用户必须在相似计划、产品、记录或设置中选择时,使用对比结构。

Feedback and state

反馈与状态

  • Give immediate micro-feedback for command receipt.
  • Show progress for delays and async operations.
  • Confirm completion when the result is not visible.
  • Make current selection, current page, current filter, unsaved changes, and offline/sync status visible.
  • Avoid noisy feedback for routine non-events.
  • 对命令接收提供即时微反馈。
  • 展示延迟和异步操作的进度。
  • 当结果不可见时确认完成。
  • 显示当前选择、当前页面、当前筛选条件、未保存更改及离线/同步状态。
  • 避免对常规无事件发送嘈杂反馈。

Errors and recovery

错误与恢复

  • Validate constraints before submission when feasible.
  • Keep invalid user input visible and editable.
  • Place errors next to affected controls and summarize long-form errors.
  • Use undo for reversible actions and confirmation for irreversible or high-risk actions.
  • Never make users start over after a recoverable problem.
  • 可行时在提交前验证约束。
  • 保留无效用户输入并使其可编辑。
  • 将错误放在受影响控件旁边,汇总长篇错误信息。
  • 可逆操作使用撤销,不可逆或高风险操作使用确认。
  • 出现可恢复问题时,绝不让用户从头开始。

Navigation and orientation

导航与定位

  • Show current section, object, state, and available next/back paths.
  • Use breadcrumbs for deep hierarchy, not as a substitute for clear navigation.
  • Use tabs only for peer sections of the same context.
  • Use drawers/menus for infrequent or space-constrained actions; avoid hiding frequently needed primary navigation.
  • Preserve route, filters, and scroll position when users return from detail to list.
  • 显示当前章节、对象、状态及可用的前进/返回路径。
  • 面包屑用于深层层级,而非替代清晰导航。
  • 标签仅用于同一上下文的同级章节。
  • 抽屉/菜单用于不频繁或空间受限的操作;避免隐藏频繁使用的主要导航。
  • 用户从详情页返回列表时,保留路径、筛选条件和滚动位置。

Learnability

可学习性

  • Make first-run help temporary and task-focused.
  • Prefer inline examples and empty-state guidance over separate help documents.
  • Let repeated successful use reduce beginner guidance.
  • Design for “perpetual intermediates”: users know the basics but do not remember everything.
  • 首次运行帮助需临时且面向任务。
  • 优先使用内联示例和空状态引导,而非单独的帮助文档。
  • 让重复成功使用减少新手引导。
  • 为“永久中间用户”设计:用户了解基础但不记得所有细节。

Accessibility and inclusion requirements

无障碍与包容性要求

  • Use semantic HTML and native elements before custom widgets.
  • Ensure all interactive elements have accessible names.
  • Keep focus order aligned with visual/task order.
  • Provide visible focus indicators.
  • Support keyboard operation for all actions.
  • Associate labels, hints, and errors with form controls.
  • Do not rely on placeholder text as the only label.
  • Do not rely on color alone.
  • Announce async status and errors appropriately.
  • Ensure dialogs trap focus while open and restore focus when closed.
  • Respect reduced motion.
  • Make target sizes suitable for touch and motor variability.
  • Write at the simplest level compatible with the task and domain.
  • 优先使用语义化HTML和原生元素,再考虑自定义组件。
  • 确保所有交互元素有可访问名称。
  • 聚焦顺序与视觉/任务顺序一致。
  • 提供可见的聚焦指示器。
  • 支持所有操作的键盘操作。
  • 将标签、提示和错误与表单控件关联。
  • 不依赖占位文本作为唯一标签。
  • 不单独依赖颜色传递信息。
  • 适当通知异步状态和错误。
  • 对话框打开时捕获焦点,关闭时恢复焦点。
  • 尊重减少动画的设置。
  • 目标尺寸适合触摸和运动能力差异。
  • 文案采用与任务和领域兼容的最简级别。

Frontend implementation guidance

前端实现指南

Semantic structure

语义化结构

  • Use
    <button>
    for actions and
    <a>
    for navigation.
  • Use persistent programmatic labels for inputs.
  • Use fieldsets/legends for related radio/checkbox groups.
  • Use headings in logical order.
  • Use tables for tabular data, not layout.
  • 操作使用
    <button>
    ,导航使用
    <a>
  • 输入框使用持久化程序化标签。
  • 相关单选/复选框组使用fieldsets/legends。
  • 按逻辑顺序使用标题。
  • 表格用于表格数据,而非布局。

State and feedback

状态与反馈

  • Include default, hover, focus-visible, active, selected, expanded/collapsed, disabled, loading, success, warning, error, empty, offline, and read-only states where relevant.
  • Use
    aria-expanded
    ,
    aria-controls
    ,
    aria-selected
    ,
    aria-current
    ,
    aria-invalid
    ,
    aria-describedby
    , and live regions as needed.
  • Disable controls only when the reason is obvious or explained; otherwise allow the action and guide the user.
  • Prevent duplicate submissions with pending state and idempotent server handling.
  • 包含默认、悬停、focus-visible、激活、选中、展开/折叠、禁用、加载、成功、警告、错误、空、离线和只读状态(如适用)。
  • 根据需要使用
    aria-expanded
    aria-controls
    aria-selected
    aria-current
    aria-invalid
    aria-describedby
    和实时区域。
  • 仅当原因明显或已解释时禁用控件;否则允许操作并引导用户。
  • 使用待处理状态和幂等服务器处理防止重复提交。

Forms

表单

  • Use
    type
    ,
    autocomplete
    ,
    inputmode
    ,
    min
    ,
    max
    ,
    step
    , and constraints appropriately.
  • Keep input flexible when users may enter equivalent formats.
  • Validate on blur or submit for complex fields; validate on input only when stable and helpful.
  • Preserve entries across errors, refreshes, authentication interruptions, and network failures whenever possible.
  • 适当使用
    type
    autocomplete
    inputmode
    min
    max
    step
    和约束。
  • 用户可能输入等效格式时,保持输入灵活性。
  • 复杂字段在失焦或提交时验证;仅当稳定且有用时在输入时验证。
  • 尽可能保留错误、刷新、身份验证中断和网络故障时的输入内容。

Responsive and input behavior

响应式与输入行为

  • Do not assume hover.
  • Keep primary actions reachable without hiding context on small screens.
  • Ensure text can zoom/reflow without loss of function.
  • Test with keyboard only, screen reader basics, touch, narrow viewport, slow network, and high zoom.
  • 不假设悬停效果可用。
  • 小屏幕上保持主要操作可访问,不隐藏上下文。
  • 文本可缩放/重排且不丢失功能。
  • 仅使用键盘、基础屏幕阅读器、触摸、窄视口、慢速网络和高缩放比例进行测试。

Quality checklist

质量检查表

  • The primary user goal is stated.
  • The screen’s purpose is clear at a glance.
  • The primary action is stronger than secondary actions.
  • Labels use user language.
  • Interactive elements are discoverable without hover.
  • Required choices are minimized and grouped.
  • The interface provides status feedback after consequential actions.
  • Errors are prevented where possible and recoverable where not.
  • Destructive actions are reversible or clearly confirmed.
  • Users do not lose work due to validation, auth, network, or navigation issues.
  • Navigation answers “where am I?” and “where can I go?”
  • Accessibility fundamentals are included.
  • Frontend behavior is implementable.
Use the full checklists in references/checklists.md.
  • 明确主要用户目标。
  • 界面用途一目了然。
  • 主要操作比次要操作更突出。
  • 标签使用用户语言。
  • 交互元素无需悬停即可发现。
  • 必要选择已最小化并分组。
  • 有影响的操作后界面提供状态反馈。
  • 尽可能预防错误,无法预防时可恢复。
  • 破坏性操作可逆或有明确确认。
  • 用户不会因验证、认证、网络或导航问题丢失工作。
  • 导航可解答“我在哪里?”和“我能去哪里?”。
  • 包含无障碍设计基础内容。
  • 前端行为可实现。
查看references/checklists.md获取完整检查表。

Common mistakes to avoid

需避免的常见错误

  • Starting with app chrome before the task.
  • Treating “easy to use” as a checklist item.
  • Hiding primary actions behind menus, gestures, or icons.
  • Using clever labels where obvious labels would work.
  • Making all actions equally important.
  • Asking users questions the system can infer safely.
  • Forcing users to remember hidden instructions or state.
  • Replacing undo with constant confirmations.
  • Blaming the user in error copy.
  • Using disabled controls without explanation.
  • Relying on color alone.
  • Designing custom controls without keyboard and assistive-tech behavior.
  • Treating accessibility as a final audit.
  • Confusing visual simplicity with reduced task complexity.
See references/anti-patterns.md for the full anti-pattern list.
  • Ignoring empty, loading, offline, validation, permission, and edge states.
  • 先设计应用框架再考虑任务。
  • 将“易用”视为 checklist 项。
  • 将主要操作隐藏在菜单、手势或图标后。
  • 在可用清晰标签时使用花哨标签。
  • 让所有操作同等重要。
  • 询问系统可安全推断的问题。
  • 强迫用户记住隐藏的说明或状态。
  • 用持续确认替代撤销功能。
  • 错误文案归咎于用户。
  • 使用无解释的禁用控件。
  • 单独依赖颜色。
  • 设计无键盘和辅助技术支持的自定义控件。
  • 将无障碍设计视为最终审计项。
  • 将视觉简洁与任务复杂度降低混淆。
查看references/anti-patterns.md获取完整反模式列表。
  • 忽略空状态、加载状态、离线状态、验证状态、权限状态和边缘状态。

How to explain recommendations to the user

如何向用户解释建议

Use this pattern:
markdown
I recommend [change] because users are likely trying to [goal]. The current version makes them [think/remember/guess/recover] unnecessarily. This change makes [action/state/recovery] visible and reduces [specific risk or effort]. The main tradeoff is [cost], which is acceptable unless [context that would change the decision].
When disagreeing with a requested pattern:
markdown
I would not hide this behind an icon-only menu because it is the primary path for the task. A better default is a visible labeled action. Use the menu only for secondary or infrequent actions.
使用以下模式:
markdown
I recommend [change] because users are likely trying to [goal]. The current version makes them [think/remember/guess/recover] unnecessarily. This change makes [action/state/recovery] visible and reduces [specific risk or effort]. The main tradeoff is [cost], which is acceptable unless [context that would change the decision].
当不同意用户要求的模式时:
markdown
I would not hide this behind an icon-only menu because it is the primary path for the task. A better default is a visible labeled action. Use the menu only for secondary or infrequent actions.