“young” 模糊 —— 用明确年龄段或人生阶段（如 “18–24 岁本科生”）。
“Asian” 过度泛化且可能带偏见 —— 除非与产品强相关，避免用族裔标签；若确有必要，用更客观可验证的范围，如“在澳大利亚的普通话/英语使用者”“在墨尔本留学的国际学生”等。
“good with technology” 主观 —— 换成可度量的技能/行为指标，例如“每天使用智能手机与笔记本”“能独立安装应用、设置 2FA、完成在线支付与云端文件共享”等，并给出水平（初级/中级/高级）。

Data Gathering and User Research Methods

Participant sample selection and size

选择样本参与者的数量没有“一刀切”的方法。你的目标、背景和方法将会产生重大影响。

时间和精力方面的成本和限制。考虑测试方法对生产、促进和分析的要求。
只需 5 名参与者即可获得良好的定性见解。
良好的定量洞察应该至少包括 30 名参与者。
如果您已经定义了目标受众，请确保您的样本定义明确且具有代表性，以生成更准确的数据。
对于更广泛的人群，精心设计的问题有助于你估算你的人口统计数据。增加样本量可以降低你的利润率或误差。

Participant sampling approaches

Probability Sampling
概率抽样
根据特定总体中的概率分布进行的随机选择。
Purposive Sampling
目的抽样
根据预定义的用户或组选择标准选择参与者。
Haphazard Convenience Sampling
随意便利抽样
根据可用性随机或近乎随机地选择参与者。

Explanatory statement and consent

解释性声明和同意书可帮助用户了解他们即将参与的研究。

解释一下问题

研究
数据收集
信息存储
参与者的权利。

Interview-based data gathering

结构式（Structured）

按严格脚本进行，几乎像一份口头问卷。容易复现和分析。
你几乎没有机会对有趣或意外的想法作出回应。

半结构式（Semi-structured）

预先规划要覆盖的主题/话题，但允许偏离。
伪可复现，不同受访者之间具有一定可比性。

非结构式（Unstructured）

前期计划较少。从一个初始问题开始，顺势推进。
能得到非常丰富、深入的数据，但使复现与分析变得困难。

Supporting research

当你的数据存在空白时，你需要对用户做出一些假设。

基于研究得出的知情性假设，比带偏见的假设更好！

研读现有文档
- 相关的既有研究与数据
- 与领域相关的文档
- 通俗资料与专业研究
研究相似的系统/产品
- 产品研究
- 直接竞争对手
- 间接竞争对手

Qualitative data from user-submitted reviews

来自用户提交评论的定性数据

在线评论是获取第一手用户体验的便捷主要来源。

产品中的技术性错误是预期会出现的——在分析评论时不要过分关注这些错误。
要理解当错误影响到体验时，用户为何会感到沮丧。
寻找那些出乎意料的用户行为。
识别产品何时没有满足用户的特定需求。
参考链接：https://play.google.com/store/apps/details?id=com.facebook.katana。

You have collected data …Now What?

Data analysis

数据分析

在发放问卷之前，先“拷问”你的题目：你真正想通过这些问题弄清楚什么？
对量化结果使用交叉列联：比较不同人群对同一问题的回答（例如：不同语言、年龄段、职业的人）。
把数据放到情境中理解，以找出对调查结果影响最大的因素。
- 例如：45% 的人不参加周一俱乐部会议，其中 70% 是西班牙语使用者。

Data analysis must go beyond simple summary

数据分析必须超越简单汇总

“数据汇总”只是把数据事实复述一遍。
- 例如：“本次收集中 56% 为女性，44% 为男性。”——这类描述并没有提供超出原始数据的新洞见。
“数据分析”旨在提出新观点，并以数据为证据支撑：
- 这些数据与我们先前的假设/预期是否一致？
- 这些数据对用户的体验与行为有什么暗示？
- 依据这些数据，我们能外推出哪些新的属性？

Data analysis – Cross Tabulation

Data analysis

分析开放式回答
- 通读所有回答
- 识别其中的情感倾向
- 提取相关关键词
- 找出反复出现的主题
可视化结果
- 用图形比较数值
- 识别关系与关联
- 让相关利益相关者更容易理解你的发现

Data analysis - Word Clouds

描述性质性数据常常难以分析；词云有助于直观展示高频词。
先纠正拼写错误再生成词云（数据清洗）。
不要只看表面：
- 寻找相似/相关词
- 回读原始数据，理解这些词为什么被频繁使用。
右图：基于 Facebook 安卓应用的 Google Play 商店部分用户评论生成的词云示例。

Data analysis - Summary

目的：在数据中发现模式与关系。
尽可能把发现细化拆分。
可以利用现成工具：
- Excel
- 其他工具（如 NVIVO，Monash 软件目录可获取）
- 机器学习方法（如情感分析、关键词抽取）。
仅做描述性汇总没有用处，应当：
- 找出观点之间的联系
- 推断为何出现某种模式
- 识别新问题
- 据此做出新决策。

Consolidating Analysis into UX Deliverables

将分析整合为 UX 交付物

将你对用户研究与数据分析的结果，整理成可共享、可复用的 UX 交付物（如人物角色、用户故事、故事板等），用于团队沟通与设计决策。

Forming a single representation of users

形成单一的用户表征

原型（Archetypes）：描述一类通用用户群或角色；当一个表示需要覆盖多个情境时有用；范围广、描述更概括。
人物角色（Personas）：基于分析结果构建的单个虚构个体；范围窄、特征与需求更具体。
为什么常用 Persona：
- 表达更聚焦、歧义更少；
- 在特定情境下更易共情；
- 团队使用时一致性更好。

Archetypes

原型是便于沟通的简写，但容易引发误读或假设。示例：

极简主义者（The Minimalist）：偏好功能精简、流程高效的应用。
探索者（Adventurous Explorer）：爱尝试新技术与每个功能。
自由追寻者（Freedom Seeker）：重视隐私，主动寻找自由/开源替代品。
收集控（The Completionist）：热衷收集与组织事物和信息。
自定义达人（Customisation Expert）：习惯调所有设置以获得高度个性化体验。
其他示例标签（用于激发思考）：国际学生、大学导师、体力劳动者、火箭科学家、好奇学习者、元素法师、披风义士、爱猫人士等。

Personas

定义：一个虚构但具体的代表性用户档案，让我们能更具体地理解用户。
特点：将数据洞见与研究+叙事结合，便于共情并理解其需求、目标与行为。
常见要素：
- 个人背景与人口统计
- 目标、需求与痛点
- 行为与态度
- 使用情境（context）

Example persona

bad example

同情（Sympathy） vs. 共情（Empathy）在 UX 中

同情：对他人遭遇的承认与怜悯。
共情：能够充分理解、映照并分享他人的表达、需求与动机。
为什么要记录“共情”：通过创建 UX 交付物，我们不仅能找到共情，还能把共情文档化，以便后来者或团队成员复用，尤其在团队项目中很重要。

Empathy maps

定义：把我们如何与某位用户/Persona 共情的要点可视化。
四个象限：用户说什么 / 想什么 / 做什么 / 感受什么。
作用：帮助团队形成对用户/Persona 的统一理解，并更好把握其动机（影响其决策过程的因素）

需求规范（Specifying Requirements）

User stories

用户故事是一句清晰呈现某个用户可被解决的问题的陈述，要求简短、具体、以目标为导向。

Example

As Max, I want to invite my friends, so that we can enjoy this service together.
As Sascha, I want to organize my work, so that I can feel more in control

User-centric vs developer-centric stories

以用户为中心 vs. 以开发者为中心的故事

以开发者为中心的反例

As a user, I want a notification button so that I can open my notifications

Prioritising your user stories

确定用户故事的优先级

客户通常不愿给需求排优先级
常受自身利益驱动。
并非所有需求价值相同

Prioritisation Techniques: In or Out?

最简单的排序法：逐条审视每个需求，决定“纳入（In）还是剔除（Out）”

局限：难以在多方利益相关者场景中扩展。

Prioritisation Techniques: Priority Matrices

优先级排序技术：优先级矩阵

把想法画到二维矩阵上，有助于团队更客观地评估优先级

Prioritisation Techniques - MoSCoW

优先级技术——MoSCoW 方法

Must（必须）：不满足就无法成功。
Should（应该）：很重要，尽量纳入，但并非成败所必需。
Could（可以）：可取但可延期/删除，时间与资源允许时再做。
Won’t（暂不做）：此阶段不实现，可能进入未来版本。

MoSCoW in Practice

你受聘做一款游戏，请给下列用户故事分配 MoSCoW：

Must（必须）：不满足就无法成功。
Should（应该）：很重要，尽量纳入，但并非成败所必需。
Could（可以）：可取但可延期/删除，时间与资源允许时再做。
Won’t（暂不做）：此阶段不实现，可能进入未来版本。

规格化用户需求（Specifying user requirements）

书面化的用户需求帮助我们在高层理解系统应为用户做什么：

清晰界定要解决的问题；
来源于访谈、问卷、观察、焦点小组等；
在不同阶段可定义不同类型需求：
- 功能性：例如“用户应能给朋友发送消息”；
- 非功能性：例如“95% 情况下消息投递≤2 秒”；
- 用户体验：例如“发送消息时应有流畅动画”。

把故事拆解为详细情境（Scenario Breakdown）

角色（Actor）：Debbie
动因（Motivator）：要出差；考虑价格可承受/评价好
意图（Intention）：需要预订一间客房
行动（Action）：在网站上浏览对比多家酒店，挑符合需求的
结局（Resolution）：选定酒店并完成预订。

Storyboards

想法用可视化表达通常更清晰。
故事板用少量（通常 3–6 张）的简单草图，来呈现一个以目标为导向的情景；配文（caption）用于提供情境背景。
右侧示例：Persona “Mark”；用户故事：“作为 Mark，我想知道自己何时驼背，这样我就能改善背部疼痛。”

如何制作故事板（Storyboard: How to）

收集数据。
选择保真度（粗略草图 / 便利贴）。
明确基本要素（涉及哪个 Persona？场景是什么？）。
一个故事板应只聚焦单一路径（不要分叉多条路线）。
明确步骤与顺序。
绘制图像与配文（大胆用很粗糙的草图也可以）。
展示给你的队友。

糟糕的故事板示例（A bad example of a storyboard）

这是一张不好的故事板。我们可以如何改进？

是否体现了共情？
是否以用户为中心？
是否交代了情境？
是否讲清了故事？

Acceptance criteria

以设计者视角思考：为满足一个用户故事/需求，需要哪些特性？
验收标准应体现目标是否完成、对用户的好处，并且要契合 Persona。
示例（Clark）：“作为 Clark，我想要便捷访问通知，这样就不会错过朋友们的重要消息。” 验收标准：
- 在每个界面都有一个清晰的铃铛图标按钮可访问；
- 按钮上有未读数量指示点；
- 可关闭某些特定好友的通知；
- 每条通知都有重要程度指示

Reading

Observation-based data gathering

现场研究方法让研究者在用户的自然场景中观察其执行任务，可获得问卷难以发现的洞见。
被动观察：研究者在自然环境中旁观用户执行任务；风险是对行为的解读可能出错。
参与式观察：研究者以“用户”的身份亲自参与并记录一手体验；若缺乏领域知识，体验可能不够真实。
主动观察：研究者在现场观察的同时，可在任务过程中或结束后采访用户。

Observation problems: Hawthorne effect

又称“观察者效应”：一旦用户知道自己被观察，其行为可能被影响。
术语由Henry A. Landsberger于1958年提出，源自霍桑工厂的研究：
- 当仅做出极小的照明变化时，生产率似乎提升；
- 研究结束后，生产率又下降。
结论：被观察时的工作者最为高效。

Contextual inquiry

先进行观察，再以后续访谈补充信息的组合方法。
比单纯访谈更耗时，但能提供情境化洞见。
不易用于大样本；更适合参与者较同质或项目很细分的领域

Focus groups

人数：一般至少6名参与者。
抽样：通常包含关键利益相关者。
讨论：参与者交流经历并表达看法与信念。
主持人需要：
- 引导并管理讨论；
- 确保议题覆盖完整；
- 确保每位参与者都有所发言。
常需多场焦点小组，因为单场讨论难以代表所有观点

课程目录