|
B端产品从前期的业务诊断、业务分析，到后期的方案形成，这个过程中，大致会经历怎样的环节或步骤？这篇文章里，作者便做了相对完整的梳理，不妨来看看，或许会对产品同学们有所帮助。  注意： 在现实中，B端产品切入的方式不止这一种，有的企业甚至并没有严格遵循以上步骤做市场分析，而仅仅是在某个行业深耕久了，对行业比较了解或者摸索到了该领域还存在潜力，进而选择了自己熟悉的赛道去做探索；或者机缘巧合工作过程中接到了一个大客户订单，通过和客户的项目制合作，完成了对该业务领域的学习和认知，进而深耕于该领域。 2. 针对选定的目标做市场调研第一节已经分析完如何选定目标市场或目标客户，接下来我们从客户的内部视角，探讨具体的业务问题调研和分析。 尤其是商业软件产品，在启动设计阶段，不可能凭空基于对业务的假想完成设计，更不可能针对一个有代表性的标杆客户进行充分调研，透彻理解业务，并刻画出MVP版本。 1）业务调研的五个环节  3）业务调研的目的 B端产品面向企业用户，产品目标是更好的支持业务运转。所以调研目标是分析业务现状和业务问题，为方案设计提供支撑，最终解决企业的业务问题，提升运转效率。 C端产品直接面向终端用户，而且一般承载着公司的商业目的（可能是变现，也可能是获取更多流量等）。所以调研目标是获取真实有效的用户体验的用户需求和体验感受，以便后面结合用户的需求，痛点设计解决方案最终实现商业诉求。 3. 业务分析的三层架构在企业开展新业务时，首先要结合自身的战略地位、组织发展阶段，思考业务目标和当前情况，从而推导出基本的管控模式，再进一步设计组织结构与绩效激励体系，基于这些顶层设计，最后才是业务开展的具体流程体系。 B端业务分析框架：  2. 使用PMF（product/Market Fit）进一步对初期市场进行验证PMF将新产品市场评估为四个阶段：
尽管业务型B端软件比较厚重，但在商业层面的运作上，一定要始终秉承“尊重市场，尊重客户，找准定位，快速迭代”的理念。 3. 确定核心业务流程现在让我们回到产品设计本身，我们要梳理核心业务流程，定义问题边界，并确定产品定位。 从核心业务流程切入产品设计，是开展整个设计工作非常好的起点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方和涉及的系统。 只有定义清楚业务边界，才能定义产品边界。很多时候我们发现产品的定位模糊混乱，这是因为设计时对产品要解决的业务问题的边界和场景定义得就不清晰。 在核心业务流程绘制过程中，只需要绘制关键场景和节点，不用陷入细节流程。 4. 明确产品定位产品定位是产品设计的指导思想和灵魂，梳理了核心业务流程和业务场景后，我们对客户的问题、痛点有了明确的范围界定，接下来我们从宏观和执行两个层面来探讨产品定位。 1）宏观层面的产品定位 宏观层面来讲，产品定位是指对于一个选定的目标市场，企业如何设计产品来承载价值主张来解决目标客户的痛点和诉求。用一句话来概括就是：产品的目标客户是谁？解决了他的什么问题？为他提供了什么价值？这也是精益画布中1、2、3点描述的要素。 针对企业自研自用系统，也需要明确宏观层面的产品定位，但自研系统不存在目标客户群体的概念，因为服务的目标客户就是自己公司的业务方。 2）执行层面的产品定位 任何一套复杂的软件产品，都不太可能只靠一套独立系统来运作， 而会由若干子系统来协同运作，支撑业务。 在B端产品设计中，我们要逐步分解、细化产品设计，在确定了产品整体定位后，下一步我们要思考应该设计几套子系统来匹配不同的业务场景，支撑业务运作，这也是执行层面的产品定位问题，我们要说清楚，产品由几套子系统组成，每套子系统的目标用户是谁，解决他们的什么问题。 划分子系统时，可以通过目标用户与场景进行子系统的定义和拆分。拆分的目的是让系统从业务层面上边界更加清晰，易于理解和使用，这也会传导到技术实现上，让系统底层的设计逻辑更加严谨、完备，在高粒度层面做到松耦合、高内聚。 另外，产品经理也要认识到，多套子系统的定义只是在应用层面上的划分，在技术实现上很可能是一套统一的底层加多套前端的表皮而已。 5. 梳理应用架构所谓应用架构，是公司所有软件系统的整体结构和布局，任何公司的应用架构都不是随意设计的，都有复杂的设计思想蕴含在其中。 1）自研软件系统的应用架构 在设计一套新的系统时，要考虑如何和公司现有的系统架构融合，不同系统的模块之间如何衔接。这项工作复杂度较高，不仅需要有丰富的架构经验，而且需要深刻理解业务特点和可能的演进方向，还要熟悉本公司的系统架构，这样才能快速的提炼出相关问题。 如果公司已经发展了多年，软件体系结构已经相对成熟，这就意味着在设计一套新的系统或产品时，完全可以复用现有的部分系统或模块，从而快速实现，提高系统建设效率，减少重复开发，更重要的是可以保证整体系统架构合理。 举例，支持分销系统的公司整体应用架构图如下：  基于业务场景抽象模块和基于业务领域抽象模块的区别之处是后者的内聚属性更强，和技术架构的模块设计比较贴合；而前者更多从用户体验和业务逻辑出发来做模块划分，在场景菜单下可能会融合多个模块的功能。 2）基于业务场景抽象模块 有时候通过业务场景来定义菜单反而逻辑更清晰，更容易理解。例如，在某些流程属性比较重的业务系统中，通过业务场景划分模块也能较好的做到功能模块解耦合的抽象归类。如下图的菜单设计，一级菜单学员管理，课程管理，直播管理，助学管理等模块，都是典型的教学场景。  以上分享了三种划分模块的思路，在实践中，往往会将几种思路融合在一起，没有绝对的原则和方法论。企业的运作管理体系已经发展多年并非常成熟，对应的管理软件建设也十分成熟；任何形态的管理软件系统，B端产品，在模块划分和抽象设计中都要尽量参考同类业务软件系统的设计思路，这是前人重要的总结沉淀，蕴含着对业务的深刻理解和洞察，切勿自己发明创造，浪费时间。 7. 规划演进蓝图通过绘制系统的功能模块图，我们可以明确业务和系统的规划脉络。将能想到的功能集合都列出来，这是一个做加法的过程。但是我们不可能一次实现全部功能，而要根据业务优先级，拆分成几期来完成，所以接下来需要做减法：确认产品的功能规划与实现节奏，就是常说的演进蓝图（roadmap）。 对于一个新系统，我们一般分几期来实现：
随着设计的深入，以及业务的开展、变化、功能模块可能需要修正和调整，但只要业务的本质模式没有变化，功能模块就不应该出现结构性的改动。功能模块图和演进蓝图代表的是概要性方案，指明了整体的产品方向，是后续细化设计的指引和准则。 8. 数字技术赋能业务单独从业务效能优化的角度来讲，数字技术赋能业务可以总结为五个阶段，这五个阶段循序渐进，逐步推演，对业务进行全面优化和赋能。 这五个阶段分别是流程化，线上化，自动化，数据化，智能化，如下图：  参考：不同实体关系实例图  3. 绘制页面流转图对于系统设计来讲，业务流程图依然属于比较粗粒度的概要性设计，如何将它与软件产品的页面设计对应起来，绘制页面流转图是一个很好的衔接方式。 页面流转图描述的是，用户完成某项工作需要访问的页面及页面跳转顺序。绘制页面流转围可以帮助设计人员审视、思考系统中的页面设计方案，包括系统中总共需要哪些页面，哪些页面可以重复使用，哪些页面需要定制化开发。 一般来讲、我们绘制页面流转图时，都是针对某个单一角色绘制某个特定场景下的页面访问和跳转逻辑，从用户的视角来梳理一遍所有相关页面，每到一个新页面时都要思考:需要新做一个页面，还是可以复用原有页面? 最终整理出系统涉及的所有页面的初稿。 页面流转实例图如下：  5. 界面设计我们已经完成了功能模块设计、演进蓝图设计、业务数据建模、业务流程梳理、页面流转梳理，功能清单等一系列环节，已经细化到每个操作需要访问哪个页面、总共有哪些页面、现在需要为每个页面设计具体的交互功能以及具体呈现，即进行界面设计。 虽然在整个界面设计之前的流程很长，但在此梳理期间，我们对整个业务形态已经了然于心，对整个项目和产品的掌控力越来越强。此时再去做界面设计，已经是水到渠成之事。 界面设计流程：  注： 本篇文章只挑选了部分业务场景作为例子进行讲解，并没有覆盖整个系统所有的细节功能设计。在实践中，我们在细节方案设计阶段，要挑选优先级和重要程度比较高的业务场景，进行进一步的业务调研，梳理每个场景背后的业务流程，完成功能设计，最终汇集得到完整的产品方案。 本文由 @梅维斯白 原创发布于人人都是产品经理，未经许可，禁止转载 题图来自 Unsplash，基于 CC0 协议 该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。 |
