前一批笔记(NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估))讲"怎么检验设计好不好",这一批讲设计这件事是怎么一步步推进、每一步交出什么东西——从"还没动手前怎么搞清要解决什么问题"(探索),到"怎么把脑子里的方案画出来"(线框/草图/原型),到"怎么把方案交给开发"(设计规格),再到"用什么文档跟不同人沟通"(交付物),以及贯穿全程的三件协作工具(专家评审、工作坊、故事板、问卷)。
一句话串起来:先别急着想方案(探索阶段保持发现心态)→ 把问题和未知摆上台面(CSD 矩阵)→ 粗粒度画想法(线框、草图)→ 做成能测的原型(保真度按测试目标选)→ 测完精修后交给开发(设计规格)→ 全程用合适的交付物跟对应受众沟通。
全文五块:一、探索阶段(心态·7 技巧·CSD 矩阵·启动项目) 二、线框与协作草图(画线框·让干系人画·Promptframes) 三、原型保真度(低保真 vs 高保真·可点击 vs 静态) 四、设计规格与交付物(spec·交付物术语·最常用) 五、协作三件套(专家评审·工作坊·故事板·过程中的问卷)。每节给心法 / Why / 反例。
一、探索阶段 Discovery:动手画之前,先搞清要解决什么
探索(Discovery)= 设计动手之前那段"搞清楚到底要解决什么问题"的工作。它最大的敌人不是缺信息,而是"团队还没研究就已经认定了方案"。这一块的四篇文章,核心都在对抗"过早收敛到方案"这件事。
1.1 发现心态 Discovery Mindset:围绕问题,而非解决方案
心法:探索者 vs 显微镜下的生物学家。 发现心态像一个登上新大陆的探险家,对"问题空间里有什么"保持开放;解决方案心态像生物学家在显微镜下盯着一个既定生物体看——视野已经被框死了。
Why——解决方案导向会触发两个认知偏差:
| 偏差 | 通俗解释 | 后果 |
|---|---|---|
| 锚定效应 Anchoring | 团队从一个既定方案出发,只验证"这个方案行不行",而不问"问题到底是怎么产生的、影响谁" | 漏掉问题本质 |
| 确认偏差 Confirmation Bias | 一旦偏爱某方案,就主动找支持它的证据,回避反面证据 | 自我说服,造出不合适的产品 |
3 招避免掉进解决方案心态:
- 重新定义目标 Reframe the Goal——别把目标写成"设计一个能追踪订单的跟踪器",而要写成它背后要解决的问题:"如何让用户对订单履约进度有透明感、增加信任"。例:仪表板真正的问题是"帮用户用实时数据做决策";聊天机器人是"用户有疑问时提供支持与安心"。问题导向的目标会自然引出研究问题(用户决策时需要哪些数据?什么时候需要?怎么用?)。
- 突出未知与假设 Highlight Unknowns and Assumptions——在 kickoff 工作坊里问"我们对用户需求、行为、问题情境有哪些假设?",并区分哪些未知是关键的、哪些只是 nice-to-know。
- 冻结心爱的想法 Icebox Favorite Ideas——把团队现有的方案点子先"冷冻"记录下来,等探索研究做完再评估。好处不只是防止过早收敛:把想法记下来能让提想法的人觉得"我被听见了",缓解他们对"方案被丢掉"的焦虑。
反例: 探索目标写成"找出 AI 聊天机器人如何回答用户的关键问题"——这已经预设了"要做聊天机器人",团队接下来只会去验证聊天机器人可行不可行,而不会去问"用户的核心问题到底该用什么方式解决"。
1.2 成功探索的 7 个技巧
探索阶段充满不确定性和协作摩擦。7 条实操建议:
| # | 技巧 | 怎么做 / 关键数字 |
|---|---|---|
| 1 | 先拿支持 Secure Buy-in | 启动前让成员和关键干系人理解探索的目的(理解问题 ≠ 立刻设计方案)。团队已偏爱某方案时,用工作坊揭示其中的未知与假设,让大家意识到直接上方案有风险 |
| 2 | 明确角色与规范 Roles and Norms | kickoff 就分清谁负责哪块研究;约定协作规范,如"每人每周至少参加一次用户研究""每天一次简短站会" |
| 3 | 写问题陈述 Frame the Problem | 简洁描述问题、受影响的用户、为什么值得解决;避免在陈述里暗示解决方案 |
| 4 | 未知排优先级 Prioritize Unknowns | 头脑风暴列未知 → 聚类成大类(如把"想要的联系时间""常用设备"合并成"用户设备使用与接触偏好")→ 投票:"哪些未知最重要?""哪些未知风险最高?" |
| 5 | 给探索设时间盒 Timebox | 时间盒制造紧迫感,防"计划谬误"(低估任务耗时)。7 周示例计划:第 1-2 周问题框定 / 第 2-4 周研究 / 第 3-5 周分析 / 第 6-7 周机会发现+构思+报告准备 |
| 6 | 全员参与用户研究 | 别一个人做研究然后汇报——成员亲身参与才会对用户产生同理心、记住用户故事,避免转述失真 |
| 7 | 一起分析、综合、构思 | 每次研究后各自记观察 → 聚类找模式 → 用服务蓝图/商业模式画布综合多来源洞察 → 用"如何实现(How-Might-We)"问题引导创意(如发现"用户爱求助"→ 提"如何提供用户需要的帮助?") |
反例: 没写问题陈述就开始研究 → 研究跑偏、浪费时间;一个人闷头做研究只交报告 → 团队对用户形成误解、没共情。
1.3 CSD 矩阵:把"已知/假设/未知"摆上同一张表
心法:CSD = Certainties(确定性)/ Suppositions(假设)/ Doubts(疑问)三列,用来让团队对项目背景达成共识。 它把混乱的项目认知整理成结构化的三类。
| 列 | 含义 | 记录格式 | 例(训狗师 App 重设计) |
|---|---|---|---|
| 确定性 Certainties | 已验证、可信的已知信息,能据此做决策 | "We know…""We understand…",并链到研究库的数据来源 | 当前市面训狗 App 又贵体验又差;教练需要给客户提供训练课的照片/视频/音频回顾 |
| 假设 Suppositions | 基于初步研究的合理推测,可被测试 | "We believe…",附来源 + 验证它需要的方法/数据 | "我们认为允许狗主人自行排课能提高预订量" |
| 疑问 Doubts | 还不了解、需要进一步研究的开放问题 | 列成问题 | "狗主人乐意在平台上跟踪训练计划吗?""课后会继续帮狗练习吗?" |
进阶——加"行"来组织信息。 除了三列,还可以加行把相似信息分组,行可以按:用户(群体/细分/需求/痛点)、商业(目标/KPI/关键成果)、技术(工具系统)、人(内部团队/资源)、流程(工作流/依赖)、状态(进行中的疑问推测)、优先级(高中低)。加行的好处:能用同一种研究方法/同一场访谈一次性解决一组疑问,也方便排研究优先级、找该参与的跨职能人员。
Why——目标是让信息"流动"。 矩阵不是填完就完事:随研究深入,把疑问验证成假设、把假设验证成确定性,或直接删掉不再相关的项。最终目的是"减少疑问、增加确定性",让团队基于已知做有信心的决策。适用阶段贯穿愿景战略 / 早期探索 / 服务设计 / 内容策略 / 界面视觉 / 迭代优先级。(NNGroup 提供 Excel 和 Miro 模板。)
1.4 启动一个新 UX 项目:4 步把 UX 工作量"显形"
心法:新项目最重要的两件事——确定 ①需要多少工作量 ②要交付哪些成果。 一位 NNGroup 从业者的个人方法:
- 带问题清单进 kickoff——围绕"目标用户是谁?用户主要任务是什么?这个项目怎么帮组织更成功?"
- 靠提问暴露信息差——在会上口头讨论这些问题。三个好处:确认核心 UX 问题、加深团队对用户的认知、降低对 UX 工作的阻力(当大家发现某些问题没人能答,就明白这些空白需要 UX 团队来补,UX 工作自然被理解和支持)。
- 据信息差制定计划与时间表——例:kickoff 上没人说得清用户三大核心任务,就说"那我们需要用户研究来找答案",并在计划里标注"UX 团队需要 3 天做用户研究",把这条嵌进项目主计划。
- 为未来项目铺路——这套做法让团队对 UX 工作不再措手不及,敏捷(Agile)和瀑布(Waterfall)都适用,长期提升团队对 UX 流程的认同感。
二、线框与协作草图:把脑子里的想法画出来
线框图(Wireframe)= 不带颜色/精美视觉、只表达"页面有哪些块、怎么排布、信息层次"的草图。 这一块讲三件事:你自己怎么画线框、怎么让不会画画的干系人也敢画、以及 AI 时代怎么用真实内容替代假文。
2.1 怎么画线框(就算你不会画画)4 步
| 步 | 做什么 | 画法约定 |
|---|---|---|
| 1 | 定浏览器/设备的宽高比 | 手绘不必精确;要精细可参考网页 1024×768 或 1920×1080 像素,移动端按设备调;加浏览器工具栏/设备按钮提供上下文 |
| 2 | 画导航和搜索 | 导航栏用矩形,当前链接用下划线/边框突出;搜索用搜索图标+矩形框,搜索建议是框下的矩形——它们给线框框架和背景 |
| 3 | 画最大的元素 | 标题=粗线;正文=细线;图片=矩形里画个 X |
| 4 | 补细节(交互组件) | 下拉框=矩形+倒三角;复选框=方框(选中打勾)/单选=圆(选中填实);按钮=矩形+标签(如"添加到购物车");横幅=一两行字+按钮/取消图标;对话框=标题+一两行+按钮;进度条=部分填充的圆角矩形 |
2.2 让干系人也敢画草图:魔法公式
心法(魔法公式):粗记号笔 + 小空间 + 时间限制 + 随意丑示例 = 放松的绘图者。
非设计背景的干系人常抗拒画草图("我不是设计师,不会画"),尤其要当众画时更紧张。这个公式靠物理约束消除焦虑:
| 变量 | 为什么有用 |
|---|---|
| 粗记号笔 Fat Markers | 用 Sharpie 这种粗头笔,物理上画不了细节,逼人专注高层创意而非精修。(对比:Micron 细头笔会诱使人去抠细节,而协作构思阶段细节没用) |
| 小空间 Tiny Spaces | 用小卡片/便签,或"把一张信纸折成 8 格",每格画一个想法,空间小迫使聚焦核心想法 |
| 时间限制 Time Limits | 最重要的变量之一。如每个想法 5 分钟,强调数量不要打磨,用计时器控节奏,避免过度思考和自我审查 |
| 随意丑示例 Ugly Examples | 给的范例越粗糙(基本形状+箭头+圆)越好;别给精美草图当例子,否则会让人觉得"标准好高",产生不足感和被评判感 |
开场设置同样关键: ①讲清目的是"生成创意+协作",不是做最终方案;②用"草图(sketch)"代替"设计(design)"降门槛,强调细节美观不重要;③鼓励数量优先于质量。
别把草图局限在界面上。 草图也能用于业务流程、客户体验、员工满意度等抽象挑战——给清晰的引导问题(如"员工感到完全被支持和满意时是什么样?"),接受多样表达(场景图/图表/单一物体)。
Why——协作草图的价值: 提高对设计决策的认同感、参与者背景多样带来更多创意、团队对成果有共同责任感、加快设计流程、让非 UX 人接触 UX 工作。
2.3 Promptframes:AI 时代的线框演化,告别 lorem ipsum
心法:Promptframe = 一份记录"该用生成式 AI 生成什么内容"的交付物,建立在线框的布局和功能之上,用真实感内容替代假文(lorem ipsum)和无意义占位图。 注意:它不取代线框,而是线框旁边一份独立的交付物,用来记录并支持"用真实内容填充线框"这件事。
Why——假内容会污染用户测试。 占位假文/无意义图片缺乏真实性,会让用户和干系人困惑,测试时参与者把注意力转到无关细节上,浪费测试时间。内容才是用户反馈的核心,不是装内容的容器。
应用 6 步:
- 定上下文和用户角色——给 AI 提供:角色(让 AI 扮内容策略师/数据分析师)、组织(使命目标)、目标(如提高注册率)、语气(专业/友好)、定义(行业术语释义)、视觉原则(配色/图形风格)、变体(让 AI 生成 2-3 个内容变体支持更广测试)。可把访谈报告/已有交付物上传给 AI 当背景(如 ChatGPT 自定义 GPT 跨多个聊天复用上下文)。
- 写并记录提示——针对每个区域写提示:文字(核心信息+展示位置如按钮/错误信息+字数限制)、图片(主体/背景/尺寸/风格)、数据可视化(图表类型/列标签/排序/总计/尺寸格式)。
- 跑提示填充设计——把内容直接放进原型;别追求完美(目标是快速产出可测内容,不是上线);提示过长就分块。
- 靠协作和测试优化——在设计评审和用户测试中验证 AI 内容,据反馈改提示快速调整。
- 快速迭代——把时间投到更高质量的内容迭代上。
- 人工精修——最终原型仍需人工提升内容和视觉保真度;Promptframes 的作用是加速早期迭代、收集更全面的反馈。
注意事项 / 反例: ①不适合高层评审——Promptframes 只适合设计团队内部用,高层需要视觉和内容保真度都更高的交付物;②AI 内容质量不均,需多次修订;③遵守组织的 AI 使用与数据保护政策。它特别适合独立设计师或资源有限的小团队。
三、原型保真度:做成"能测的东西",但保真度按目标选
原型(Prototype)= 一个假设——针对特定设计问题的候选解决方案。 测它最直接的方式就是看真实用户怎么用。关键决策不是"做得越精越好",而是"为了回答当前的测试问题,我需要多高的保真度"。
3.1 为什么要测原型(以及那些反对意见为什么站不住)
Why: ①省成本(改代码贵,改原型便宜,尤其纸质原型);②避风险(在最终产品上测设计风险大,原型能提前暴露问题);③迭代提升设计直到足够好。
常见反对意见——"设计完成才能自然地测""不必为 UX 调整敏捷/瀑布流程""别浪费资源在失败的原型上"——都忽视了用户研究的价值:测原型让团队更有信心优化设计、减少最终用户的负面反应。
3.2 三个维度 + 高保真 vs 低保真对照
原型在三个维度上拉开范围:单页 ↔ 多页 / 现实详细 ↔ 手绘草稿 / 交互式 ↔ 静态。
| 属性 | 高保真原型 | 低保真原型 |
|---|---|---|
| 交互性 | 点击目标可用,自动响应操作 | 需人工实时切换页面 |
| 视觉效果 | 逼真的视觉层级、布局、间距 | 黑白草图或简单示意 |
| 内容完整性 | 包含最终设计的完整内容 | 简化或替代内容 |
- 高保真优势: 测试场景更真实、用户行为更接近实际、减少人为操作错误。
- 低保真优势: 准备更快、便于据反馈快速调整、鼓励用户和团队给更多改进意见(用户知道"还没做完"反而更敢说真话)。
3.3 可点击原型 vs 静态原型:7 问决策
心法:逐题回答是/否,"是"多 → 用可点击原型;"否"多 → 用静态原型。
| # | 问题 | 倾向 |
|---|---|---|
| 1 | 有足够时间和技能预设所有可能操作的响应吗? | 能 → 可点击 |
| 2 | 有足够时间多次试运行任务吗? | 能 → 可点击 |
| 3 | 有足够时间试验任务并修复所有问题吗? | 能 → 可点击 |
| 4 | 设计已稳定、测试之间不需频繁改吗? | 频繁改 → 静态更灵活 |
| 5 | 没人能在测试中充当"电脑"手动切页吗? | 没人 → 可点击 |
| 6 | 屏幕间的流程是研究的重点吗? | 是 → 可点击 |
| 7 | 用户需要注意动态变化(变色/动画)吗? | 是 → 可点击 |
- 交互式(可点击)原型: 优点=即时响应模拟真实系统、测试更接近实际、减少人为错误让设计师专注观察;缺点=构建耗时(要设置所有点击目标和响应)。
- 静态原型: 优点=省时(不实现交互,把时间投在页面内容上)、易调整、减少压力(用户知道没做完更敢说真话)、设计师更愿意改草图而非改高保真;缺点=人工模拟切页可能出错,影响体验和测试结果。
测试中的用户交互处理: 测前简单解释原型特性但别过度说明设计元素;遇无响应的点击目标,告诉用户"此功能尚未完成"并问其预期行为;遇错误页面尽快纠正并帮用户恢复上下文。
四、设计规格与交付物:把方案交给开发,以及用什么文档跟谁沟通
4.1 设计规格 Design Spec:设计→开发的交接文档
心法:设计规格 = 让设计团队和开发团队对齐的文件,详述一个设计的功能、行为、外观,让开发能准确把设计实现成可用产品。 大多数团队用 Figma 链接(或同类设计工具)+ 开发工具任务单(GitHub / Linear) 组合传达。它的核心价值是预防"设计做完了却开发不了"。
设计规格通常 = 两大核心件:
| 件 | 内容 | 谁负责 |
|---|---|---|
| 设计文件 Design File(如 Figma) | 交互流程(点击元素后发生什么)·视觉设计(颜色/字体/图标,样式统一命名便于复用)·布局系统(栅格+响应式断点)·交互元素(按钮/输入框+动画过渡)·内容信息(用真实文字图像+标尺寸)·无障碍细节(tab 顺序、替代文本 alt text 需单独说明) | 设计师(视觉/内容设计师等),标注关键说明 |
| 开发任务单 Development Issue(如 Linear) | 目标·范围·使用场景·设计解决的问题·功能与非功能需求(如性能)·风险与对策·与 Figma 一致的截图或链接·设计更新需讨论并安排时间避免版本不一致·规格过大可拆成多个小规格 | 通常产品负责人或开发成员写,视团队结构而定 |
开发任务单的典型结构(以"课程详情页"为例):目标 Objectives(给用户清晰可操作的课程信息、支持决策、减少导航摩擦)/ 范围 Scope(明确写出包含的功能如课程元数据、描述、购买按钮、响应式、状态逻辑,以及明确不包含的功能如深层教师跳转、内嵌评论、相关推荐)/ 前提假设 Assumptions(数据走 API 或 CMS、未登录可浏览)/ 成功指标 Success Metrics(详情页到购物车转化率 +X%、降低跳出率、提升停留时长 Y 秒)/ 设计链接 / 注意事项(按钮文案 "Add to Cart" vs "Enroll Now"、元数据缺失的替代方案、无障碍、登录与未登录路径)。
设计规格创建于设计阶段,在它之前需先完成:定义战略目标 → 用户研究 → 构建交互流程与原型 → 可用性测试 → 据反馈优化。
与开发对齐的 4 个技巧: ①尽早邀请开发参与(别等设计"完成"才通知,规格应记录之前已达成共识的行为/功能/视觉);②留时间给开发在设计文件里评论(提前提可行性建议,让评审会更高效);③准备好折中(面对资源限制评估哪些是用户真正需要的、权衡成本);④确保设计更新被记录和同步(变更是混乱的源头,改动要写进规格并通过常用渠道通知开发)。
三个真实形态参考: ①小型移动端导航(Linear 写目标+研究发现"大多数能导航但一位卡在搜索",Figma 标交互);②大型网页(Figma 用绿/黄/红三色标页面是否就绪进开发、红色标后端相关);③组件规格(如 Google Material Design 按钮组件,标状态和属性值如高度 40dp,以网页形式而非仅 Figma 呈现)。
4.2 交付物术语表:50+ 个 UX 交付物速查
心法:交付物(Deliverables)= 项目周期里用来记录设计过程、研究发现、项目背景的文档/成果。 这是一份术语对照,常被混淆的同类项放一起看:
| 类别 | 术语(中/英)及一句话定义 |
|---|---|
| 信息整理 | 亲和图 Affinity Diagram(便签按相似性聚类)· 概念图 Concept Map(节点=概念,标记箭头=关系)· 思维导图 Mind Map(中心主题+子主题树)· 认知地图 Cognitive Map(某人/群体的心理模型可视化) |
| 用户角色 | 角色 Persona(虚构但真实的目标用户描述)· 原始角色 Proto Persona(基于假设而非调研的快速角色)· 定性角色 Qualitative Persona(基于小样本定性研究)· 统计角色 Statistical Persona(基于大样本调查)· 反角色 Antipersona(可能负面影响目标用户和业务的群体,防误用)· 原型 Archetype(抽象的用户类型,不涉及具体个人)· 干系人角色/简介 Stakeholder Persona/Profile |
| 旅程与地图 | 时间轴地图 Chronological Map(随时间变化的体验总称)· 用户旅程图 Journey Map · 体验地图 Experience Map(典型用户全过程,不涉具体产品)· 服务蓝图 Service Blueprint(服务组件关系,关联旅程接触点)· 生态系统地图 Ecosystem Map · 资产地图 Asset Map(任务中遇到的所有界面元素按时序)· 关系图 Relationship Map · 景观地图 Landscape Map |
| 流程与任务 | 用户流程 User Flow(完成任务的步骤集)· 流程图 Process Map · 层级任务分析图 HTA Diagram(任务拆子任务)· 用户故事地图 User-Story Map · 待完成任务 Jobs-to-Be-Done(用户"雇佣"产品完成"任务") |
| 优先级框架 | Kano 模型(吸引性/表现型/必须/无关四类)· MoSCoW(必须/应该/可以/不会做,Dai Clegg)· RICE(覆盖/影响/信心/投入,Intercom)· 影响-投入矩阵 Impact–Effort Matrix · 可行性可取性可持续性评分表(IDEO) |
| 设计与视觉 | 线框图(隐含)· 模型 Mockup(带颜色图像的静态高保真 UI)· 原型 Prototype · 纸质原型 Paper Prototype · 原型规范 Prototype Specification(原型旁的文字说明字号行距)· 设计系统 Design System · 样式指南 Style Guide · 风格指南/情绪板 Mood Board · 提示框架 Promptframe |
| 研究与协作 | 共情图 Empathy Map · 访谈指南 Interview Guide · 研究计划 Research Plan · 研究仓库 Research Repository · 筛选问卷 Screener · 调查 Survey · 可用性报告 Usability Report · 分析报告 Analytics Report · 内容清单 Content Inventory + 内容审核 Content Audit · 草图测试 Sketch Test(让同事画/总结你的文档,看输出找不清晰处)· 技能图 Skill Map · 仪表盘 Dashboard · 故事 Story · 故事板 Storyboard · 场景图 Scenario Map · 网站地图 Site Map · 交互式 UX 地图 |
| 路线图 | 产品路线图 Product Roadmap(含 UX/营销/内容全领域)· UX 路线图 · 领域路线图 Field Roadmap(只 UX,不涉营销)· 专项路线图 Specialty Roadmap(只 UX 单一领域如用户研究)· RACI 矩阵(角色在任务中的参与方式) |
4.3 哪些交付物最常用?——按受众选,没有"一招通吃"
86 位 UX 从业者调研。最常创建的交付物(总体): ①静态线框(展示页面布局便于讨论结构)②交互式原型(模拟真实操作便于测试演示)③流程图 ④站点地图 ⑤可用性/分析报告。
关键洞察:不同受众要不同交付物。
| 受众 | 最有效的交付物(含命中率) | 为什么 |
|---|---|---|
| 内部管理层 | 交互式原型 · 可用性报告 · 用户旅程图 | 管理层要快速看到设计价值和体验核心点;交互原型让他们直接看产品怎么跑,可用性报告直观呈现数据支持决策 |
| 外部客户 | 交互式原型 67% · 高保真视觉模型 47% · 竞争分析报告 34% | 客户多不懂技术,重直观和视觉;高保真模型用视觉吸引力打动,竞品分析展示设计领先在哪 |
| 开发人员 | 交互式原型 63% · 流程图 55% · 样式指南 51% | 开发关注技术实现和逻辑细节;流程图展示操作逻辑,样式指南提供统一标准 |
三条教训 / 反例: ①没有"一招通吃"的交付物,按受众选;②静态线框 ≠ 最终方案——它很常用但更多是设计师自用,缺乏直观性,别拿它当给客户/高层的成品;③即使低保真的交互式原型,也能帮管理层/客户快速理解设计。(案例:一家初创用交互原型向客户证明新功能可行 + 用样式指南帮开发快速实现,一次省了 30% 时间。)
五、协作三件套 + 过程中的问卷
5.1 专家评审 Expert Review:用外部专家的眼睛做体检
心法:专家评审 = 由 UX 专家分析设计、发现可用性问题和设计优势的评估方法。 它是"设计评审(Design Review,用专家眼睛检查)"家族里最宽的一种,三类设计评审:
- 启发式评估 Heuristic Evaluation——基于一套可用性启发式(如 Nielsen 10 条,见 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估))评估。
- 独立设计评议——对进行中的设计做小组讨论,评估是否达标。
- 专家评审 Expert Review——UX 专家检查系统找问题,最宽,结合启发式评估和其他可用性原则、认知心理学、人机交互原则。
Why——为什么要外部视角: ①更客观(不受团队内部情感和政治影响);②发现盲点(团队长期忽略的问题)。"设计者看不清自己的设计问题,就像作者很难校对自己的文章。"(注:UX 专家的资格来自大量真实用户研究和实践经验,不是凭空设计。)
专家评审报告的 5 个核心组件: ①可用性优势清单(突出优点,避免后续改进时破坏好设计)②可用性问题清单(标明问题所在区域+违反的原则+参考文献)③严重性评级(高/中/低,帮排改进计划)④改进建议(每个问题给方案或进一步研究方向)⑤最佳实践案例(给类似问题的成功示例)。
vs 可用性测试——互补不替代:
| 专家评审 | 可用性测试 | |
|---|---|---|
| 靠 | 专家知识+启发式 | 真实用户行为 |
| 擅长发现 | 较小问题(字体不一致、颜色偏差)+ 违反最佳实践的大问题 | 用户独特需求/知识导致的问题(专家想不到的) |
配合方式:专家评审先做,解决明显问题后,让用户测试专注于发现意想不到的用户行为。
何时做: 设计周期任何阶段(只要有专家,原型或成品都行)· 重大改版前(摸清当前优缺点)· 即使没大改版,每隔 2-5 年定期评一次,确保设计仍满足用户需求。最佳实践:把专家评审融进迭代阶段,早发现早修,避免后期大返工。
5.2 工作坊引导 Workshop Facilitation 101
心法:工作坊引导 = 通过客观、不干扰的指导,帮团队朝一个目标共同前进的过程。 注意它和用户研究中的引导(moderation)不同:工作坊引导聚焦"促进团队协作",不是和参与者一对一互动。引导师的角色是:计划并引导活动、确保人人充分参与、保持中立不主导。
四大引导目标:
- 确保全面且平等的参与——创建民主环境让人人敢说;用分散-集中 Diverge-Converge(先个人思考再分享,再引导汇总)。
- 促进相互理解——建立团队共用语言,用可视化工具(共情图/旅程图)和成果物(便签/投票结果)。
- 支持包容性和协作性决策——成果(任务列表/行动项/共享语言)需协作形成,确保认同和参与。
- 推动共享责任——明确每人后续责任,确保工作坊后行动可执行、公平分配。
六大引导原则(目标和参与者无论如何都适用): ①始终倾听(必要时帮人更清晰表达)②创建包容空间(鼓励内向者,用"有人想补充吗?""你似乎有想法,能分享吗?")③欢迎即兴(灵活应对意外)④保持真实透明(不熟内容就坦诚承认、专注促进讨论)⑤避免提供建议(保持中立,别说"如果是我会…",引导聚焦过程而非内容)⑥拥抱建设性冲突(冲突是多样意见的自然结果,是建信任和突破的手段)。
引导工具包 = 材料 + 活动 + 技巧:
| 维度 | 内容 |
|---|---|
| 材料 | 便签纸·记号笔·白板·大型便签·投票贴纸·索引卡(帮记录整理想法、可视化记忆) |
| 活动 | Post-up(自由张贴想法)·亲和图 Affinity Diagramming(相似想法分组)·全景映射 Landscape Mapping(画整体结构)·强制排序 Forced Ranking(排优先级)·情景绘图 Storyboarding·角色扮演 Role Playing(从用户视角探索)·Playback(回顾分享成果) |
| 技巧 | 沉默技巧(用停顿鼓励参与者填空白)·平衡技巧(邀请其他人提相反观点)·关联技巧(把跑偏的讨论引回主题) |
怎么练: 从低风险场景起步(和同事的小型内部会议)→ 观察并协助经验丰富的引导师 → 工作机会有限可为非营利/志愿活动引导 → 靠实践和反馈不断优化。
5.3 故事板 Storyboard:用图把 UX 想法讲出来
心法:故事板 = 用一系列面板里的图片,按时间顺序展示故事主要事件的可视化工具。 在 UX 里它给团队和干系人提供情境信息,图片让故事一目了然、易记。基本特点:不必复杂或高保真,简单视觉 + 一个具体场景就够。
三大组件: ①场景 Scenario(基于具体场景/用户故事+明确角色,如"James 需要补办公用品",描述要清晰到看图前就懂)②视觉 Visuals(一系列图逐步表现每一步,可草图/插画/照片,精度依受众,体现环境/对话气泡/设备交互)③图片说明 Captions(每图配简短文字:动作/环境/情感/设备,一般不超过两点)。
vs 用户旅程图——别混:
| 用户旅程图 | 故事板 | |
|---|---|---|
| 内容 | 文本为主,含行为/思维/情感/洞察点 | 图像为主,文字少 |
| 视角 | 大局视角,跨部门协作工具 | 具体情境,更适合团队内部小范围用 |
为什么用故事板: ①研究与可用性测试(向没参与测试的人传递用户怎么交互,可含真实语录/肢体语言)②补充旅程图(给各阶段加情境图增强共鸣)③优先级与共识(可视化交互帮识别必要功能并排序,提供全团队共享理解)④头脑风暴与创意。
创建 6 步: ①收集数据(访谈/测试/指标;数据不足也可用故事板做创意发想)②定精度(低保真=团队头脑风暴用草图便签;高保真=Adobe/Sketch 制作用于展示交付)③定基础(明确角色和场景,一个故事板只对应单一用户路径,复杂场景每条路径单独做)④规划步骤(写下每步用箭头连,标情感状态图标;若怕画图就先从写步骤+标情绪开始)⑤创建视觉+加说明(简单图形即可)⑥分发与迭代。
反例: 一个故事板硬塞多条用户路径 → 看不懂,应每条路径单独做。
5.4 过程中的问卷 Surveys:不只是"倾听阶段"的工具
心法:大多数人误以为问卷快又简单,于是误用;实际上问卷类型应按设计周期阶段选。 设计周期 4 阶段——发现 Discover / 探索 Explore / 测试 Test / 倾听 Listen——每阶段有不同最适合的问卷类型。(虽然问卷通常归在倾听阶段,但合理策略下能在每个阶段发挥作用。)
| 阶段 | 阶段目标 | 适用问卷类型 | 示例问题 / 关键数字 |
|---|---|---|---|
| 发现 Discover | 收集问题空间的背景信息,确保识别正确的问题 | 发现问卷(偏定性,开放式,揭示后续访谈可深挖的主题)· 干系人问卷(干系人难约访谈时收集目标期望)· 日记研究问卷(长期记录行为/交互) | "如果能随意改变[产品],你会改什么?""1-7 分,产品当前满足你需求的程度?";干系人:"项目主要问题?哪些算成功/失败?明确排除的范围?";日记:"评价当前情绪""今天执行了多少次[行为]?" |
| 探索 Explore | 深入问题空间、确认范围和用户需求(设计评审/竞品分析/角色创建) | 统计角色问卷(大样本量化数据生成角色)· 竞品客户问卷(了解竞品优缺点) | 统计角色:"过去 7 天用了几次?""开始用的主要原因?""家庭年收入?";竞品:"对[产品]满意度 1-7?""最喜欢哪个功能?""希望解决的未满足问题?" |
| 测试 Test | 验证探索阶段的假设(迭代可用性测试),问卷通常在任务完成后做 | 任务后问卷 Post-Task(评单个任务难易,常用单项易用问题 SEQ)· 测试后问卷 Post-Test(评整体可用性,常用系统可用性量表 SUS,10 个问题,有可靠行业基准) | SEQ:"该任务难易度 1-7?" |
| 倾听 Listen | 产品使用周期里持续收集反馈、监测体验和情感 | NPS 净推荐值(推荐可能性,分数 -100% 到 100%)· CSAT 客户满意度 · CES 客户努力评分(完成操作的难易,基于前三高分占比)· 自定义倾听问卷(用户旅程/关键操作结束时现场弹窗收即时反馈) | NPS:"推荐该产品的可能性?0-10 分";CSAT:"总体满意度?1-5 分";CES:"完成该任务有多容易?";自定义:"[功能/改动]是否让你工作更轻松?同意/不同意" |
反例 / 心法: 把问卷当"又快又简单"随手发 → 误用;决定用不用问卷前,先想清研究目标和问题,再选对应阶段的类型。问卷擅长拿"自我感知和态度"(attitudinal),要拿真实行为还得配行为研究——这点和 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估) 里"态度 vs 行为研究"一致。
源自 NNGroup Topics / Organization & Design Process - UX设计工作(设计流程子集,17 篇)。可用性测试与启发式评估见 NNGroup 可用性测试与十大可用性启发式(10 条启发式完整表 · 复杂应用应用 · 用户愉悦层级 · 测试方法 5 人法则/招募/远程/任务场景/分步任务/态度vs行为/4步分析/小样本误差/竞争性评估);定性研究方法见 NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理);用户旅程图见 NNGroup 用户旅程 Customer Journeys(旅程地图五要素/七种分析法 · 四大映射方法 vs 服务蓝图/体验地图/同理心图 · 旅程 vs 流程 vs 故事地图 · 服务设计与蓝图三线五步 · 项目方法论现状-未来&假设-研究 · CX 转型与旅程中心设计 · 研究地基 CUEs/用户面板 · 实战奢侈品/医疗/AI 绘图);UX 战略与路线图见 NNGroup UX 策略·路线图·地图·风险债务·复盘·利益相关者(21 篇 · UX策略/复杂应用三阶段/CASTLE/情绪板 · 路线图角色时间+5种优先级法+Pareto · 互动地图/资产映射/旅程图制作时间73.8h/技能地图 · 设计风险6步+UX债务+断裂追踪RAS · Retrospective四步/Postmortem七要件 · 利益相关者权力兴趣矩阵+访谈+跨团队+RACI+Scrum职责)。图片/原档(含 UX Deliverables Glossary PDF)保留在 sources。
来源与关联资料
- NNGroup UX 策略·路线图·地图·风险债务·复盘·利益相关者(21 篇 · UX策略/复杂应用三阶段/CASTLE/情绪板 · 路线图角色时间+5种优先级法+Pareto · 互动地图/资产映射/旅程图制作时间73.8h/技能地图 · 设计风险6步+UX债务+断裂追踪RAS · Retrospective四步/Postmortem七要件 · 利益相关者权力兴趣矩阵+访谈+跨团队+RACI+Scrum职责)
- NNGroup 定性研究与研究方法工具箱(方法全景/访谈/共情图/样本量/任务设计/主持/专家评估/工作坊/伦理)
- NNGroup 用户旅程 Customer Journeys(旅程地图五要素/七种分析法 · 四大映射方法 vs 服务蓝图/体验地图/同理心图 · 旅程 vs 流程 vs 故事地图 · 服务设计与蓝图三线五步 · 项目方法论现状-未来&假设-研究 · CX 转型与旅程中心设计 · 研究地基 CUEs/用户面板 · 实战奢侈品/医疗/AI 绘图)