taste-design-review

taste-design-review

像设计总监一样审核：先看截图，再按严重程度列出问题，最后只修复值得修复的问题。

1. 流程（审核 → 排序 → 修复 → 验证）

审核时绝不修复。按以下顺序进行：

1. **截图：**为每种视口尺寸截取完整页面截图（桌面端 1440、平板端 768、移动端 390）。审视页面的实际样子，而不是你想象中的样子。
2. **初读（8 秒）：**这个页面在说自己是什么？不滚动页面，你能说出产品、受众和主要操作吗？
3. **结构化检查：**按顺序应用以下检查项。
4. **问题排序：**P0（损坏／法律风险／阻塞）／P1（严重损害品质）／P2（润色）／P3（偏好）。
5. 按排序结果修复，每次只做一个原子级改动；重新截图，并验证每项修复都没有破坏设计主张。
6. **报告：**用表格列出问题、截图引用、严重程度，以及每项问题的一句话修复方案。

2. 品味检查（视觉品质）

• **扼杀感检查：**这个页面会不会像是由默认 Agent 生成的（低质模式：紫色渐变、居中式 Hero + 3 张卡片、表情符号图标、仅用 Inter、rounded-2xl、带浏览器边框的截图）？每个“会”都是 P1。
• **层级：**每个视口是否只有一个主导元素？视线是否落在业务希望用户关注的位置？
• **字体：**有没有小于 10px 的文本、超过 3 种字重、缺少展示字体对比、正文铺满宽度、6 行段落、标题中的孤行？
• **颜色：**是否有超过约 3 种有意义的颜色、用渐变做装饰、每个视口中强调色使用超过 4 次、浅色填充上使用白色文本、对比度不达标（具体标准：正文 4.5:1／大号文本 3:1／UI 3:1）？
• **对齐：**共用同一边缘线的元素是否对齐（目测检查）；是否采用细线网格，而非散落的悬浮卡片；间距尺度是否统一（有没有 7px 或 13px 的内边距？）。
• **层次感：**是否只靠阴影营造层次；是否到处使用玻璃拟态；是否存在卡片套卡片、层层嵌套的情况？

3. 启发式检查（可用性——应用 Nielsen 的 10 项原则）

1. 系统状态可见性（2–3 秒）：每项操作都有反馈；没有无响应的按钮；存在加载状态。
2. **与现实世界相符：**使用用户的语言，而非公司的语言（消费类网站上写“部署实例”＝不合格）。
3. **用户控制与自由：**到处都有退出路径；破坏性操作可以撤销。
4. **一致性：**同一种操作在任何地方看起来都相同；按钮样式统一；前往同一目的地的方式统一。
5. **错误预防：**破坏性操作需要确认；提交按钮有防误触措施；表单启用自动补全。
6. **识别而非回忆：**不使用自创术语；导航名称清晰易懂。
7. **灵活性：**为重复使用的用户提供快捷方式（搜索、键盘操作），同时不让新手路径变得杂乱。
8. **美观与简约：**任何遮挡主要操作的内容都是噪声。如果某个元素没有作用，就在报告中将其删除。
9. **清晰传达错误：**每条错误信息都说明发生了什么、原因是什么，以及该怎么做——绝不能只写“错误”。
10. **帮助与文档：**用户遇到困难时就提供帮助，而不是放在无人访问的帮助中心里。

4. 无障碍检查（简版——参见 taste-accessibility）

• 使用 Tab 键逐项切换：每个焦点位置都清晰可见；没有焦点陷阱；顺序符合逻辑。
• 每个输入框都有标签；每个按钮／链接都有文本；替代文本有意义，或留空。
• 对每种不同的界面区域抽查对比度（标题／正文／按钮／占位符）。
• 处理 prefers-reduced-motion；暂停任何自动播放或自动切换的内容。

5. 转化检查（如果用户要求改进，而不只是审核）

• 首屏上方有一个主要 CTA；次要操作在视觉上更弱，或延后显示。
• 用户能在 ≤ 8 秒内理解价值主张（由标题传达，而不是副标题中的副副标题）。
• 梳理阻力：从“感兴趣”到“开始”之间的字段、步骤和点击次数——每一项都要有合理依据。
• 在用户做决定的地方提供信任信号（CTA 附近、定价区域）：社会认同、保障、没有隐藏条款。

6. 报告格式（固定）

## Audit — <page> (<viewport set>)

### P0 — Blocking
- [screenshot ref] finding + one-sentence fix

### P1 — Quality
...

### P2 — Polish
...

### P3 — Preference
...

### Verdict (one paragraph)
Is the design argument clear? What single change would improve the page most?

严重性准则：P3 项目可以列出，但绝不能在修复 P1 项目的同一轮会话中修复。结论只点明一项更改——如果你无法指出一项，说明审计没有找到真正的问题。

7. 检查清单（若出现以下情况，审计不通过……）

• 未截取或查看截图（绝不能只依据代码进行审计）。
• 问题未标明严重性或截图引用。
• 将劣质模式视为“风格偏好”而不予处理（它们属于 P1）。
• 完整审计尚未结束，就修复了页面上的任何内容。
• 结论没有指出一项最重要的更改。