focal

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Focal

One screen, one clear intent.

Good UX guides attention. People don't read a screen, they orient on it—scanning for where they are, what matters, and what to do next. Every screen, the moment it appears, has to answer three questions: Where am I? What matters here? What do I do? The faster and more certainly it answers, the better it works—whether it's a phone app glanced at one-handed or a dashboard an expert lives in all day. Only the pace and the density change.

Focal's answer is a single methodology: every screen needs one clear organizing intent. That does not mean one action, one content block, or one possible user goal. A task screen usually has one primary action; a hub can offer many destinations; an exploration surface can foreground many items. What stays singular is the screen's center of gravity—the reason its content and actions belong together.

Simple, clean UX is not a style. It is the visible result of a screen making that organizing intent legible instead of forcing the user to sort competing intents by eye.

Three disciplines, treated as top priorities, are how you earn that outcome:

Information Architecture—what belongs on the screen, and how it's organized.
Visual Hierarchy—what wins attention once it's there.
Progressive Disclosure—what's shown now, and what waits.

                 ┌────────────────────────────────────────────┐
   the outcome   │         ONE SCREEN, ONE CLEAR INTENT         │
                 └────────────────────────────────────────────┘
                        ▲              ▲               ▲
   the means     Information      Progressive       Visual
                 Architecture     Disclosure        Hierarchy
                 what belongs     what shows now     what wins

Get all three right and the screen settles around one clear intent on its own. Miss any one and that intent blurs. Progressive Disclosure is the load-bearing discipline—a screen with the right structure and clear hierarchy decays the instant you let complexity pile on, so weight it the most.

Together, the disciplines make the screen a better decision surface. Keep these four rules in view:

Minimize choices. Minimize decisions, not information: present the choices that change the next action; keep technical detail discoverable when it supports trust, verification, or an expert path.
Pattern recognition—infer before asking. Recognize structured input when the system can, show the interpretation, and let the user correct it instead of forcing manual classification.
Contextual UI—keep context at the decision surface. Put the history, status, price, or consequence needed for an informed choice beside the action; defer deep detail, not decision-critical context.
Show the consequence. Make relationships, tradeoffs, and process state legible through a clear summary, comparison, preview, or visualization when raw values alone make the user do the reasoning.

一屏一明确意图

优秀的UX设计会引导用户注意力。人们不会逐字阅读屏幕内容，而是快速定位——扫描自己所处位置、重要内容以及下一步操作。每一个界面在出现时，都必须回答三个问题：我在哪里？这里最重要的是什么？我该做什么？ 回答得越快、越明确，界面的实用性就越强——无论是单手浏览的手机应用，还是专家全天使用的仪表盘，唯一的区别只是节奏和信息密度。

Focal的解决方案是一套统一的方法论：每个界面都需要一个清晰的核心意图。这并不意味着一屏只能有一个操作、一个内容块或一个用户目标。任务型界面通常有一个主要操作；枢纽型界面可以提供多个跳转目标；探索型界面可以展示大量内容。保持唯一的是界面的核心重心——即内容与操作组合在一起的原因。

简洁干净的UX不是一种风格，而是界面清晰呈现核心意图的直观结果，而非让用户自行分辨相互冲突的意图。

要实现这一目标，需优先遵循三大原则：

Information Architecture（信息架构）——确定哪些内容属于当前界面，以及如何组织这些内容。
Visual Hierarchy（视觉层级）——确定界面中哪些元素最吸引注意力。
Progressive Disclosure（渐进式披露）——确定哪些内容现在展示，哪些延迟展示。

                 ┌────────────────────────────────────────────┐
   最终成果      │         ONE SCREEN, ONE CLEAR INTENT         │
                 └────────────────────────────────────────────┘
                        ▲              ▲               ▲
   实现手段      Information      Progressive       Visual
                 Architecture     Disclosure        Hierarchy
                 内容归属         即时展示项        注意力焦点

三大原则全部落实后，界面会自然围绕一个明确的核心意图展开。任何一项缺失都会导致核心意图模糊。Progressive Disclosure是最关键的原则——即使界面结构合理、层级清晰，一旦让复杂度堆积，界面就会失效，因此需重点关注这一点。

三大原则共同让界面成为更优的决策载体。请牢记以下四条规则：

减少选择项：减少决策次数而非信息量——只展示会改变下一步操作的选择；将技术细节设置为可发现状态，以支持用户建立信任、验证信息或满足专家级需求。
模式识别——先推断再询问：当系统能够识别结构化输入时，展示解析结果，让用户进行修正，而非强制用户手动分类。
上下文UI——将上下文置于决策界面：将做出明智选择所需的历史记录、状态、价格或结果与操作选项放在一起；延迟展示深层细节，但绝不延迟决策关键上下文。
展示结果：当原始数值需要用户自行推导关系、权衡或流程状态时，通过清晰的摘要、对比、预览或可视化呈现这些信息，同时保留精确数值作为支撑依据。

When to use

适用场景

Focal is for functional interfaces—the screens of an app, product, or tool, on any platform (mobile, web, desktop, tablet), for any user (first-timer or expert). Onboarding, feeds, home screens, settings, dashboards, admin panels, checkout, editors, consoles. If a person is on the screen trying to do something, Focal applies.

It is not for:

Marketing pages, landing pages, campaigns—design there is persuasion and narrative, not task completion, so the clear-intent test and working-memory limit bend too far to guide you.
Backend, infra, or non-UI work.

Dense, expert tools (dashboards, IDEs, trading terminals) are in scope—high density is right when the audience can read it. The methodology bends for them, never breaks, through two modifiers covered below: the screen's register and the user's expertise (experts read dense displays as a few familiar chunks; first-timers can't).

Scope. Focal is a lens for structure and attention—what belongs on a screen and how it's ranked—not a full visual-design system. It tells you the screen's organizing intent, the action model appropriate to its register, its information structure, and its hierarchy. The execution of color, typography, spacing, and motion is left to your own design system and tooling. Get the methodology right first: visual polish lands far better on a screen whose center of gravity is already clear.

Focal适用于功能性界面——包括任意平台（移动、网页、桌面、平板）上的应用、产品或工具界面，面向所有用户（新手或专家）。引导页、信息流、首页、设置、仪表盘、管理面板、结账流程、编辑器、控制台等均适用。只要用户在界面上执行操作，Focal就适用。

不适用场景：

营销页、落地页、活动页面——这些页面的设计核心是说服和叙事，而非任务完成，因此明确意图测试和工作记忆限制无法提供有效指导。
后端、基础设施或非UI相关工作。

高密度的专家工具（仪表盘、IDE、交易终端）属于适用范围——当目标用户能够解读时，高密度信息是合理的。方法论会通过以下两个调整项适配这类场景：界面的类型和用户的专业程度（专家会将密集显示的信息视为几个熟悉的模块；新手则无法做到）。

范围说明：Focal是聚焦于结构与注意力的视角——确定界面内容归属及优先级——而非完整的视觉设计系统。它会明确界面的核心意图、适配其类型的操作模型、信息结构和层级。颜色、排版、间距和动效的执行则由你自己的设计系统和工具决定。请先落实方法论：当界面的核心重心已经清晰时，视觉打磨的效果会好得多。

The methodology—One Screen, One Clear Intent

方法论——一屏一明确意图

The north star. Every screen earns its place by making one organizing intent legible. An organizing intent is the reason this screen exists in the product—not a demand that only one action, destination, or item can appear.

The one-sentence test. Finish this sentence: "This screen exists so the user can ______." If "and" joins two outcomes that can succeed independently, the screen has competing intents. Split them, or demote one to a secondary path. Do not fail a coherent task merely because its natural name contains "and"—review and approve this invoice is one intent when review is necessary to approval.
The register-aware action model. Do not force one CTA onto every screen. A task screen usually gives one action primary weight. A hub ranks several destinations. An exploration surface lets a coherent field of content lead. Binary-choice screens (Accept / Decline) and genuine dual-mode screens (a map's browse + search) may carry an inherent co-equal set. Multiple primary-weight actions are a failure only when they compete for different outcomes or leave the screen without a clear center of gravity.
Why this is the whole game. People need to understand what kind of place they are in before they can use it. A screen with one legible organizing intent feels coherent; a screen hedging across three independent outcomes feels like work. The three disciplines below are the three ways that intent becomes clear—or gets lost.

这是核心准则。每个界面都必须清晰呈现其核心意图，以此证明自身存在的价值。核心意图指的是该界面在产品中的存在意义——而非要求界面只能有一个操作、跳转目标或内容项。

一句话测试：完成这句话：「这个界面存在的目的是让用户______。」 如果用「和」连接两个可独立完成的结果，说明界面存在相互冲突的意图。需拆分界面，或将其中一个降为次要路径。不要仅仅因为任务的自然名称包含「和」就判定任务不连贯——审核并批准该发票是一个单一意图，因为审核是批准的必要前提。
适配界面类型的操作模型：不要强制所有界面都使用单一的CTA（号召性用语）。任务型界面通常将一个操作设为主要操作；枢纽型界面会对多个跳转目标进行排序；探索型界面会让连贯的内容成为焦点。二元选择界面（接受/拒绝）和真正的双模式界面（地图的浏览+搜索）可以包含同等重要的操作集。只有当多个主要操作追求不同结果，或导致界面失去清晰核心重心时，才会被视为设计失败。
为什么这是核心：用户需要先理解自己所处的场景，才能使用界面。核心意图清晰的界面会让人感觉连贯；同时承载三个独立意图的界面则会增加用户负担。以下三大原则是让核心意图清晰或模糊的关键因素。

The three disciplines

三大原则

These describe the task screen—the default screen type, where the user is completing a single job. Hub and exploration screens bend them; see Registers, below.

这些原则描述的是任务型界面——默认且最常见的界面类型。枢纽型和探索型界面会对这些原则进行调整；详见下文的界面类型。

1. Information Architecture—what belongs, and how it's organized

1. Information Architecture（信息架构）——内容归属与组织方式

A screen is a unit of intent. IA decides which content and actions belong on it, how they're grouped and labeled, and where the screen sits in the larger flow. Get this wrong and no amount of hierarchy or polish can rescue the screen—it is organizing the wrong things.

One organizing intent per screen. Supporting actions can coexist when they advance the same intent. If an action or content region serves an independently completable outcome, move it, defer it, or make the screen's routing role explicit. Split by intent, not by content type or by your data model.
Group by relatedness. Things used together live together. Proximity is the cheapest, strongest signal that two elements belong to the same idea.
Label in the user's words. Navigation, sections, and actions named in plain language the user already owns—never system or domain jargon. Recognition beats recall.
Pattern recognition—infer before asking. When input has recognizable structure—an address, identifier, date, or transaction type—parse it and propose the likely interpretation. Show what was inferred, let the user correct it, and keep a manual fallback for ambiguity; do not make the user classify input the system can already recognize.
Contextual UI—keep context at the decision surface. Co-locate everything needed to make a choice where the choice is made. If history, status, price, or consequence informs the decision, bring the relevant slice into the same screen or region. Defer deep detail, never the context required to decide or trust the action, and never force the user to remember a fact from a previous screen (the "memory bridge").
Merge needless round-trips; split overloaded screens. Two screens that each do half of one intent should be one. One screen carrying three independent intents should be split or reframed as an explicit hub.
Orientation. The user always knows where they are and how to get back. Findability is structure, not decoration.

Fails: the kitchen-sink screen (three jobs at once); structure that mirrors the database instead of the user's intent; orphan content with no clear home; jargon labels; the memory bridge across screens.

界面是一个意图单元。信息架构决定哪些内容和操作属于当前界面，如何分组和命名，以及该界面在整体流程中的位置。如果这一步出错，无论层级设计多么完善或视觉多么精美，都无法挽救界面——因为它组织的是错误的内容。

一屏一核心意图：辅助操作可与核心意图共存，只要它们服务于同一意图。如果某个操作或内容区域服务于可独立完成的结果，需将其移至其他界面、延迟展示，或明确界面的跳转定位。按意图拆分界面，而非按内容类型或数据模型。
按关联性分组：一起使用的元素放在一起。邻近性是最便宜、最有效的信号，表明两个元素属于同一概念。
用用户的语言命名：导航、分区和操作使用用户熟悉的直白语言——绝不要使用系统或领域术语。识别比回忆更容易。
模式识别——先推断再询问：当输入具有可识别的结构（如地址、标识符、日期或交易类型）时，进行解析并给出可能的结果。展示推断内容，让用户进行修正，并为模糊情况保留手动输入选项；不要让用户对系统已能识别的输入进行分类。
上下文UI——将上下文置于决策界面：将做出选择所需的所有信息与选择项放在同一位置。如果历史记录、状态、价格或结果会影响决策，将相关信息纳入同一界面或区域。延迟展示深层细节，但绝不延迟决策所需的上下文，绝不要让用户记住上一界面的信息（即「记忆桥梁」）。
合并不必要的往返操作；拆分过载界面：两个各完成一半单一意图的界面应合并为一个。承载三个独立意图的界面应拆分或重新定位为明确的枢纽型界面。
定位：用户始终知道自己所处位置以及返回路径。可查找性是结构问题，而非装饰问题。

失败案例：杂乱无章的界面（同时承载三个任务）；镜像数据库结构而非用户意图的界面；无明确归属的孤立内容；术语化命名；跨界面的「记忆桥梁」。

2. Progressive Disclosure—show now, defer the rest (load-bearing)

2. Progressive Disclosure（渐进式披露）——即时展示与延迟展示（核心原则）

Reveal complexity only when the user needs it. Working memory is the hard constraint, not screen real estate. This is the discipline that keeps a screen's organizing intent legible over time.

The working-memory rule. Humans hold about 4 items in working memory at once (Miller's Law, revised by Cowan). At any single decision point, count the distinct options, fields, or facts the user must hold simultaneously:
- ≤4—within budget.
- 5–7—group or defer.
- 8+—overloaded; users skip, misclick, or abandon.
Count chunks, not raw elements. A group the user recognizes as one unit—a familiar toolbar, a labeled section—counts as one. Expertise grows chunk size: a pro tool can show dense data because its users read it as a few learned groups, where a first-run screen cannot. The budget is ~4 chunks, and who the user is sets how large a chunk can be.
The disclosure triage. For every element, decide Now / On-demand / Never.
- Now—needed to complete the primary action this visit. It stays.
- On-demand—needed by some users sometimes. Defer it behind a reveal (see reference/patterns.md).
- Never—nobody needed it; you assumed they would. Cut it.
Minimize decisions, not information. Present the few choices that change the next action. Keep technical detail available when it supports trust, verification, or an expert path, but do not force everyone to interpret it before they can proceed. Smart defaults plus an "Advanced" reveal beats a wall of equal options. Ten settings shown at once is a wall; three with "More options" is a path.
No disclosure without a signifier. Every deferred thing needs a perceptible cue that it exists—a chevron, a labeled "More options," a tab, a count. Deferral hides complexity; it must never hide existence. Name the cue when you defer, not just the fact of deferring: "advanced filters, behind an 'Advanced' toggle," not "advanced filters, deferred." Content behind a cue nobody perceives is content you cut—and you cut it without deciding to, which is the one form of cutting this skill does not allow. A cue qualifies only if it is present in the screen's default state, without hover or gesture. A function reachable only by swipe or long-press is the named worst case: if the only way to discover it is to be told about it, it is hidden, not deferred.
The disclosure trap (read this). Progressive disclosure is deferral, not burial. Hiding the primary action, the price, a required field, or a consequence behind a tap is a dark pattern, not disclosure. Never defer what the user needs now to act or to trust the screen. Disclosure reduces choice overload, never honesty.

Fails: the wall of options; an onboarding form that asks everything up front; settings exposed before they're relevant; the primary action or price buried behind a reveal; a reveal with no cue that anything is behind it.

仅在用户需要时展示复杂内容。工作记忆是硬性限制，而非屏幕空间。这一原则是保持界面核心意图清晰的关键。

工作记忆规则：人类一次只能在工作记忆中保留约4个项目（Miller定律，经Cowan修订）。在任何决策点，统计用户必须同时处理的不同选项、字段或事实数量：
- ≤4——在预算范围内。
- 5–7——分组或延迟展示。
- 8+——过载；用户会跳过、误点击或放弃操作。
统计模块，而非原始元素：用户视为一个单元的组（如熟悉的工具栏、带标签的分区）计为一个项目。专业程度会增加模块大小：专业工具可以展示密集数据，因为用户会将其视为几个已学习的模块；而首次使用的界面则无法做到。预算约为4个模块，用户的专业程度决定了模块的大小。
披露分类：对每个元素，决定即时展示 / 按需展示 / 永不展示。
- 即时展示——完成本次主要操作所需的内容。保留。
- 按需展示——部分用户有时需要的内容。通过触发元素延迟展示（详见reference/patterns.md）。
- 永不展示——没有人需要的内容；你只是假设用户需要。删除。
减少决策次数，而非信息量：仅展示会改变下一步操作的少量选择。保留技术细节以支持用户建立信任、验证信息或满足专家级需求，但不要强制所有人在操作前解读这些细节。智能默认选项加「高级」触发元素，胜过一墙同等重要的选项。同时展示10个设置项是障碍；展示3个加「更多选项」则是合理路径。
无提示不披露：每个延迟展示的内容都需要一个可感知的提示，表明其存在——如箭头、带标签的「更多选项」、标签页或计数。延迟展示隐藏的是复杂度；绝不能隐藏存在性。延迟展示时要命名提示，而非仅说明延迟：「高级筛选，在'高级'切换按钮后」，而非「高级筛选，延迟展示」。用户无法感知的提示背后的内容等同于被删除——且是未经决策的删除，这是本技能不允许的操作。提示必须在界面默认状态下可见，无需悬停或手势触发。 仅通过滑动或长按才能访问的功能是最糟糕的情况：如果只能通过告知才能发现，那它是被隐藏，而非延迟展示。
披露陷阱（务必阅读）：渐进式披露是延迟展示，而非隐藏。将主要操作、价格、必填字段或结果隐藏在点击操作后是暗黑模式，而非披露。绝不要延迟展示用户当前操作或信任界面所需的内容。披露是为了减少选择过载，而非降低透明度。

失败案例：一墙选项；一开始就询问所有信息的引导表单；在相关前就展示的设置项；隐藏在触发元素后的主要操作或价格；无提示的触发元素。

3. Visual Hierarchy—what wins attention

3. Visual Hierarchy（视觉层级）——注意力焦点

Once the right things are on the screen and the rest deferred, rank what remains. Importance is communicated by visual weight: the heaviest element or region is the most important one—always, with no exceptions you did not choose deliberately for the register.

The squint test. Blur your eyes (or the screenshot). Can you still tell what's #1, what's #2, and how things group? If everything has the same weight, you have a list, not a hierarchy.
The 3-second test. A first-time user should be able to name the most important thing on screen within ~3 seconds.
Weight must match importance. The most common hierarchy bug: decoration (a hero image, an illustration, a giant logo) outweighs the action model's dominant element or region. Visual weight is a budget—spend it on what the user came to do.
The focusing mechanism. One element or region must be the visual entry point that says start here. On a task screen that is usually the primary action or the content needed before it; on a hub it can be the leading destination or group; in exploration it is the content field itself. If the eye bounces between unrelated, equally weighted regions, the organizing intent is not being expressed.
Show the consequence. When a decision depends on a relationship, tradeoff, or process state, show that meaning at the decision surface—a simple summary, comparison, preview, or visualization may do more than a list of raw numbers. Keep exact values and supporting detail available as evidence; the visual should clarify, not decorate or conceal.
Weight ranks; it does not permit. Hierarchy answers what should I do; it does not answer what can I do. A heading can be the heaviest thing on screen and still be inert. So where the primary is an action, it has to carry a signifier that reads as actionable inside the same ~3 seconds: a traced boundary (fill, border, or elevation), a platform-native control convention (an iOS bar button), or an icon plus label inside a tap target. Bare text at any weight, with no convention behind it, ranks without permitting—say which of these the primary is using. A screen can pass the squint test and still leave the user unsure they are allowed to touch anything.
No false signifiers. A shadowed card that doesn't open, underlined text that isn't a link, a chevron that leads nowhere—these spend attention the screen budgeted for real actions, because the eye reads them exactly like real controls. They also cost trust the first time someone taps one and nothing happens. Count them as clutter, not decoration.
The hierarchy ladder. Use the fewest dimensions that achieve clear ranking, in this order: space → weight → size → color. Reach for color last; it is the loudest and easiest to overuse.
The shape of a good screen: one dominant element or region, two to three secondary tiers, everything else ambient. The dominant thing must match the register's action model. When every element is loud, none is.

Fails: hierarchy carried by color alone; the "visual noise floor" where everything has equal weight; decoration outweighing function; six type sizes that read as one; a dominant action that ranks first but doesn't read as actionable; inert elements dressed as controls.

确定界面内容归属并延迟不必要内容后，对剩余内容进行优先级排序。重要性通过视觉权重传达：视觉权重最高的元素或区域是最重要的——这一点始终成立，除非你为界面类型故意选择例外情况。

眯眼测试：眯起眼睛（或模糊截图）。你是否仍能分辨出第1、第2重要的元素以及元素分组？如果所有元素权重相同，那你得到的是列表，而非层级。
3秒测试：首次使用的用户应能在约3秒内说出界面上最重要的内容。
权重必须匹配重要性：最常见的层级错误：装饰元素（如英雄图、插图、大logo）的权重超过操作模型的主导元素或区域。视觉权重是一种预算——应将其分配给用户的核心操作。
聚焦机制：必须有一个元素或区域作为视觉入口，提示从此处开始。在任务型界面上，通常是主要操作或操作前所需的内容；在枢纽型界面上，可以是主要跳转目标或分组；在探索型界面上，则是内容区域本身。如果眼睛在无关的、同等权重的区域之间跳动，说明核心意图未被清晰呈现。
展示结果：当决策依赖于关系、权衡或流程状态时，在决策界面展示其含义——简单的摘要、对比、预览或可视化可能比原始数值列表更有效。保留精确数值和支撑细节作为证据；视觉呈现应起到澄清作用，而非装饰或隐藏信息。
权重用于排序；而非许可：层级回答的是我应该做什么；而非我能做什么。标题可以是界面上权重最高的元素，但仍可能是静态的。因此，当主要操作是一个动作时，必须在约3秒内让用户感知到其可操作性：如带边框的区域（填充、边框或阴影）、平台原生控件（如iOS栏按钮），或点击目标内的图标加标签。任何权重的纯文本，若无约定支持，只能排序但无法提示可操作性——需明确指出哪个是主要操作。界面可能通过眯眼测试，但仍让用户不确定是否可以点击任何内容。
无虚假提示：看似可交互的静态元素。如无法打开的带阴影卡片、不是链接的下划线文本、无跳转的箭头——这些会消耗界面分配给真实操作的注意力，因为眼睛会将它们视为真实控件。用户首次点击无反应时，还会损失信任。将这些视为杂乱内容，而非装饰。
层级阶梯：使用最少的维度实现清晰排序，顺序为：空间 → 权重 → 尺寸 → 颜色。最后使用颜色；它最醒目，也最容易被过度使用。
优秀界面的形态：一个主导元素或区域，2-3个次要层级，其余为次要内容。主导元素必须匹配界面类型的操作模型。当所有元素都很醒目时，就没有元素会被关注。

失败案例：仅通过颜色实现层级；所有元素权重相同的「视觉噪音」；装饰元素权重超过功能；6种字号看起来无区别；排序第一但无法感知可操作性的主要操作；看似可交互的静态元素。

Registers—when the rules shift

界面类型——规则调整场景

The disciplines above assume the task screen: the default, and the most common. Two other screen types are legitimate, and applying task rules to them is a mistake—it flattens screens that are supposed to hold many things. Identify the register first; it changes how the clear intent is expressed, which action model fits, and where the disciplines bind.

Classify with this tree. Walk it top to bottom and take the first match. Answer about what the user came to do, not about how the screen currently looks—a cluttered screen is not automatically a hub.

Did the user come here to complete one specific job?
├── Yes → TASK
└── No
    ├── Is this screen's own job to send them somewhere else?
    │   └── Yes → HUB
    └── Did they come to browse content, with no particular endpoint?
        ├── Yes → EXPLORATION
        └── Neither is clearly true
            └── TASK, overloaded into a hub. Score it as a task screen
                and flag the overload under Information Architecture.

Two ties worth naming, because they recur:

A record or detail screen (a contact, an issue, an order) is a hub when its job is to show state and route you onward, and a task screen when it exists to be edited. If it tries to be both at once, that is the overloaded case—the tree's last branch.
Search results are exploration when the user is scanning to discover, and a task screen when they are finding one known item to act on.
Task—the user is completing a specific job. Default; everything above applies as written. One completion intent, usually one primary action, ≤4 chunks at a decision point. An inherent binary choice or inseparable dual mode can be co-equal without creating a second intent. (Checkout, compose, a signup step, a settings detail, any form.)
Hub—the user is choosing where to go. The organizing intent is routing; many destinations is correct, not clutter. (Home screen, profile, settings index, account screen, app root.)
Exploration—the user is browsing for its own sake. Abundance is the point; the goal is dwell and discovery, not a fast exit. (Feeds, discover/browse tabs, search results, a photo or product grid.)

The methodology still holds—one screen, one clear intent—but its expression changes by register, and the working-memory limit relocates rather than disappears:

	Task	Hub	Exploration
Organizing intent	complete one coherent job	route among related destinations	browse one coherent content space
Action model	one primary action usually wins; name any inherent co-equal set	rank destinations; let the likely next route lead	content leads; controls support continued discovery
Where ≤4 binds	the whole decision point	per group / per row (not the total destination count)	per item (each card holds ≤4 facts), not the item count
Hierarchy	one dominant action or read-first region	one destination or group leads; routes remain comparable	one content type dominates; chrome recedes

Note that ≤4 never vanishes—it moves. A settings index with 9 rows is fine (hub); a settings row cramming 9 facts is not. A feed with 200 posts is fine (exploration); a feed card with 9 competing elements is not.

The trap runs both ways: flattening a hub or feed down to a single action (now it does its job badly), or letting a task screen sprawl into an accidental hub because you skipped the one-sentence test. When you can't tell which register you're in, you're usually looking at a task screen wearing too many hats—split it or deliberately reframe it as routing.

上述原则基于任务型界面：默认且最常见的类型。另外两种界面类型是合理的，将任务型界面规则应用于它们是错误的——这会削弱本应承载大量内容的界面。请先确定界面类型；它会改变核心意图的呈现方式、适配的操作模型以及原则的约束方式。

通过以下分类树确定类型：从上到下，选择第一个匹配项。基于用户的操作目的，而非界面当前的外观——杂乱的界面并非自动属于枢纽型界面。

用户是否来此完成一项特定任务？
├── 是 → 任务型（TASK）
└── 否
    ├── 此界面的作用是否是引导用户前往其他地方？
    │   └── 是 → 枢纽型（HUB）
    └── 用户是否来此浏览内容，无特定目标？
        ├── 是 → 探索型（EXPLORATION）
        └── 两者均不明确
            └── 任务型，但过载为枢纽型。按任务型界面评分
                并在信息架构部分标记过载问题。

两种常见的模糊场景：

记录或详情界面（如联系人、问题、订单）：当作用是展示状态并引导用户前往其他界面时，属于枢纽型；当作用是编辑时，属于任务型。如果同时尝试实现两种功能，属于过载情况——即分类树的最后一个分支。
搜索结果：当用户扫描以发现内容时，属于探索型；当用户查找特定项目以执行操作时，属于任务型。
任务型——用户完成特定任务。默认类型；上述所有原则均适用。 一个完成意图，通常一个主要操作，决策点≤4个模块。固有二元选择或不可分割的双模式可以同等重要，而不会产生第二个意图。（如结账、撰写、注册步骤、设置详情、任何表单。）
枢纽型——用户选择前往何处。核心意图是跳转；多个跳转目标是合理的，而非杂乱。（如首页、个人资料、设置索引、账户界面、应用根目录。）
探索型——用户为浏览而浏览。丰富内容是核心；目标是停留和发现，而非快速退出。（如信息流、发现/浏览标签页、搜索结果、照片或产品网格。）

方法论仍然成立——一屏一明确意图——但呈现方式会因界面类型而异，工作记忆限制转移而非消失：

	任务型	枢纽型	探索型
核心意图	完成一项连贯任务	在相关目标间跳转	浏览一个连贯的内容空间
操作模型	通常一个主要操作占主导；明确任何固有同等重要的操作集	对跳转目标排序；让可能的下一路径成为焦点	内容为主；控件支持持续发现
≤4约束位置	整个决策点	每组/每行（而非总跳转目标数）	每个项目（每个卡片包含≤4个事实），而非项目总数
层级	一个主导操作或优先阅读区域	一个跳转目标或分组为主；跳转目标保持可比性	一种内容类型为主；控件弱化

请注意，≤4的限制从未消失——只是转移了位置。包含9行的设置索引是合理的（枢纽型）；但一行包含9个事实的设置项则不合理。包含200条帖子的信息流是合理的（探索型）；但一个包含9个竞争元素的信息流卡片则不合理。

陷阱双向存在：将枢纽型或信息流界面简化为单一操作（会导致其无法正常工作），或让任务型界面因跳过一句话测试而意外变成枢纽型界面。当你无法确定界面类型时，通常是因为任务型界面承载了过多功能——需拆分界面或明确将其重新定位为跳转界面。

How they combine—order of operations

组合方式——操作顺序

Apply them in this order. Skipping ahead produces a pretty screen that does the wrong thing.

Define the intent and action model (methodology). One sentence; then choose the model that fits the register.
Architect the information (IA). Decide what belongs, how inputs are interpreted, and what decision-relevant context stays with the action.
Disclose progressively (PD). Minimize decisions, not information; sort what belongs into Now / On-demand / Never.
Establish hierarchy (VH). Rank what survived and make the consequence legible without letting supporting visualization outrank the action model.

You cannot rank elements before you know which show (3 before 4), cannot decide what shows before you know what belongs (2 before 3), and cannot decide what belongs before you know the screen's organizing intent (1 before 2). Hierarchy applied to a kitchen-sink screen just makes the clutter well-organized.

This order holds for every register; only the targets shift—in a hub, step 4 ranks destinations; in exploration, it ranks content types over chrome.

按以下顺序应用原则。跳过前面的步骤会导致界面美观但功能错误。

定义核心意图和操作模型（方法论）。用一句话描述；然后选择适配界面类型的模型。
构建信息架构（IA）。确定内容归属、输入解析方式以及决策相关上下文与操作的关联方式。
渐进式披露分类（PD）。减少决策次数，而非信息量；将内容分为即时展示/按需展示/永不展示。
确定剩余内容的优先级（VH）。对保留的元素或区域进行层级划分：主导（1个）、次要（2-3个）、次要内容（其余）。让主导层级匹配界面类型的操作模型，并清晰呈现结果，同时避免支撑性可视化超过操作模型的权重。

在确定展示内容前无法进行优先级排序（步骤3在步骤4之前）；在确定内容归属前无法决定展示内容（步骤2在步骤3之前）；在确定界面核心意图前无法决定内容归属（步骤1在步骤2之前）。将层级应用于杂乱无章的界面，只会让杂乱内容变得有条理。

此顺序适用于所有界面类型；只有目标会变化——在枢纽型界面中，步骤4对跳转目标进行排序；在探索型界面中，步骤4对内容类型进行排序，弱化控件。

Flows—hand off to Compass or Flywheel

流程——移交至Compass或Flywheel

Focal is screen-local on purpose. A flow is a sequence of screens with clear organizing intents, so apply Focal to each screen in one—but the path between them belongs to Compass, the sibling skill for cross-screen flows. Focal is within a screen; Compass is between them.

Route it:

Focal's—a screen that does too much, buries what matters, uses the wrong action model, or ranks the wrong thing loudest.
Compass's—too many steps, a dead end, a trapped modal, a Back that wipes work, a deep link that dumps the user at step one, or a user who can't tell where they are in the journey.
Flywheel's—a journey step that stalls activation before first value, hides a delivered win, or causes users to drift instead of return. Compass maps and connects the step; Flywheel diagnoses the lifecycle leak.

An end-to-end journey must include necessary but unglamorous work—setup, verification, signing, recovery, and confirmation—not just the core utility. Compass owns how those steps are sequenced, connected, and resumable. Flywheel owns whether they create friction before value or another lifecycle leak. Focal owns the local decision surface of each screen and should not turn one step into a catch-all.

These skills are not a whole-app IA or sitemap tool. If the question is "how should the entire product be organized," that is a larger exercise—return to Focal screen by screen, and Compass flow by flow, once that map exists.

Focal特意聚焦于单屏。流程是一系列具有清晰核心意图的界面，因此需对每个界面应用Focal——但界面之间的路径属于Compass，即跨屏流程的配套技能。Focal负责屏内；Compass负责屏间。

分工如下：

Focal负责：承载过多功能、隐藏重要内容、使用错误操作模型或错误排序重要元素的界面。
Compass负责：步骤过多、死胡同、无法关闭的模态框、会清除工作内容的返回按钮、直接跳转到第一步的深层链接，或用户无法判断自己在流程中所处位置的情况。
Flywheel负责：在首次价值交付前阻碍激活、隐藏已交付成果或导致用户流失而非返回的流程步骤。Compass负责步骤的排序、连接和可恢复性；Flywheel负责诊断生命周期漏洞。

端到端流程必须包含必要但不吸引人的工作——设置、验证、登录、恢复和确认——而非仅核心功能。Compass负责这些步骤的排序、连接和可恢复性；Flywheel负责这些步骤是否会在价值交付前产生摩擦或导致生命周期漏洞。Focal负责每个界面的本地决策载体，不应将一个步骤变成万能界面。

这些技能并非全应用IA或站点地图工具。如果问题是「整个产品应如何组织」，这是一项更大型的工作——一旦地图确定，再逐屏应用Focal，逐流程应用Compass。

Routing

分工规则

No argument → explain the methodology and three disciplines briefly, then ask: building a new screen, or reviewing an existing one?
A whole-app or cross-scale audit request → hand off to Product Judgement, which runs Focal with Compass, Flywheel, and Soul and reconciles the results.
build
(or a description of a screen to design) → follow The five moves below. Pull techniques from reference/patterns.md.
A multi-screen flow, journey, or navigation question → that is Compass's, not Focal's. Say so and hand off (see Flows, above). If the question is where the journey loses activation, value recognition, or return, also hand off to Flywheel.
review
/
critique
/
audit
(or a file, screenshot, or URL to evaluate) → load and follow reference/review.md. It scores each discipline 0–4 against a written rubric, requires an evidence-based rationale and next-point change for every score, totals to /12, displays a normalized /4 average and common quality band with a weakest-dimension ceiling, tags issues P0–P3, anchors every issue to the exact screen region, app state, and lifecycle moment, and closes on a Clear-Intent verdict. That file defines the rubrics, scoring contract, bands, severities, and audit locator—all of them, and nowhere else.
A question about a specific technique or anti-pattern → consult reference/patterns.md.

Before emitting either output, read reference/examples.md. It is the calibration for length, tone, and how the locked templates look when filled well—the templates define the shape, the examples set the bar.

无争议 → 简要说明方法论和三大原则，然后询问：是构建新界面，还是评审现有界面？
全应用或跨规模审计请求 → 移交至Product Judgement，该技能会结合Compass、Flywheel和Soul应用Focal并协调结果。
build
（或描述要设计的界面） → 遵循以下五步操作。从reference/patterns.md中提取技术。
多屏流程、旅程或导航问题 → 这属于Compass的职责，而非Focal。说明这一点并移交（详见上文流程）。如果问题是旅程在何处失去激活、价值认可或返回率，同时移交至Flywheel。
review
/
critique
/
audit
（或要评估的文件、截图或URL） → 加载并遵循reference/review.md。它会根据书面评分标准对每个原则进行0-4分评分，要求每个评分都有基于证据的理由和下一步修改建议，总分/12，显示标准化的/4平均分和常见质量等级以及最弱维度上限，标记问题优先级P0-P3，将每个问题锚定到精确的界面区域、应用状态和生命周期时刻，并以明确意图结论收尾。该文件定义了评分标准、评分规则、等级、严重性和审计定位——所有内容均在此文件中，无其他来源。
特定技术或反模式问题 → 查阅reference/patterns.md。

在输出任何内容前，请阅读reference/examples.md。它是长度、语气以及锁定模板填写效果的校准标准——模板定义结构，示例设定标准。

Build: the five moves

构建：五步操作

For each screen, in order. Write the answers down—they are the spec.

Name the intent and action model. One sentence: "This screen exists so the user can ___." Reject an "and" only when it joins independently completable outcomes. Classify the register, then name one primary action, an inherent co-equal set, ranked routes, or the content field that leads.
Architect the information. List what belongs on the screen. Group related items; label them in the user's words; infer recognizable inputs before asking the user to classify them; and keep decision-relevant context beside each action. Anything serving a different intent moves to another screen.
Triage disclosure. Minimize decisions, not information. Sort every element into Now / On-demand / Never. Cut the Nevers. Defer the On-demands behind a reveal. Keep the Nows.
Rank what stays. Assign each surviving element or region a tier: dominant (one), secondary (2–3), ambient (the rest). Make the dominant tier express the register's action model, and make the consequence legible without letting supporting visualization outrank the action.
Run the gates. Self-check against the six gates in the ## Gates
block of the Screen Spec template below. That block is the single canonical list—read them there, and emit them there. Never restate them in your own words.

A screen that passes all six is structurally sound by Focal's standard. Apply visual styling and motion on top of that foundation—it lands far better on a screen that already earns its hierarchy.

Output—the Screen Spec (use this exact structure). Every build returns this template verbatim, in this order. Fill the

<…>

slots; keep every fixed label and every gate, even when the answer is one line.

**Screen:** <name>—organized around <one clear intent; no unrelated second outcome>. **Action model:** <one primary | inherent co-equal set | ranked routes | content-led>: <name the action, set, routes, or content field>.
**Register:** task | hub | exploration | task-overloaded   ·   **Audience:** novice | mixed | expert

按顺序处理每个界面。写下答案——它们就是规范。

命名核心意图和操作模型。用一句话描述：「这个界面存在的目的是让用户______。」 仅当「和」连接可独立完成的结果时才拒绝该描述。确定界面类型，然后命名一个主要操作、固有同等重要的操作集、排序后的跳转路径或主导内容区域。
构建信息架构。列出属于当前界面的内容。将相关项目分组；用用户的语言命名；在要求用户分类前推断可识别的输入；并将决策相关上下文与每个操作放在一起。服务于不同意图的内容移至其他界面。
披露分类。减少决策次数，而非信息量。将每个元素分为即时展示/按需展示/永不展示。删除永不展示的内容。将按需展示的内容通过触发元素延迟展示。保留即时展示的内容。
对保留内容排序。为每个保留的元素或区域分配层级：主导（1个）、次要（2-3个）、次要内容（其余）。让主导层级呈现界面类型的操作模型，并清晰呈现结果，同时避免支撑性可视化超过操作模型的权重。
检查关卡。对照以下界面规范模板中**
```
## Gates
```
**部分的六个关卡进行自我检查。该部分是唯一的标准列表——请阅读并输出这些关卡。永远不要用自己的话重述。

通过所有六个关卡的界面在Focal标准下结构合理。在该基础上应用视觉样式和动效——效果会比核心重心不清晰的界面好得多。

输出——界面规范（使用此精确结构）。每次构建都必须返回此模板，顺序不变。填写

<…>

占位符；保留所有固定标签和关卡，即使答案只有一行。

**界面：** <名称>——围绕<一个明确意图；无无关的第二个结果>组织。 **操作模型：** <一个主要操作 | 固有同等重要操作集 | 排序后的跳转路径 | 内容主导>: <命名操作、操作集、跳转路径或内容区域>。
**类型：** task | hub | exploration | task-overloaded   ·   **受众：** novice | mixed | expert

Information

信息架构

<element or group>—<why it belongs / how it's grouped>
Moved off: <element> → <where it goes instead>

<元素或分组>——<归属原因 / 分组方式>
移至其他界面：<元素> → <新位置>

Disclosure

渐进式披露

Now: <shown this visit>
On-demand: <deferred> → behind <reveal>
Cut: <removed; nobody needed it>

即时展示：<本次展示内容>
按需展示：<延迟内容> → 通过<触发元素>
删除：<移除内容；无人需要>

Hierarchy

视觉层级

Primary: <the one element or region that is the visual entry point—the task action, read-first content, leading hub route/group, or exploration content field; when it is an action, name what makes it read as actionable>
Secondary: <2–3>
Ambient: <the muted rest>

主导：<视觉入口元素或区域——任务操作、优先阅读内容、枢纽型主导跳转路径/分组或探索型内容区域；如果是操作，说明其可操作性的提示>
次要：<2-3个>
次要内容：<弱化的其余内容>

States

状态

Empty: <what the screen says and offers with no data>
Loading: <skeleton or optimistic; never a blank>
Error: <plain-language message, at the source, work preserved>
Full (worst case): <how it holds at max realistic data—longest label, most rows>

空状态：<无数据时界面显示的内容和提供的操作>
加载状态：<骨架屏或乐观加载；绝不要空白>
错误状态：<直白语言提示，在错误源处，保留工作内容>
满状态（最坏情况）：<最大真实数据量时的展示方式——最长标签、最多行>

Gates

关卡

One-sentence organizing intent; no unrelated second outcome
Action model matches the register; any co-equal actions are inherent to the same intent
Grouped + labeled; no orphans; no memory bridge
≤4 chunks at any decision point; nothing essential deferred
One element or region is materially heaviest and expresses the action model; any primary action reads as actionable
All four states above designed


Filling it:
- **Repeat any labeled bullet as many times as the screen needs**—`Moved off`, `On-demand`, and `Cut` usually take several lines each. Repeating a label is not adding a section.
- **`<reveal>` means the perceptible cue, not the mechanism.** "Behind an 'Advanced' toggle" and "behind a chevron on the row" are answers; "behind a modal" and "deferred" are not, because neither tells the reader what the user would see that says anything is there.
- **Gates ship unchecked.** Mark `[x]` only for gates the spec actually satisfies; leave `[ ]` with a short reason (one clause) for any it doesn't. Never check a gate the spec does not satisfy—but a spec that genuinely satisfies all six should show all six checked.
- **`Cut` covers removed and replaced.** If a control was needed but has to become a different, safer control, put it under `Cut` and name the replacement—"uncapped refund field → hard-capped to the order total." Cutting an unsafe affordance is not the same as deciding nobody needed it.
- If a labeled bullet has nothing, keep the label and write "None."

Gate 5 is deliberately worded for spec time: it asks whether the spec *assigns* one element or region decisive weight, matches that weight to the action model, and names what makes any primary action read as actionable—all of which a spec can answer. The squint test itself needs a render—run it once the screen exists, and treat a failure there as a review finding, not a build gate.

---

一句话核心意图；无无关的第二个结果
操作模型匹配界面类型；任何同等重要的操作都服务于同一意图
已分组并命名；无孤立内容；无记忆桥梁
任何决策点≤4个模块；无必要内容被延迟展示
一个元素或区域具有明显最高权重并呈现操作模型；任何主要操作都可感知可操作性
上述四种状态均已设计


填写说明：
- **根据界面需要重复任何带标签的项目符号**——`移至其他界面`、`按需展示`和`删除`通常需要多行。重复标签不属于添加新章节。
- **`<触发元素>`指可感知的提示，而非机制**。「通过'高级'切换按钮」和「通过行内箭头」是有效答案；「通过模态框」和「延迟展示」不是，因为它们没有告诉读者用户会看到什么提示。
- **关卡默认未勾选**。仅当规范满足关卡要求时标记`[x]`；未满足的关卡保留`[ ]`并附上简短理由（一个分句）。绝不要勾选规范未满足的关卡——但真正满足所有六个关卡的规范应显示全部勾选。
- **`删除`包括移除和替换**。如果某个控件是必需的，但需要变成更安全的控件，将其放在`删除`下并命名替换项——「无上限退款字段 → 硬上限为订单总额」。删除不安全的控件与判定无人需要该控件不同。
- 如果带标签的项目符号无内容，保留标签并填写「无」。

关卡5特意针对规范阶段：它询问规范是否*指定*一个元素或区域具有决定性权重，是否将该权重与操作模型匹配，以及是否命名主要操作的可操作性提示——这些都是规范可以回答的问题。眯眼测试本身需要渲染——界面完成后再进行测试，并将失败视为评审发现，而非构建关卡。

---

Voice (when giving feedback)

反馈语气

When you review or justify a Focal decision, write like a senior designer reviewing work they want to be great:

Emit the exact output template. Build and review each have a locked structure—the build template is in the build section above, the review template is in reference/review.md. Use it verbatim every time: same sections, same order, same headers, same table columns, same issue-line format. Don't add, remove, reorder, or rename sections; if a section has nothing, keep its header and write "None." Repeatable and scannable is the whole point.
Template precedence. The template is the complete contract for what gets emitted. If any instruction in this skill asks you to produce something the template has no slot for, put it in the nearest slot that fits, or leave it out—never invent a section. A gap like that is a bug in this skill, not a judgment call: name it in one line after the output so it can be fixed. Analysis the template has no room for is still worth doing; it informs the scores even when it isn't printed.
Be specific and quantitative. "There are three primary-weight buttons" beats "too many buttons." Count elements, name the tiers, quote the labels.
Be decisive. "This screen carries two independent intents"—not "this might feel unfocused."
Factual first, then judgment, then the fix. State what you see, why it hurts the user, what it should be instead.
No hedging, no praise padding. Don't sandwich criticism in empty compliments. If something works, say exactly why.
Tie every issue to a discipline. Each problem names which of the three it breaks, and how that obscures the screen's organizing intent. That is the whole point of the lens.
Locate every issue. Name the exact screen or region, rendered app state, and user lifecycle moment where the change belongs. Never make the implementer infer when the finding applies.

当你评审或证明Focal决策时，要像资深设计师评审想要变得优秀的作品一样：

输出精确的模板。构建和评审各有固定结构——构建模板在上述构建部分，评审模板在reference/review.md。每次都要严格使用：相同的章节、顺序、标题、表格列、问题行格式。不要添加、删除、重新排序或重命名章节；如果章节无内容，保留标题并填写「无」。可重复性和可扫描性是核心目标。
模板优先级。模板是输出内容的完整约定。如果本技能中的任何指令要求你生成模板中没有的内容，将其放在最接近的合适位置，或忽略——绝不要创建新章节。这种空白是本技能的漏洞，而非判断问题：在输出后用一行文字说明，以便修复。模板无法容纳的分析仍然有价值；它会影响评分，即使不打印出来。
具体且量化。「有三个主要权重按钮」胜过「按钮太多」。统计元素数量，命名层级，引用标签。
果断。「这个界面承载两个独立意图」——而非「这可能让人感觉不聚焦」。
先事实，再判断，最后解决方案。说明你看到的内容，解释它对用户的影响，提出改进方案。
不要含糊，不要空泛赞美。不要用空泛的赞美包裹批评。如果某部分有效，说明具体原因。
将每个问题与原则关联。每个问题都要说明它违反了三大原则中的哪一个，以及如何模糊了界面的核心意图。这是该视角的核心目标。
定位每个问题。命名精确的界面或区域、渲染的应用状态和用户生命周期时刻。永远不要让实现者推断发现的适用场景。

Absolute don'ts

绝对禁忌

Match-and-refuse. If you're about to do one of these, you've broken a discipline—rework it.

The kitchen-sink screen. (IA) A screen carrying three independent intents is three screens, or an explicit hub with focused task paths.
Structure that mirrors the data model. (IA) Organize by user intent, not by your tables.
Jargon labels and the memory bridge. (IA) Name things in the user's words; carry context forward instead of making them remember it.
Opaque inference. (IA) Never silently infer a consequential value. Show the interpretation, let the user correct it, and provide a manual fallback when confidence is low.
The wall of options. (PD) Defaults plus a reveal, never N equal choices at once.
Information withheld as simplification. (PD) Minimize decisions, not the evidence a user needs to trust, verify, or understand the action.
Burying what the user needs now. (PD) Price, required fields, consequences, and controls required by the action model are never hidden behind disclosure.
Competing primary actions on a task screen. (Methodology / VH) Demote one when they pursue independent outcomes. Preserve an inherent binary-choice or dual-mode set, and never apply this task rule to a hub or exploration surface (see Registers).
A reveal with no cue. (PD) If nothing on screen says something is there, it isn't deferred—it's cut by accident. Gesture-only functions are the worst case.
False signifiers. (VH) Inert things dressed as controls. A shadowed card that doesn't open, underlined text that isn't a link. They spend the attention budget and cost trust on the first tap.
Hierarchy by color alone. (VH) Climb the ladder: space and weight first.
Raw values without meaning. (VH) Do not make users derive a relationship, tradeoff, or process consequence from numbers alone; add a clear summary, comparison, preview, or visualization while preserving exact values as supporting evidence.
Decoration outweighing the action model. (VH) The hero image must not beat the task action, leading hub route, or exploration content field.
Modal as first thought. (VH) A modal interrupts the screen's organizing intent. Exhaust inline and progressive alternatives first.

匹配并拒绝。如果你即将执行以下操作，说明你违反了原则——需重新设计。

杂乱无章的界面。（IA）承载三个独立意图的界面应拆分为三个界面，或明确为带有聚焦任务路径的枢纽型界面。
镜像数据模型的结构。（IA）按用户意图组织，而非你的数据表。
术语化命名和记忆桥梁。（IA）用用户的语言命名；传递上下文而非让用户记忆。
不透明的推断。（IA）永远不要默默推断重要数值。展示解析结果，让用户进行修正，并在置信度低时提供手动输入选项。
一墙选项。（PD）使用默认选项加触发元素，而非同时展示N个同等重要的选项。
为简化而隐藏信息。（PD）减少决策次数，而非用户建立信任、验证或理解操作所需的证据。
隐藏用户当前所需内容。（PD）价格、必填字段、结果和操作模型所需的控件绝不能隐藏在披露后。
任务型界面上的竞争主要操作。（方法论 / VH）当它们追求独立结果时，将其中一个降为次要操作。保留固有二元选择或双模式操作集，且永远不要将此任务型规则应用于枢纽型或探索型界面（详见界面类型）。
无提示的触发元素。（PD）如果界面上没有任何提示表明内容存在，那它不是延迟展示——而是意外删除。仅通过手势触发的功能是最糟糕的情况。
虚假提示。（VH）看似可交互的静态元素。如无法打开的带阴影卡片、不是链接的下划线文本。它们会消耗注意力预算，并在首次点击时损失信任。
仅通过颜色实现层级。（VH）遵循层级阶梯：先使用空间和权重。
无意义的原始数值。（VH）不要让用户从数值中自行推导关系、权衡或流程结果；添加清晰的摘要、对比、预览或可视化，同时保留精确数值作为支撑证据。
装饰元素权重超过操作模型。（VH）英雄图的权重不能超过任务操作、枢纽型主导跳转路径或探索型内容区域。
优先使用模态框。（VH）模态框会打断界面的核心意图。优先尝试内联和渐进式替代方案。

References

参考资料

reference/review.md—the three-discipline audit, the Focal scorecard (0–4 per discipline), severity, and output format.
reference/patterns.md—IA techniques, the progressive-disclosure technique catalog, focus mechanisms and the hierarchy ladder in practice, state care (empty / loading / error / full / first-run / peak-end), and the anti-pattern library with fixes.
reference/examples.md—worked examples: a cluttered dashboard reviewed, and a screen built, both in the locked output templates.

reference/review.md——三大原则审计、Focal评分卡（每个原则0-4分）、严重性和输出格式。
reference/patterns.md——IA技术、渐进式披露技术目录、聚焦机制和层级阶梯实践、状态处理（空/加载/错误/满/首次使用/峰值-结束）以及带修复方案的反模式库。
reference/examples.md——实例：一个杂乱的仪表盘评审，以及一个界面构建，均使用锁定的输出模板。