7000字实战总结 | B端产品怎样降低用户的使用门槛？（建议收藏）

7000字实战总结 | B端产品怎样降低用户的使用门槛？（建议收藏）

对于相对复杂的B端产品操作，用户的入驻、熟悉过程存在较高的学习难度，我们可以通过什么方法来降低用户的使用门槛呢？本文总结了3类场景+8种方法，希望能给你带来一些帮助。

对于相对复杂的B端产品操作，用户的入驻、熟悉过程存在较高的学习难度，我们作为产品设计者可以通过哪些方法来降低用户的使用门槛呢？本文通过总结了3类场景+8种方法，希望我们在拓展功能边界的同时，注重用户使用效果，更好的发挥产品作用。

不知道从何时开始，很多B端产品的销售团队以产品功能多，业务逻辑复杂当成了宣传亮点，以大而全为竞争优势，极力渲染自己的产品能够解决业务场景中的“一体化痛点”。

诚然，这种推广模式对于B端用户的决策者而言，会有一定的吸引力，但作为产品团队，我们始终不能忽略一个关键问题：新用户、初期成长型用户怎样能快速掌握你的产品？怎样能快速通过你的产品而达到他的目的？

全文概览：

1. 产品初装费的无奈
2. 降低客户入驻门槛的3类场景分析
3. 降低用户学习成本的8种方法
4. 写在最后的总结

今天的文章很长，建议先收藏~

01 产品初装费的无奈

我遇到有些SaaS平台在收费内容中包含了“产品初装费”，当然也有平台会采用一些优惠活动减免这部分“初装费”。

这里的“初装费”并不是我们日常理解的系统安装、维护、实施的费用。而是给用户开通了新的账号，由平台服务人员帮助用户完成一系列必需的复杂操作，并维护好初始数据。

举例说明：比如某个产品（平台）提供了较为成熟的配置化审批流程自定义功能，包含了图形化的配置、不同的条件分支、不同的业务种类、不同的数据权限及流转过程，以及抄送、会签/或签、数据权限配置等等。（听起来就蛮复杂的）

现在我的企业要使用此平台完成各项业务流转，企业本身一定有个性化的业务审批流程，企业操作人员大概率不知道怎样在平台中创建适合自己的审批流，便可以把审批流程的场景线下描述清楚，由平台的服务人员代为配置。配置完成后企业直接使用即可。

这个过程似乎很贴心，而且将更多的产品服务融入其中，更有甚者借此宣称为“更有温度、更贴心的增值服务”。而在我看来，仅从产品设计和应用的层面来分析，这项“初装费”的服务在一定程度上也是不得已而为之。

毕竟产品的设计、操作、初始化规则太复杂了，对于新用户增加了大量的学习成本，如果一切均由用户自行操作，可能会有大量用户望而却步，从而影响了平台的推广进度。尤其当你的用户日常对互联网软件、互联网操作并不熟练时，这样一套“功能强大”的平台，一定会把他拒之门外。（这也是我一直想探索的【平台思维】与【用户思维】的差别与矛盾）

而且我们现在讨论的依然是用户进入之后，怎样快速上手。如果再向前思考一步，还有什么办法能够优化“用户进入”的过程？即在用户正式使用之前，有哪些办法能够降低其入驻门槛？

尤其是A企业已经使用过同类的产品，我们要把企业“撬过来”的时候，有哪些可尝试的功能来支撑？

所以今天的分享，我会整体分为两部分：一方面探索产品层面用户入驻的简化过程；另一方面才是入驻之后，如何让用户对产品尽快由陌生到熟悉。

此过程我也处于初步探索阶段，希望能够为有同样困惑的伙伴们带来一点帮助，同时如果你有更好的设计方案，欢迎和我分享，我们一起汇集智慧做出更好的产品。

02 降低客户的“入驻门槛”

首先我把平台的新客户分为三类，再针对每类的特点进行分析。

1. 全新型客户

全新型客户是我们最常见也最好理解的，对于“全新”的客户来说，我们的设计可以围绕【入驻操作效率】来优化。

举一个容易理解的例子，银行很多业务涉及到监管要求和风控等因素，需要线下办理。随着互联网时代的到来，银行也一直在探索更多线上化的可能性。但是不同的银行对于同一类业务，开通的流程也有很多差别。

科技力量强的银行，可能有些企业服务支持全线上办理，通过web端进行资料填写、安全认证，即可完成开通；

但还有很多银行采取“先线上提交资料预约，再拿着纸质材料到网点线下办理”的方式，平心而论，如果你是企业，在其他因素都对等的情况下你会怎么选？我也遇到过一些小银行的客户经理说，因为入驻流程的不便捷，导致他们某些业务很难推广。

而且，即便是全流程线上处理，不同的入驻模式对于客户也有不同的体验。我们以需要审核企业资质的场景为例，下面就有两种不同的模式：

1. 用户注册——>填写企业认证资料——>平台方审核——>企业登录——>查看平台全量功能
2. 用户注册——>自动登录并进入平台——>查看平台部分功能（弹出待认证提示）——>填写企业认证材料——>平台方审核——>查看平台全量功能

以上两种模式，你会更倾向于哪个？或者你认为哪个企业的入驻门槛更低？

当然，其中可能包含不同业务模式，平台对入驻企业的“真实性”、“安全性”等方面有不同的要求。第二种也可能会存在更多的垃圾数据，但是如果仅从“入驻门槛”的角度分析，第二种无疑是更低的。

而且现在越来越多的B端产品，尤其是SaaS类产品更倾向于采用第二种“开放注册”的模式。（当然，这种方式也容易被竞争对手了解更多，但这就是另一个话题了）

再深入考虑一步，同样的入驻流程，用户注册或企业认证时填写的资料多与少，势必也会影响入驻转化率，这也是为什么现在越来越多的产品（尤其是C端），可能只需要一个手机号+验证码就可以注册成功了。B端认证时所收集的资料，除去企业的基本资质信息之外，每多一个附加信息，就会增大一部分入驻的难度。

2. 半新型客户

半新型客户指这些客户和我们产品存在一定的关联关系，比如我们的产品是对某些存在合作关系的产品，在业务场景上的拓展，因此合作方现有的客户也可以成为我们的客户。

而对于这类客户，从体验上讲，我们总不能让他再来注册一遍吧？因此，我们的设计可以围绕【系统自动迁移】的思路进行优化。

所以此时我们需要设计出一套可以从合作方平台平滑自动迁移客户信息的方案，让这些存量的客户可以直接登录我们的产品，无需进行其他任何操作。

如果我们平台所需的部分信息合作方无法提供，那我们再考虑如何通过补录，或者简化注册的流程来解决。

• 补录指的是用户可以正常登录平台，但如果开展某项业务操作之前，需要有提示去进行信息补录；
• 简化注册指的是用户无法正常登录平台，但假设注册需要10项数据，平台能通过合作方获取8项，那就再提供另外2项的信息，从而让入驻流程更简单。

当然，系统间的数据迁移过程也是比较复杂的，尤其对于同一个客户，在不同的平台均有业务操作，而客户信息如果在某个平台发生变更之后，多个平台间如何进行数据同步从而保证客户的操作连贯性，也是一个非常值得单独探讨的场景。

其中还会牵扯出很多种情况，包含功能架构层面、处理逻辑层面、技术架构层面等等，今天就不展开分析了，后续我会单独整理一篇关于“数据迁移”的场景总结。

3. 竞争对手的客户

最后，对于“竞争对手”的老客户来说，我们的设计可以围绕【打通技术壁垒】的可能性来探索。

记得两年前读《幕后产品》这本书时，网易云音乐当时对于是否支持“导入歌单”功能进行了激烈的讨论，最终这个功能为产品带来了非常显著的效果，让其他音乐平台的用户带着他们的歌单顺利迁移到了网易音乐。其中具体的场景和功能我记不清了，我也没有使用过网易的“导入歌单”，但这个思路就是针对竞争对手中的老客户非常有效的降低入驻门槛的体现。

以大家熟知的OA协同产品来举例，假设A公司以前使用钉钉，现在你们新推出了一个产品，其中包含了其中的功能以及其他的客户增值功能，那么有什么办法能够让A公司更容易接受这一步的产品迁移呢？

我们知道，一旦客户在某个平台沉淀了三年及以上的业务数据，那么这些数据价值是非常大的，我们很难让对方放弃这些价值。

《俞军的产品方法论》一书中提到一个公式，我认为非常具有指引性：

用户价值=新体验-旧体验-替换成本

相信我们都能重视新产品的新体验，也一定是因为新体验的优势才有机会让客户抛弃旧体验。但我们千万不要忽略【替换成本】，而数据价值在替换成本中占有最重要的地位。

所以我们的方案更加清晰了——支持旧平台的业务数据导入（这里的导入并不一定指文件导入，我们不要被固有观念影响）

当然也有可能客户希望新旧平台一起用，那我们的方案可能要修改为支持新旧平台对于部分业务的数据同步/共享。

而因为这里的新旧平台不存在合作关系，所以无论是数据同步还是导入，都只能通过我们的产品来探索方案。这也是为何我把这个场景的关键定义为【打通技术壁垒】。

• 如果旧平台有OpenAPI，那我们势必要对接上；
• 如果没有OpenAPI，但是有数据导出功能，则需要用户先进行导出，我们再支持这一类数据模板的导入。

但是如果我们是一个平台级的产品，目标用户所涉及的旧系统参差不齐，在模板导入上也很难做到标准化，这时我们可以优先支持几类常见的模板，后续再迭代更多的模板。或者设计出一款能够自动识别多种模板的导入功能。

假设旧系统的数据无法导出，那就只能通过其他途径线下收集这些数据，再由用户批量导入了。一旦实际情况走到这一步，面对着具体的替换成本，这个客户我们大概率很难“撬动”。

以上三类，是常见的降低客户入驻门槛的思路，不知道读到这里的你有没有一些收获呢？下面我们来看另一方面，对于新用户，如何降低他们的学习成本。

03 降低用户的“学习成本”

1. 在新功能首次使用时，贴心的提示很重要

首先，用户首次登录之后的整体布局、功能、重点操作的入口介绍很重要。

我们常见的平台类产品，首次登录的介绍功能比较同质化，多数以“浮动”、“突出”、“指引”为主。但是，这些静态的标注，以及通用化的标注，对用户来说真的有用吗？代入用户思维来试想：我们有多少次是通过这些提示来认识平台的？

但是如果没有这一步，似乎也会少点什么。所以我们应该思考的是，如何让这一步新用户指引更能贴合用户的【入门水准】。

其次，用户首次在正式使用某个功能时，功能的操作流程，温馨提示等共性介绍也很重要，具体内容请看下一条。

2. 操作指引真的能完成指引吗？

现在常见的操作指引，更多像是【页面介绍】，告诉你这页重点的操作在哪。如果不做指引，用户多花几秒的时间也能看个大概。

但是这个业务应该怎么做？有什么前后顺序要求，需要提供哪些数据，能够生成哪些结果，能够为我带来什么，这些问题用户从哪里知晓呢？

所以真正有效的操作指引应该是怎样的？

我的观点是：至少要有一个单独的功能带着用户把功能的效果简单直接的介绍清楚，并半自动的带领用户进行关键节点学习，通过简单的点击、数据变化，把MVP流程快速“跑通”一遍。

这里有点像我们玩游戏时的【新手教程】，边讲边练。

写到这里我也突然好奇，为什么B端产品中，很少有真正的【新手教程】？是因为不重视？还是因为体验要求<功能要求，亦或是因为领导觉得现阶段够用了，先去攻克更重要的功能了？

总之，这一类的问题，在优先级排期时确实很容易被放到最后，最后的最后就是不了了之。（延伸阅读：B端产品迭代，优先级排序是一个复杂而艰难的抉择）

3. 帮助手册真的能帮助到用户吗？

每个B端产品都会有【用户帮助手册】或者【操作手册】之类的功能介绍，入口可能藏在很深的地方，也可能很小，很难让用户发现。似乎是在和用户“躲猫猫”，生怕对方发现点进来学习是吗？

• 帮助手册也有多种风格，最简单无效的，是把平台所有的功能罗列一遍，配上截图和简短文字，似乎是为了应付差事而产生的功能；
• 相对好一点的会通过不同功能的操作顺序来组织手册的内容，相当于把上述提到的“新用户指引”、“平台介绍”之类的功能一股脑摆在这里。不过只要你能耐心搜索，耐心查看，还是能学会一些；
• 更好一点的，会在上述的基础上增加“常见疑问解答”，通过用户在使用过程中产生的疑问，对应组织解决方案、操作步骤。

好一点的平台，会把“常见疑问解答”中问题的类型进行归集，同时增加模糊搜索功能，在用户使用时遇到困难，即可通过搜索定位到对应的答案，这种交互显然会更好一些。

同时，帮助手册一定不是独立的文字+截图，适时搭配一些视频、动画、图片说明，效果应该会再进一步。

4. 预测用户在哪里需要帮助

操作指引、帮助手册之类的功能，更多是需要用户主动学、主动操作。之前我对于“产品的温度”定义是：在合适的时机做出贴心的反馈。

当然这一步在B端产品中很难实现的比较完整，但对于一些基础的常见问题，操作错误，操作提示，我们还是可以通过“用心感知用户的使用过程，体会用户诉求产生的时机”来逐渐优化。

而且基于平台大量的操作记录，我们也可以在经常报错、经常中断用户操作的节点增加对应的温馨提示，或者帮助提醒。

• 比如用户同样的错误出现3次以上时，系统是否可以自动出现【去学习】或者【常见问题答疑】之类的教程？
• 比如用户总是操作到最后一步的时候中断，系统是否可以在出现几次之后，询问用户“您是有什么顾虑吗？”从而形成意见收集。

诸如此类的细节功能，只要我们静心去观察，去体会，势必能够寻找到很多优化空间，从而让你的产品真正变成一款“有温度的产品”。

5. 视频操作和图文介绍，你更喜欢哪一个？

对于新产品的操作介绍，如果你的业务相对熟练，看图文介绍可能更高效；如果你的业务操作很生疏，我相信视频操作的讲解更能让你快速掌握。

但是很多产品只提供了图文介绍，并没有提供视频操作。因为首先视频的录制、制作、剪辑会花费更多的时间和精力，哪有图文来得快~也可能是产品团队没有意识到图文的低效性，或视频的重要性，所以压根就没想着提供视频。

这里并不是说所有的产品都必须提供视频指引，但如果通过我们的判断，视频能够帮助用户更好的理解产品，提升效率，那还是想办法搞出来吧。

当然，视频也不仅局限于操作视频、对应的宣传视频，图片拼接的视频等等形式都是可以的，我们的目的不是形式，而是结果。

6. 复杂的业务一定要有例子

新用户进入关键功能后，面对空荡荡的数据栏，“无助感”又会增加。所以我的建议是，在用户没有真正完成相关操作时，系统预制一个默认的示例。

示例的好处不仅能让用户看到使用后的结果，还可以通过示例了解功能规则和使用方法，并快速复制、修改、生成自己想用的信息。

至于用户已经完成第一次全流程操作之后，示例是保留还是消失，可以基于我们产品的实际形态，以及示例数据（默认数据）后续是否还有其他用处，自行决定。

7. 复杂的业务步骤场景化

大多数B端产品有一个常见的使用问题：功能菜单的排列是很割裂的，没有结合用户的使用场景“适时”出现。而是往导航栏一摆，自己找去吧~

经常有一些相对复杂的场景，用户需要在多个一二三级菜单内反复切换，如果不是对产品达到一定的熟悉程度，要么会找不到下一步要怎样做，要么出现步骤遗漏报错的时候也看不懂缺失了哪一步。

常见的解决办法有两个：

• 一是【功能场景化】，把多步骤操作连接到一个大的步骤指引里，不要让用户自己找；
• 另一个是【报错直达+改错返回】，也就是对于前置步骤缺失或数据错误的报错，要有“去修改”之类的按钮直达，用户依然通过最简单的点击找到下一个要去的地方。同时在修改完成之后，要有对应的“返回”，返回上一个操作节点继续进行。

这个修改方案可能很多同行都知道，但是在真正落地时会遇到多方阻力，不过从用户体验和执行效率上来讲，这些功能都应该是标配。

8. “倒装”的思路也能用到产品上

在我刚转型产品时，遇到过一个问题，拟物化表达出来可以这样理解：

1. 小明想吃西红柿炒鸡蛋，于是去厨房准备露一手，但是发现家里的炒锅坏了，于是去找邻居借了一口锅；
2. 然后在切西红柿的时候发现家里没有西红柿，于是去楼下超市买了几个西红柿；
3. 准备起锅烧油的时候又发现家里没油了，于是又去买了一壶油。

类似的问题在产品应用上也经常遇到，尤其是新用户在第一次使用时，很多需要提前配置的规则没有做，需要提前维护的数据没有录入，等到真正做业务的时候走一步卡一步。

所以衍伸而来一个新用户初始化的功能，通过“倒装”的思路把这些前置条件按顺序、按指引逐一维护好。一次设置、长期受用~

以上，就是我针对【降低用户学习成本】的方式探讨。可能有些方法我们也尝试过，但是真正把它做好，做到适时、适度确实很难，需要我们产品同行一起去探索。

预告：

恰巧最近在看两家SaaS平台的【帮助中心】功能，综合评估属于同类产品中做的不错的，从帮助指引、示例提示、操作演示、视频教程、步骤连接、疑难问题解答等几个大的方面都有对应功能的产出，值得我们借鉴和优化。

争取下个月整理分享出来，让我们能够更具象地解决这类问题，敬请期待~

04 写在最后

即便我们把这些功能都设计出来，也并不一定能够解决用户的所有问题，尤其是对于平台类产品，本身所涵盖的场景很多，相互之间的关联度确实比较复杂，也许一对一面对面教用户，也需要很长时间才能“出师”。

而且本篇文章通篇仅站在产品功能设计的角度来分析，实际应用中还会掺杂业务规则、产品特性、公司理念、团队资源等诸多内容，所以最终所呈现出来的功能，有时并不是产品团队能够主导的。

但这并不代表对于这些问题我们视而不见或不去尝试，不去向着更便捷、更智能、更“傻瓜”而努力。尤其对于产品团队，我们设计出来的所有功能都是为了让用户真正用起来，从而体现更多的价值。

所以降低用户学习成本，优化产品操作链路，提高问题定位速度，简化功能理解难度，是每一个B端产品势必要去探索，一定要为之精进的方向。

都说B端产品是为了场景赋能，提升效率，当我们真正“以用户为中心”来考虑问题，代入场景时，才是效率跃迁的开始。