第 7 章 · 体验设计

引言#

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

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

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端产品尤其如此。产品经理如果只画页面，就会低估组织关系对体验的影响。

到手价不是把优惠规则消灭，而是把计算放到系统里，把明细放到用户需要时可以展开的位置。自动调价也不是把价格风险消灭，而是把实时计算交给系统，把风险边界、预览和告知留在用户可控的位置，把异常处理放进组织协作里。体验设计不是把复杂消灭，很多复杂本来就消灭不了。优惠规则不会因为页面简化而消失，价格波动不会因为系统自动化而消失，审批责任不会因为流程线上化而消失。真正的设计，是把复杂放到更合适的位置。复杂放对了，用户任务就会变轻；复杂放错了，页面再顺，用户也会继续承担不该承担的成本。

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

体验判断如果只停留在某个产品经理的个人敏感度里，这件事是不稳定的。这个项目里你想到了任务成本，方案就会往用户任务里收；下一个项目排期一紧、评审一赶，团队又很容易回到页面好不好看、路径顺不顺、信息全不全。体验设计要真正进入团队工作，不能只靠一句“这里体验更好”，而要让团队在设计评审里沿着一条更清楚的链路往下问。这五个问题是：用户真正要完成什么，用户多承担了什么成本，复杂应该交给谁，产品用什么设计动作降低成本，最后又用什么信号证明体验真的变好了。

任务线：用户真正要完成什么

不要一上来就讲页面新增了什么、按钮挪到了哪里、弹窗改成了什么样。先讲用户来到这里，是为了完成什么任务。到手价里，用户不是来学习优惠规则的，而是要确认最终多少钱，并判断值不值；自动调价里，运营不是来体验一个配置页面的，而是想在可控风险内把调价动作交给系统执行。任务讲清楚，页面变化才有依据。

成本项：用户多承担了什么

体验不好不是一个可以直接落方案的判断。要继续往下问：用户是看不懂规则，还是要重复操作？是在等待一个不确定结果，还是完成动作后解释不了？是担心点错，还是担心出了问题无法补救？不同成本对应不同设计方向。到手价要降的是认知成本，所以主路径先给最终价格；自动调价要降的是责任成本和出错成本，所以不能只优化配置路径，而要补预览、兜底、留痕和告知。

复杂归属：复杂应该交给谁

复杂没法凭空消灭。优惠规则不会因为页面简化而消失，价格风险也不会因为系统自动化而消失。关键是复杂应该放在哪里。能由系统稳定计算的，就不要让用户自己算；必须让用户知道的后果，就不能为了页面干净全部藏掉；需要组织共同承担的风险，就要进入审批、预警、留痕和兜底机制。到手价是系统承担计算，用户按需查看明细；自动调价是系统执行策略，人定义边界，组织接收风险告知。

设计动作：用什么设计降低成本

任务、成本和复杂归属说清楚以后，设计动作才有依据。到手价的关键动作，是主价格区优先给结果，明细放到用户需要时再展开；自动调价的关键动作，不是继续优化配置项，而是补预览、兜底、留痕和通知。好的设计动作不是为了让页面显得更完整，而是让任务更轻、风险更可见、后果更可控。结果优先、给默认、给明细、可预览、可撤回、有通知，这些动作看起来不一样，本质都是在把用户不该承担的成本移走，或者把用户必须承担的风险变得更清楚。

验证信号：怎么证明体验真的变好了

如果评审时说不清验证信号，上线后就很容易只看一个大指标，然后把结果解释成自己想要的样子。到手价不能只看页面点击，而要看商详到支付转化、停留时长、价格咨询量；自动调价不能只看配置页使用率，而要看核心品类是否开始使用、风险预警是否触发、异常是否能被兜住。验证信号要对应成本：降认知成本，就看理解、咨询、停留和转化；降操作成本，就看完成时间、步骤流失和重复动作；降等待成本，就看刷新、催问、超时和取消；降解释成本，就看客服、群里追问、复盘材料和口径争议；降责任和出错成本，就看核心功能使用范围、异常处理、撤回和用户是否敢把关键动作交给系统。

这五个问题放进设计评审，并不会让流程变重，相反，它会减少很多无效争论。以前大家争“信息要不要露出完整”，现在可以问“这条信息是在主路径上帮助用户做决定，还是只是增加理解负担”；以前大家争“确认步骤能不能删”，现在可以问“这一步是在消耗用户，还是在保护用户”；以前大家争“页面是不是更顺”，现在可以问“这个顺，是不是把解释、风险或责任留给了用户”。体验判断真正进入工作，不是团队多背了一套方法，而是大家开始习惯把“体验更好”翻译成更具体的话：用户少算了什么，少等了什么，少解释了什么，少承担了什么风险。只有说到这一层，设计评审才不只是看稿子，而是在判断产品有没有把用户任务里的成本放到更合适的位置上。

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

如果说问题定义解决的是“该不该这样做、为什么这样做”，体验设计解决的就是另一个问题：既然要做，产品应该把用户任务里的哪些成本接过来。到了这一步，方案不只是要对，还要轻。这里的“轻”，不是简单少做功能，也不是一味缩短路径，而是产品不再把不该由用户承担的成本推给用户。用户不该自己算的，系统先算出来；用户不该反复跳转的，产品把动作收回当前任务里；用户必须知道的风险，提前讲清楚；用户出了错需要补救的地方，产品把退路留出来。

到手价就是这样的设计，它没有把商详页做成更大的优惠说明中心，也没有试图把所有营销规则都解释完整，而是把主信息收成一个最终数字。用户进入商详页，不是为了学习拼团、满减、优惠券、积分抵扣之间的关系，而是为了确认自己最终要花多少钱。系统把计算接过去，用户就少做了一道题。明细没有消失，只是退到用户需要时再展开的位置。这个方案之所以变轻，不是因为页面少了几个模块，而是因为用户从“自己算规则”变成了“先拿到答案，再按需看依据”。

自动调价也是如此，它真正要解决的，不是配置页面够不够顺，而是运营敢不敢把核心价格交给系统执行。兜底、预览、风险提示和群通知，表面上看增加了产品动作，但用户任务反而变轻了。因为运营最担心的不是多点几下，而是出了问题以后解释不了、补救不了、证明不了当时系统为什么这么做。当系统给出边界、依据、留痕和预警，用户才会觉得自己不是把责任交给一个黑箱，而是在可控范围内使用自动化。

判断一个设计是不是变轻，不能只看页面上少了什么，也要看用户心里少承担了什么。认知成本高的时候，产品应该优先给结果，而不是继续加说明；操作成本高的时候，产品应该减少任务跳出，而不是只压缩页面步骤；等待成本高的时候，产品应该给状态和预期，而不是只让用户看到“处理中”；解释成本高的时候，产品应该给依据、口径和记录，而不是只提供一个结果；责任和出错成本高的时候，产品应该给预览、撤回、留痕、兜底和通知，而不是简单追求流程更短。很多体验问题之所以反复改不好，是因为团队把成本看错了。用户停留久，不一定是信息不够丰富，可能是他在算账；用户不用自动化，不一定是配置太复杂，可能是他不敢担责；用户反复找客服，不一定是入口不明显，可能是系统没有给出足够可信的答案。

产品经理做体验设计，不能只问用户能不能完成操作，还要问他完成这件事时到底多承担了什么。多理解了一套规则，多跳了一个系统，多等了一个不确定结果，多解释了一段口径，还是多承担了一次不可逆的风险。问到这一层，方案往往会自然收敛。该给结果的时候，不再堆说明；该保留依据的时候，不为了简洁把信息藏死；该增加确认的时候，不机械追求少一步；该让系统承担计算的时候，不再让用户自己找答案；该让组织接住责任的时候，不再把压力留给一个一线使用者。

好的体验设计，最后会让产品动作更克制。它不是急着展示产品做了多少，而是把产品能力放在用户任务最需要的位置上。该由系统计算的，就不要让用户自己算；该让用户知道的，就不要为了页面简洁藏起来；该让组织接住的，就不要把责任留给一线使用者。产品在底层做了更多工作，用户在前台才会少用一点力。

闲言碎语#

我刚做产品的时候，很容易被“好看”和“完整”吸引。一个页面排得整齐，按钮层级清楚，流程从开始到结束都能跑通，心里就会觉得踏实。后来做的项目多了，才发现很多真正有用的体验，并不一定显眼。有时是少让用户算一道题，有时是默认一个上次用过的选项，有时只是多给一次撤回，有时只是把风险提前说清楚。好体验经常是沉默的，它不抢用户注意力，不展示产品团队多聪明，也不要求用户理解背后做了多少复杂工作，它只是让用户继续往前走，而且走得没那么累。

这对产品经理其实是一种很好的提醒，我们很容易想证明自己做了很多：功能很多，规则很全，系统很智能。但用户不关心我们做了多少，他只关心自己要完成的事有没有变轻，甚至很多时候，产品越努力展示自己，用户越累。我现在越来越喜欢那些看起来朴素的设计，不是因为朴素一定高级，而是因为朴素常常意味着克制：知道什么该露，什么该藏；知道什么该让用户决定，什么该由系统承担；知道什么时候少一步，什么时候多一步；知道让用户快一点之前，先让他清楚一点、放心一点。

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