# App Interaction Review

> 从宝妈用户视角评审 APP 交互是否合理、视觉是否冲突，给出可选交互方案并附可点击交互 Demo。 Use when the user mentions 交互、交互评审、交互是否合理、视觉冲突、交互方案、交互 demo, or shares APP 截图 / 设计稿 asking for interaction/UX feedback for mom users.

- Skill: `lareina0011/app-interaction-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lareina0011/app-interaction-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lareina0011/app-interaction-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lareina0011 (https://skillmd.com/u/lareina0011)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/lareina0011/app-interaction-review

---


# APP 交互评审（宝妈视角）

面向群体默认是**宝妈**（一手抱娃/忙碌、碎片化操作、易分心、偏好少步骤与低认知负担）。收到截图或设计稿时，按本流程评审；不要做成通用 UI 审美点评。

## 何时启用

用户带「交互」相关表述，并附上 APP 截图、设计稿、原型说明时启用。输入不足时先问清：目标页面/任务、当前方案意图、有无可选竞品或约束（品牌规范、已定组件）。

## 工作流

1. **读图与还原任务**：标出主任务、次要入口、状态反馈、拦截/确认。只评可见与用户说明，缺信息再问，不臆造未展示的流程。
2. **宝妈场景压力测试**（见下方清单）：一手操作、夜间/碎片时间、疲劳、中断后回来等。
3. **合理性 + 视觉冲突判断**：操作路径、反馈、层级、可点区域、文案含义是否冲突或抢注意。
4. **输出**：严格按「输出结构」——**先结论与理由，再给方案**；方案必须附带**可点击交互 Demo**（用户明确说不要 Demo 除外）。
5. **落盘 Demo**：写入工作区可打开的 HTML；在回复里给出文件路径与如何打开。

## 宝妈视角检查清单

按项过一遍，有问题在「理由」里点名：

| 维度 | 关注点 |
|------|--------|
| 一步达成 | 核心任务是否能少步完成；有无多余确认/跳转 |
| 一手可用 | 主按钮是否落在易触区；关键操作是否需精细点按 |
| 即时反馈 | 点击后是否立刻有状态/结果；等待是否说明「在做什么」 |
| 容错可逆 | 误触成本；危险操作是否有清晰确认且文案不吓人费解 |
| 中断恢复 | 离开再回能否接上；草稿/进度是否保留或可感知 |
| 认知负担 | 一次屏上决策是否过多；名词是否口语化、少 jargon |
| 情绪负担 | 警告/失败是否指责感；空态是否给下一步而非冷冰冰 |
| 时间压力 | 是否适合「抽空点两下」；长流程能否分段或稍后继续 |

## 视觉与交互冲突检查

重点找「看起来像能点但点不了 / 看起来重要但不该抢主任务 / 状态含义打架」：

- **层级**：主操作、次操作、装饰信息谁在抢第一眼
- **可点击性**：链接色、按钮样式、卡片、图标是否误导为可点或不可点
- **状态表达**：选中/禁用/加载/错误/成功是否易混；图标与文案是否打架
- **密度与留白**：信息过挤导致误触或扫读困难
- **对比与可读**：弱对比、小字、图标无文字依赖（宝妈常边看娃边扫一眼）
- **一致性**：同类操作在不同屏交互方式是否突变

## 输出结构（必须按此顺序）

### 1. 结论

用短句直接说：

- **总体判断**：合理 / 基本合理需改 / 不合理（择一）
- **主要问题**（如有）：列 1–3 条，每条一句话
- **视觉冲突**（如有）：点名冲突点；没有则写「未见明显视觉冲突」

### 2. 理由

对照宝妈场景与检查清单，说明**为什么**下上述结论。引用图中具体元素（按钮文案、位置、弹层、色块），避免空泛「体验不好」。

### 3. 交互方案（2–4 套）+ Demo

每套方案固定格式：

```markdown
#### 方案 A：{一句话命名}
- **怎么改**：步骤/控件/流程怎么变（可对照原设计说差异）
- **适合**：什么场景/约束下优先选
- **代价**：实现成本、学习成本、或牺牲的能力
- **宝妈收益**：对哪条压力测试有帮助
- **Demo**：见下方文件中的「方案 A」标签 / 对应区块
```

方案之间要真有差异（例如：减少步骤 vs 加强确认；底部主操作 vs 就地操作；弹窗 vs 页内引导），不要只换文案。最后用一句话标明**若无特殊约束，更推荐哪套及原因**（仍尊重用户自选），并明确写出 Demo 路径。

## 交互 Demo 规范

默认交付**一个自包含 HTML**（单文件，无构建、无外网依赖），用浏览器直接打开即可点。

| 项 | 要求 |
|----|------|
| 路径 | 工作区如 `interaction-demos/{页面或任务名}-demo.html`；用户指定目录则按其目录 |
| 结构 | 顶部切换「原方案（若需还原）/ 方案 A / B / C…」；下方为手机框（约 375px 宽）内的可点界面 |
| 保真度 | **交互保真优先**，视觉近似即可：复现关键按钮、步骤切换、弹层/Toast、禁用态、成功/失败反馈；不追求像素级还原 |
| 必须可点 | 主任务路径从头走到结果；误触相关的确认/撤销若在该方案中，也要能点到 |
| 标注 | 每套 Demo 内短注「本方案差异：…」，避免用户忘了在对比什么 |
| 禁用 | 用户说「只要文字方案 / 不要 Demo」则跳过落盘 |

实现约定：

- 纯 HTML + CSS + 少量 JS；状态用简单 show/hide 或 class 切换。
- 触控热区按宝妈场景偏大（主按钮高度不宜过小）。
- 不引入 React/Vue/构建工具，除非用户明确要求其他形态（如接入现有项目组件）。

## 读图注意

- 先描述你「理解的当前交互」再评审，便于用户纠偏。
- 用户若说明「这是草稿/局部」，只评该范围，并标明假设。
- 多张图按任务流串起来评，不要割裂成纯画面审美。

## 边界

- 不替代完整可用性测试；结论是设计评审建议。
- Demo 是示意原型，非正式开发交付物。
- 无障碍、品牌规范仅在用户提及或图中明显违例时点到。
- 不输出与本次交互无关的大重构或重做视觉系统建议，除非冲突根源在此。