第 7 章 · 体验设计

引言#

问题定义清楚之后，产品经理很容易进入一个熟悉的动作：画方案→出流程/方案→评设计稿→排期开发。到了这一步，团队讨论的语言会变得很具体：这个页面是不是太挤，路径是不是太长，按钮是不是够明显，信息是不是完整，交互是不是顺。设计师会关注视觉层级和操作路径，运营会关注利益点是否露出，研发会关注规则能不能实现，产品经理夹在中间，看起来是在做体验判断。我觉得很多所谓的体验判断，其实只是停留在界面，缺失了对用户任务的关注。界面当然重要，页面混乱、文案含糊、操作反常识，都会让用户被劝退。但如果产品经理只盯着界面，就很容易把体验误解成页面更清楚、路径更短、信息更全、样式更统一。真实情况往往没这么简单：用户觉得累，不一定是因为按钮难找；用户停留很久，不一定是因为兴趣更强；用户不用一个功能，不一定是因为不会用。有时他是在算账，有时他是在犹豫后果，有时他是在等别人确认，有时他是在担心自己点下去之后要解释什么。

我们这章不讲UI设计，也不讲交互规范，坦言说设计师可比产品经理更懂视觉、动效、组件和细节体验，产品经理不应该把自己伪装成半个设计师。产品经理真正要承担的，是另一类判断：这个设计有没有让用户在真实场景里更低成本地完成任务。这里的成本，不只包括点击次数和页面长度，它还包括认知成本、操作成本、等待成本、解释成本、责任成本和出错成本。一个设计如果只是让页面看起来更完整，却把计算、判断、解释等风险都留给用户，它就不算真的好用。反过来，有些设计看起来很朴素，甚至不太显眼，但它把用户脑子里的那道题拿掉了，把用户心里的那点不确定兜住了，把用户出错后的退路留好了，它就可能是真正好的设计。当问题定义已经相对清楚之后，方案不应该自然长成一堆功能，而应该先问清楚，用户完成这件事时，最重的成本在哪里。体验设计不是问题定义之后的美化环节，而是问题定义真正落到用户任务里的第一道关。

7.1 画任务线——从页面路径到用户路径#

拿到一个设计稿时，产品经理的第一反应往往很自然：看页面，看路径，看流程。这个反应太习惯了，以至于很少有人会停下来问一句：我看到的这条路径，是用户真正要走的路，还是产品想让用户走的路？这两件事在大部分设计稿里是重合的，用户从A到B再到C，流程上确实走得通，但重合不代表一致。页面路径描述的是用户经过了哪些页面，任务线描述的是用户为什么要经过这些页面，以及在页面之外他还做了什么。页面路径在产品内部，任务线在用户现场。如果产品经理只盯着页面路径做判断，就很容易把体验理解为“页面更清楚、路径更短、信息更全、样式更统一”，但用户觉得累，往往不是因为页面不够顺，而是因为任务线中间有东西没被接住。

我以前做过一个“到手价”的项目，就是从页面路径和任务线的差异开始切入的。当时平台的营销能力发展得很快，沉淀了大量可复用的促销工具。拼团、秒杀、补贴、套餐，每一个业务场景都有对应的价格形态；满减、立减、赠品、优惠券、积分，每一种促销工具也都有自己的规则和互斥关系。单看平台能力，这当然是好事，促销工具越多，平台可以组织的活动越丰富，运营可以调动的杠杆越多，用户理论上也能拿到更多优惠。但问题出在商详页的数据表现上，一个商品可能标着“拼团价89元”，旁边又写着“单独买99元”；页面上有一张“满99减10”的券，但拼团价用不了，只有单独买才能用；积分可以抵扣一部分，但有上限；如果买两件，还有第二件半价。价格区本身已经很拥挤，往下还有优惠券领取区、满减活动说明、赠品展示区和各种利益点标签。这些信息在页面路径上都是通的：用户能看到每个标签，每个标签都有入口，每个入口都能点进去看规则。从页面设计角度看，信息完整、路径清晰、结构也合理。但用户的任务线不是“看完所有优惠信息”，用户进入商详页时，尤其是在大促场景里，最关键的任务是确认一件事：我买这个东西，最终要花多少钱，然后判断它值不值。

页面路径给了用户一堆材料：原价、活动价、券后价、满减规则、积分抵扣、赠品条件，用户需要自己把这些材料拼成一个最终数字，而任务线需要的，就是这个最终数字本身。页面路径没有给用户答案，只给了原材料，让用户自己算。这两条线之间出现了断层，断层的位置很隐蔽，页面路径看起来是完整的，用户没有在任何一个环节被卡住，也没有任何一个按钮点了没反应。但任务线从“看价格”到“确认最终价格”之间多了一步“自己算”，这一步对页面来说看不见，对用户来说却实实在在。大促数据印证了这个判断，活动期间的商详页和购物车的用户停留时长相比日常增加了将近50%，但转化率没有同步提升。继续拆下去，规律更明显，营销工具覆盖越多的商品，用户停留时长越长，但转化率和其他商品没有明显差异。一个商品如果同时有拼团价、满减、优惠券、积分抵扣，用户会在页面上停留很久；如果只有一个价格标签，用户反而决策更快。与此同时，客服那边也在持续反馈，大量用户进线问：“这个商品到底多少钱”、“拼团价和券能不能一起用”、“积分还能再减吗”。用户花在“算账”上的时间，比花在“做决定”上的时间还多。

这个差异把问题指向了一个方向：用户在页面路径上走了很远，但任务线在“确认最终价格”这一步断了。因为他拿到的是一堆规则，不是一个答案。方向变得很清楚，商详页不应该继续让用户自己算。系统应该把拼团价、秒杀价、满减、立减、优惠券、云币抵扣等所有可用优惠算好，直接在主价格区给用户一个最终数字：“预估到手价”。其他优惠不再争抢主信息，降级为利益点标签，放在到手价下方，用一句简单说明告诉用户这个价格已经包含哪些优惠，用户如果想看明细，可以点击展开查看。这个方案在讨论时遇到一个分歧，运营同学希望把所有优惠明细都直接列出来，理由很合理：我们确实给了这么多优惠，用户要相信这个价格，就应该看见优惠从哪里来。如果只给一个到手价，会不会显得像平台随便标了一个数字？这个担心不是没有道理，但它混淆了两件事：页面路径的完整性和任务线的顺畅性。把所有优惠明细列出来，页面路径当然更完整，但用户的任务线没有变顺，他只是从“自己算”变成“看别人怎么算”，仍然要花精力理解每一项优惠，仍然要判断这个最终价是否真实可达，页面路径看起来更丰富了，但任务线的断层还在。

上线后，A/B 测试验证了这个判断。商详到支付转化率提升了 23.5%；商详页平均停留时长下降了约 20%；加购率明显提升，尤其是价格敏感型商品；在线客服的价格咨询进线量明显下降。更有意思的是，不同活动档位、不同营销工具覆盖数量的商品之间，转化差异开始被拉开。过去用户分不清“拼团价”和“满 299 减 50”到底哪一个更值，现在到手价把差异直接摆在眼前，用户能更快判断哪个选择更适合自己。商详页停留时长下降，反而是一个好信号，它说明用户花在算账上的时间少了，用户不是少看了商品，而是少做了一道不该由他做的题。数据不只是在验证一个方案的成功，它也在验证一件事：当页面路径和用户任务线对齐时，用户的行为会发生可见的改变。

画任务线不是画一个流程图，而是画用户“做决定”的完整过程。流程图在页面边界内就停下来了，用户进入商详页，看完信息，加购或离开。任务线要到用户心里才停下来，他有没有得到做决定需要的那个关键答案，还是说他在用自己脑子里的计算器在算。页面路径说“用户已经看到了所有优惠”，但任务线可能在说“用户看了很久，但没看懂”。两条线之间出现断层时，最容易被误读的指标就是停留时长，停留变长不一定是因为更感兴趣，有时只是用户被困住了。页面路径越完整，这种误读越容易发生，因为看起来“一切正常”。落地到具体方法上就是：拿到一个设计稿之后，先别急着评价页面好不好看、路径顺不顺、信息全不全。先做一件事，画一条线，从用户决定做这件事的起点，到他确认可以结束的终点，把这条线上所有用户自己完成的“脑内动作”标出来。他需要算什么，需要判断什么，需要担心什么，需要等什么，需要解释什么。然后问自己：这些动作里，有哪些本该由产品承担，却被留给了用户？到手价之前，用户需要自己算优惠，这就是一个被留给了用户的脑内动作，去掉它，就是画任务线之后最重要的判断。截止到这，我想说的是一个应该形成的习惯：别再只看页面了，先看见用户在走的那条路，再决定页面上放什么东西。

7.2 降成本项——从操作效率到使用意愿#

到手价讲的是C端场景里最常见的一类体验成本：用户不想在购买前替系统算账。到了B端，问题会复杂一些，B端用户当然也希望系统顺、路径短、效率高，但很多时候，真正挡住使用的不是操作成本，而是责任成本。我曾经在做一个零售平台的价格中心时，对这件事感受很深。当时平台针对自营品类搭建了价格中心，管理着5000多个SPU、超过3万个SKU。部分品类的市场价格波动非常敏感，生鲜、日用、3C这些品类，今天一个价，明天一个价，人工调价很难追上市场节奏。运营和品类同学都很清楚，靠人工维护数万SKU的价格不现实，于是团队做了一套自动调价能力。从方案上看，这个能力很完整，系统接入市场价格监控和成本监控，基于成本、市场价、不同时间段、不同用户类型、不同曝光程度等因子，自动计算建议价格并执行调价。策略配置页面也做得不错，操作路径清晰，各种调价因子都能灵活组合，还接入了OA审批流程，策略配置完后，要经过层层审批才能生效。站在产品团队视角，这已经是一个相当成熟的中后台能力。

上线后，大家也都说这个能力好，方向对，逻辑对，实现也对。但使用数据不乐观，自动调价覆盖的基本都是低价、低毛利、边缘品类商品，核心品类和重点商品几乎没人敢用。一线运营同学的态度很微妙：嘴上说好，手上不用。问他们为什么，回答很一致：怕，不是怕系统不会调，也不是怕配置页面太复杂，而是怕“出了错算谁的”。自动调价一旦跑起来，价格是系统自动调整的。如果价格调低了导致亏损，或者调高了导致销量下滑，最终背KPI的是运营同学，不是系统。审批流程当然存在，审批通过也代表组织认可了这套策略，但“审批过了”和“出问题了我能解释”之间，隔着一道很大的心理鸿沟。这个现象暴露出B端体验里很容易被忽略的一点：审批解决的是合规问题，不一定解决责任问题。一个策略经过审批，说明它在流程上被允许执行。但当系统自动做出的决策产生负面结果时，谁来解释为什么这么调？谁来证明当时依据是什么？谁来处理亏损或销量波动？这些问题不会因为有审批就自动消失。人工调价虽然慢、累、容易漏，但运营同学知道这个价格是自己调的。他知道为什么调，知道当时看的数据，知道哪位业务同学催过，知道这个决定的来龙去脉，即使被问责，他至少能解释。但自动调价不一样，价格是系统算出来的，运营只是配置了策略，价格出问题时，他很难回答老板那句最现实的问题：“这个价格怎么定的？”。如果系统无法解释、无法追溯、无法补救，用户就不会把核心决策交给它。

后来我们做了几个调整，核心思路不是让配置更简单，而是让用户对系统行为重新获得掌控感：

• 兜底策略：用户可以在配置策略时设置安全边界，如果调价后击穿毛利底线，系统自动恢复到上一次调价金额，该商品进入自动调价黑名单，并在群里预警。或者击穿毛利后按策略总约定的某个固定毛利作为兜底定价，至少保证不亏。这个设计的本质不是多一个配置项，而是告诉用户：系统可以在边界内自动执行，但到了危险边界会停下来等人介入。
• 预览能力：策略新建时，系统提前展示这个策略覆盖哪些商品、下一次预计调价时间和金额、调整后的毛利、与当前价格的差距，并直接提示风险，比如“该商品有击穿当日毛利风险”。这一步把用户最担心的后果提前摆出来，用户不再是把策略交给系统后等结果，而是在系统行动之前先看到可能发生什么。
• 提前告知：针对部分核心商品，系统在自动调价前把即将执行的调价动作和金额变动推送到群里，提前告知相关同学。这个动作很轻，但它对用户很重要，核心价格不是偷偷改，而是有人知道、有人可追溯、有人能在异常时及时介入。

这些调整上线后，自动调价覆盖范围明显扩大，核心品类和重点商品开始有人敢用了。不是因为价格风险消失了，而是因为用户知道自己有退路：击穿毛利有兜底，调价之前能看到预览，核心商品的调价动作有人知道。系统做的事本质上没有变，还是基于各种因子自动计算价格。变化的是用户对这件事的感受，他不再觉得自己把定价权完全交给了系统，而是觉得系统在自己的规则里执行，自己仍然握着方向盘。

这个案例让我加深了对B端体验的理解，很多C端场景首先暴露的是麻烦，很多B端场景更深处藏着担责。C端用户怕的是“麻烦”，所以体验优化的方向是让操作更顺、路径更短、决策更快。但B端用户怕的是“担责”，用了系统之后出了事，自己解释不了、补救不了、也无法证明当时不是自己的问题。如果产品只降低操作成本，却没有降低责任成本，用户会很聪明地绕开它。这也是为什么一些B端产品看起来功能完整，却使用率很低。产品团队会继续优化页面、缩短路径、增加快捷操作，但用户真正缺的可能不是更快，而是更安全。系统越自动化，用户越需要知道边界在哪里；系统越替人决策，用户越需要知道依据是什么；系统越高效，用户越需要有撤回、预览、留痕和兜底。自动化不是把人从责任里拿掉，而是让人能在更清楚的责任边界里使用系统。

7.3 任务成本视角——从案例判断到可复用视角#

两个案例讲完，如果只记得“到手价”和“自动调价”这两个故事，那就只停留在我遇到过的两个体验问题，这是远远不够的，真正有用的是：下一次产品经理面对一个页面、一个流程、一个设计稿、一个中后台能力时，能不能更稳定地判断，体验到底应该往哪里改。体验设计面对的不是一条线性的流程，而是一组交织的取舍：信息该露还是该藏，选择该减少还是保留，确认该删掉还是补上，复杂该交给系统还是留给用户。所以更适合沉淀的不是一个固定步骤，而是一个拆解视角，把“体验好不好”拆成“任务成本由谁承担”，这个视角里最先要看的，是用户正在完成的任务线，而不是产品里的页面线。页面线通常是产品内部视角：进入商详页、查看价格、领券、加购、支付；进入价格中心、配置策略、提交审批、自动调价。任务线则是用户视角：我想知道这件商品最终多少钱，判断值不值；我想让系统帮我调价，但出问题时我还能解释、能补救。这两条线不一样，页面线描述用户经过了哪些地方，任务线描述用户为什么要经过这些地方。产品经理如果只看页面线，就会自然优化页面；如果看任务线，就会发现有些页面本身不是问题，有些页面外的动作才是问题。到手价里，用户的任务线不是“看完所有优惠信息”，而是“确认最终价格并判断值不值”。自动调价里，用户的任务线不是“配置完策略并提交审批”，而是“在可控风险内把调价动作交给系统执行，并在异常时能解释和补救”。任务线看清楚之后，再看用户付出了哪类成本。到手价里最重的是认知成本，用户要理解优惠叠加、互斥和抵扣规则，同时也有解释成本，因为用户不清楚价格，就会找客服确认。自动调价里最重的是责任成本和出错成本，用户不是不会配置，而是不敢让系统碰核心商品，同时也有解释成本，因为出事以后他需要说明系统为什么这么调。

很多体验优化之所以无效，就是因为把成本看错了。用户不用定时群发，不一定是时间选择器不顺；用户不用自动调价，不一定是策略配置复杂；用户在商详页停留很久，也不一定是商品信息不够吸引人。你以为在降操作成本，用户真正承受的可能是责任成本；你以为在补信息，用户真正缺的是一个可以直接行动的结果。成本看清楚之后，真正难的是判断复杂应该由谁承担：

• 有些复杂应该放进系统：优惠叠加、价格计算、历史意向匹配、默认支付方式、库存状态判断，这些事情系统比用户更快、更准、更稳定。让用户自己处理，只是在浪费他的注意力。
• 有些复杂应该留给用户，但要用更清楚的方式呈现：比如最终价格的明细、自动调价的风险、批量操作影响范围、发送前确认、审批依据。这些事情不能完全藏掉，因为它们关系到信任、责任和后果。用户不一定每次都看，但他必须有能力在需要时看见。
• 有些复杂不应该由产品单独承担，而要回到组织机制里：比如谁有权审批，谁能撤回，出了问题谁复盘，风险预警发给谁，核心商品调价是否需要人工确认。这些不是单纯的交互设计问题，但它们会直接决定用户体验。B 端产品尤其如此。产品经理如果只画页面，就会低估组织关系对体验的影响。

到手价不是把优惠规则消灭，而是把计算放到系统里，把明细放到用户需要时可以展开的位置。自动调价也不是把风险消灭，而是把实时计算交给系统，把风险边界、预览和告知留在用户可控的位置，把异常处理放进组织协作里。**体验设计不是把复杂消灭，很多复杂本来就消灭不了。**优惠规则不会因为页面简化而消失，价格波动不会因为系统自动化而消失，审批责任不会因为流程线上化而消失。**真正的设计，是把复杂放到更合适的位置，**这样理解之后，具体设计动作就不再是“加功能”或“减步骤”那么简单。到手价里的关键动作，是主价格区先给最终数字，底部弹窗保留明细依据。聚合支付里的关键动作，是默认上次支付方式，同时保留切换入口。满减凑单里的关键动作，是购物车就地展示近期有意向且能跨门槛的商品。定时群发里的关键动作，是预约期间可撤回，发送前 30 分钟二次确认。自动调价里的关键动作，是兜底策略、调价预览、风险提示和核心商品提前告知。

这些设计动作看起来不一样，但本质相同：它们都在降低某一种具体成本。如果成本是认知，就给结果、给默认、给排序，不要让用户重新理解一套规则；如果成本是操作，就减少跳转、减少重复输入、让用户停留在当前任务里；如果成本是等待，就给状态、给预期、给下一步；如果成本是解释，就给依据、给口径、给记录；如果成本是出错和担责，就给预览、撤回、留痕、兜底和通知。这也是为什么“少一步”不能被简单理解为好体验。少一步之前，要先问这一步承担什么职责。它是在消耗用户，还是在保护用户？如果它只是让用户重复系统已经知道的东西，就该减少；如果它是在高风险节点帮用户确认后果，就不能轻易删掉，而要把它做得更清楚、更有用。

最后，体验设计还要回到验证，否则“体验更好”很容易停留在主观判断里。到手价上线后，我们看的不是页面好不好看，而是商详到支付转化率、商详页停留时长、加购率、价格咨询量，以及不同活动档位之间的转化差异是否被拉开，因为我们要验证的是：用户有没有少算账，能不能更快判断值不值；自动调价上线后，最重要的也不是配置页点击率，而是自动调价覆盖范围有没有扩大，核心品类和重点商品有没有开始使用，风险预警和兜底机制是否被触发，运营是否更愿意让系统执行关键调价动作，因为我们要验证的是：用户有没有更敢用，而不是页面有没有更顺。验证信号一定要对应成本，如果降的是认知成本，就看理解、咨询、停留、转化；如果降的是操作成本，就看完成时间、步骤流失、重复动作；如果降的是等待成本，就看刷新、催问、超时、取消；如果降的是解释成本，就看客服、群里追问、复盘材料、口径争议；如果降的是责任和出错成本，就看撤回、异常、误操作、核心功能使用范围。这套拆解视角可以压缩成一张表：

这张表不是流程，也不是要求每个项目都逐格填写，它更像一张评审时的坐标系，让团队别在“好不好看”、“顺不顺”、“完整不完整”里打转。有时先发现成本，有时先发现任务线，有时先发现复杂被放错了地方，重要的不是顺序，而是不要漏掉“体验到底让谁少承担了什么”。和上一章的问题定义放在一起，它们更像一个连续动作：先定义问题，再拆任务成本。前者防止团队解决错问题，后者防止团队用一个看起来完整的方案，把成本继续转嫁给用户。很多项目并不是输在其中一步，而是两步都跳过了：问题还没定义，就开始画页面；页面画完以后，又只看视觉和路径，不看用户到底少承担了什么。

7.4 固化机制——让体验判断进入设计评审#

如果体验判断只停留在某个产品经理的个人敏感度里，这件事不稳定。一个项目里他想到了，体验就会被拆成任务成本；另一个项目里他被排期压住，体验又会退回页面好不好看、路径短不短、信息全不全。所以体验设计要在评审机制中体现，这里说的机制，不是增加流程，也不是给设计评审再加一堆表格，而是让团队在讨论设计稿之前，先把几个问题说清楚。尤其要注意的是，在评审体验设计时，少说一句“这里体验更好”，多补一句“这里降低了什么成本”，这句话会逼着人把体验说实。如果他说降低操作成本，那就看路径有没有真的减少跳转和重复输入；如果他说降低认知成本，那就看用户是否少理解了一套规则；如果他说降低风险，那就看有没有预览、撤回、留痕和兜底。体验一旦被拆成成本，很多模糊判断就会变成可讨论的设计取舍。具体到评审，有几个在流程上可关注的事情：

先讲用户任务，不先讲页面变化

很多设计评审一上来就讲页面：这里新增一个模块，那里加一个弹窗，这里调整价格区，那里优化按钮。听起来很专业，但团队很快会被页面本身带走。更好的开场，是先讲用户任务：用户来到这里是为了完成什么？他当前卡在哪里？他现在付出的成本是什么？到手价评审如果一上来讲“价格区要收拢”、“优惠明细要放到底部弹窗”，运营很容易担心优惠露出不够。可如果先讲“用户在商详页最关键的任务是确认最终多少钱，现在他在算账”，后面的方案就有了依据。自动调价评审也是一样，如果一上来讲“新增兜底策略和风险预览”，业务会觉得流程又重了；但如果先讲“核心商品没人敢用，因为用户无法解释系统为什么这么调”，新增控制点就不再是多余功能，而是让功能被用起来的前提。

明确主要降低哪类成本

一个方案不可能同时把所有成本都降到最低。想降低认知成本，可能要隐藏部分信息；想降低解释成本，可能要保留明细；想降低操作成本，可能会减少确认；想降低出错成本，可能要增加预览和确认。团队如果不先排序，就会在评审里互相拉扯。到手价里，主路径优先降低认知成本，所以不能把所有优惠明细摊在价格区；但可信度也重要，所以底部弹窗必须保留。自动调价里，不能为了操作顺滑删掉预览和兜底，因为这次真正要降的是责任成本和出错成本，而不是配置步骤。

说明复杂被分配到了哪里

任何体验优化都不是让复杂凭空消失。到手价看起来简单，是因为复杂进入了系统；自动调价看起来更安全，是因为复杂被拆给了系统、用户和组织：系统负责计算，用户负责定义边界，组织接收风险告知。产品经理在评审里要说清楚这些复杂去哪了，否则别人会误以为你只是“把信息藏起来”或者“把流程加重了”。这也是跨团队沟通里很重要的一点，运营要优惠露出，不是因为运营不懂体验，而是他们担心用户不相信优惠；业务要审批流程，不是因为业务不重视责任，而是他们以为审批已经足够兜底。产品经理不能只说“不用展示那么多”、“审批不够”，而要说明复杂如何被重新分配：主价格区给最终价，展开层给依据；审批证明策略被允许，预览和兜底帮助一线解释与补救。

明确上线后的验证信号

设计评审最容易缺这一项，大家讨论完页面，觉得方案合理，就进入开发。上线后如果数据好，就说体验优化有效；数据不好，就继续改页面。但如果上线前没有说清楚“我们到底要验证什么成本下降”，复盘会很虚。到手价的验证信号不是“用户是否觉得页面更好看”，而是商详支付转化率、停留时长、价格咨询率和加购率。自动调价的验证信号不是“策略配置页使用率”，而是核心品类是否敢用、自动调价覆盖范围是否扩大、异常风险是否能被兜住。不同成本对应不同信号，这一点必须在评审时就讲清楚。

把这四件事放进设计评审，并不会让流程变重，相反，它会减少很多无效争论。以前大家争论“信息要不要展示完整”，现在会变成“这条信息在主路径上承担什么任务，放到展开层会不会影响可信度”；以前大家争论“确认步骤能不能删”，现在会变成“这一步是在消耗用户，还是在保护用户”。讨论对象变了，评审质量也会变，这也是方法论真正落地的地方。一个产品经理如果只在脑子里知道“体验是任务成本”，但评审时仍然只说“这里感觉太复杂”，那方法没有进入工作，只有当团队开始习惯问“这里降低了什么成本”，这套方法才算真正站住。不要求产品经理写一篇体验分析报告，只要求他在讲方案之前，先把体验判断的来路说清楚。到手价可以写成：用户任务是确认最终价格并判断值不值；当前成本是算不清优惠；复杂分配是系统计算优惠、用户按需查看明细；控制点是预计到手价和明细弹窗；验证信号是商详支付转化率、停留时长、价格咨询率和加购率。自动调价可以写成：用户任务是在可控风险内让系统执行调价；当前成本是担责和不可解释；复杂分配是系统执行、人定义边界、组织接收预警；控制点是兜底、预览、风险提示和群通知；验证信号是核心商品覆盖和异常处理情况。

这些是产品经理在评审前先想清楚，而不是到评审会上临场解释“为什么这样设计”。很多方案被挑战时说不清，不是因为设计师稿子不好，而是因为产品经理没有把任务成本说清楚，评审会不是用来现场发明判断的，它更应该用来检验判断是否站得住。上线后也一样，复盘时不要只问“转化涨没涨”、“使用率涨没涨”，还要问“我们当初定义的成本有没有下降”。到手价如果转化涨了，但价格咨询率没有下降，说明用户可能仍然不信这个价格；自动调价如果使用率涨了，但核心商品仍然没人敢用，说明它只是覆盖了低风险场景，没有真正降低责任成本。复盘只有回到成本，团队才知道下一轮该继续优化方案，还是重新定义体验问题。

7.5 收敛方案——好设计让产品动作变轻#

问题定义清楚以后，方案经常会变小；任务成本拆清楚以后，设计也经常会变轻。但这里的“轻”，不是简单少做功能，也不是一味缩短路径。它更像一种重新定位：把产品动作放到用户任务最需要的位置上，把系统该承担的复杂接过去，把用户必须知道的后果说清楚，把组织里必须兜住的责任补起来。到手价没有把商详页做成更大的优惠说明中心，而是把主信息收成一个最终数字；自动调价没有继续堆更多审批，而是补了兜底、预览和告知；满减凑单没有做完整低价池，而是在购物车展示少量意向商品；定时群发没有继续做更花哨的时间选择器，而是补了发送前确认。它们都不是把产品做得更大，而是把产品放到用户任务里更合适的位置。我们常见的任务成本包含下述几种：

在做产品体验设计时，记得提醒自己，别把“体验不好”说成一句空话。下一次你准备说“这个页面太复杂”时，可以再往下问一句：复杂在哪里？是用户看不懂规则，还是用户要跳出任务？是等待没有预期，还是结果无法解释？是操作不可逆，还是责任边界不清？

• 认知成本高：解决方式可能不是再加说明，而是直接给结果。到手价就是这样。用户不需要先理解所有优惠规则，他需要先知道最终多少钱。
• 操作成本高：解决方式可能不是砍功能，而是减少任务跳出。聚合支付默认上次方式、满减凑单就地展示意向商品，都是让用户停留在原任务里。
• 等待成本高：解决方式不一定是让系统更快，有时是让用户知道正在发生什么、还要多久、是否需要他做决定。很多审核、支付、物流、风控场景里，用户真正焦虑的不是等待本身，而是等待期间没有确定性。
• 解释成本高：解决方式不只是导出更多数据，而是把口径、时间、版本、依据和责任边界一起带出去。CMS 数据看板，运营看完一个数还要搬到 Excel 和飞书里，本质上就是系统没有把数据放进协作语境里。
• 责任和出错成本高：解决方式往往不是减少确认，而是补预览、撤回、留痕、兜底和风险提示。价格中心自动调价就是这样。核心商品没人敢用，不是因为配置不顺，而是因为出错后的代价太高。

这些成本也不是互相孤立的，很多真实问题会同时叠加几种成本。到手价降低的是认知成本，也降低了客服解释成本；自动调价降低的是责任成本，也降低了出错成本和解释成本；定时群发降低的是心理成本，也补了撤回和二次确认；CMS 数据看板的问题里，有跨系统操作成本，也有向上汇报的解释成本。产品经理真正要做的，是判断这一轮设计最应该降低哪一种成本，不能一上来就说“体验要更好”，这句话太大，落不到方案上。要说清楚：这次是让用户少算一次账，少跳一个系统，少等一个不确定结果，少解释一次口径，还是少承担一次不可逆错误。当成本被说清楚，方案通常会变得更轻，而产品设计的核心目的正是如此，不是让产品显得完整，而是让任务变轻。

闲言碎语#

我刚做产品的时候，很容易被“好看”和“完整”吸引。一个页面排得整齐，按钮层级清楚，流程从开始到结束都能跑通，心里就会觉得踏实。后来做的项目多了，才发现很多真正有用的体验，并不一定显眼，有时只是少让用户算一道题，有时只是默认一个上次用过的选项，有时只是多给一次撤回，有时只是把风险提前说清楚。好体验经常是沉默的，它不抢用户注意力，不展示产品团队多聪明，也不要求用户理解背后做了多少复杂工作，它只是让用户继续往前走，而且走得没那么累。这对产品经理其实是一种很好的提醒，我们很容易想证明自己做了很多：功能很多，规则很全，页面很完整，系统很智能。但用户不关心我们做了多少，他只关心自己要完成的事有没有变轻，甚至很多时候，产品越努力展示自己，用户越累。我现在越来越喜欢那些看起来朴素的设计，不是因为朴素一定高级，而是因为朴素常常意味着克制：知道什么该露，什么该藏；知道什么该让用户决定，什么该由系统承担；知道什么时候少一步，什么时候多一步；知道让用户快一点之前，先让他清楚一点、放心一点。

产品经理做体验，不能仅仅看做一条转化路径，路径当然重要，但用户不是一个从入口流到按钮的流量单位。他是一个鲜活且明确的生命个体，他会算不清、会担心、会犹豫、会怕出错、会怕被问责、会在某个瞬间因为产品替他少想了一点、少担了一点，而愿意继续往前走。好的设计，不是让产品显得更聪明；好的设计，是让用户不用那么努力。