Back to Details

grain

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

grain

grain

A UX execution and review skill. Work with the grain of how people actually think, read, and recover — not against it.
一项UX执行与评审技能。遵循用户真实的思考、阅读和恢复逻辑，而非与之相悖。

Setup

设置

When this skill is active, treat every user-facing decision as UX. Use 
grain
as a judgment layer on top of the product's existing design contract, not as a replacement for local conventions.
Before coding or reviewing, inspect the relevant product context when available: design docs, existing components, design system, i18n/locale structure, accessibility patterns, and nearby flows. Follow them unless they violate the Core laws; if they do, make the smallest corrective change and name the conflict.
Do not invent rules. If a situation is not covered here, prefer the smallest change that satisfies the laws, and say so.
当启用该技能时，将所有面向用户的决策视为UX问题。将
grain
作为产品现有设计规范之上的判断层，而非替代本地约定。
在编码或评审前，若有相关产品上下文，请先查阅：设计文档、现有组件、设计系统、i18n/本地化结构、无障碍设计模式以及相关流程。除非它们违反核心法则，否则需遵循这些规范；若存在冲突，请做出最小的修正并说明冲突点。
请勿自创规则。如果遇到未涵盖的情况，优先选择符合核心法则的最小改动，并加以说明。

Activation and scope

激活范围

Use this skill actively when the work changes what a user sees, reads, clicks, decides, trusts, grants, pays for, recovers from, or loses.
Stay quiet for backend-only logic, infrastructure, internal refactors, tests, data plumbing, or tooling unless they change user-visible behavior, latency, permissions, recovery, trust, or data loss risk.
当工作内容涉及用户可见的变化（如用户看到的内容、阅读的文案、点击的按钮、做出的决策、信任的内容、授予的权限、支付的费用、恢复的操作或丢失的内容）时，请主动使用该技能。
仅涉及后端逻辑、基础设施、内部重构、测试、数据管道或工具的工作，且未改变用户可见行为、延迟、权限、恢复流程、信任度或数据丢失风险时，请保持静默。

Before answering

作答前需明确

Identify these before implementation, review, or critique. Expose them in the answer only when useful:
  • The user or role being served.
  • The current primary decision and the next action the interface should make obvious.
  • The visible value before the interface asks for signup, payment, permission, private data, or effort.
  • The happy path, failure path, empty/loading/partial states, and recovery path.
  • The rule, policy, or business constraint creating UX cost.
  • Whether the primary task still works with keyboard, touch, narrow viewport, and reduced motion.
  • The existing project contract: design docs, component library, route patterns, product voice, and i18n structure.
在实施、评审或提出意见前，先明确以下内容。仅在有用时在答案中披露：
  • 服务的用户或角色。
  • 当前的核心决策，以及界面需明确引导的下一步操作。
  • 在要求用户注册、付费、授权、提供隐私数据或付出精力前，展示可见价值。
  • 顺畅路径、失败路径、空/加载/部分状态，以及恢复路径。
  • 产生UX成本的规则、政策或业务约束。
  • 核心任务是否仍支持键盘操作、触摸操作、窄视口和减少动画模式。
  • 现有项目约定：设计文档、组件库、路由模式、产品语气和i18n结构。

Reference routing

参考文档路由

Open the smallest set of references needed. When several domains match, start with the highest-stakes consequence: trust and recovery before polish, input before copy, flow before visual density.
TriggerOpen firstAlso open when
Navigation, page hierarchy, multi-step flows, dashboards, onboarding path, entry/exit
references/flow-and-ia.md
Add cognitive load for dense decision surfaces.
Dense screens, settings, defaults, choices, progressive disclosure
references/cognitive-load.md
Add flow when location or sequence is unclear.
Forms, search, filters, uploads, imports, validation, onboarding questions
references/forms-and-input.md
Add errors for failure states; add trust for imports, bulk edits, or sensitive data.
Keyboard, focus, labels, touch, contrast, motion, responsive layout, localization assumptions
references/accessibility-and-inclusion.md
Use for any UI implementation that changes interaction behavior.
Sharing, publishing, billing, privacy, permissions, notifications, AI output, automation, destructive actions, account settings
references/trust-and-agency.md
Add errors for recovery; add microcopy for consent, billing, or permission text.
Empty, loading, failed, partial, offline, permission-denied, validation, conflict, retry
references/errors-and-recovery.md
Add forms when input is involved; add trust for destructive or external impact.
Buttons, labels, error copy, empty-state copy, onboarding copy, banners, toasts, legal microcopy
references/microcopy-and-tone.md
Add trust for cost, consent, privacy, billing, AI, or permissions.
Use Core laws only when the change is tiny and no domain-specific rule would alter the decision. For forms, imports, AI, automation, sharing, billing, permissions, or destructive actions, open the relevant reference before answering.
仅打开所需的最小范围参考文档。当多个领域匹配时，优先从高风险后果开始：信任与恢复优先于细节打磨，输入相关优先于文案，流程优先于视觉密度。
触发场景优先打开额外打开场景
导航、页面层级、多步骤流程、仪表盘、新手引导路径、进入/退出流程
references/flow-and-ia.md
处理高密度决策界面时，需考虑认知负荷。
高密度界面、设置、默认值、选项、渐进式披露
references/cognitive-load.md
当位置或顺序不清晰时，需结合流程相关内容。
表单、搜索、筛选、上传、导入、验证、新手引导问题
references/forms-and-input.md
涉及失败状态时需结合错误处理；涉及导入、批量编辑或敏感数据时需结合信任相关内容。
键盘操作、焦点、标签、触摸操作、对比度、动画、响应式布局、本地化假设
references/accessibility-and-inclusion.md
任何改变交互行为的UI实现均需参考。
分享、发布、计费、隐私、权限、通知、AI输出、自动化、破坏性操作、账户设置
references/trust-and-agency.md
涉及恢复时需结合错误处理；涉及授权、计费或权限文案时需结合微文案内容。
空状态、加载状态、失败状态、部分加载、离线、权限拒绝、验证、冲突、重试
references/errors-and-recovery.md
涉及输入时需结合表单内容；涉及破坏性或外部影响时需结合信任相关内容。
按钮、标签、错误文案、空状态文案、新手引导文案、横幅、提示框、法律微文案
references/microcopy-and-tone.md
涉及成本、授权、隐私、计费、AI或权限时需结合信任相关内容。
仅当改动极小且无特定领域规则会影响决策时，才直接应用核心法则。对于表单、导入、AI、自动化、分享、计费、权限或破坏性操作，请在作答前打开相关参考文档。

Output contracts

输出规范

Respect the user's requested format when explicit. Otherwise:
  • Reviews and audits: lead with findings, ordered by severity. Each finding should name the issue, violated law or anti-pattern, user impact, smallest fix, and verification needed. If there are no findings, say so and note residual risk or untested states.
  • Implementation work: state the UX behavior being targeted, make the smallest project-consistent change, preserve existing components and voice, and avoid broad redesign. In the final answer, report changed behavior, covered states, validation, and any remaining risk.
  • Copy work: show the before/after when useful, explain the decision in terms of user action or trust, preserve product tone, and route new strings through the existing locale/i18n structure when one exists.
  • Design plans: name the user, primary decision, next action, required states, accessibility checks, and the smallest buildable slice.
若用户明确要求格式，请遵循该格式。否则：
  • 评审与审计： 先列出发现的问题，按严重性排序。每个问题需说明问题点、违反的法则或反模式、对用户的影响、最小修复方案以及所需验证。若无问题，需明确说明并指出残留风险或未测试状态。
  • 实施工作： 明确目标UX行为，做出符合项目约定的最小改动，保留现有组件和语气，避免大范围重设计。最终答案需汇报改动后的行为、覆盖的状态、验证情况以及剩余风险。
  • 文案工作： 必要时展示修改前后的内容，从用户操作或信任角度解释决策，保留产品语气，若存在现有本地化/i18n结构，需将新文案纳入该结构。
  • 设计方案： 明确目标用户、核心决策、下一步操作、所需状态、无障碍检查项以及最小可实现版本。

Verification

验证

For implemented UI changes, verify the states that changed where practical:
  • Keyboard path, focus order, focus trap/restore, and visible focus.
  • Narrow viewport and touch path; no hover-only or pointer-only primary task.
  • Reduced motion or motion-off behavior when animation carries state.
  • Empty, loading, failed, disabled, permission-denied, undo/retry, and success states.
  • Copy length in supported locales, especially buttons, tabs, table cells, and constrained containers.
If runtime verification is not possible, say which checks remain unverified.
对于已实现的UI改动，尽可能验证所有变动的状态：
  • 键盘操作路径、焦点顺序、焦点陷阱/恢复以及可见焦点。
  • 窄视口和触摸操作路径；核心任务不得仅依赖 hover 或指针操作。
  • 当动画承载状态时，需验证减少动画或关闭动画的行为。
  • 空状态、加载状态、失败状态、禁用状态、权限拒绝状态、撤销/重试状态以及成功状态。
  • 支持语言环境下的文案长度，尤其是按钮、标签页、表格单元格和受限容器中的文案。
若无法进行运行时验证，请说明哪些检查项未完成。

Core laws

核心法则

These cut across every domain. Apply them in order — earlier laws beat later ones when they conflict.
  1. Make the next action obvious. A user should never have to ask "what do I do now?"
  2. Simplify the rule before the screen. A complex policy, pricing rule, eligibility rule, or workflow will feel complex no matter how polished the UI is.
  3. Reduce decisions before reducing clicks. One extra click on a clear path beats one fewer click on a confusing one.
  4. Show state, not just controls. The user must know what the system is doing, what it just did, and what will happen if they act.
  5. Show value before asking for effort. Before signup, permission, payment, sensitive input, or a long form, make the benefit and consequence visible.
  6. Usable means accessible. A flow that depends on perfect vision, a mouse, hover, motion, a large screen, or a fast network is unfinished.
  7. Preserve user effort. Input, choices, progress, drafts, and context must survive errors, navigation, refresh, and retry.
  8. Let users undo, not just confirm. Confirmation dialogs train users to ignore them. Reversibility is the real safety net.
  9. Words are UI. Read them aloud. If a label, error, or instruction sounds awkward spoken, it is wrong. Rewrite.
  10. Match the user's model, not the system's. Name things after what the user is trying to do, not after the table, endpoint, or class.
  11. Defaults are decisions. Whatever is pre-selected, pre-filled, or pre-checked, you are choosing for the majority of users. Choose deliberately.
  12. Do not surprise the user. Sharing, deletion, billing, permissions, AI output, and automation must expose consequences before action.
  13. Edges are the product. Empty, loading, failed, partial, offline, permission-denied, and conflict states are first-class screens.
  14. Consistency over cleverness. A novel pattern must earn its place by being demonstrably better; otherwise, match what the rest of the product does.
  15. Respect the user's attention. Every interruption — modal, toast, badge, sound, vibration — is a withdrawal from a finite budget.
这些法则适用于所有领域。按顺序应用——当法则冲突时，优先遵循靠前的法则。
  1. 让下一步操作清晰可见。 用户永远无需问“我现在该做什么？”
  2. 先简化规则，再优化界面。 复杂的政策、定价规则、资格规则或工作流程，无论UI打磨得多么精致，都会让用户觉得复杂。
  3. 先减少决策，再减少点击。 清晰路径上的多一次点击，好过模糊路径上的少一次点击。
  4. 展示状态，而非仅展示控件。 用户必须知道系统正在做什么、刚刚做了什么，以及操作后会发生什么。
  5. 先展示价值，再要求付出。 在要求用户注册、授权、付费、提供敏感信息或填写长表单前，需明确展示收益和后果。
  6. 可用即意味着无障碍。 依赖完美视力、鼠标、hover、动画、大屏或高速网络的流程，均属于未完成状态。
  7. 保留用户的付出。 用户的输入、选择、进度、草稿和上下文，必须在错误、导航、刷新和重试后仍保留。
  8. 让用户可撤销，而非仅确认。 确认对话框会让用户养成忽视的习惯。可撤销性才是真正的安全保障。
  9. 文字即UI。请大声朗读。 如果标签、错误提示或说明读起来生硬别扭，那它就是错误的，需要重写。
  10. 匹配用户认知模型，而非系统模型。 按用户想要完成的任务命名，而非按数据表、接口或类命名。
  11. 默认值即决策。 任何预先选择、预先填充或预先勾选的内容，都是在为大多数用户做选择。请谨慎选择。
  12. 不要让用户意外。 分享、删除、计费、权限、AI输出和自动化操作，必须在用户操作前披露后果。
  13. 边缘状态即产品本身。 空状态、加载状态、失败状态、部分加载、离线、权限拒绝和冲突状态，都是一等一的界面。
  14. 一致性优先于新颖性。 新颖模式必须被证明明显更优才能使用；否则，需与产品其他部分保持一致。
  15. 尊重用户注意力。 每一次干扰——模态框、提示框、徽章、声音、震动——都是在消耗用户有限的注意力预算。

Domains

细分领域

User flow & information architecture

用户流程与信息架构

Design the path before the page. A flow is a sequence of decisions; the screen exists to support one decision at a time.
  • One primary action per screen. Secondary actions are visually quieter, not just smaller.
  • Simplify the policy or eligibility rule before explaining a complicated path.
  • Group by the user's task, not by the data model. "Things I own" is a task; "Resources" is a table name.
  • Surface the next step inside the current context — do not send users back to a hub to continue.
  • Never hide a required step behind a non-obvious affordance (icon-only buttons, hover-only menus, gestures without hints).
  • Depth costs more than breadth. A flat 7-item menu beats a 3-level tree of 3 each.
  • Entry and exit points must be symmetric: every flow has a clear way out that does not destroy work.
Full reference: 
references/flow-and-ia.md
先设计路径，再设计页面。流程是一系列决策的序列；界面的存在是为了支持用户一次做出一个决策。
  • 每个界面只有一个核心操作。次要操作在视觉上需更低调，而非仅仅缩小尺寸。
  • 在解释复杂路径前，先简化政策或资格规则。
  • 按用户任务分组，而非按数据模型分组。“我拥有的内容”是任务；“资源”是数据表名称。
  • 在当前上下文内展示下一步操作——不要让用户返回中心页面继续流程。
  • 永远不要将必要步骤隐藏在不明显的交互元素后（纯图标按钮、仅hover可见的菜单、无提示的手势）。
  • 深度比广度成本更高。一个包含7项内容的扁平菜单，好过3层每层3项的树形菜单。
  • 进入和退出点必须对称：每个流程都有清晰的退出方式，且不会破坏用户工作。
完整参考：
references/flow-and-ia.md

Cognitive load & simplicity

认知负荷与简洁性

"Simple" does not mean "few features." It means "few decisions per moment." Hide complexity in time and space, not under the rug.
  • Show only what the user needs to make the current decision. Move the rest behind progressive disclosure.
  • Make every question easy to answer: split hard questions, recommend safe defaults, and retrieve known data.
  • Chunk long forms into stages with visible progress. Each stage should be answerable in under 30 seconds.
  • Prefer recognition over recall — show options instead of asking users to remember them.
  • Reuse the same control for the same idea everywhere in the product. A "Save" button must always save and never sometimes-submit.
  • Number of choices is more taxing than length of text. Cutting two options helps more than cutting two sentences.
  • Defaults handle the 80% case. Settings handle the 20%. Never make the 80% configure to get the obvious behavior.
Full reference: 
references/cognitive-load.md
“简洁”并不意味着“功能少”，而是意味着“每一刻的决策少”。将复杂性按时间和空间隐藏，而非掩盖。
  • 仅展示用户当前决策所需的内容。其余内容通过渐进式披露隐藏。
  • 让每个问题易于回答：拆分难题、推荐安全默认值、调取已知数据。
  • 将长表单拆分为多个阶段，并展示进度。每个阶段的回答时间应控制在30秒以内。
  • 优先选择识别而非回忆——展示选项，而非让用户记忆。
  • 同一概念在产品各处使用相同控件。“保存”按钮必须始终用于保存，而非有时用于提交。
  • 选项数量比文本长度更消耗精力。减少两个选项比减少两句话更有效。
  • 默认值处理80%的场景。设置处理20%的场景。永远不要让80%的用户需要配置才能获得明显的行为。
完整参考：
references/cognitive-load.md

Forms & input

表单与输入

Input is work. Every field asks the user to spend attention, memory, trust, or private information.
  • Ask only what is needed for the next decision or outcome.
  • Show why the input is worth giving before asking for sensitive, private, or high-effort data.
  • Order fields by the user's reasoning, not by database shape.
  • Mark required, optional, and format rules before failure.
  • Match control type to data: choose, autocomplete, mask, upload, or free text deliberately.
  • Preserve input across errors, navigation, refresh, and network failure.
  • Preview imports and bulk changes before mutating durable data.
Full reference: 
references/forms-and-input.md
输入是用户的付出。每个字段都要求用户投入注意力、记忆、信任或隐私信息。
  • 仅询问完成下一步决策或结果所需的信息。
  • 在要求用户提供敏感、隐私或高付出的数据前，先展示该输入的价值。
  • 按用户的思考顺序排列字段，而非按数据库结构排列。
  • 在失败前标记必填、可选和格式规则。
  • 根据数据类型选择控件：选择器、自动补全、掩码、上传或自由文本需谨慎选择。
  • 在错误、导航、刷新和网络故障后保留用户输入。
  • 在修改持久数据前，预览导入和批量更改的内容。
完整参考：
references/forms-and-input.md

Accessibility & inclusive interaction

无障碍与包容性交互

Accessibility is not a mode. A screen that works only with a mouse, perfect vision, a large display, or a quiet room is unfinished.
  • Every primary task must have a keyboard path.
  • Focus order follows decision order; focus indicators remain visible.
  • Controls need persistent labels or accessible names.
  • Color, motion, hover, and sound cannot carry meaning alone.
  • Touch targets must forgive real fingers, especially near destructive actions.
  • Responsive design means the task survives the viewport change.
Full reference: 
references/accessibility-and-inclusion.md
无障碍不是一种模式。仅能通过鼠标、完美视力、大屏或安静环境使用的界面，属于未完成状态。
  • 每个核心任务必须有键盘操作路径。
  • 焦点顺序遵循决策顺序；焦点指示器需保持可见。
  • 控件需要持久标签或无障碍名称。
  • 颜色、动画、hover和声音不能单独承载含义。
  • 触摸目标需适配真实手指操作，尤其是破坏性操作附近的区域。
  • 响应式设计意味着任务在视口变化后仍可完成。
完整参考：
references/accessibility-and-inclusion.md

Trust, consent & agency

信任、授权与自主性

Users should never wonder, "Wait, did it just send, charge, delete, share, publish, or automate that?"
  • Consent must be specific, timely, separable, and revocable where possible.
  • Preview before external impact: send, publish, share, import, sync, or bulk edit.
  • Automation must show pending, running, completed, failed, skipped, and cancelled states.
  • AI output is a draft until the user accepts it.
  • Billing, permissions, and privacy copy must expose real consequences.
  • Cost, limits, and trade-offs must be visible before conversion pressure appears.
  • Durable or shared actions need history: who or what changed what, and when.
Full reference: 
references/trust-and-agency.md
用户永远不应疑惑：“等等，它刚才是不是发送、扣费、删除、分享、发布或自动执行了那个操作？”
  • 授权必须具体、及时、可分离，并尽可能可撤销。
  • 在产生外部影响前预览：发送、发布、分享、导入、同步或批量编辑。
  • 自动化需展示待处理、运行中、已完成、失败、跳过和取消状态。
  • AI输出在用户确认前仅视为草稿。
  • 计费、权限和隐私文案需披露真实后果。
  • 在转化压力出现前，需展示成本、限制和权衡。
  • 持久或共享操作需要历史记录：谁或什么做了什么更改，以及更改时间。
完整参考：
references/trust-and-agency.md

Errors, edge cases & recovery

错误、边缘情况与恢复

Errors are the most-read copy in your product. They appear when users are already frustrated — design them first, not last.
  • Prevent before validate, validate before submit, submit before fail. Catch issues at the earliest possible step.
  • Every error message must answer three questions: what happened, why, and what can I do now.
  • Never blame the user. "Email is invalid" → "We could not find an account with that email."
  • Make destructive actions reversible by default. Confirmation dialogs are the weakest form of safety; undo is the strongest.
  • Empty, loading, partial, offline, and permission-denied states are screens, not afterthoughts. Design them with the same care as the happy path.
  • Before improving a loading state, ask whether the wait can be removed, backgrounded, cached, or shortened.
  • Measure the user-visible bottleneck before trading readability for optimization.
  • Retry must be one tap away. Never make the user re-enter data after a network failure.
Full reference: 
references/errors-and-recovery.md
错误文案是产品中被阅读最多的内容。它们出现在用户已经感到沮丧的时候——请优先设计这些内容，而非最后才考虑。
  • 先预防，再验证，再提交，最后处理失败。在最早的步骤中发现问题。
  • 每个错误消息必须回答三个问题：发生了什么、为什么以及我现在能做什么。
  • 永远不要指责用户。“邮箱无效” → “我们无法找到使用该邮箱的账户。”
  • 默认让破坏性操作可撤销。确认对话框是最弱的安全保障；撤销才是最强的。
  • 空状态、加载状态、部分加载、离线和权限拒绝状态是界面，而非事后补充。需像设计顺畅路径一样精心设计这些状态。
  • 在优化加载状态前，先考虑是否可以消除等待、后台处理、缓存或缩短等待时间。
  • 在为优化牺牲可读性前，先衡量用户可见的瓶颈。
  • 重试操作需一键可达。永远不要让用户在网络故障后重新输入数据。
完整参考：
references/errors-and-recovery.md

Microcopy & tone

微文案与语气

Copy is the highest-leverage UI surface — a one-word change in a button label can shift conversion more than a redesign.
  • Button labels describe the result of the action, not the action itself. "Send invite" beats "Submit." "Delete account" beats "OK."
  • Cut every word that does not change the meaning. "Please click here to..." → the verb.
  • Match the user's vocabulary, not the team's. If users say "post," do not call it a "submission."
  • Sentence case for everything except proper nouns. Title Case Makes Buttons Feel Like Headings.
  • Tone scales with stakes. Casual for routine, neutral for transactional, formal for irreversible or legal.
  • Respect beats conversion pressure: do not hide cost, effort, risk, or limits behind friendly copy.
  • Never write copy you would not read aloud to a stranger.
Full reference: 
references/microcopy-and-tone.md
文案是影响力最高的UI层面——按钮标签的一个单词改动，比重新设计更能改变转化率。
  • 按钮标签描述操作的结果，而非操作本身。“发送邀请”优于“提交”。“删除账户”优于“确定”。
  • 删除所有不改变含义的单词。“请点击此处以...” → 直接保留动词。
  • 使用用户的词汇，而非团队的词汇。如果用户说“发布”，不要称之为“提交”。
  • 所有内容使用句子大小写，专有名词除外。标题大小写会让按钮看起来像标题。
  • 语气随风险调整。常规操作使用随意语气，交易操作使用中性语气，不可逆或法律相关操作使用正式语气。
  • 尊重优于转化压力：不要用友好文案掩盖成本、付出、风险或限制。
  • 永远不要写你不愿对陌生人朗读的文案。
完整参考：
references/microcopy-and-tone.md

Anti-patterns

反模式

Treat anti-patterns as objections with different force:
  • Block when the requested behavior hides consent/cost, commits durable or external AI/automation output without review, destroys meaningful work, makes a primary task inaccessible, or creates high-blast-radius destructive action without object-specific safety. Do not implement the unsafe version; offer the closest compliant alternative. If the user explicitly overrides and the work is still allowed, add visible guardrails and name the residual risk.
  • Push back when the request would confuse, interrupt, obscure, or make recovery harder. Object once, propose the smallest safer change, and continue if the user still wants the trade-off.
  • Mitigate when the issue is local polish or copy quality. Improve it inside the requested scope and note any remaining compromise only if it matters.
  1. [Push back] Modal as the first thought. Modals interrupt. Use them only for decisions that block the next step. Never for confirmations of low-stakes actions, never for marketing.
  2. [Block] Irreversible destructive action without object-specific safety. If there is no undo, trash, or retention path, name the object and consequence; for high-blast-radius actions, require typed confirmation.
  3. [Push back] Error toast that auto-dismisses. If it disappears in 3 seconds, the user did not read it. Make errors persistent until dismissed or resolved.
  4. [Push back] Disabled buttons with no explanation. A greyed-out "Save" with no tooltip teaches the user nothing. Either say why or do not disable it.
  5. [Mitigate] Empty state that just says "No items." Every empty state is a chance to teach what this screen does and offer the first action.
  6. [Push back] Required field marked only with red text after submit. Mark required fields before the user types, not after.
  7. [Push back] Loading spinner with no context. "Loading..." for more than 1 second needs a label ("Generating preview..."). For longer waits, add a progress estimate, cancellation, or backgrounding.
  8. [Block for primary tasks] Hover-only affordances on touch surfaces. If a feature is only discoverable via hover, it does not exist for half the users.
  9. [Push back] Settings that hide important behavior. If toggling a setting could surprise the user later (notifications, sharing, deletion), surface the consequence inline at the moment of toggle.
  10. [Push back] Onboarding that asks for everything up front. Ask for what is needed to complete the next step, not the entire profile.
  11. [Push back] Confirmation that does not name the object. "Are you sure?" -> "Delete Q4 Report (2026)?"
  12. [Mitigate] Success states that vanish. A success toast that fades before the user looks up leaves them wondering if anything happened. Pair feedback with a persistent state change.
  13. [Block for primary tasks] Pointer-only path. Any task that requires hover, drag, or precise cursor movement must also have a visible keyboard/touch path.
  14. [Block when effort is significant] Form that destroys input. Resetting fields after validation, navigation, refresh, or network failure violates Preserve user effort.
  15. [Block] Consent bundled into one checkbox. Required agreement, marketing consent, tracking consent, and data sharing must not be hidden behind one control.
  16. [Block for durable or external impact] AI or automation that commits without review. Generated or automated output must not send, publish, charge, delete, or change durable data without explicit approval when stakes are real.
  17. [Push back] Complex policy disguised as simple UI. If the underlying rule is confusing, another tooltip or wizard step will not make the product feel simple. Simplify the rule or expose the trade-off honestly.
  18. [Push back] Asking before value is visible. Signup walls, permission prompts, payment forms, and sensitive questions must not appear before the user understands why the effort is worth it.
  19. [Mitigate] One hard question instead of several easy ones. If the user must calculate, remember, compare, or infer too much, split the question or let the system do the work.
  20. [Push back] Spinner as strategy. A pretty spinner is not a solution when the wait can be removed, backgrounded, cached, or made cancellable.
  21. [Mitigate] Unmeasured optimization. Do not make code harder to read for a theoretical speedup. If the bottleneck is not user-visible or measurable, leave the simpler code alone.
将反模式视为不同力度的异议：
  • 阻止（Block）：当请求的行为隐藏授权/成本、未经审核就提交持久或外部AI/自动化输出、破坏重要工作、使核心任务无法访问，或创建高影响范围的破坏性操作且无针对对象的安全措施时。请勿实现不安全版本；提供最接近的合规替代方案。如果用户明确覆盖且工作仍被允许，请添加可见的防护措施并说明残留风险。
  • 反对（Push back）：当请求会造成混淆、干扰、模糊或使恢复更困难时。提出一次异议，建议最小的安全改动，若用户仍希望权衡则继续执行。
  • 缓解（Mitigate）：当问题属于本地细节打磨或文案质量时。在请求范围内改进，仅在重要时说明剩余妥协。
  1. [反对] 首先想到模态框：模态框会干扰用户。仅在决策会阻碍下一步时使用。永远不要用于低风险操作的确认，也不要用于营销。
  2. [阻止] 无针对对象安全措施的不可逆破坏性操作：如果没有撤销、回收站或保留路径，请明确对象和后果；对于高影响范围的操作，要求输入确认。
  3. [反对] 自动消失的错误提示框：如果3秒内消失，用户可能没看到。让错误提示保持可见，直到用户关闭或解决问题。
  4. [反对] 无解释的禁用按钮：灰色的“保存”按钮无提示信息，无法教会用户任何东西。要么说明原因，要么不禁用。
  5. [缓解] 仅显示“无内容”的空状态：每个空状态都是向用户说明该界面用途并提供首个操作的机会。
  6. [反对] 仅在提交后用红色文本标记必填字段：在用户输入前就标记必填字段，而非之后。
  7. [反对] 无上下文的加载 spinner：“加载中...”超过1秒时需要标签（如“生成预览中...”）。对于更长时间的等待，需添加进度预估、取消选项或后台处理。
  8. [核心任务阻止] 触摸界面上仅hover可见的交互元素：如果功能仅能通过hover发现，对一半用户来说它相当于不存在。
  9. [反对] 隐藏重要行为的设置：如果切换设置可能在之后让用户意外（通知、分享、删除），需在切换时内联展示后果。
  10. [反对] 一开始就要求提供所有信息的新手引导：仅要求完成下一步所需的信息，而非完整资料。
  11. [反对] 未明确对象的确认提示：“你确定吗？” → “删除2026年Q4报告？”
  12. [缓解] 消失的成功状态：在用户抬头前就消失的成功提示框，会让用户疑惑是否操作成功。需将反馈与持久状态变化配对。
  13. [核心任务阻止] 仅依赖指针的操作路径：任何需要hover、拖拽或精确光标移动的任务，也必须有可见的键盘/触摸操作路径。
  14. [高付出时阻止] 丢失输入的表单：验证、导航、刷新或网络故障后重置字段，违反保留用户付出法则。
  15. [阻止] 合并为一个复选框的授权：必要协议、营销授权、跟踪授权和数据共享，不得隐藏在一个控件后。
  16. [持久或外部影响时阻止] 未经审核就提交的AI或自动化操作：当风险真实存在时，生成或自动化输出不得在未经明确批准的情况下发送、发布、扣费、删除或修改持久数据。
  17. [反对] 伪装成简洁UI的复杂政策：如果底层规则令人困惑，再多的提示框或向导步骤也无法让产品变得简洁。要么简化规则，要么诚实地披露权衡。
  18. [反对] 在展示价值前就提出要求：注册墙、权限提示、支付表单和敏感问题，不得在用户理解付出的价值前出现。
  19. [缓解] 一个难题而非多个简单问题：如果用户必须计算、记忆、比较或推断过多内容，请拆分问题或让系统完成这些工作。
  20. [反对] 将spinner作为解决方案：当等待可以消除、后台处理、缓存或取消时，好看的spinner并非解决方案。
  21. [缓解] 未衡量的优化：不要为了理论上的速度提升而让代码更难读。如果瓶颈不是用户可见或可衡量的，请保留更简洁的代码。

How to apply

应用方法

  • When reviewing, name the law or anti-pattern by phrase. Generic critique ("this feels off") teaches nothing.
  • Suggest the smallest change that satisfies the rule. Refactors are expensive; rules are cheap to apply incrementally.
  • Preserve the user's voice and product personality. These laws shape structure, not personality.
  • If two laws conflict in a specific case, prefer the earlier law in the Core laws list. Explain the trade-off.
  • When unsure, design the failure case first. If the failure is dignified, the success will be too.
  • Also identify the rule, policy, or business constraint creating the UX cost. If the rule can be simplified, fix the rule before polishing the interface around it.
  • Before a flow asks for effort, identify the visible value the user has already received or is about to receive.
  • If performance is part of the UX cost, identify the user-visible symptom and the measurement before proposing an optimization.
  • For UI code reviews, check changed behavior, not only changed pixels: focus, loading, empty, failed, disabled, permission-denied, undo, and success states.
  • 评审时，明确指出违反的法则或反模式的名称。泛泛的批评（如“这感觉不对”）毫无意义。
  • 建议符合规则的最小改动。重构成本高；法则可以逐步低成本应用。
  • 保留用户的语气和产品个性。这些法则塑造的是结构，而非个性。
  • 如果特定案例中两条法则冲突，优先遵循核心法则列表中靠前的法则。解释权衡。
  • 不确定时，先设计失败场景。如果失败场景设计得体，成功场景也会如此。
  • 同时识别产生UX成本的规则、政策或业务约束。如果规则可以简化，请先优化规则，再围绕规则打磨界面。
  • 在流程要求用户付出前，明确用户已获得或即将获得的可见价值。
  • 如果性能是UX成本的一部分，请先识别用户可见的症状和衡量指标，再提出优化方案。
  • 对于UI代码评审，检查改动后的行为，而非仅改动的像素：焦点、加载、空状态、失败状态、禁用状态、权限拒绝状态、撤销和成功状态。

Lineage

思想来源

These ideas have lineage. Recorded here, in one place, rather than scattered through the text:
  • Donald Norman — visibility, feedback, mapping, affordance, and the gulf between user intent and system response. (The Design of Everyday Things)
  • Jakob Nielsen — the ten usability heuristics. Visibility of system status, match between system and the real world, error prevention, recognition over recall, and help users recognize, diagnose, and recover from errors are load-bearing for this skill.
  • Steve Krug — Don't make me think. Scannability, convention over invention, the cost of a misplaced click.
  • Bruce Tognazzini — First principles of interaction design; the case for reversibility, latency budgets, and Fitts's law in practice.
  • Alan Cooper — goal-directed design; the distinction between what the system does and what the user is trying to achieve.
  • Dan Saffer — microinteractions as the texture of a product; the principle that small details are the product.
  • Edward Tufte — data-ink ratio applied to UI: every pixel either serves the user's task or interferes with it.
这些思想有溯源。集中记录于此，而非分散在文本中：
  • Donald Norman —— 可见性、反馈、映射、交互性，以及用户意图与系统响应之间的鸿沟。（The Design of Everyday Things）
  • Jakob Nielsen —— 十大可用性启发法。系统状态可见性、系统与现实世界的匹配、错误预防、识别优于回忆以及帮助用户识别、诊断并从错误中恢复是该技能的核心支撑。
  • Steve Krug —— Don't make me think. 可扫描性、约定优于创新、错误点击的成本。
  • Bruce Tognazzini —— 交互设计的第一原则；可逆性、延迟预算和Fitts定律的实践案例。
  • Alan Cooper —— 目标导向设计；系统行为与用户目标之间的区别。
  • Dan Saffer —— 微交互作为产品的质感；细节即产品的原则。
  • Edward Tufte —— 数据墨水比在UI中的应用：每个像素要么服务于用户任务，要么干扰用户任务。