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

字实战总结|B端产品怎样降低用户的使用门槛？（建议收藏）对于相对简单的B端产品操作，用户的入驻、熟识过程存在较高的学习难度，我们作为产品设计者可以通过哪些方法来降低用户的使用门槛呢？本文通过总结了3类场景+8种方法，盼望我们在拓展功能边界的同时，注意用户使用效果，更好的发挥产品作用。

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

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

全文概览：

产品初装费的无奈降低客户入驻门槛的3类场景分析降低用户学习成本的8种方法写在最终的总结今日的文章很长，建议先保藏~

01产品初装费的无奈

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

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

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

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

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

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

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

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

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

此过程我也处于初步探究阶段，盼望能够为有同样困惑的伙伴们带来一点关心，同时假如你有更好的设计方案，欢迎和我共享，我们一起汇合才智做出更好的产品。

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

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

1.全新型客户

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

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

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

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

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

用户注册——填写企业认证资料——平台方审核——企业登录——查看平台全量功能用户注册——自动登录并进入平台——查看平台部分功能（弹出待认证提示）——填写企业认证材料——平台方审核——查看平台全量功能以上两种模式，你会更倾向于哪个？或者你认为哪个企业的入驻门槛更低？

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

而且现在越来越多的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.“倒装”的思路也能用到产品上

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

小明想吃西红柿炒鸡蛋，于是去厨房预备露一手，但是发觉家里的炒锅坏了，于是去找邻居借了一口锅；然后在切西红柿的时候发觉家里没有西红柿，于是去楼下超市买了几个西红柿；预备起锅烧油的时候又发觉家里没油了，于是又去买了一壶油。类似的问题在产品应用上也常常遇到，尤其是新用户在第一次使用时，许多需要提前配置的规章没有做，需要提前维护的数据