Menu
进行可用性设计与评估。当用户说"可用性"、"易用性"、"用户界面设计"、"交互设计"、"可用性测试"时使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
执行用户研究与洞察分析。当用户说"用户调研"、"用户画像"、"用户访谈"、"了解用户"时使用。
进行需求分析与优先级排序。当用户说"需求分析"、"需求优先级"、"需求评审"、"写PRD"时使用。
设计产品峰值体验与关键时刻。当用户说"峰值体验"、"用户体验设计"、"关键时刻"、"MOT"时使用。
用数据驱动产品决策，避免认知偏误。当用户说"数据分析"、"AB测试"、"数据驱动"、"指标解读"时使用。
运用心理学原理设计说服机制。当用户说"说服设计"、"转化率优化"、"行为引导"、"心理学"时使用。
设计并执行 MVP 验证实验。当用户说"MVP"、"最小可行产品"、"快速验证"、"原型测试"时使用。
| name | 17-usability-design |
| description | 进行可用性设计与评估。当用户说"可用性"、"易用性"、"用户界面设计"、"交互设计"、"可用性测试"时使用。 |
对现有产品进行可用性审查：
基于可用性原则进行设计：
用真实用户验证设计：
将可用性标准沉淀为设计规范：
| 原则 | 说明 |
|---|---|
| 别让用户思考 | 每个需要思考的地方都是摩擦点 |
| 为扫描而设计 | 用户不读，他们扫——视觉层次要清晰 |
| 出错后好恢复 | 允许 undo，错误提示要说怎么修、不只说出错了 |
| 约定大于创新 | 遵循平台惯例，别造新轮子（除非新方式明显好10倍） |
| 先做再测 | 不要争论，做个原型去测试，5个人就够发现 80% 的问题 |
# 可用性评审清单：[功能/页面名称]
## 基本信息
- 评审日期：YYYY-MM-DD
- 评审人：[姓名]
- 被评审页面/流程：[URL 或截图]
- 目标用户：[...]
- 核心任务：[用户来这个页面要完成什么？]
## 一、自明性检查
- [ ] 页面标题/头部能一眼说清"这是什么页面"
- [ ] 主操作按钮（CTA）明确且突出
- [ ] 用户不需要阅读说明就能开始操作
- [ ] 导航位置和标签符合平台惯例
- [ ] 表单标签清晰，不存在歧义字段名
## 二、功能可见性与意符检查
- [ ] 可点击元素看起来可以点击（按钮有按钮的样子）
- [ ] 不可点击元素不会被误点（没有伪链接/伪按钮）
- [ ] 输入框有 placeholder 提示格式
- [ ] 可滑动/可展开的区域有视觉暗示
- [ ] 图标含义明确（有文字标签辅助或通用图标）
## 三、映射与反馈检查
- [ ] 每个操作都有即时反馈（loading/成功/失败）
- [ ] 加载时间 > 1s 有加载动画
- [ ] 错误提示在出错位置旁边（不是页面顶部飘一个红条）
- [ ] 错误提示说了"怎么修"不只是"出错了"
- [ ] 成功操作有确认反馈（toast/页面跳转/状态变化）
## 四、认知负荷检查
- [ ] 同一屏幕选项数量 ≤ 7（或合理分组）
- [ ] 复杂流程已拆分为多步（有进度条/步骤指示）
- [ ] 默认值合理（减少用户需要填的字段）
- [ ] 高级/不常用选项有收起/渐进披露
- [ ] 同样的操作在不同页面保持一致的位置和样式
## 五、容错性检查
- [ ] 重要操作前有确认（删除/付款/提交）
- [ ] 支持撤销（undo）或至少能回退
- [ ] 表单不会因为一个字段错误清空其他字段
- [ ] 网络错误/超时有重试机制
- [ ] 浏览器后退按钮行为符合预期
## 六、文字与信息检查
- [ ] 文字简洁：能用 5 个字说清的不用 20 个字
- [ ] 没有行话/技术术语（或有解释）
- [ ] 关键数字有单位（"3天后过期"比"72h"易读）
- [ ] 空状态有引导（不是白屏/空列表）
- [ ] 长文本有分段、标题、列表——支持扫描
## 七、移动端适配（如适用）
- [ ] 触摸目标 ≥ 44px × 44px
- [ ] 输入框获取焦点时不被键盘遮挡
- [ ] 横屏/竖屏切换不丢失数据
- [ ] 主操作按钮在拇指热区内（屏幕下半部分）
## 评审总结
### 发现的问题
| # | 问题描述 | 严重程度 | Norman 原则 | 建议修改 |
|---|---------|---------|------------|---------|
| 1 | | 高/中/低 | [哪个原则被违反] | |
### 强制修复（上线前必须改）
- [ ] [问题 #x]
### 建议修复（下个迭代改）
- [ ] [问题 #x]
### 可用性测试建议
- [ ] 是否需要做 5 人可用性测试验证？
- 测试重点任务：[...]
详细理论基础、原则解析和推荐书目见 references/knowledge.md。