第 12 课：UI/UX 设计协作
模块三：产品开发协作 | 第 12 课
课前思考
"界面好不好看"和"好不好用"是两回事。一个好看的界面可能让用户完全不知道下一步该做什么。一个看起来普通的界面可能让用户不假思索地完成操作。
产品经理不需要成为设计师，但需要理解设计的基本原则，才能和设计师有效沟通。这一课不教你怎么画图，而是教你怎么用设计的视角思考产品，怎么把设计思考融入需求定义。
用户体验设计的基本原则
原则一：别让用户思考
用户打开你的产品时，不应该需要"研究"怎么用。操作应该是直觉性的。
- 按钮应该看起来可以被点击（而不是一个装饰性的色块）
- 重要的操作应该在显眼的位置（而不是藏在菜单深处）
- 操作的结果应该是立即可见的（点击了就应该有反馈）
案例：一个极简待办清单。用户打开页面，输入框在正中间，placeholder 写着"输入新任务"。回车，任务出现。点击勾选框，删除线出现。没有任何需要"学习"的地方。
原则二：容错设计
用户会犯错。好的设计让错误容易撤销。
- 删除操作要有确认提示（但不是那种"确定删除吗？"再弹三层的过度确认）
- 关键操作后提供撤销选项（"任务已删除——撤销"）
- 输入错误时给出具体提示，而不是"输入无效"（应该提示"密码不能少于 6 位"）
原则三：渐进式信息披露
不要一次性把所有功能和选项都展示给用户。先展示最核心的功能，次要功能在需要时才出现。
新用户打开待办清单时应该看到的：一个输入框 + 一个空白列表。不是：分类标签、筛选器、排序选项、导出按钮、设置菜单——全部堆在同一个页面上。
产品经理和设计师的协作模式
PM 应该提供什么
- 用户场景和痛点（不是"这个按钮放哪"）：用户在什么情况下会使用这个功能？他们当时的状态是什么？最担心的事情是什么？
- 功能优先级（不是"所有功能都要好看"）：哪些功能是用户最常用的？哪些是偶尔才用的？
- 约束条件（不是"你就看着设计吧"）：有什么技术限制？多端适配的需求？对加载速度的要求？
设计师需要从 PM 那里得到什么
设计师最怕的不是需求多，而是需求模糊。"你觉得怎么好看就怎么设计"——这句话听起来很尊重设计师，但实际上让设计师无从下手。
更好的说法是："这个页面最核心的目标是让用户快速添加任务。用户通常在地铁上用手机操作，注意力分散。所以操作步骤要少，目标要够大，反馈要明显。"
好的需求描述让设计师知道：目标是什么，约束是什么，判断标准是什么。
设计评审：PM 关注什么
当设计师拿出设计稿时，PM 不是去评论"这个颜色不够高级"——那是主观偏好。PM 应该关注：
- 功能完整性：用户需要完成的操作，这个设计都支持了吗？
- 信息层级：最重要的信息在一眼能看到的位置吗？
- 状态覆盖：正常状态、空数据、加载中、失败——这些状态都有对应的界面吗？
- 一致性：同样的操作在不同页面上的表现一致吗？
用故事思维驱动设计
我们在第 7 课学过用故事表达需求。在设计协作中，故事的价值尤其突出。
功能列表 vs 用户故事
功能列表式需求：
首页要有输入框、任务列表、删除按钮、筛选栏、排序选项。
设计师拿到这个，只能按常规做法拼凑。
用户故事式需求：
小李早上通勤时，一只手抓着扶手，另一只手打开待办清单。他想快速记下今天要做的事。输入框要够大，点击区域要够大（单手操作），回车就保存。不需要精准操作。
设计师拿到这个，能想象真实的使用场景，做出符合场景的设计决策。
用户旅程地图在设计评审中的应用
在第 7 课学过的用户旅程地图，同样适用于设计评审。对照旅程地图中每个阶段的用户情绪：
- 情绪低点 → 这里的设计需要特别关注，不能增加用户的负担
- 情绪高点 → 这里的设计可以加强正面体验，让用户感到满足和愉悦
AI 时代的设计协作
用 AI 快速生成设计原型
你可以用 AI 工具（如 v0、Lovable）快速生成交互原型，不需要等设计师出稿再讨论。这些不是"最终设计"，而是"讨论的工具"——让你和设计师、开发者在同一个可见的东西上沟通，而不是各自脑补。
新的工作流：模糊想法 → AI 快速原型 → 拿给用户测试 → 基于反馈写清晰规范 → 设计师精修 → AI 辅助实现。
AI 时代设计师角色在变化
当 PM 可以直接用 AI 生成可交互的原型时，设计师的角色从"画图的人"转变为"定义交互规范的人"。
设计师的价值不在"做出好看的界面"，而在"设计出好用的体验"——理解用户心理、定义交互规则、确保全流程体验的一致性。这些是 AI 无法替代的判断力。
给产品经理的设计沟通清单
当你和设计师讨论需求时，确保覆盖以下内容：
- [ ] 用户是谁？在什么场景下使用？
- [ ] 用户当前的心理状态是什么？（匆忙？专注？放松？）
- [ ] 这个页面的核心目标是什么？（一个页面最好只有一个核心目标）
- [ ] 用户完成操作后，期望看到什么反馈？
- [ ] 如果操作失败了，用户期望怎么被引导？
- [ ] 有哪些技术约束需要考虑？
本课实践
- 找一个你常用的产品，用"别让用户思考"的标准检查它的一个核心流程。你操作时在哪一步犹豫了？为什么？
- 为你 PRD 中描述的核心功能写一段"用户故事式"的设计需求——不是描述按钮和布局，而是描述用户在什么场景下需要什么体验。
- 如果可能，找一个设计师聊 15 分钟：问他在之前的协作中，最希望 PM 提供但常常没有提供的信息是什么。
模块三小结
恭喜你完成了产品开发协作的 4 课。回顾一下：
- 第 9 课：技术基础。前后端分离、API、技术栈选择——不需要会写代码，但需要理解这些概念才能在技术讨论中做出判断。
- 第 10 课：与开发协作。理解开发的思维模式，讲"为什么"而不是"怎么做"，透明管理优先级。
- 第 11 课：测试思维。产品经理不需要写测试代码，但需要在 PRD 阶段预见到边缘情况，验收时覆盖"痛苦路径"。
- 第 12 课：设计协作。用故事和场景驱动设计讨论，关注功能完整性和状态覆盖而非主观偏好。
接下来进入最后一个模块：产品上线与运营——从开发完成到用户手中的最后一段路。