笔者曾经将做C端产品比喻过建大平房，B端管理软件产品类似于建小高楼，占地面积是用户的量，楼的高度是业务的复杂度。C端产品重定位以及交互能力，B端产品重架构以及抽象能力。
 
实际上将产品比喻为建筑物也是有不合适的地方，建筑物在建造之前一般都有了很精确的设计图纸，但是作为软件产品来说，很多时候是没有精确的图纸的，除非已经很成熟的赛道，很多场景下面它更像一个相对未知的生物体，生命体，它是不断在生长的，在产品生长的过程中，产品很容易变得臃肿不堪，最后很难维护以及扩展，用户也很难使用.

 

即使SAP，Workday，Salesforce这样优秀的软件也难逃其命运，不过这些软件都是21世纪初或者20世纪的产物，随着移动互联网的发展，B端软件产品设计的理念正在发生很大的变化，那么怎样保证产品在长期错综复杂的发展过程中，保持其简洁性，笔者提供一些小的原则建议：

 

1:努力想清楚产品最终的大致形态，以及用户在哪些场景，用什么样的方式来使用我们的产品，做好取舍。

产品的发展是基于公司的战略以及愿景，在想清楚产品的最终形态之前，需要想清楚公司的战略以及愿景。基于公司服务的人群，以及提供的服务，确定产品的最终形态。

 

基于战略对于哪些功能需要做，哪些不要做有一定的准则，否则陷入撒都要做的境地。

 

另外，笔者经常看到一种境况，创业公司有时候产品定位不准确，切入的是用户痒点的需求，很多时候产品供应商没有察觉到，反而觉得是功能不够多，不断的去迭代更多的痒点功能，实际上痒点＋痒点不等于痛点，再多的痒点功能的叠加也是不可能形成客户对产品的依赖的。

 

2: 做好每条产品线的定位，避免定位的混乱后，产品走向不明，不同产品线之间重复交叉在一起。

 

产品的使用一般有多个角色，使用的场景也不尽相同，很多时候我们都会有面向客户的移动端，web端，也会有公司内部的运营端，每条产品线的定位需要想的非常清楚，避免交叉。

 

这里我们经常看到的误区有如下几个：

 

  • 不同的角色用不同的产品线来支持。

笔者经常看到一些公司，不同角色因为功能有所区分，就用不同的产品线，不同的app来支持，实际上一般来说随着产品的发展，不同角色重叠的功能会越来越多，实际上只需要统一成一条产品线，通过权限来区分不同角色的使用功能就足够了。

  • 滥用移动端，什么功能都往移动端来走。

作为移动端，一些经常需要在移动端使用的功能，协同功能以及高频需要查看的数据可以放在移动端，但是移动端不适合做一些输入工作太重的功能，也不适合做的很重，太重了就不适合“移动”了。

 

3: 优先做好主线功能，也要保证极端低频事件有路可走。

 

对产品发展的过程当中，需求优先级的控制极其重要，低频事件，特别是一些逆主流程的功能实际上的工作量是极大的，比如说流程走的好好的，用户需要支持逆向的操作，如果这种业务流程中有大量的逻辑，这种逆向操作的代价是巨大的。

 

这里的一个原则就是对于低频极端事件，不一定要完全线上支持，很多时候可以采用线上＋线下的支持方式，保证客户在低端情况发生的时候，系统不至于无路可走就行。打一个比方，在ERP的上下游结算，或者薪酬的薪资计算的时候，总是会有一些费用是很难标准化的，或者计算方式是很难抽象的，这种时候可以考虑开一个口子支持这种费用项目，但是这种费用项目的完整管理不要线上化，让客户通过线下的计算，然后有入口进行输入或者调整就好了。

 

4: 每个迭代把握做小，做少，做精的原则。做加法很容易，做减法很难。

 

将一个产品做复杂很容易，但是复杂之后，要变简单非常难，无论是前端，还是后端的数据库以及逻辑层，做加法都是容易的，但是做减法都是极难的。所以在产品的把控上面，采用线做小，做少，做精的克制原则是非常重要。否则，产品发展2，3年之后，就复杂到客户很难使用，维护成本很高，扩展难度很大的积重难返的地步。

 

5: 合并同类项，减少复杂度。

 

前面说过笔者有一个看法是产品是不断在生长的，无论是大的功能，还是小的逻辑分支，这些分支随着产品的发展会不断生长出新的分支，这样不断的裂变，会导致产品复杂度不断上升，所以需求控制，产品设计，逻辑实现上面，需要尽量抽象，合并同类项，尽量减少分支是在产品落地层面的最重要的技巧。

 

所以在设计以及研发这个层面，核心工程师的抽象能力也是非常重要的，需要找一些逻辑思维能力强，追求最佳实现路径的工程师来承担一些核心的功能。

 

6: 基于场景来进行设计，避免过度设计。

 

过度设计是经常发生的现象，简单如一般的搜索，笔者看到大量客户不会用到的检索条件罗列放在上面，客户在用这个功能的时候希望看到哪些信息，可能会怎样进行检索，一定要了解客户使用的场景之后再去做设计。

当然一些通用软件，因为使用场景很难预测，将场景进行放大也是可以理解的，只是无论通用场景还是垂直场景，都需要尽量了解场景之后，基于场景做最小化的设计，过度的设计实际上会影响用户体验，也会增加系统的复杂度。

 

7: 做好权限的区分，尽量让每个客户，每个角色只是看到自己需要的功能。

 

每个客户，每个角色需要的功能集是会有一些不一样的，保证每个客户，每个角色只看到自己需要的功能集，对于产品的易用性会有不错的提升。

 

8:做好系统，每个模块，每个功能首页的设计。

 

B端产品的功能很多，只是客户真正高频关心的数据，真正高频使用的功能实际上是不多的，系统的首页，每个功能模块的首页，每个功能的首页就变得非常重要。需要将用户真正高频关心的数据，使用的功能放在首页上面，这样保证用户只使用少数几个功能就能看到自己真正关心的核心数据，完成自己日常的工作。

复杂易，简洁难。万物之间，简洁最美，希望最美。

END

欢迎大家添加我的微信:jianguzhuxin,交个朋友，或者扫描下方二维码:

     

 李东林

菜小秘联创、

36Kr特约作家

SaaS产品说

SaaS产品说近期精选文章:

(原则）SaaS创业日记(一)北京行
（原则）如何定义需求的优先级
（原则）如何定义B端产品MVP(下）
（原则）如何定义B端产品MVP(上）
（原则）B端产品数据库设计的一些原则
（原则）如何让B端产品像C端一样极致易用
（原则）如何做B端产品的PMF

   钉钉，我劝你善良（一）

     
更多文章请长按二维码关注我们，实时了解最新SaaS产品技术深度分析：

         

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。