以任务为中心的产品UX设计
从用户的实际处境和预期目标开始。现有的设计系统、研究和已提供的设计稿都是证据；不要用一个通用仪表板来替换它们。阅读模式与反例中相关任务类型的部分，而不是每个模式。
构建屏幕之前
对于每个主要角色/任务，识别触发器、已知信息、需要做出的决策、完成结果和恢复路径。当不同角色的工作流决策不同时，将其分离；当任务和上下文真正匹配时，共享屏幕。
生成与变更规模相称的紧凑流程图和低保真布局。对于每个可见区域状态：
- 用户现在需要哪个决策或操作来触发它？
- 它是主要的、上下文细节的，还是在此视图中不必要的？
- 哪个需求、来源或明确的设计决策为其提供了理由？
使用这些来筛选信息，而不是生成更多的产品文案。不要自动添加概览卡片、图表、横幅、过滤器、导航、AI解释或“即将推出”面板。只有当有人做出相关决策时，指标才属于这里。技术来源信息可以在需要判断新鲜度或有效性时纳入；调试日志和实现状态通常应保留在开发记录中。
不要盲目地最小化。保留无障碍说明、有意义的错误信息、必要的上下文、必需的披露以及决策的后果。主要操作是一个有用的默认值，而不是一个任意的单按钮限制。避免仅仅为了减少可见控件而将重要操作隐藏在通用菜单后面。
状态与交互
建模相关状态：初始、加载、空、失败、成功、编辑/未保存、陈旧结果以及权限约束。只使用产品需要的状态。确保选中的输入和显示的结果引用相同的上下文。在可恢复的错误发生时，保留用户的工作。在静默更改会使用户感到意外的情况下，选择显式操作。
当选择编辑界面或更改有状态布局时，阅读交互模式选择。根据任务复杂性、频率、上下文需求和可用空间，选择内联编辑、对话框或独立页面；不要仅仅为了隐藏布局错误而使用模态框。检查重要控件的之前/之后位置、滚动和焦点。有意的信息披露可能会移动内容；偶然的跳转或消失的目标需要修正。
使用项目的设计标记、组件、语言和无障碍约定。通过可用的受支持工具检查提供的参考；缺少Figma MCP本身不是停止的理由。切勿将未经检验的设计标记为匹配。不要仅仅为了一个小改动而引入新的组件库。
在有效/错误/恢复状态下检查可访问名称和描述，而不仅仅是视觉可见性和焦点。当被可访问描述引用时，隐藏的消息仍然可以被暴露；仅在错误适用时连接错误文本。
审查渲染后的流程
使用可用的浏览器或应用程序工具，从实际入口点执行任务。检查结构和控件的标签，以及渲染截图中的层次结构、裁剪、间距和视觉状态。仅靠自动化无障碍检查或DOM检查不能证明视觉或可用性质量。
对于响应式检查，确认浏览器的实际视口尺寸并检查最终捕获的图像。单独裁剪截图、更改元素宽度或检查水平溢出并不是等效的视口测试。如果工具无法设置或验证视口，则标记该覆盖项为未验证。将截图与报告的结果进行核对：缺少内容、不可用的换行或不可见的操作不能仅仅因为DOM检查通过就称为视觉通过。
对于每个发现，记录：复现步骤 → 观察到的行为 → 对用户的影响 → 最小可行的修正 → 重新检查。将推断与观察分开标记。在添加解释之前，优先考虑移除、移动、合并或改进默认值。除非更改或剩余问题证明有必要，否则不要重复已通过的审查。
如果无法访问浏览器，则审查代码/布局证据并将运行时UX标记为未验证；继续独立工作。不要伪造截图、点击或用户验证。开发者或代理的审查不是用户研究。