第 3 章 用户研究与场景洞察
上一章我们读懂了业务和系统,这一章我们转向人。
ToB 的用户研究,和 ToC 不是一回事。ToC 研究的常是一个相对单一的用户群,设计师可以靠对人性的普遍洞察走得很远。ToB 不行。你面对的是一张由多个角色织成的网,每个角色身处不同的业务场景,执行不同的任务,而且他们的需求常常深埋在专业的业务背景之下,连他们自己都未必说得清。所以 ToB 的用户研究,需要一套更结构化的方法。这一章的主角,就是这套方法的核心:"角色—场景—任务"三段式。
一、为什么 ToB 用户研究这么难
先说清楚难在哪,你才会理解后面那套方法为什么这么设计。
第一难,是用户的专业性。ToB 用户是某个领域的专家,他们懂仓储、懂财务、懂诊疗,而你大概率不懂。这种知识落差让研究变得困难:你问不到点子上,他答的你听不懂,很多对他来说理所当然、根本不会主动提的"常识",恰恰是你最需要知道的关键信息。我做仓储系统时,第一次访谈完全是灾难,我连"波次""越库""动碰"这些词都听不懂,只能不停地打断问"这是什么意思",访谈节奏全乱了。后来我学乖了:访谈前先做功课,把行业基本概念摸个大概,再去聊,才聊得下去。
第二难,是需求的隐蔽性。用户能说出来的,往往只是需求的冰山一角。他会告诉你"我想要一个导出按钮",但他不会告诉你他为什么要导出、导出后拿去干嘛、现在不能便捷导出给他造成了多大的麻烦。表层的功能诉求背后,藏着真实的目标和痛点,而这些才是设计真正该回应的。
第三难,是研究对象的多重性。前面反复说的多角色问题,在研究阶段就开始发威了。你不能只研究一个用户,你得研究一组角色,还要理解他们之间的协作与冲突。研究的复杂度,随着角色数量成倍上升。
这三难叠加,决定了 ToB 用户研究不能靠灵感和直觉,得靠方法。下面这套"角色—场景—任务",就是应对这三难的结构化武器。
二、角色:先分,降低复杂度
应对多角色复杂性的第一步,是"分角色"。
这背后有一个朴素而有力的道理:面对复杂的信息架构,先按角色拆分,可以大幅降低每个角色需要处理的信息量和业务逻辑量。一个庞大的系统,如果不分角色,所有功能、所有信息一股脑摊给所有人,那对每个人来说都是灾难,他要在一大堆跟自己无关的东西里,辛苦地找出自己需要的那一点。而一旦分了角色,每个角色面对的就只是与他职责相关的那个子集,认知负担一下子就降下来了。
所以,角色拆分不只是研究方法,它本身就是一种强大的复杂度治理手段。这一点会在第五章被反复印证。
怎么分角色?核心是回到上一章讲的业务理解:沿着业务流程,看每个环节由谁驱动,这些"谁"就是你的角色雏形。然后对每个角色,搞清楚几件事:他的核心职责是什么(他在这个业务里负责把什么事办成)?他的权限边界在哪(他能看什么、能改什么、不能碰什么,这直接关系到第十三章的权限设计)?他的核心诉求是什么(他最在乎效率、准确,还是别的)?他的能力背景如何(他是熟练的专业人士,还是流动性高、需要快速上手的普通员工,这决定了你该为他提供"快车道"还是"引导")?
这里要再强调一遍上一章的提醒:角色不是职位,更不是某个具体的人。你要抽象出的是"逻辑角色"。同一个职位的人可能扮演多个角色,同一个角色也可能跨多个职位。对着逻辑角色设计,你的方案才有普适性和稳定性,不会因为客户那边某个人的岗位调整就失效。
我见过一个反例。某团队做用户画像时做的是"张经理,42 岁,喜欢喝茶,管理风格严谨"这种 ToC 式的、充满生活化细节的画像。这在 ToB 几乎没用。张经理喜不喜欢喝茶,跟他怎么用审批系统毫无关系。ToB 的角色画像,该聚焦的是职责、权限、诉求、能力背景这些和业务直接相关的维度,而不是那些生活化的、看似生动却无用的细节。
三、场景:再分,锚定真实情境
分完角色,还不够。同一个角色,在不同的情境下,需求也不一样。所以第二步是"分场景":根据真实用户的使用情况,把角色的活动切分成一个个具体的场景。
什么是场景?场景是"某个角色,在某种情境下,为了某个目的,所进行的一段连续活动"。它包含几个要素:谁(角色)、在什么时间地点环境下、出于什么动机、要达成什么目标。
为什么场景如此重要?因为脱离场景谈需求,几乎必然失真。
让我们把前奏那个"戴手套"的例子讲透。我做一个仓储拣货系统时,在办公室里对着"拣货员"这个角色,设计了一个信息丰富、按钮精致的界面,自我感觉良好。直到我去了一次真实的仓库:那是冬天,仓库没有暖气,拣货员戴着厚厚的棉手套,手指根本没法精确点击我设计的那些小按钮;仓库光线昏暗,我精心调的浅灰色辅助文字根本看不清;拣货员是推着车、半小跑着工作的,根本没空仔细看屏幕,他需要的是一眼就能看到的、大大的下一个货位号。"按钮要做大、对比要够强、关键信息要极度突出",这些需求,我坐在办公室里对着角色画像,无论如何都想不出来。只有把角色放回"在寒冷昏暗的仓库里、戴着手套、半跑着拣货"这个具体场景里,它们才会浮现。
场景,是让抽象的角色重新落回真实世界的锚。
ToB 的场景常常有一些 ToC 设计师容易忽略的特殊性,值得专门留意。
物理环境的特殊性。ToB 的使用环境千差万别:嘈杂的车间、强光下的户外、需要戴手套或护目镜的实验室、光线昏暗的监控室。这些物理条件会硬性地约束设计(字号、对比度、点击区域、是否依赖颜色区分,这些都关系到第七章和第十三章)。
中断与并发的常态。ToB 用户的工作常被打断:电话来了、客户催了、临时有别的急事。他可能填到一半的表单被迫中止,过会儿再回来。这要求设计认真对待"中断恢复":自动保存、明确的进度、随时能续上(第六章会落到具体做法)。
熟练度的两极。同一个功能,可能既有每天用几百次的熟练工,也有偶尔才用一次的生手。熟练工要的是极致效率(快捷键、批量、跳过引导),生手要的是清晰引导(提示、默认、防错)。好的场景分析,会把这种熟练度的差异识别出来,从而在设计上做出兼顾,而不是只为其中一极设计。
把角色和场景结合,你得到的是一个二维的网格:每个角色乘以每个关键场景,构成一个需要被设计认真对待的格子。这张网格,就是你设计的真实战场。它能帮你避免遗漏:别只设计了"主角色在主场景下"的格子,而漏掉了那些次要却真实存在的格子。
四、任务:落到底,看清用户究竟要做什么
角色、场景之后,第三步是"任务":在某个场景里,用户具体要完成哪些任务,每个任务又分解成哪些步骤。
任务是最具体的一层,也是最接近界面的一层。一旦任务和步骤理清了,界面的雏形几乎就呼之欲出了,因为界面本质上就是支持用户完成任务的工具。
分析任务时,有一个好用的工具叫"任务流":把用户完成一个任务的步骤,一步步画出来,标注每一步用户的目标、操作、所需信息、可能的卡点。当你把任务流画完,你常会惊讶地发现:原来一个看似简单的任务,中间藏着这么多步骤、这么多需要做判断的地方、这么多可能出错的环节。这些,都是设计要去优化的对象。
任务分析还有一个重要价值:它帮你区分"高频任务"和"低频任务"。
ToB 系统里,任务的使用频率差异极大,有的任务一天做几百次,有的一个月才做一次。设计资源应该向高频任务倾斜:高频任务要做到极致顺滑,哪怕牺牲一点点低频任务的便利也值得。
一个常见的设计错误,是把宝贵的界面黄金位置(首屏、主操作区)给了某个看起来"重要"但其实低频的功能(比如"系统设置""年度报表"),而把每天高频使用的操作(比如"新建工单""快速查询")藏在二级菜单里。结果就是,用户每天最常做的事最难够到,偶尔做一次的事反而摆在最显眼处。任务频率分析,能帮你避开这个坑:把界面的黄金位置,留给真正高频的任务。
"角色—场景—任务"三段式,到这里就完整了。它是一个从抽象到具体、逐层下沉的漏斗:先用角色把人群切开,再用场景把情境锚定,最后用任务把动作看清。走完这个漏斗,你对"用户是谁、在什么情况下、要做什么"就有了结构化的、可设计的答案。这套方法,是 ToB 设计师对抗多角色复杂性的看家本领,请务必把它练熟。
五、研究方法:定性与定量的结合
有了"角色—场景—任务"这个分析框架,接下来是用什么手段去填充它。这里要讲方法的搭配:定性与定量结合。
定性方法,回答"为什么"。访谈、实地观察(影随)、可用性测试,这些方法能帮你深入理解用户的动机、痛点、心智模型。
在 ToB 里,我要特别为"实地观察"重重地说几句话。前面那个"戴手套"的例子,就是观察的功劳。很多 ToB 的关键洞察,是访谈问不出来的,因为用户对自己的工作太熟悉了,熟悉到那些关键细节对他来说是"不值一提的常识",他根本想不起来要告诉你。你必须亲自到现场去,看他真实地工作,才能捕捉到这些被语言遗漏的真相。在 ToB,去现场,是用户研究里性价比最高的投入,没有之一。哪怕只去蹲半天,你的收获也常常超过在会议室里听十场访谈。
定量方法,回答"有多少"。行为数据分析、问卷,这些方法能告诉你现象的规模和分布:哪个功能用得多、用户卡在哪一步的比例高、哪类操作的错误率高。定量数据的价值在于,它能帮你从一堆定性洞察里分清主次:你访谈中听到的那个抱怨,到底是个别现象还是普遍问题?数据能给你答案。
定性和定量是互补的,缺一不可。只有定性,你会知道很多生动的故事,却不知道它们有多大代表性,容易被个别极端案例带偏。只有定量,你会知道很多数字,却不知道数字背后的原因,无从下手去改。好的做法,是用定量发现问题(哪里有异常)、用定性理解问题(为什么会这样)、再用定量验证方案(改了之后有没有变好)。它们在研究的不同阶段轮番上场,各司其职。
只是要注意,前奏里提过 ToB 的一个现实约束:用户基数往往小,定量数据的统计意义可能不强。这意味着在 ToB 里,定性方法的权重通常要比 ToC 更高。当你的日活只有几百个,与其纠结那些跑不出显著性的数字,不如多花时间去跟关键用户深聊、去现场蹲点。这个权衡,后面第十章讲数据驱动设计时还会专门展开。
六、挖掘潜在需求:同理心与冰山之下
这一章最后,我想回到那个最难、也最能体现 ToB 设计师功力的问题:如何挖出用户没有说出口的潜在需求。
前面说过,用户能表达的只是冰山一角。表层是他直接说出的功能诉求(我要一个导出按钮),水面之下是他真实的目标(我要把这些数据拿去做月度汇报),再往下是他深层的痛点和情绪(每个月做汇报都要手动整理半天,烦得要命,还容易出错,做完还担心被领导挑出错)。
一个只响应表层诉求的设计师,会老老实实加一个导出按钮;一个能潜到水下的设计师,会意识到用户真正要的是"轻松、准确地完成月度汇报",于是他可能直接提供一个汇报模板、甚至自动生成汇报草稿,这才是真正解决了问题的设计。两者的差距,不在画图,而在有没有潜到水下。
怎么才能潜到水下?核心是同理心,但同理心不是一句空话,它有具体的方法支撑。
多问"为什么"。当用户提出一个具体诉求,别急着记下来就去实现,多追问几层:你为什么要这个?有了它你接下来要做什么?现在没有它你是怎么解决的?这个连环追问(有点像精益里的"五个为什么"),能帮你穿透表层,抵达真实目标。前面那个"导出"的例子,就是靠"你导出后拿去干嘛"这一问,挖到了"做月度汇报"这个真实目标。
关注"变通做法"。用户为了绕过系统的不足,常会发明各种"变通做法":把数据导到 Excel 里自己处理、在备注栏里塞本不该放在那里的信息、用一套只有他们自己懂的土办法(比如用不同颜色的便利贴贴在显示器上)标记状态。这些变通做法,是金矿。每一个变通,都指向一个未被满足的真实需求。看到用户在"凑合",别放过,那里一定藏着设计的机会。我曾在一个客户现场,看到客服们在显示器边框上贴满了手写的便利贴,记着各种"遇到 XX 情况要怎么处理",那一墙便利贴,就是系统缺失的、本该内建的帮助和规则提示。
代入完整的情境。回到场景里去,想象用户工作的一整天,而不只是他用你这个功能的那几分钟。他在用你的功能之前在做什么、之后要做什么、当时心情如何、周围在发生什么。当你能在脑子里完整地"过一遍"用户的处境,很多潜在需求会自然浮现。
挖掘潜在需求,是 ToB 设计师最有价值、也最难被 AI 替代的能力之一。生成一个界面、套用一个模式,AI 很快;但去现场观察、从一墙便利贴里读出系统的缺失、从一个变通做法里读出未被满足的渴望、在多角色的诉求里体察出那个谁都没明说的真实痛点,这些需要的是身处其中的人的判断和共情。这是设计师的护城河,值得用一生去打磨(第十二、十七章还会反复回到这个判断)。
本章要点清单
- ToB 用研三难:用户专业(访谈前先做功课)、需求隐蔽(挖冰山之下)、对象多重(多角色)。
- 角色:沿流程识别逻辑角色;画职责/权限/诉求/能力背景,而非生活化细节;对逻辑角色而非具体人设计。
- 场景:务必去现场(很多关键洞察访谈问不出);注意物理环境、中断常态、熟练度两极。
- 任务:画任务流看清步骤与卡点;区分高频/低频,把界面黄金位置留给高频任务。
- 方法:定量发现问题 → 定性理解原因 → 定量验证方案;ToB 中定性(尤其现场观察)权重更高。
- 挖潜在需求:多问"为什么"、关注"变通做法"(金矿)、代入完整情境。
小结
这一章,我们建立了 ToB 用户研究的核心方法。"角色—场景—任务"三段式,是一个从抽象到具体的分析漏斗,帮你驾驭多角色的复杂性;定性与定量的结合,是填充这个框架的手段,而在 ToB 里定性、尤其是现场观察的权重更高;挖掘潜在需求,则是这一章的灵魂,穿透表层诉求,抵达用户真实的目标和痛点。
读懂了业务,也读懂了人,我们就完成了"理解"这一篇的核心积累。从下一章开始,我们进入全书最厚重的第二篇"建造"。我们将从"需求分析与设计建模"讲起,看看如何把这些理解,科学地转化成扎实的设计。