编辑导语：To B全称是To Business即对商家（泛指企业）的产品；To C全称是To Customer即对消费者（泛指用户）的产品。To B运营更多承担了市场、销售、公共服务环节等事项；To C运营更多承担了研发、营销、体验环节等事项。本文作者为我们讲述了TO B产品交互体系一次性推翻重构的过程，并且总结了8点经验。

也许大家已经觉察到最近几年产业互联网需求激增，即所谓B2B或SaaS、PaaS、VaaS等，对企业级用户在互联网+技术上赋能的To b类产品或服务，这也是互联网科技行业的行情轮动。

与此同时，很多大厂也开始掷资切换赛道。

当然业务决策的切换是瞬时的，但业务能力的切换却是需要一定的调整和适应周期的。硬切换的过程中多少都会犯To c模式下的习惯性错误，话题太大，这里还是想通过聚焦到个别细分实例，聊聊在产品体验设计过程中容易犯的错误点。

既然是讲To b，就免不了结合其对照组To c一起来聊， 这里先讲一下二者的三个概念差异：

1. To c产品是现实生活的映射（简单的、有结果预期的），而To b产品却是一个复杂的工作台（多线程的，不确定性的）；
2. To c产品满足的是人们现实生活中已知需求或其升级版（是一种消费、社交娱乐行为或其形式的升级版），而To b产品满足的是社会化大生产的复杂协同和创造性需求（他本质是一种生产行为）；
3. To c产品设计需要具备社会行为心理模型（是一种标准化行为模式），而To b产品设计需要具备的是纷繁复杂的行业知识和业务场景（是一种行业差异化行为模式）。

这是二者在交互体验设计乃至业务模式设计上的本质的差别，消费行为面对的是社会个体，而社会个体行为具有规律性和趋同性。用户行为和决策模型相对比较容易捕捉，所以To c产品体验设计在经历过相当长一段时间沉淀以后会形成一致的群体性认知。

这样对To c业务的体验设计成本也会大大降低，比如我要给对方发一段语音，我就知道要长按实心圆圈按钮，我要删除list页中的某条记录，我要么长按（android）要么左划（ios）list项呼起删除按钮。

所以大家会发现最近To c的设计重复执行类需求会越来越少，这也是To c的界面和交互设计师现阶段会出现供需瓶颈和需求错位的主要原因。

聊完二者之间的差别后，就进入正题了，产品改版在To c行业应该是家常便饭了。

以前在腾讯做产品设计的时候，迫于数据kpi压力，业务团队有个不成文的规定，产品必须做到一周小迭代、一月大迭代、半年小改版、一年大改版，目的是为了变着花样提升用户体验和满足不断升级的c端用户需求。

因为To c业务往往解决的是生活中点对点的确定性需求，所以产品需求和交互流程相对比较简单。

比如我要用共享单车，核心需求就是骑车到目的地，所以我们在app上的正常交互流程就是：打开app——找附近的自行车——开锁——骑行——关锁结束服务——支付费用——退出app。

这个流程叫服务主流程，就是说该交互流程能完全满足你的核心刚需。

所以To c类的产品保持周期性高频改版对用户的体验并不会有太大影响，加上有升级引导的加持，一般都能做到傻瓜式的学习成本并瞬间适应，但To b业务就完全不是这样了。

最近公司服务于开发者的一款SaaS产品面临一次改版，计划对重点产品的核心功能（更准确的说应该是高协同性的核心功能矩阵）进行用户体验上的升级，理由有三：

1. SDK集成方式上，以往是使用什么就集成什么，任君选择的佛系设定，预期调整为批量一次性集成sdk方式，为未来服务升级和推广降低下载安装和配置成本（因为所有服务必须事先集成sdk才能实现），该需求出发点是没有问题的；
2. 优化推送服务流程，丰富化各种人群定向、提高送达率的配置项，使其更符合运营增长需求场景；
3. 增加数据统计和分析能力，用数据能力持续优化运营增长。

这看上去没毛病也很合理。但经过一个星期的金品分析和潜心打磨之后，拿到产品需求后才发现，原有的产品交互逻辑全部被推翻了，就是说出了底层数据和功能逻辑保持不变，展示层形态和交互流程完全推翻了，基本从零重新搭建了一套，看上去有零有整有细节，方案还特别结构化，从细节上堪称是一份教科书式的产品需求文档；

但在用户体验体验委员会评估环节，设计环节提出了诸多异议，

1. 这一次改版缺乏目标价值指标（或者说是目标太泛太宏观，很难关联到具体工作上），上线后无从评估好坏，没有衡量标准就不知道下一步的迭代方向；
2. 没有前期工作，凭一己之力输出的产品方案，是否有信心完全颠覆经历4年多沉淀下来的用户使用习惯；
3. 在没有形成用户价值依赖，也无从保证客户需要高昂的切换迁移成本的前提下，如何防止产品体验的繁杂低效导致用户流失，切换到更简单易用的友商竞品去；

到这里，你肯定会好奇后来是否叫停了该版本的推进呢？

这个版本最终还是推进下去了，毕竟产品是需求的决策环节，用户体验中心可以提出合理化建议，但是否采纳还是取决于产品经理自己，因为是产品团队为结果负责，此处省去500字。

结果上线后离预期相差甚远，用户一次性集成sdk任务完成率很低，新增用户集成、配置并完整完成第一个业务类任务成功率大大减少、客服接听率倒是明显增多、新用户转化漏斗衰减严重；老用户线上负面反馈增多（无用功能和信息太多，产品不友好），最糟糕的是一个全新的版本上线后发现不符合预期，接下来完全不知道该怎么做了，只能版本回滚。

这里没有幸灾乐祸的意思，因为行业以往绝大部分To b产品经理是没有To c的经验的，对用户体验影响没有那么强的感知。

设计和产品本就同在一条船，一损俱损，此处引出该实例纯粹是为了准确给大家诊断和分析问题所在，并告诫同行小伙伴如何规避。

篇幅有限，我尽量浓缩，对此次经验总结如下：

1. 产品错了，体验再好也是没有价值的，所以体验设计价值必须依附于产品价值。如果你认为你是对的，就坚持下去或者一杆子捅到更高的决策环节，在一个错误的前提下做正确的事情本身没有意义；
2. 介于To b产品的业务复杂性，对用户习惯的敬畏就是对客户场景和行业壁垒的敬畏。我们个体的同理心和经验复用无法代替To b用户真实需求，这是无论产品还是设计都很容易犯的下意识错误，总认为自己最懂客户；
3. 一个复杂产品的全新版本硬切换是一件高风险行为，你首先需要做大量的前期调研、评估、甚至和销售一起拜访客户，以验证你的版本需求阶段合理性；然后你还要去接触真实使用者来评估其易用性影响，因为上面说了To b产品是生产场景，生产就一定要追求效率，工作效率虽不是核心价值。但一定是客户的永恒不变的价值，最后你还需要拆分你的大版本成为局部功能分开来迭代，适时验证、逐步替换；
4. To b产品的改版也要有明确的价值目标，他可以是明确的业务指标，没有业务指标也要有用户数据细节指标，没有细节指标也要有价值衡量标准，SUS价值量表也好、NPS衡量也罢，没有目标就是没有方向，改完以后无法保证其后续迭代的延续性；
5. To b产品的To c化，但凡是带有任何To c属性的产品（有自然流量和海量免费用户，且有免费向付费转化的产品），就必须做用户精细化运营设计和灰度样本测试对比，因为免费用户就是潜在的未来付费客户池，你不能只关心正在买衣服的，而不关心试穿的；
6. To b的体验设计满足的不仅仅是友好性和舒适度，其实最大的价值在于设计一套生产和工作协同流程，他是带有专业的业务视角的，并引领客户达成不同的业务目标；
7. To b类产品体验设计一定要服务于提升业务的切换和迁移成本，设计是可以被被模仿和替代的，产品功能也很容易被抄袭，但与平台核心能力的依赖度，以及产品矩阵的之间的价值协同性，才不容易被轻易替代，从而提升留存、降低流失风险、也降低销售续单压力；
8. 数据报表设计是一个很难界定价值大小的功能模块，你可以直接把用户和业务数据都采集并矩阵式的展示出来供用户去分析查看，他也有价值，但这太1.0时代了，优秀的数据报表筛选是要能直接关联明确的业务目标的，且能辅助决策并尽量缩短决策链，提升决策效率和决策准准确性的。

所以大家会发现，一款To b产品或系统的改版升级，一定是一个非常复杂的协同和严谨的论证过程。

为了不影响客户的正常生产，还要保持分布式迭代验证，直到最后的版本整体替换，到最后其实你会神奇的发现，最终的形态已经不是当初的模样了，这样才是To b产品的精益设计的过程。

本文由 @咕咕咕 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议