B端产品的“能力与体验”，如何平衡？

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

全文共 2979 字，阅读需要 6 分钟

——————— / BEGIN / ——————

最近在做产品中，遇到了很多问题，就像游戏中打小怪兽一样，要一个个打，其中一个就是B端产品的“能力与体验”这一难题。但这不是一个一次性可以打败的小怪兽，而是一个持续要打的小怪兽，而且，每次的小怪兽可能都不一样。

就是说，能力越强大（你也可以认为能力多）的产品，其体验就反而差，要提升体验，也更加复杂。

能力：就是我们常说的，你的产品在解决这一业务领域的问题时，是否具备足够全面的功能。

体验：就是用户在使用产品的某个功能时，是否感觉好用，是否符合使用逻辑。

那么，当我们一旦遇到产品能力要提升，体验也要解决时，就出现了矛盾。最直接的就是，时间不够，为啥呢？因为“体验=质量”，而质量上乘的东西，需要时间来完成。

几个能力与体验不平衡的可能性

为什么说，目前大部分B端产品在“能力与体验”总是无法平衡，大致归结于这么几个原因：

B端产品业务逻辑很复杂，特别是对于中台类、工具类产品来说，要抽象出满足业务场景需要的通用能力已经是个大难题，更别说还要用户体验好，真的不容易。

由于用户基础能力、业务诉求不同，导致对同一款产品的体验需求也会有差异。比如新手用户和专家用户对同一功能的使用体验要求、容忍度就不一样。

B端产品的能力建设和体验建设属于两个团队的职能，但体验如果对业务不够充分了解，实际上很难达到从根本处来提升B端产品的体验。这也是我常说的，很欢迎设计师转为产品经理，这样子，会对产品体验构建有更深层次的了解；同时，在功能设计之初，就可以设计出相对可用的功能。

团队成员一直在流动。而深刻认知一个产品底层构建逻辑和深刻认知一个行业需要多年，甚至一辈子，可成员流动会带来产品一直处于设计不稳定阶段。由此，产品能力虽然越来越全，但能力合理性与用户体验问题，一直会存在。

团队重视功能，不重视体验。大部分B端产品，确实处于功能都来不及开发的阶段，哪里还有时间考虑体验问题，况且，团队内部也没什么体验专家角色，那就先上功能吧。然后就发现，产品基本积重难返，只能思考是否弄个2.0、3.0升级来解决，殊不知，其实真正通过产品大版本升级来解决“能力与体验”问题的，实则甚少。

基于第五点的后半句，展开来说说为什么有些B端产品靠大版本升级，不一定比原版提升了“能力与体验”，基于我自己的实际经验与朋友们的讨论得出：

第一，重构翻新时间通常并不充分（给个一年慢慢推敲，不存在的），领导希望早点看到新版本，快一点推出市场，此时，会影响产品的质量，时间和质量永远是个不可调和的矛盾（特别当遇到对业务不是太熟悉的产品经理）。

第二，领导产品重构的负责人是否对原产品踩过的坑了如指掌，并且一直寻思怎么去优化，如果是否定的，特别当负责人对该领域还不熟悉，那么为什么新推出的版本就一定比原本版本好呢？

前些日子，我的一个产品朋友，接受了产品重构任务，要求6周完成整个产品的能力与体验提升，涉及到的部分包括信息架构重新组织、各模块流程链路重构、每个模块内部功能与体验优化等。而他还是对这块业务不熟悉的，更不知道原来的产品是个什么状态，用户吐槽过哪些地方，此时第一点和第二点的劣势他都中招了，试想，这时候新版本一定就比原版本好吗？我俩心中都打了个问号。

“体验阶梯金字塔”模型

那么，既然B端产品的“能力与体验”总是很难完美平衡，那我们又该怎么去做呢？总不能任之不管。

我想，由于B端产品所处的阶段不同，产品“能力与体验”矛盾的问题，还得拆分开来看。当然，如果再引入产品战略、客户现阶段情况、技术可行性问题、产品与体验专家等，这个“能力与体验”问题就会相当复杂。

比如，假设今年产品规划中就没有体验提升这一战略性诉求，那么，一大堆功能优先去实现一定是排在最靠前的。

再比如，我们大家应该都遇到过，技术团队实现不了某个体验设计方案，需要产品团队和设计团队重新想方案的场景。

还有，如果团队规模不大，压根没有既懂产品又懂体验的专家，那么提升产品体验就极其之难。

所以，我们可以发现，提升产品能力（加功能）相较于提升产品体验，是相对简单的。

那么，此时，变成了我们要去寻找和回答，如何提升B端产品体验的问题——如何在加功能的同时，可以顾及到体验问题。

这里，我分享一个“体验阶梯金字塔”模型，它可以帮助我们诊断当前我们所负责产品的体验阶段，及规划产品后续体验的方向。

“体验阶梯金字塔”模型由下至上分为依次为能用、可靠、可用、易用、愉悦、意义这六层。下面我们来展开讲讲。

从“能用”到“意义”

1）能用

是指产品实现了功能，用户通过苦学、苦练、频繁使用、记忆背诵方式，能通过功能把任务完成。

比如，有个设计者设计了一把弯着的刀，让用户用它来切土豆片。

2）可靠

是指产品在实现功能的基础上，让用户使用的时候少出故障等安全级别的能力。

比如，这把切菜的弯刀稍微拉直了一些，且刀头圆润了些，让用户可以切出更多土豆片的同时，兼顾到了安全性。

3）可用

是指产品功能具备了一定的好用性。

比如，经过工艺的迭代，菜刀刀体拉直了，用户切土豆片更快更省事了，咔咔咔就把土豆片切好了。

4）易用

是指产品在可用基础上进行创新，比如加入自动化、智能化能力，让用户完成任务更方便。

比如，菜刀变成了切片工具，只要把土豆放到工具中，按一下按钮，工具就自动完成切土豆片任务。

5）愉悦

是指产品具备一种触动用户情感的能力。

比如，用户在使用“切片工具”时，在按下按钮那一刻，工具会和用户进行交流，如说：“主人，很高兴为您服务，balabalabala。”如果更智能一点，还可以进行人机互动交流。

6）意义

是指产品具备一种勾起用户回忆、情怀，或可以表达用户影响力、身份、地位象征的能力。

比如，“切片工具”和某知名品牌联名，设计一些限量的有特殊意义的内容。

“体验阶梯金字塔”模型可以帮助我们在设计产品的时候，衡量目前产品整体的平均体验，或某个功能体验处于某个水平，从而指导我们进行针对性的优化。

最后的话

B端产品“能力与体验”问题，会一直存在。

一是先把能力构建完善，还是先把目前体验问题解决掉？

二是在不断构建能力的过程中，体验问题越来越多怎么办？

三是能力基本构建完善了，如何优化体验问题，无从下手？

针对第一点，需要产品负责人安排好优先级，如果核心功能体验极差，那很可能需要纳入与能力完善一样的优先级。

针对第二点，团队需要找一名懂产品和体验，或至少要懂体验专家，在构建能力的过程中就参与进来。不要试图采用功能开发完后进行补救的方法，通常来说，没有壮士断腕的决心，挺难救的。

针对第三点，使用“体验阶梯金字塔”模型，将体验问题区分维度，是属于六个维度中的哪一个，从而安排计划。

实际上，不断新增功能肯定是少不了的；第二，开发功能时，就要考虑体验问题；最后，体验到底该怎么做，使用“体验阶梯金字塔”模型。

以上，是我最近的一些些思考，期望也能对你有所启发。