Back to Details

heuristic-evaluation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Heuristic Evaluation

启发式评估

Purpose

目的

Run a structured usability evaluation of a flow using Nielsen's 10 usability heuristics, independent of visual style.
基于尼尔森的10条可用性启发式原则，对流程进行结构化可用性评估，评估过程独立于视觉风格。

Operating Role

操作角色

Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes.
作为此特定技能的Figma设计文件评审者。先检查当前选中内容，给出有证据支持的发现，除非用户要求修改，否则避免宽泛的重新设计。

Supported Context

支持场景

  • Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits.
  • Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations.
  • Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption.
  • Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions.
  • 默认范围为当前选中内容。若未选中任何内容，仅使用当前页面进行评审/报告任务；进行全文件编辑前需先询问用户。
  • 优先使用可见的Figma设计文件上下文：框架、组件、实例、变量、样式、图层、原型设置、评论、分区和注释。
  • 仅当用户提供或会话中已有连接器或代码上下文时，才使用该类上下文。基于缺失上下文得出的结论需标记为假设。
  • 最多提出两个针对性问题，且仅当缺失的答案会实质性改变结果时才提问。否则基于已说明的假设继续执行。

Activation Boundary

触发边界

  • When usability, not visual polish, is the concern
  • Before user testing, to catch obvious issues cheaply first
  • 当关注点为可用性而非视觉美化时
  • 用户测试前，先低成本排查明显问题

Required Inputs

必要输入

  • The flow (ordered set of screens) to evaluate, or a single screen if that's the scope
  • If an input is missing but can be inferred safely from the selection, proceed and label the assumption.
  • 待评估的流程（有序的界面集合），若范围限定则为单个界面
  • 若输入缺失但可从选中内容安全推断，则继续执行并标记该假设。

Fast Defaults

快速默认规则

  • Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file.
  • Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low.
  • Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible.
  • Use heuristics as lenses, not as a generic checklist. Report only issues visible in the selected flow.
  • 从选中的框架、组件、分区或评论线程开始。若用户指定了范围，则使用该范围而非扫描整个文件。
  • 无需等待完美上下文，先完成有用的初步检查。当风险较低时，简要说明假设并继续推进。
  • 优先使用文件内证据而非通用最佳实践。尽可能明确指出具体的图层、框架、变量、样式或交互。
  • 将启发式原则作为分析视角，而非通用检查清单。仅报告选中流程中可见的问题。

Workflow

工作流程

Walk the flow once per heuristic and record concrete violations, referencing the specific screen/element:
  1. Visibility of system status -- does the user always know what's happening (loading, progress, confirmation)?
  2. Match between system and the real world -- does language and iconography match user mental models, not internal jargon?
  3. User control and freedom -- is there an obvious way to undo, cancel, or go back at every step?
  4. Consistency and standards -- do similar actions look and behave the same way throughout the flow?
  5. Error prevention -- are destructive or hard-to-reverse actions confirmed or made hard to trigger by accident?
  6. Recognition rather than recall -- are options visible when needed, rather than requiring the user to remember something from an earlier screen?
  7. Flexibility and efficiency of use -- are there reasonable shortcuts for repeat/expert users without cluttering the default path?
  8. Aesthetic and minimalist design -- is every element earning its place, or is there competing/irrelevant information?
  9. Help users recognize, diagnose, and recover from errors -- are error messages specific, in plain language, and paired with a way to fix the problem?
  10. Help and documentation -- for complex actions, is contextual help available where it is needed, not just in a separate help center?
针对每条启发式原则遍历一次流程，并记录具体违规情况，引用对应的具体界面/元素：
  1. 系统状态可见性——用户是否始终知晓当前状态（加载、进度、确认）？
  2. 与现实世界匹配——语言和图标是否符合用户心智模型，而非内部术语？
  3. 用户控制与自由——每一步是否有明显的撤销、取消或返回方式？
  4. 一致性与标准——整个流程中，相似操作的外观和行为是否一致？
  5. 错误预防——破坏性或难以逆转的操作是否需要确认，或设置为难以意外触发？
  6. 识别优于回忆——需要时选项是否可见，而非要求用户记住之前界面的内容？
  7. 灵活性与使用效率——是否为重复操作/专业用户提供合理快捷方式，且不打乱默认操作路径？
  8. 极简美学设计——每个元素是否有存在的必要，是否存在相互竞争或无关的信息？
  9. 帮助用户识别、诊断并恢复错误——错误信息是否具体、通俗易懂，并提供解决方法？
  10. 帮助与文档——对于复杂操作，是否在需要的位置提供上下文帮助，而非仅在独立的帮助中心？

Figma Execution Limits

Figma执行限制

  • Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently.
  • For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes.
  • For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing.
  • Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available.
  • Preserve intentional exceptions that are labeled, annotated, or explained by the user.
  • 任务需限定在本技能范围内。若需要相关工作，应将其列为后续任务，而非擅自扩大范围。
  • 对于仅需报告的请求，请勿修改文件。对于修复/应用请求，除非用户批准更广泛的更改，否则仅进行限定范围的可撤销编辑。
  • 进行批量更改前，需预览规则及受影响的数量。跳过模糊的图层、组件、变量或文案，而非猜测。
  • 除非实际拥有相关上下文，否则请勿声称可访问私有库、管理员设置、分析数据、插件状态或代码。
  • 保留用户标记、注释或解释过的有意例外情况。

Guardrails

约束规则

  • Only report a violation if it is concretely observable in the flow -- do not pad the report with heuristics that have nothing to flag.
  • Rate severity (Critical / Moderate / Minor) per Nielsen's standard severity scale so findings can be triaged.
  • 仅当违规情况在流程中可具体观察到时才报告——请勿在报告中添加无问题可标记的启发式原则内容。
  • 根据尼尔森的标准严重程度等级对问题进行评级（严重/中等/轻微），以便对发现的问题进行优先级排序。

Finding Quality Rules

发现质量规则

  • Lead with the highest-impact issues, not the order discovered.
  • Tie each finding to a specific frame, layer, component, variable, style, comment, interaction, or supplied source.
  • Include severity only when it changes priority: Blocker, High, Medium, or Low.
  • Pair every finding with an exact fix, replacement, or next decision.
  • Separate confirmed findings from assumptions, recommendations, and unverified areas.
  • 先呈现影响最大的问题，而非按发现顺序排列。
  • 每个发现需关联到具体的框架、图层、组件、变量、样式、评论、交互或提供的来源。
  • 仅当严重程度会改变优先级时才标注：阻塞、高、中、低。
  • 每个发现需搭配确切的修复方案、替代方案或下一步决策。
  • 将已确认的发现与假设、建议和未验证区域分开。

Output Contract

输出规范

Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas.
  • Skill-specific format: One section per heuristic with violations found (or "No issues observed"), each violation rated by severity.
以3行摘要开头：评审范围、阻塞问题数量、最高风险问题。然后按分组呈现发现内容，包含位置、严重程度、证据和确切修复方案。最后列出跳过或未验证的区域。
  • 技能特定格式：每条启发式原则对应一个章节，列出发现的违规情况（或“未发现问题”），每个违规情况需标注严重程度。