根据我之前的工作经历，总结的B端产品设计经验，希望对一线从事B端产品工作的产品经理有一点参考价值。
什么是B端产品
B端产品，可以概括为：在供求关系中，给供给端使用的产品或系统。
B端产品区别于C端产品的特征是：
C端产品，侧重满足个人生活需求，给用户提供愉悦感（满足便利、新鲜感、虚荣心、欲望冲动），好玩。
B端产品，侧重满足组织生产需求，帮用户提升效率（发现并解决业务问题），有用。
有一个段子讲“手机那么好玩，还找什么女朋友呀”，这里的好玩，多数来自C端产品给用户的愉悦感。
而贯穿B端产品迭代发展的落脚点是：在业务流程中发现问题、解决问题，并提升效率。
我的B端产品设计经验
写这篇总结的基本思路是：如果要做一个独立且相对复杂的B端产品系统，该如何开展产品设计工作？
主要包括以下几个方面：
B端产品系统设计的基本原则（指导思想）
B端产品系统设计的五个步骤（具体怎么做）
B端产品系统设计中需要避免的误区（不要那么做，或不要做成那样）
1 基本原则
产品思维，业务导向
先说“业务导向”：产品系统是为业务服务的，所以要尊重业务的发展规律，最终让产品帮助到业务的发展。产品经理要到业务中去了解业务的宏观与细节，根据业务抽象系统逻辑，用互联网的方式系统性的解决问题或提升效率。
再说“产品思维”：产品经理有责任把原来自己可能不熟悉的业务，熟悉并抽象成产品需求且把事说清楚，并能够提供合理化的解决方案，不能只做需求的传声器——“他们给我提了一个需求，我们就做这么一个功能”，避免为了做而做。
由于业务快速发展，有些组织中没有“产品经理”的角色，又或者其他角色的成员主动承担了“产品经理”范畴内的工作，岗位名称无所谓，是否有经验无所谓，重要的是在承担这个事情的时候做到“产品思维，业务导向”，这是把事做好的基础。
用使用者角度去思考
所有的产品经理都知道“用户体验”，不过很多人理解的“用户体验”偏重在前端交互、视觉文案上。对于B端产品来说，只关注这些是不够的。所以我喜欢用更普通直白的说法——关注“使用者角度”。在设计产品的时候，想一想真正的使用者他们需要一个什么系统？他们会怎么用这个系统？现在的实现方式对他们来说好用吗？
很多B端产品，当产品经理离开办公室作为一个普通用户的时候，是想不到或者用不到的，所以极端的情况会出现，在需求开始之前产品经理没有用过相关产品，系统上线之后产品经理也不会用自己做的产品。B端产品经理，一定要走入具体工作场景，观察真正的产品使用者在具体的业务氛围中是怎么工作的。我一直相信一点：只有沉浸其中，才能更好的理解。
在小度掌柜（百度外卖商户端）电脑版上线第一周，我去一家商圈头部商户的后厨蹲点了俩小时，看餐厅的工作人员是怎么接单、处理订单的，在现场我发现我们的“接单”按钮有点小、不够明显。回来之后，我和视觉设计师沟通优化方案，给他们描述我们产品使用的具体场景：8平米的小屋（拥挤嘈杂），配置不高的组装电脑（显示屏分辨率不高），工作人员站着处理三四个平台的订单（紧张慌忙）。在这样的场景下，还需要工作人员俯下身去“寻找”操作按钮是不够效率，也不厚道。以此说服视觉设计师愿意接受“不符合设计规范”的大号按钮。
还有一个案例，是在优化客服系统之前，我去百度外卖的客服工作区，站在客服同学的背后，看他们怎么接电话、怎么记录信息、怎么解决投诉，只有这样才能了解客服人员在使用系统的时候需要什么功能，在哪些环节浪费了时间。
针对和内部使用者的沟通合作，个人觉得可以重点做好以下几点：
产品经理是来解决问题的，不要担心一锤子买卖（而提海量的需求），开发资源是有限的，我们可以一起来排需求优先级（不是所有的功能能一下子全上线）；
建立好信息同步机制，固定时间固定方式同步关键进展（当然所有信息同步方式里，面对面沟通效果是最好的）；
不要依赖业务方提需求，要帮业务方想方案，由于角色的不同、思维方式的不同，业务同学不一定能提出自己真的需要的功能，产品经理要主动去思考业务中的问题，并形成需求；
通过一两个项目，建立互信，形成互相支持的关系。过项目，建立互信，形成互相支持的关系。
考虑系统的延展性与弹性
业务肯定是发展的，而当前的资源和时间是有限的，一个产品版本，不会解决所有问题，迭代是必然的。怎么增加系统的延展性与弹性，减少后续研发的开发难度、减少使用者的后续学习成本就很重要。尤其是在设计1.0系统的时候，更考验产品经理的这项能力。
一方面，需要增加对业务发展的预见性，当前业务是怎么样的，以后一到两年会怎么发展，甚至未来五年的形态是什么样？没有人能保证自己的预测一定是对的，但是尊重业务规律，去思考业务可能的发展方向，提前想到的越多，在设计系统的时候能考虑到的延展性与弹性就越多。用“谋全局”的高度去思考一个系统，才会生成更合理的当前“谋一隅”的一版需求。
另一方面，在具体的产品方案里，针对这个系统的核心业务落脚点、基本单位尽量做到“模块化”——方便组装、方便基于这个标准模块叠加逻辑。下文的“定义最小颗粒度”会详细阐述这块的思考。
总之，一个好的产品系统要做到适合延展、有容纳新功能的“弹性”，B端产品经理要有这个自我期许。
2 五个步骤
确定产品系统的目标
接到一个需求，首先要想：这个系统给谁用？要做哪些事（解决什么问题）？系统的边界是什么（需要覆盖到什么范围）？
在这个大目标下，开展后续的工作。
梳理业务流程（用逻辑把系统串起来）
业务流程中包含哪些角色、包含哪些关键节点，从头到尾的顺向流程是怎么样的，从尾到头的逆向流程是什么样的，中间的分支流程是什么样的，从上到下、从下到上各类角色怎么配合……
梳理业务流程要做到以下几点：要闭环（不能有半逻辑，不能有停留在某个环节走不下去的流程）；要看到底（不只是宏观上合理，最底层的细节逻辑也要覆盖到），要有边界（一个全的系统是什么，不是没边没延）。
争取用一个大的业务流程图，把整个系统要解决的问题包含进去。这样做的好处是，可以把功能想全了，防止有重大逻辑缺陷，或遗漏功能。
定义最小颗粒度（基本单位）
基于上述业务流程，会发现有一个“基本单位”可以从头到尾、从尾到头、从上到下、从下到上顺畅的在这个系统里流转。
这个基本单位就是需要我们定义的“一件事”，拆解到合理大小颗粒度的“一件事”——这个系统主要解决的问题的基础组成部分，靠这些最小颗粒度的“一件事”组成整个系统。这个“一件事”在系统存在、流转有哪些“节点”，这个“节点”对应的是系统里的关键状态；不同的人，在这个系统里存在，就是系统里的“角色”；有哪些“角色”可以针对“一件事”的“节点”产生影响，针对哪些内容产生哪些影响就是“权限”和“数据范围”。
根据业务流程，抽象出：基本单位“一件事”、关键状态的“节点”、使用者的“角色”、“权限”、“数据范围”。这个系统就基本成型了。
以客服工单系统为例：
最小颗粒度的基本单位“一件事”是指“一个投诉”，不是一个电话（太小了），也不是一个人的所有投诉记录（太大了）。“节点”：就是工单的状态，从投诉开始、到流转到相关部门或负责人、到最后投诉解决，工单的每一次停留都可以作为一个“节点”。“角色”：除了一线客服、小组长、客服负责人，还有其他配合部门的角色等，凡是参与到这个系统的人都可以概括到某类角色里；不可概括的参与者或需要细化分工的参与者，需要增加角“角色”以适应需要。“权限”和“数据范围”：各个角色能做哪些操作、操作哪些内容、造成哪些影响就构成了“权限”和“数据范围”。
一个好的基本单位就像集装箱一样，具有普适性（可以灵活被处理）、具有弹性（方便添加功能）。定义好一个系统的最小颗粒度，系统就成功一半了。
我见到的B端产品设计里，做的不好的多数就是由于最小颗粒度的定义不合理，造成系统逻辑不全或延展性很差。
建立框架与归类（用页面把系统串起来）
根据不同的角色、不同的功能，进行归类，进而组合成一个整体框架，用页面的形式呈现出来，就可以形成交互稿。
从第二步到第三步，从第三步到第四步，是一个拆解再组装的过程，先拆解了、揉碎了再用产品思路组装起来以形成最终的产品形态。
撰写需求文档
将上述梳理的过程和内容，用文字的形式将产品逻辑、图表、页面、功能点串起来，并进行丰富细化，就形成了需求文档。
好的需求文档应该：逻辑严谨，条理清楚，文字简练，能把事说清楚。
每个角色（交互、视觉、开发）都能准确理解需求的背景、目标、实现方式，大到流程逻辑，小到功能细节。可以针对不同角色，提供侧重点不同的需求形式。
尽量用平实的语言（而不是形容词）描述需求，挤压任何歧义空间。
3 需要避免的误区
一个新用户，第一次使用系统但通过自己的琢磨看不懂这个系统（不会用、不知道都有哪些功能），我觉得这个系统不算好系统。好的系统，可以通过页面功能或者不多的介绍，就能把底层逻辑和边界看明白。
看不到底的伴生现象是特殊逻辑多，造成的问题往往是枝蔓太多。产品逻辑用打补丁的方式，解决某个问题可能很快捷，但长期来看，这种方式影响产品系统的简洁性和条理性。
看不到底的坏影响是，一方面使用者（尤其是新人）学习成本高；另一方面新增功能时容易挖到“电线”，增加了维护与迭代成本。
上面的文字已经提到，由于初期考虑的不周全（业务理解的前瞻性不够，或者最小颗粒度定义不清楚等）造成系统延展性差，增加一个功能就像给系统做一次大手术。所以尽量在产品设计初期，考虑的多一些，每一次迭代都想着为后续迭代提供便利。
所有问题都想着用产品系统来解决
一个系统不能解决所有的问题，也不是所有的问题都适合用产品系统来解决。有些事（需求）从投入产出比、灵活性上来说，通过管理规范、SOP、Excel去解决可能比做一个系统更适合。
4 B端产品经理的自我修炼
在和那些令人佩服、事业有成的前辈/领导一起共事过程中，还有我这几年的工作感受，我觉得B端产品经理需要持续沉淀的能力有：
无论是O2O也好，互联网+也好，B端产品要解决好业务的问题，必须要去理解业务，要了解这个行业的历史与现状、关注行业的发展。
除了垂直的业务逻辑，多数的互联网+都会涉及到商业问题，经济管理、市场营销这些知识会帮助产品经理开阔思路、提升商业思维。
B端产品多数业务链条比较长，涉及角色较多，一个B端产品的成功，离不开相关角色共同努力与相互支持。
通过一两件事，建立与合作部门的互信，是后续合作的基础；建立固定的信息同步机制（与研发团队的每日站会，与业务部门的每周周会等），是合作顺畅开展的保障。
在工作中，能够发现资源、利用资源都是一种能力。
让我佩服的那些前辈，平时办公桌上都会有一本书。一个人能力很强不可怕，可怕的是他还一直在学习。
无论是这个时代，还是互联网行业，都发展太快了，我们需要持续学习。
