用户画像、场景、任务与用户旅程地图

研究之后的共同语言

用户研究结束后，团队常常会遇到一个新问题：资料很多，但大家记住的东西不一样。研究员记得访谈里的细节，设计师记得几个明显的痛点，产品经理记得优先级，业务负责人记得客户抱怨，客服记得工单，数据同事记得漏斗。每个人都掌握了一部分真相，但如果没有共同的表达方式，团队很快又会回到各说各话。

用户画像、使用场景、任务分析和用户旅程地图，正是为解决这种分裂而存在的。它们不是给报告增加几页"看起来很 UX"的图，而是让大家下次争论时能指向同一组用户处境，而不是各自讲自己记住的片段。它们相当于几种不同焦距的镜头：画像让团队看清关键角色，场景把这个角色放回具体处境，任务分析拆开他一路要做的动作，旅程地图则把从开始到结束的触点、情绪、摩擦和机会串起来。

如果没有这些模型，团队对用户的理解很容易停留在模糊印象层面。比如大家都说"新用户很迷茫"，但迷茫的是谁？什么时候迷茫？是看不懂术语、找不到入口、还是不知道下一步？迷茫之后是退出、求助、反复尝试，还是错误操作？这些问题不说清，后续设计就会变成凭印象解决问题。

核心问题

用户画像到底有什么用？如果画像只剩年龄、职业和兴趣爱好，它更像营销标签；在 UX 项目里，画像要说明一类用户如何完成任务、受什么限制、怕什么风险、用什么标准判断成功。

用户分群和用户画像有什么区别？分群更偏数据和商业划分，画像更偏研究叙事和设计决策，两者可以配合，但不能互相替代。

场景为什么重要？同一个用户在不同情境下会有完全不同的需求、耐心、风险感和判断标准。

任务分析和功能清单有什么区别？功能清单像系统菜单，任务分析像用户办事路线。只盯着菜单，团队容易忘记用户在系统外还要找材料、问同事、等审批、处理退回。

用户旅程地图如何帮助团队发现体验痛点？它不只是把步骤排成一条线，还要把用户在每个触点上的目标、行为、感受、阻碍和机会放进去。

服务蓝图和用户旅程地图有什么区别？旅程图以用户经历为中心，服务蓝图进一步连接前台触点、后台流程、系统和角色协作。

如何避免这些工具变成形式主义？关键是证据来源、建模目的、使用场景和后续决策要清楚。

四种分析视角

用户画像，Persona，是基于研究表达典型用户目标、行为、需求和限制的模型。"王女士，32 岁，喜欢旅行，爱喝咖啡"也许能让页面显得亲切，却未必能指导设计。真正有用的画像要回答：这个用户想完成什么？他为什么这样做？他遇到什么限制？他如何判断成功？他和其他用户的差异在哪里？比如企业后台的"管理员"不能只写成"35 岁，熟悉办公软件"。更重要的是：他是否负责配置权限？是否经常处理新员工入职？是否担心配错权限造成安全风险？是否需要向 IT 或 HRBP 求助？这些信息才会影响设计。

用户分群，Segment，是按行为、价值、需求、角色或数据特征划分用户群。分群更像把用户按业务规则分进不同抽屉，帮助团队看规模、价值和差异；画像则像把其中一类人的工作日展开，帮助团队理解他如何思考和行动。分群可以告诉你"企业客户中有管理员、审批人、普通员工和管理者"，画像可以帮助你理解"管理员在配置权限时最担心什么"。

使用场景，Scenario，是用户在特定情境下完成目标的描述。场景要包含时间、地点、环境、动机、限制和触发条件。同样是"填写地址"，在电商下单中可能是用户坐在家里慢慢填；在外卖下单中可能是用户很饿、赶时间、用手机操作；在政务服务中可能是用户对材料要求很紧张，担心填错导致退回。场景会把设计问题从"按钮能不能点"推到"用户当时有没有精力、信息和信心把这件事做完"。

任务分析，Task Analysis，是分析用户完成目标所需步骤、信息、决策和依赖的过程。它关注用户要做什么，而不是系统有什么功能。比如"报销"这个任务，不只是填写报销单，还包括收集发票、确认规则、选择费用类型、找审批人、等待结果、处理退回和追踪到账。任务分析能把功能清单背后的真实工作翻出来：哪些动作在系统里，哪些动作发生在邮件、聊天群、纸质单据和同事确认之间。

Jobs to Be Done 常被译为"待完成的工作"或"用户要完成的任务"。它强调用户购买或使用产品，是为了在特定情境下推进某个目标。这里把 JTBD 作为一种实用视角：不要只问用户是什么人，还要问他想完成什么事、为什么现在要完成、完成不了会怎样。当前资料库尚缺 JTBD 专门来源，因此不把它写成完整理论体系，正式出版前建议补充专门资料。

用户旅程地图，Customer Journey Map 或 User Journey Map，是描述用户从目标产生到完成或放弃过程的工具。它关注用户经历的阶段、触点、行为、感受、痛点和机会。旅程图的重点不是画一条漂亮时间轴，而是让团队看到体验如何跨越多个触点。用户在 App 上提交申请，在短信里收到通知，在网页上补材料，再打电话问客服，最后去线下网点处理问题。组织内部看起来是五个渠道，用户感受到的却是一件事有没有被顺利办完。

服务蓝图，Service Blueprint，是连接前台用户触点、后台流程、支持系统和角色协作的工具。NN/g 对服务蓝图的介绍强调了前台与后台、用户行为与支持流程之间的关系。 如果旅程图像用户眼中的路，服务蓝图就像路面下面的管线、阀门和维修口。用户只看到提交、等待、通知和结果，服务蓝图会继续追问：后台谁处理？系统如何流转？哪些规则触发？客服如何介入？哪里可能断裂？¹

六组容易混淆的边界

用户画像不是用户人设。 很多画像看上去很完整，实际却停在角色设定。一张画像里写了姓名、年龄、收入、兴趣、口头禅，还配了一张照片，却没有说明用户目标、关键任务、行为差异、限制和设计影响。这样的画像很容易被挂在墙上，等到需求评审时却没人再提。判断画像有没有用，可以问一个很现实的问题：有了这张画像之后，团队会不会改变方案、优先级、文案、流程或指标？如果答案都是否定，它大概率只是装饰。

用户画像不等于用户分群。 分群通常来自数据或业务划分，比如新用户/老用户、高价值客户/普通客户、管理员/普通员工、购买者/使用者。它回答"有哪些不同群体、规模如何、价值如何"。画像往往要把多次访谈、观察和数据线索揉在一起，最后回答的是一类人在任务中怎样理解规则、怎样行动、受什么限制、怎样判断事情算办成。两者最好配合使用。先用分群理解业务结构和用户规模，再用画像表达关键群体的行为和需求。只做画像容易缺少规模感，只做分群又容易缺少人的处境。

场景有别于用户故事模板。 敏捷团队常写用户故事："作为某类用户，我想要某个功能，以便达成某个目的。"这对需求表达有帮助，但它往往太短，无法充分表达使用情境。场景需要更具体。比如"作为财务人员，我想审核报销单"还不够。更有用的场景是：月底结账前，财务人员要在一天内处理大量报销单，他需要快速识别异常发票、确认费用归属，并把有问题的单据退回给申请人。此时效率、批量处理、异常提示和退回说明就会变得重要。

任务流不同于系统流程图。 系统流程图常从系统状态出发，描述页面、接口和后台处理。任务流要从用户目标出发，描述用户如何一步步推进目标。同样是"提交报销"，系统可能看到的是创建、编辑、校验、提交、审批、归档；用户看到的是准备材料、确认规则、填写信息、担心出错、等待审批、处理退回、确认到账。如果只看系统流程，团队会遗漏用户在系统外的工作和情绪成本。

用户旅程地图不同于流程图。 流程图通常描述步骤顺序，旅程地图还要表达目标、触点、情绪、痛点和机会。比如一个售后退货流程图可以写成：申请退货、商家审核、寄回商品、平台退款。旅程地图会继续呈现：用户为什么要退货，在哪一步不确定，是否担心运费，客服是否说法一致，物流状态是否透明，退款后是否恢复信任。旅程图要补上的，正是流程图看不到的那部分：不确定、等待、反复确认、信任下降，以及这些感受如何影响下一步行为。

服务蓝图不是旅程图的高级版本。 服务蓝图不是把旅程图画得更密，而是把视角从"用户经历了什么"推进到"组织怎样交付这段经历"。如果问题主要在前台信息表达，旅程图可能已经足够；如果问题涉及客服、运营、审批、库存、排班、系统接口和第三方服务，就需要服务蓝图继续追到后台。前者让团队看见用户一路怎么走，后者让团队看见这条路是谁铺的、哪里断了、谁有权修。

怎样建模：从研究到决策的一条路

以售后退货项目为例，团队可以先把工单、访谈和行为数据放在一起，看到"买错尺码""不知道谁承担运费""寄回后没有进度"三类问题。接着区分首次退货用户、频繁购买用户和客服人员，再写出他们各自的使用场景，拆开退货任务，最后画出从申请、寄回、等待、退款到账到再次购买的旅程。

这条路不必每个项目都走全。小项目可能只需要场景和任务分析，复杂服务可能需要画像、旅程图和服务蓝图一起上。关键不是工具摆得齐不齐，而是模型有没有让团队更清楚地做判断。

先明确建模目的。 开始画画像或旅程图之前，先问一句更朴素的话：团队接下来要靠它决定什么？如果团队要确定产品面向哪类用户，分群和画像更有用。如果团队要优化某个流程，任务分析和旅程图更有用。如果团队要解决跨部门服务断裂，服务蓝图更有用。如果团队要设计内容和入口，场景和任务会比宽泛画像更有帮助。没有目的的建模，最容易变成模板填空。

用证据建立画像。 画像应该从研究和数据里长出来，而不是从会议室想象里长出来。建立画像时，可以先整理用户目标、行为模式、任务频率、能力差异、约束条件、决策标准和痛点。不要急着给画像起名字、找照片、写性格标签。那些元素只在帮助记忆时有用，如果它们掩盖证据，就应该少用。例如一个 SaaS 产品可能有三个关键画像：负责购买的业务负责人、负责配置的管理员、每天使用的普通员工。购买者关心价值、预算和风险；管理员关心配置、权限和维护；普通员工关心是否省事、是否打断工作。把这三类人混成"企业用户"，后续设计就会失焦。

写好场景。 场景要把用户放回真实处境。写场景时，不妨把问题问具体：谁在用？为什么现在用？他想完成什么？当时有没有时间压力？他已经知道什么、不知道什么？哪些限制会让他失败？完成这件事对他意味着什么？比如"用户使用在线问诊"太宽。更具体的场景是：晚上 10 点，孩子突然发烧，家长在家中用手机寻找儿科在线咨询。他焦虑、时间紧、希望尽快判断是否需要去医院，同时又担心平台医生是否可靠。此时设计重点会落在可信信息、响应时间、风险提示、人工介入和后续指引，而不是单纯页面美观。场景越具体，设计判断越不容易飘在空中。

做任务分析。 任务分析不要从页面开始数，而要从用户目标开始拆。以"新员工入职系统开通"为例，管理员的任务不只是"添加用户"。他可能要收集员工信息、确认部门和岗位、选择权限模板、配置系统权限、通知员工、处理登录失败、根据岗位变化调整权限。如果每一步都拆清楚，团队就能看到哪些地方需要默认模板，哪些地方需要风险提示，哪些地方需要批量操作，哪些地方需要撤回。任务分析还要区分主任务和支持任务。主任务是用户真正要完成的事，支持任务是为了完成主任务不得不做的事。好的设计会尽量减少支持任务，让它们更清楚，也更容易撤回和恢复。

绘制用户旅程地图。 一张可用的旅程图，至少要把阶段、用户目标、用户行为、触点、情绪或感受、痛点、证据和机会放在同一张图里。旅程图不靠"大"取胜。初学者常把旅程图画成一张巨大的表，里面塞满信息，最后没人愿意看。更实用的做法，是围绕一个明确问题画旅程。如果目标是优化退货体验，就只画从"产生退货意图"到"收到退款并恢复信任"的过程。如果目标是优化 SaaS 新手体验，就只画从"注册"到"完成首次价值动作"的过程。旅程范围太大，会让痛点变得泛泛；范围太小，又可能看不到前后影响。

从旅程图走向服务蓝图。 当旅程图暴露出问题一路跨过多个团队时，就该进入服务蓝图。例如用户抱怨"申请提交后没有消息"。旅程图能显示用户在等待阶段焦虑、反复刷新、联系客服。服务蓝图会继续追问：后台是否有人审核？审核系统是否自动通知？短信服务是否稳定？客服能否看到审核状态？如果审核被退回，谁负责解释原因？这时体验问题已经不只是页面问题，而是前台触点和后台协作的断裂。

把模型转化为设计机会。 用户模型最后要回到决策桌上。画像可以让团队判断优先服务谁；场景可以让团队判断设计重点；任务分析能暴露步骤和决策负担；旅程图能识别跨触点痛点；服务蓝图能把后台协作问题从幕后拉到台前。如果模型没有转化为设计机会、优先级或验证计划，它就还没有真正发挥作用。

实际场景

场景 1：SaaS 产品的新手体验。 一个项目管理工具发现新用户注册后很快沉默。团队最初想做更漂亮的新手引导，但研究发现，新用户不是不喜欢界面，而是不知道如何把自己的团队工作搬进系统。这时用户画像可以区分个人尝试者、团队管理员和部门负责人。场景可以说明他们是在试用期、赶项目进度、还是被老板要求评估工具。任务分析可以拆出创建项目、导入成员、建立任务、分配负责人、完成第一次状态流转。旅程图则能看到用户在哪一步开始犹豫，在哪里需要模板，在哪里需要邀请同事，在哪里担心打扰团队。指标也会随之变化。团队不应只看注册成功，而应看首次项目创建率、邀请成员率、首次任务流转率和 Time to Value。

场景 2：企业后台的多角色协作。 企业后台常常不是一个人在用。以采购审批为例，申请人要提交需求，部门负责人要审批预算，采购人员要比价，财务要确认付款，法务可能要审核合同。每个角色都说"系统不好用"，但不好用的原因完全不同。画像先把角色目标分开：申请人怕流程慢，审批人怕预算失控，采购怕比价证据不足，财务怕付款信息出错。任务分析再拆每个角色的动作，旅程图把一次采购从申请到付款串起来，服务蓝图继续追到后台规则、系统接口和部门责任。如果只做一个"采购用户画像"，团队很可能把多角色问题压扁，最后设计出一个谁都能用一点、但谁都不顺手的系统。

场景 3：售后退货的跨触点体验。 售后退货很适合用旅程图。退货体验不是从用户点击"退货"按钮那一刻才开始。他可能先发现商品不合适，查看退货规则，担心运费，联系商家，提交申请，等待审核，打包寄回，追踪物流，等待退款，最后决定是否还信任平台。如果团队只优化退货申请页面，可能碰不到真正消耗信任的地方：规则看不懂，商家回复慢，物流状态不透明，退款到账时间说不清。旅程图能把这些断点串在一起，让团队看到用户的不满不是来自单个页面，而是来自多触点之间的信息断裂。

场景 4：公共服务中的申请流程。 公共服务常常涉及线上线下、政策语言、材料准备、人工审核和多部门协作。以补贴申请为例，申请人要先判断自己是否符合条件，再准备材料、在线填写、等待审核、补充材料、接收结果。如果资格条件难懂、材料名称不一致、审核状态不透明，他可能反复打电话、跑线下窗口，工作人员也会增加解释成本。这类场景中，画像、旅程图和服务蓝图要同时照亮三件事：申请人如何理解政策，工作人员如何解释和处理，后台流程如何流转。它们不只服务界面设计，也服务内容设计、流程优化和组织协作。

案例

想象用户提交申请后一直没有消息。旅程图能让团队看到用户在等待、查询、打电话、再次提交之间反复切换；服务蓝图会继续追问：后台有没有派单，短信是谁触发，客服看到的状态和用户看到的状态是否一致。Service Design Network 对服务设计的说明，以及服务设计相关教材，可以放在这个场景里理解：服务设计关注跨触点、跨角色和服务系统，而不是只优化一个界面。 服务蓝图是诊断和协作工具，成效取决于组织是否愿意调整流程、系统和权责。⁴

NN/g 的 Journey Mapping 101 和 Service Blueprints 资料也可用于区分两种工具。旅程图用于理解用户体验过程，服务蓝图用于进一步理解服务交付结构。 它们帮助初学者理解：旅程图关心用户一路怎么经历，服务蓝图关心组织如何把这一路交付出来。两者都能帮助团队跳出单个页面，但观察重心不同。²

衡量模型有没有用

模型画完不代表工作完成。更关键的是它有没有让团队少一点误判：优先级是否更清楚，方案是否更贴近任务，验证指标是否更对题。画像可以用证据覆盖度来衡量——是否来自访谈、观察、行为数据或客户反馈，是否说明样本限制，是否区分了关键用户差异，是否能影响需求优先级和设计判断。场景可以用具体性来衡量——是否说明触发条件、时间压力、环境限制、用户目标和风险，是否避免只写一句抽象目标。任务分析可以连接任务成功率、任务完成时间、错误率、学习成本和支持咨询：比如企业后台权限配置，如果任务模型准确，团队后续就不只看"权限页面是否上线"，而会观察配置错误是否减少、完成时间是否缩短、IT 支持工单是否下降、新员工开通等待是否变短。旅程地图可以连接漏斗流失、客服联系率、投诉率、CSAT、CES 和关键触点满意度：以退货为例，如果用户主要卡在规则理解和退款等待，团队就不能只庆祝"退货申请提交率提高"，还要看规则相关咨询是否下降、审核等待是否缩短、退款到账咨询是否减少，以及用户对售后过程是否重新建立信任。服务蓝图则可以连接后台运营指标，如平均处理时长、一次解决率、返工率、跨部门交接次数和客服成本——但这些指标不能直接证明旅程图或服务蓝图本身有效，它们只能说明模型指导下的改进是否可能影响了服务结果。⁵

更实际的衡量方式是看模型是否进入了决策：画像影响了目标用户选择吗，旅程图改变了优先级吗，任务分析影响了流程和信息架构吗，服务蓝图暴露了后台协作问题吗。

常见误区

画像越像真人越好？ 照片、名字和口头禅能帮助记忆，但不能替代证据。把画像重点放在目标、行为、限制、任务和设计影响上。

一个产品只需要一个用户画像？ 很多产品有多个关键角色。尤其是 B2B、SaaS、企业后台和服务系统，购买者、管理员、实际使用者和支持人员可能完全不同。根据关键任务和决策差异建立少量核心画像，而不是把所有人压成一个"平均用户"。

旅程图越大越专业？ 过大的旅程图容易变成信息墙，团队看完不知道该做什么。围绕明确问题选择旅程范围，只保留能帮助决策的信息。

旅程图就是流程图？ 流程图只说明步骤，旅程图还要说明目标、触点、感受、痛点、证据和机会。每个阶段都追问用户为什么这样做、在哪里卡住、情绪和风险来自哪里。

服务蓝图只是设计师工具？ 服务蓝图常常涉及客服、运营、技术、销售、线下服务和管理层。把服务蓝图用于跨部门对齐，而不是只作为设计团队内部产物。

用户模型一旦完成就长期有效？ 用户行为、业务策略、产品功能和组织流程都会变化。模型也会过期。在关键项目、重大改版、用户群变化或服务流程变化后更新模型。

没有量化数据就不能做画像？ 早期项目可能只有访谈和观察证据，也可以建立探索性画像。标注证据等级和不确定性。探索性画像可以帮助学习，但不能被当作稳定用户结构。

用户画像、场景、任务分析和用户旅程地图，最终都要把"我们理解用户"这句话变成团队能使用的工作语言。

关键不是会不会套模板，而是能不能用证据建立模型，并让模型影响设计机会、优先级和验证计划。比如先选定"新管理员"这个关键画像，再写他为新员工开通权限的场景，接着拆开邀请成员、选择角色、确认权限和撤回错误的任务，最后用旅程图看哪些触点让他停住。

识别这些工具是否真的在降低决策风险：可信的用户模型会说明证据、边界和用途；有用的用户模型会改变团队对问题、优先级和投入的判断。

不要为了显得专业而画模型。只有当模型让团队更清楚地知道"为谁设计、在什么情境下设计、解决哪段任务、观察什么结果"时，它才真正有价值。

⁶NN/g 的 *Journey Mapping 101* 提供了从用户旅程中发现体验痛点的基本方法，初学旅程图的团队可以以此为起点。³

注释

¹ NN/g, Journey Mapping 101。用户旅程地图可用于表达跨触点用户经历、痛点和机会。 🔗 https://www.nngroup.com/articles/journey-mapping-101/

² NN/g, Service Blueprints。服务蓝图连接前台触点、后台动作和支持流程。 🔗 https://www.nngroup.com/articles/service-blueprints-definition/

³ GOV.UK Public Design Evidence Review: Case Study Bank。复杂公共服务需要多角色、多触点和服务系统视角。 🔗 https://www.gov.uk/government/publications/the-public-design-evidence-review/public-design-evidence-review-case-study-bank-html

⁴ Service Design Network / Polaine, Lovlie, Reason, Service Design。服务设计关注跨触点、角色协作和服务交付系统。 🔗 https://rosenfeldmedia.com/books/service-design/ 方法资料不等于商业成效证据。

⁵ Don Norman, The Design of Everyday Things。任务分析和观察证据可支撑用户模型。 🔗 https://www.nngroup.com/articles/task-analysis/

⁶ NN/g, Mental Models。用户心智模型、分类和任务理解会影响后续信息组织。 🔗 https://www.nngroup.com/articles/mental-models/ 认知基础在第 9 章讨论，具体 IA 方法在第 10 章展开。