TO B产品交互体系一次性推翻重构.docxVIP

TO B产品交互体系一次性推翻重构 也许大家已经觉察到最近几年产业互联网需求激增，即所谓B2B或SaaS、PaaS、VaaS等，对企业级用户在互联网+技术上赋能的To b类产品或服务，这也是互联网科技行业的行情轮动。 与此同时，很多大厂也开始掷资切换赛道。 当然业务决策的切换是瞬时的，但业务能力的切换却是需要一定的调整和适应周期的。硬切换的过程中多少都会犯To c模式下的习惯性错误，话题太大，这里还是想通过聚焦到个别细分实例，聊聊在产品体验设计过程中容易犯的错误点。 既然是讲To b，就免不了结合其对照组To c一起来聊， 这里先讲一下二者的三个概念差异： To c产品是现实生活的映射（简单的、有结果预期的），而To b产品却是一个复杂的工作台（多线程的，不确定性的）； To c产品满足的是人们现实生活中已知需求或其升级版（是一种消费、社交娱乐行为或其形式的升级版），而To b产品满足的是社会化大生产的复杂协同和创造性需求（他本质是一种生产行为）； 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产品面临一次改版，计划对重点产品的核心功能（更准确的说应该是高协同性的核心功能矩阵）进行用户体验上的升级，理由有三： SDK集成方式上，以往是使用什么就集成什么，任君选择的佛系设定，预期调整为批量一次性集成sdk方式，为未来服务升级和推广降低下载安装和配置成本（因为所有服务必须事先集成sdk才能实现），该需求出发点是没有问题的； 优化推送服务流程，丰富化各种人群定向、提高送达率的配置项，使其更符合运营增长需求场景； 增加数据统计和分析能力，用数据能力持续优化运营增长。 这看上去没毛病也很合理。但经过一个星期的金品分析和潜心打磨之后，拿到产品需求后才发现，原有的产品交互逻辑全部被推翻了，就是说出了底层数据和功能逻辑保持不变，展示层形态和交互流程完全推翻了，基本从零重新搭建了一套，看上去有零有整有细节，方案还特别结构化，从细节上堪称是一份教科书式的产品需求文档； 但在用户体验体验委员会评估环节，设计环节提出了诸多异议， 这一次改版缺乏目标价值指标（或者说是目标太泛太宏观，很难关联到具体工作上），上线后无从评估好坏，没有衡量标准就不知道下一步的迭代方向； 没有前期工作，凭一己之力输出的产品方案，是否有信心完全颠覆经历4年多沉淀下来的用户使用习惯； 在没有形成用户价值依赖，也无从保证客户需要高昂的切换迁移成本的前提下，如何防止产品体验的繁杂低效导致用户流失，切换到更简单易用的友商竞品去； 到这里，你肯定会好奇后来是否叫停了该版本的推进呢？ 这个版本最终还是推进下去了，毕竟产品是需求的决策环节，用户体验中心可以提出合理化建议，但是否采纳还是取决于产品经理自己，因为是产品团队为结果负责，此处省去500字。 结果上线后离预期相差甚远，用户一次性集成sdk任务完成率很低，新增用户集成、配置并完整完成第一个业务类任务成功率大大减少、客服接听率倒是明显增多、新用户转化漏斗衰减严重；老用户线上负面反馈增多（