在B端UI的学习过程中，我们会接触大量和产品经理有关的知识与技能，甚至在工作中还得自己完成和他们职能有关的工作，比如画原型、流程图，甚至输出产品方案和文档等等。
所以一直以来，大家对B端产品经理和UI设计师之间的岗位职能与界限都有很大的疑问，而我们今天这篇分享，就要来解决这个问题。
要了解产品和UI之间的差异，核心问题在于理解产品经理的工作职能，毕竟UI设计师的本职工作很好理解，不用多做介绍。
B端产品经理的工作，可以总结成一句话 —— 将业务需求以产品的形式实现出来。
我们首先理解业务和产品这两个概念，业务就是企业经营的方法和模式的总称，比如一家给本地餐厅提供新鲜食材的批发商，它的主营业务就是食材批发。但光说这个太草率，肯定还要进一步细化它的细节。所以我们可以把食材批发这个业务再细分成上游的食材采购、中游的物流仓储、下游的食材销售。
而这几个部分依旧很宏观，还可以再做拆分，比如上游采购中，怎么找到供应商，怎么确定供应和采购的形式。在中游供应链环节，怎么将采购的货物进行入库、保存、出库，以及统计中间的损耗。在下游的销售端，怎么找到客户和给他们提供服务，签订协议等等。
上面这些可以理解成是主线业务，而主线业务的正常运转还需要一系列支线业务的辅助，比如财务中针对上游的付款和下游的收款，人事方面要招聘并管理采购与销售，售后方面还要提供客服与赔偿机制等等。
业务是一种抽象的概念，但它又是企业运转起来的基石，所以任何企业都会自己建立业务体系，并且这套体系还会随着企业的发展不断做出调整与优化。
接着我们理解产品，在B端领域产品就是用于支持业务运转的数字化软件/工具。比如前面提到的供应链部分，货品从采购、运输、入库、销售、出库、送达的整个生命周期，就可以使用数字化产品来进行记录和管理，而不是使用手写账本的这种古老的方法。
但让产品满足业务的运转要求并不是一件容易的事情，因为业务中包含了大量的规则与信息，比如产品入库这一个业务点就要考虑大量的细节，比如存储位置分配，保存时间上限，产生损耗的记录，过期销毁的处理方式等等。
而产品经理要做的，就需要根据业务需求，制定产品的具体形式与功能，交付给团队进行设计和开发。
在实际项目中，了解业务需求就是一件非常消耗时间与精力的过程。因为业务需求主要由企业其他角色制定与提出，产品经理在业务中属于下游的环节，需要参与大量业务相关的会议来讨论并消化这些信息。
确定完业务需求以后，下一步才到具体的产品形式与功能的规划。很多同学第一反应可能就是开始画原型和写PRD文档，这就是无法正确理解产品经理职能的根源，因为这只是最底层的工作，还有更上层的工作没有被关注到。
产品经理做的规划可以分为四个层级，从上到下分别是：产品框架、数据服务、功能逻辑、交互操作。
层级1：产品框架
产品框架层就是产品具体包含的功能明细与层级分类，这需要和业务紧密相关。比如上方提到的业务模块，就可以转化成产品的功能模块，但实际的产品落地包含的功能肯定还远不止上面这些，除了更细分的业务点外，还包括账户管理、银行对接、数据展示等等额外的功能服务。
这部分的工作制定的就是产品的股价，重要性最高，但需要消耗的时间不会太多，因为在项目前期定好以后很少会做出大改。
层级2：数据服务
数据服务就是产品中需要包含的数据内容与处理方式，和产品的后端开发密切相关。比如在物流中，采购的货物到入库需要记录哪些数据，是需要产品经理一条条想出来的，如货物名、分类、采购来源、发出时间、运输车辆、入库时间、损耗比例、存储位置等等。
每个数据字段不是光定出来就够了，作为产品肯定还要搞清楚数据是怎么形成的，是人为填写，还是有外部设备录入（扫码枪），还是根据其它数据计算出来。这部分工作同样重要，且包含更多的细节，需要产品投入大量的时间去规划。
层级3：功能逻辑
功能逻辑就是前端可操作功能的步骤流程与具体逻辑，可以脱离界面的具体形式进行定义。比如完成一个采购和入库，那么第一步先创建订单，表单要怎么填写，填好的订单会进入那个列表，后续怎么进行操作，中间有几种状态，最后怎么入库等。
这些都是产品进行后续设计和开发的关键信息，同样需要投入大量的时间做分析，在确定方案以后才会开始后续的原型绘制。
层级4：交互操作
交互操作部分就是产品具体的页面布局形式和操作方法，主要通过线框图和标注信息来示意，也就是多数人理解的画原型和输出PRD文档。
在理想环境中，产品经理需要输出这些内容，但它们同样需要消耗大量的时间精力，且它们在多数项目中的权重、优先级又不高，所以最容易成为产品忽视（偷懒）的部分。即使做了，也不会做得太细，因为设计稿才对交互有最终解释权，只要保证设计师能看懂就行了。
并且，除了产品规划之外，产品经理还需要承担后续项目的推进与落地（类似项目经理），要不断和团队成员进行沟通与协调，并参与最终的产品测试，这也要消耗产品经理的大量时间和精力。
可以用以下这张图来概括B端产品的核心工作内容：
原型和交互在B端产品经理的职能中是最弱势的，所以这部分工作往往会被忽视，或是交给设计师来完成。所以这也是为什么B端UI设计师要大量承担产品工作的原因，也就是完成产品规划中的最后一环。
完成产品的工作以后，才到我们具体设计界面的部分。但我们一直强调，B端界面设计本身的价值就比较有限，除了视觉规范和组件库的搭建以外，B端设计师的价值体现在对业务的理解并转化成有效交互方案的能力。
听起来就像补充产品规划工作的最后一环，但在真实项目中设计输出的交互是肯定要比产品输出的交互更具体、更专业、更细节。在一些复杂的项目中，专业交互方案的输出是无法被替代的，即使有AI也没用。
但问题也就随之而来，如果我们所在项目并不复杂，也没有特别高的要求，那么设计师即使能力再强，也没有发挥的余地。再者一部分初级设计师没有经历这样的项目，很难理解交互的重要性，也没有得到充分的锻炼和经验，就很难提升相关的能力进入更高的平台，形成恶性循环。
所以我们这里就要探讨一个更现实的话题，作为普通B端设计师，因为特定的限制，没办法往更高阶的B端设计师方向发展，还有什么发展路线。
答案只有两个：
- B端产品化设计师
- B端产品经理
产品化设计师就是产品+设计一体的“设计师”，要向上负责更多产品的工作，同时把设计一起做完。对于一些简单但对设计又有要求的项目，有设计能力就具备普通产品经理无法替代的优势。
比如网上现在有很多产品经理在使用AI生成界面并直接完成开发工作，虽然产品勉强能用，但视觉效果是无法满足更专业的使用场景的，交互也存在各种缺陷。没有专业的设计经验积累，就无法对它们做出有效的调整。
第二种路线就是直接转行做纯粹的产品经理，不用负责后续的页面设计。相比前一个类型，设计转行的产品也具备一定的优势，那就是输出原型速度会更快，懂得如何用最小的成本输出前端能够理解的产品说明。
说到这里肯定也有同学有疑问，那就是既然最终是往产品转，为什么不直接从事产品经理还不用绕弯？
这是一个非常有意思的问题。在国内的B端市场，一上来就做产品的产品经理往往专业性是最差的，尤其是原型画得少，文档也写的少的那部分。虽然我们一直强调输出原型和文档是相对末端的工作，但是上层能力的积累是起于微末的，基础训练积累得越少，上层能力也就别指望会好到哪里去。
所以B端市场普遍呈现出来的现状，就是普通产品经理即做不好上层的设计与规划，在需要制定底层细节的时候也力不从心。简单来形容就是 —— 一无是处。因为B端产品经理的技能是没有专业培训的，直接上岗缺失的部分又会因为各种情况（懒）不去修补，最后就是所有技术类岗位都对B端产品经理怨声载道。
由此引申出另一个暴论，那就是由其它相关岗位转岗做产品的效果，远比一个普通的产品经理更有用，进步速度也会更快，不管是业务员、客户经理、产品运营、前后端程序员还是UI设计师。
因为在我们的日常工作中，都对产品的形态有非常明确的预期，会通过和产品的协作中越来越清楚作为下游或评审人员想看见哪些交付物。这种视角是作为一般产品绝对无法获得的，是他们天然存在的短板和缺陷。
直接做B端产品是很难学习入门的，所以先从一个专业岗位入手，深度理解产品的构建过程和机制，未来想转产品的话就会更容易，也更得心应手。
而只要你们有这样的想法，那么在今后的实际工作中也会不断出现这样的机会。因为对中小团队来说，现有产品经理离职（或者没有产品）等于要重新培养新加的产品经理去熟悉业务，面对这种情况企业会更希望让现有职员转岗，再招新人顶替他原有的岗位，这就是设计师转产品最合理且无缝的模式。
有了这段正式的经验，就不存在转行投简历的阵痛期，你自然拥有更多的可能性，可以获得更多的机会。
最后，就是想完成对产品岗位的切换，是需要你们在当前岗位完成有效的积累，具备足够专业的基本功和水平，而且不能抗拒负担产品相关的工作。而不是在原有岗位就是半桶水，那么“逃”到产品岗位以后也依旧只能是半桶水……
还是要提一点，对中小企业来说，B端产品经理的需求量会更大，发展空间也会更多，待遇也会更好。但没有好的机会你是很难获得产品岗位的，也很难做好，市面上的底层产品经理水平大多都惨不忍睹。
所以先做好设计是个更佳的选择，一方面入行更简单，另一方面就是可以快速积累对真实项目的认识和提升产品需求输出的能力，就可以直接超越大多数的产品。
有什么想法可以在下方留言。
我们下篇再贱~
欢迎关注作者的微信公众号：「超人的电话亭」
