检查实现和设计稿
差了多少
- 01找到设计稿
- 02逐页对照实现
- 03标记还原差异
无设计稿或实现已偏离时,检查基准失效。
从输入到交付,
每一条结论都有来路。
WHY / 为什么做
真实项目里,设计稿不一定存在,实现结果也不一定与设计稿一致。比起追问“还原了多少”,更需要回答“用户面对的实际产品好不好用”。
无设计稿或实现已偏离时,检查基准失效。
以用户最终面对的产品为证据起点。
METHOD / 方法
先锁定人、任务、环境和成功标准,再进入界面。这会让设计判断有边界,也让后续修改真正可验收。
REVIEW BRIEF · 7/7 CONFIRMED
确认走查范围、主要用户、核心目标、关键任务、PC 使用情境、成功标准和失败影响。
EVIDENCE / 证据
实际交互、页面截图、DOM、无障碍树和代码证据分别归档,不把推测包装成观察。
影响来源、用户任务和业务风险单独表达;没有用户实测,就不虚构错误率或效率数据。
高、中置信的确定问题才进入问题清单;其他风险进入待验证队列,并给出验证方法。
COVERAGE / 覆盖
页面视觉、关键任务和适用状态分别展示。每一个目标只能是已验证、有问题、未测试、不适用或被阻断。
OUTPUT / 交付
REPORT.MD
范围、方法、覆盖、问题、待验证风险、正向模式与限制。
REPORT.JSON
Issue、task、surface、state、evidence 和 coverage 双向引用,可继续处理。
ANNOTATIONS
URL 与截图模式的确定问题附带标注与 bbox,不手估位置。
REPORT.DOCX
经结构和标注校验后生成,适合审阅、归档与设计评审。
FOLLOW-UP REVIEW
不记录“开发说已完成”,只判断修改后的实际设计体验,并检查受影响页面与相邻状态的回归。
BOUNDARIES / 边界
管理后台、业务工作台、数据管理、运营、配置与审批系统。
它们是 PC 体验的一部分,与对比度和辅助技术一起进入正式检查。
App、小程序、手势与跨设备连续性不在这套 Skill 的正式结论范围内。
INSTALL THEN REVIEW
这个页面现在包含真实的 ux-walkthrough Skill。先将安装指令发给 Codex;安装完成后新建一个任务,再用 $ux-walkthrough 调用。未安装时,调用指令只是普通文字。
$skill-installer
请从 GitHub 仓库 https://github.com/liuyahui59/designhub-site 的 ux-walkthrough-skill 目录安装这个 Skill。安装完成后告诉我实际安装路径。
查看完整 Skill 源码
$ux-walkthrough
对这个 PC 端 B 端产品做一次体验走查。
输入:<代码库 / URL / 截图>
本次范围:<页面或流程>
请先完成设计走查前置调查,再按四阶段流程执行。