Google UX 证书 / 测试·迭代·设计评审·交付

设计做出来之后的环节:测什么时候算"做完"、怎么基于反馈迭代、怎么开设计评审会、怎么把设计交付给开发。可用性研究本身的做法在 Google UX 证书 / UX 研究与共情-定义 §六,这里讲拿到测试结果之后怎么办。

对 PM 的意义:设计评审(design critique)这套"3 角色 + 描述问题不给方案 + 反馈转行动"的规则,几乎可以直接搬到你的需求评审/方案评审会——尤其"评论者只描述问题、不替对方改设计"和"会后把反馈分类成采纳/暂缓/需澄清"这两条,能立刻改善你团队的评审质量。

一、判断设计"完成"的 3 标准

做完原型、测试、评审、修改后,设计师常纠结"真的做完了吗"。别只用"时间/预算到了"当唯一标准。问这 3 个问题,全是"是"就可以交付:

能实现想要的用户体验吗? 用户能顺利完成主要操作吗?
临时内容都换成正式的了吗? 文字/图标/图片都是真实的(非占位符)吗?
用户不用人教就能看懂吗? 你不在旁边解释,用户能自己明白怎么用吗?

心态:不追求完美。产品上线后还会持续迭代(几周/几个月就更新),重点是每次有进步。新手对"不改了"会焦虑,经验多了自然知道何时该交。

二、迭代高保真设计

第二轮可用性测试后,根据反馈在 Figma 更新。关键省力技巧:高保真原型迭代耗时,优先改静态 Mockup 解决问题,再补交互。

真实案例(遛狗 App 第二轮洞察):

洞察"用户难从日历选日期" → 把滚轮选择器换成下拉菜单 + 弹出完整日历(显示日/月/星期几),用 Figma 社区现成日历组件改样式。

洞察"用户到流程结束才看到价格" → 在首页遛狗员卡片的评分/距离后加上价格(用 Material Design 的 "$" 图标),让用户能提前比较。

迭代流程:旧页面移出 → 新页面替换进用户流程 → 重测完整流程。

三、设计评审 Design Critique(核心)

团队一起给设计提意见的有组织会议。Kunal(Google Material 团队)的比喻:"像穿了新衣服给朋友看,让他们说好不好看"。价值:避免设计师陷入细节、引入外部视角、锻炼表达与判断。不分资历,人人既当 Presenter 又当 Reviewer。

3(+1)角色

角色	职责
主持人 Facilitator	控流程/时间、保证目标聚焦、人人有机会发言(小型评审可省)
呈现者 Presenter	讲设计 + 背后逻辑,积极听取、提问澄清(不当场辩解)
评论者 Reviewer	给建设性反馈,描述问题、提优化方向,不直接给解决方案(通常多位)
(可选)记录员 Notetaker	记下所有反馈,让 Presenter 专注对话

4 步流程 + Presenter 的 5 个准备问题

流程:① 主持人介绍目标(明确评审重点,如"评预约流程,不是图标细节") → ② 呈现者展示(目标用户/背景/逻辑/界面流程) → ③ 评论者反馈(建议分阶段:喜欢的 → 疑问 → 可能的问题) → ④ 总结(确认目标是否达成,记要点,排后续)。

Presenter 展示前用 5 问梳理(讲思考,不只讲页面):① 为谁设计? ② 解决什么问题? ③ 设计如何解决? ④ 进展到哪步? ⑤ 想要哪方面反馈? 复杂设计提前发原型预习;时间有限只讲关键 + 只展示最想要反馈的部分(别展示首页却问购物车)。

给 / 收反馈的技巧

收反馈:把反馈当"礼物"不是攻击;听"问题背后"的思考而非个人否定;不必全采纳,提取有价值的。会后必须有行动——设计像船,反馈是指南针。

给反馈 3 技巧:

考虑对象:对 PM/工程师/设计师、新手/资深,用对方能懂的方式。
解释"为什么":不说"我不喜欢这颜色",说"这颜色对色弱用户不友好,可能分辨不清"。
描述问题,不给方案:✅"这按钮位置可能让用户难注意到" ❌"你应该把按钮放右上角"。

学生实操:分享作品邀人提建议 → 记录反馈 + 标注是否采纳及原因 → 下轮体现优化 → 轮流扮演设计师/评论者双向练。

反馈转行动(6 类判断)

会后回顾笔记,逐条判断价值,列 action items。核心是分类——不是所有反馈都要改:

反馈类型	处理
无设计原则支撑的措辞建议("谁去散步"→"哪只狗散步")	"锦上添花",可不改
需跨角色配合的新功能(支持单独遛多只狗)	联系 PM/运营评估可行性,发邮件约会讨论
明确的体验缺口(只有一只狗的流程)	直接做额外屏幕支持
一致性问题(按钮大小/位置不一)	Figma 逐一检查统一(对齐 x/y 坐标)
表意不清的反馈(简化顶部图标——指颜色还是文字?)	回去问清楚再动手
可量化的标准(橙色 CTA 对比度)	用 WebAIM 测,不达标换更深橙 `#D53E0B`;Figma "Selection Colors" 批量替换

四、交付开发 Handoff

高保真原型完成后,大部分开发规格(specs)已在 Figma 里。但两类需额外单独记录给开发:① 边缘案例 Edge Cases(错误状态、空页面、断网) ② 无障碍考量(辅助技术用户)。

两种交付模式(看公司规模)

	小公司 / 设计代理	大公司(如 Google)
比喻	接力赛——设计师冲刺到完成,交棒给工程,转去别的项目	并行协作——设计基本完成后工程接手仍可能小幅调整;工程做个人页/购物车时,设计师继续完善主页/导航
设计完成度	高,设计师开发期参与低	持续协作,可能返工,沟通是关键

Figma Handoff 准备

设计是团队协作:PM 留言提意见、文案改文字、研究员分享原型做测试、开发查细节/复制代码/下素材。要点:

缩略图:1920×960,中间 1600px 总能看到,放当前状态/团队信息/规范链接(右键画布"设为缩略图")。
权限:编辑(改文件)vs 查看(留言/下素材/看原型,免费)。
何时邀开发:早期问"能不能实现",后期"准备交付"。
查看模式:有检查面板(看图层/样式/代码)和导出面板(下图标素材)。

作品集案例研究(case study)的写法见 Google UX 证书 / 作品集·简历·面试·求职——本课的"创建作品集案例研究"内容并入那里。

关键术语速查(Glossary)

英文	中文	一句话
Design Critique	设计评审	团队给设计提意见的有组织会议
Facilitator / Presenter / Reviewer	主持人/呈现者/评论者	评审 3 角色,不分资历轮流当
Action Items	行动项	反馈分类后的可执行任务
Iterate	迭代	基于反馈改进,优先改静态 Mockup
Handoff	交付开发	把设计规格交给工程实现
Edge Cases	边缘案例	错误/空页面/断网等特殊情境,要单独记
Specs	设计规格	开发所需的尺寸/样式/代码,Figma 自带
Selection Colors (Figma)	选区颜色	框选批量替换颜色