大概在2019年8月份的时候，有赞发布了“有赞产品设计原则”

从毕业到现在，很少找到成型的方法论去指导B端产品的设计，而这份设计原则，一定程度上填补了这一块的空白。我个人是非常认同这份产品设计原则，在这里也根据工作上遇到的一些实际情况，和大家分享“有赞产品设计原则”中自身比较有感触的点。

                                           01

1.用户和场景是一切的基础

          清晰的用户画像和使用场景，是整个产品的基础条件

            无论是to B还是to C，用户和场景都是我们绕不开的话题。to C的用户是个人。在考虑to  c产品的用户和场景时，出发点是为了让用户用的爽，会基于人性去创造愉悦感和克服焦虑感，由于本身的工作不是to C的产品经理，所以在这里就不细谈，希望能见到其他大佬的分享。

对于to B，“用户”或许在这里称作“客户”更加合适。to B产品面对的是个体之间组成 以营利为目的的经济组织，也就是我们理解的“公司”概念。我们在考虑to B产品的用户和场景时，应该注意到以下几点。

1.1客户是以营利为目的。由于是以营利为目的，那么成本和效率是每一个to B产品无法逃避的问题。

1.2不同岗位之间的利益平衡。企业本身是高度协同分工的，不同岗位的关注点不一样，我们在考虑使用场景的时候，一定要关注 不同岗位带来的需求差异。举个例子，业务岗关心客户关系的归属问题，如果系统的改动让业务岗之间的客户分配出现不公平现象，直接损害了业务岗工作人员的实际利益，那可想而知，业务岗的工作人员肯定不会让这样的系统运行的。所以每一次改动一定要关注各个职位的诉求，这就需要产品设计者要尽可能去平衡各个职位之间的利益。

1.3使用者和购买者之间的诉求差异。在to B行业，客户虽然是企业，但是我们应该认识到系统的购买者和使用者对系统的关注点是不一样的。购买者更多的关注系统整体能给我带来多少的收入或者节约多少成本，一些购买者也会实际关注你的系统有多少功能。

总问言之，购买者更关注系统的整体价值。而对于使用者，他们关注的是在使用过程的细节提升，例如更新系统后处理5个预约单是不是比以前更加便捷和快速等问题。这一点在工作中深有体会，同一个公司，职级高的工作人员提出的需求会更关注整体功能，职级低的工作人员提出的需求常常是优化某一个操作细节。

                                          02

2. 首先要是能够最小可用的全场景闭环。

        商家端的产品要做成全场景、完整业务链路的闭环，因为任何一个环节的缺失和不完善都会导致商家的生意无法正常运转。

在讨论to C产品迭代的时候，常常会引用MVP概念， 开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段。在 MVP概念中，每一次迭代关注的是主流程的验证，分支流程和高级功能可以后续再优化。

但是在to B的产品迭代中，每一次迭代关注的是最小可用的全场景闭环。正如有赞的产品设计原则中所描述的一样，产品迭代中任何一个环节的缺失和不完善都会导致商家的生意无法正常运转。在实际的迭代复盘中，总结了如下几个注意点

2.1关注迭代功能中影响的业务链路中的各个节点，以及每个节点对应的工作岗位。

由于企业高度协同的特性，企业级的服务产品通常会要求业务链路完整，数据流通准确。因此，每一次迭代功能，都要清晰的列举出这次更新功能所涉及的业务链路中的节点，要去探讨每个节点的处理方式，如果业务链路的节点是需要人工处理，那就要思考这个节点对应的工作岗位是否会受到影响。

举一个例子，在商家端更新预约上门功能的时候，会涉及到的关键节点有：谁处理预约单、谁分配预约单、谁对预约单进行售后，谁根据预约单对客户进行服务等等，这些关键节点后面有些可以是系统自动处理，但是有些是需要工作人员手动处理，涉及到手动处理的时候就要思考这次更新会对岗位产生何种影响，要考虑到不同岗位之间的排班问题，业绩问题等。

2.2迭代版本更关注功能的完整性，而非交互和界面美观

to B产品往往是购买者为了达到某些营利目标而购买，然后制定规则让使用者学习使用。由于是半强制性的让使用者使用，所以导致了B端产品关注的核心点是能不能解决问题，而不是界面美观等（当然界面美观也重要，但不是最重要），在多次迭代中客户都跟我反馈，为了达成这个业务目标，这个功能一定要赶紧出来，先让我们用起来，后面你们再慢慢优化。

                                          03

3. 每个商家都应该是独立的个性化的。

本质上我们的服务是“在云上为每个客户提供了一个独立的产品”，商家都是独立的，每一个商家都有个性化配置一切的权利。我们要尽全力去实现每一个商家的独立和每一个商家的个性化，而不是规定他们一定要怎么样。

我负责的产品是本地化部署的模式，一开始我接手产品的时候系统比较混乱，为了满足各种客户的个性化需求，仅仅是在页面样式的配置上都臃肿不堪，随着客户量的增多，抛开功能不谈，每一个客户对页面样式，功能配置都有自己想法。但随着系统发展至今，再去进行组件化困难重重。所以如果软件是服务于众多中小型企业的产品，一开始就应该考虑每个商家都应该是独立的，个性化的。

                                             04

4.先有，再高效，然后易用，最后好看。

有是最基础的体验，有总比没有要好。然后使用效率要很高，再然后才是要好用易用，最后才是要好看。当然，丑也是不行的。

    在这里主要是想和大家谈谈“高效”和“易用”2个原则，在实际的产品设计中，怎么判断一个产品功能的设计是以“高效”为原则，还是以“易用”为原则？下面结合具体事例来看看

4.1案例一

具体业务场景：人流量较大的大型超市

具体功能：收银功能

分析：我们能经常看到在人流量较大的大型超市的收银台前都排着长长的队伍，在这种场景下，收银功能的使用频率极高，使用者对系统的操作速度也有高要求，所以此场景下的收银系统应该更注重使用效率。具体设计中可以通过节省几个步骤来提高收银效率，哪怕前期需要培训，但是随着使用时间的延长，高效率节省的成本将远远覆盖软件的学习成本。

指导原则：高效

4.2案例二

具体业务场景：普通人要去提取公积金

具体功能：公积金提取功能

分析：在我们具体生活中，公积金的提取功能使用频率较低，如果这时候以高效的原则去设计产品，那么带给用户的是极高的学习成本，特别是由于使用频次少，使用时间间隔长，用户可能每使用一次都要学习一次，学习成本将远远大于高效节省的成本。所以此种场景在实际设计中，可以通过增加步骤的方式来降低学习成本。

指导原则：易用

                                            05

对于我个人而言，整个2019年看过的资料当中，“有赞产品设计原则”带给我的影响是最大的。一直以来，市面上成型的指导B端产品设计的方法论稀少，再加上B端产品之间的行业壁垒较大，每个企业都有自己的保密原则，这也导致了B端产品知识的流通性不够，加剧了知识的匮乏。而有赞的这次发布的产品设计原则，很大程度上解决了我工作上的困惑，指导了我怎么去进行B端产品的设计，特在此感谢！

“有赞产品设计原则”一共13条，这次我选取了其中感触较深的4条和大家分享，也算是对自己工作的一次总结，希望大家多指正指正。另外大家对“有赞产品设计原则”剩下内容感兴趣的百度一下即可。

微信公众号: Discoveryisland