B端产品设计:整体方案长这样?
编辑导语:B端产品更多是面向客户的,是比较有实用性的产品,在产品设计中,需要从各个方面进行产品的调研输出,找到最佳的业务方式以及完整框架;本文作者分享了关于B端产品设计的整体方案,我们一起来学习一下。
经过充分调研,我们了解了业务现状和问题。接下来是不是应该画原型写PRD了?其实不然,还需要再输出“整体解决方案”。
整体解决方案是一个产品的实现思路、明确产品的基本框架和范围。只有确定了整体方案,才能够细化后续的工作内容,为产品做详细设计。
方案主要由五部分组成:梳理业务梳理、明确产品定位,功能模块设计、划分实施阶段、应用架构设计。
方案呈现形式根据团队的规范要求输出即可,如果团队没有输出要求,产品经理也应和对应干系人沟通情况并达成共识。达成共识的内容需要公示,让团队及相关人知晓。
接下来依次讲述整体解决方案的各组成部分。
01 梳理业务流程
在调研时已经梳理过业务流程,明确了在业务运行时各环节各角色的具体任务。
现在我们再次梳理业务流程,是需要进一步将业务和系统(产品)相结合,确定需要系统介入的环节、保留线下操作的环节、对接三方系统的环节。
系统不是纯粹的将线下操作改为线上操作,而是根据业务现状、项目目标、资源限制等因素,设计出符合当下需求又为未来保留了拓展可能性的灵活产品。
举例:
Z公司TMS项目中,调研得知目前的紧急需求在于2部分:
- 运输任务初步信息化,提高作业环节效率;
- 车辆执行监控,掌握车辆位置相关信息。
关于运输任务:任务来源于上游的业务系统,由于时间和资源限制,暂不考虑系统对接;所以订单创建与管理、运单调度等环节均由本系统操作;在运输执行的交接环节涉及多业务方,暂时保留线下操作。
关于执行监控:因为对司机行为管控力度不足、软件对手机设备要求等因素影响,最终采用安装GPS硬件设备的方式采集车辆执行信息,TMS系统和GPS设备系统对接获取相应行驶数据,从而达到监控目的。
02 明确产品定位
当我们知道了产品会参与哪些业务部分,这也要求我们为产品做好“定位”。
定位的意义在于明确产品是做什么的,即:针对谁(角色)在什么场景下提供什么支持。这样也就限定了产品对业务支持的边界,或者说是功能边界。
定位是锚,让我们知道自己在哪里,该做什么,让产品设计不偏离跑道。
举例:
Z公司TMS项目中,运输执行的最后环节是将物料运至仓库签收,因此在运输送货和仓库收货会有交接;业务场景中,车辆送货到达仓库后进行挂号排队,然后等待叫号卸货。
在此之前我们为“TMS”做好定位:为运输任务管理和任务执行提供支撑,以此为中心拓展服务内容。
在实际场景中“排号”属于仓储业务范围,同时为了后续系统的拓展性考虑,将排号划分到WMS系统中,即便WMS的1.0版本只有排号功能;现阶段车辆达到仓库的自动排号由TMS向WMS传数据并触发任务,以此支持双方后续业务的开展。
03 功能模块设计
从表面上看,系统就是由各个功能模块通过逻辑组装在一起的集合体;实际上是基于业务场景,对对应角色在该业务环节中需要做的操作进行抽离,以此提炼出功能模块。
提炼过程中常出现对资源、业务的管控边界模糊问题,就需要及时代入实际业务场景验证,或者和业务负责人沟通,避免设计偏差。
当功能模块提炼完成后,需要规划出系统的菜单结构。菜单结构犹如身体骨架,具体功能犹如不断填充的血肉;菜单万不能随意摆放,结构若是不符合整体逻辑,对系统设计和用户体验都是极不友好的。
举例:
Z公司TMS项目中,通过业务逻辑能够划分出前期资源准备、运输任务执行、运营结果数据。
所以在提炼功能模块时1期功能主要分为以下:
- 资源管理:物料管理、供应商管理、承运商管理、车型管理、车辆管理、司机管理。
- 业务管理:订单管理、运单管理、车次管理、异常管理(运单)。
- 数据报表:数据概览(首页)、车次统计。
上述功能为主要模块,在实际场景中存在其他功能;如“在途监控”,调度需要观察执行任务的所有车辆当前状态,此功能不能归属于具体车次;因此在设计菜单时需要充分考虑全局。
1期功能菜单如下,后续功能可进行延伸:
04 划分实施阶段
划分实施阶段又称为演进蓝图,可以理解成系统规划不同的发展阶段。
俗话说一口吃不成胖子,产品也不是一次就开发成最终版;往往基于重要紧急程度、功能影响面等因素,先明确功能优先级,进而划分产品不同阶段的功能模块以及实现节奏。
阶段划分的影响因素有很多,比如项目资源(时间、人员、支持…)、业务诉求(当前诉求和未来诉求),要根据权重综合考量。
举例:
Z公司TMS项目中,在调研时已明晰了当前重要紧急需求,因此以实现此目标为主。其他功能都要靠边站,哪怕很有技术含量、提升用户操作体验等。
车辆调度时运输任务执行的核心之一,系统至少可以通过2种方式实现。
- 调度员在系统中手动指派车辆和司机;
- 系统自动指派车辆和司机,系统通过维护物料和车型匹配数据、送货时间和车辆任务匹配等多种参数自动指派。
方式2比方式1从工作效率和操作体验上都加分不少,但是在1期的项目目标、项目各项资源、实际场景(前期业务量不是特别多)约束下,选择了方式1来实现调度功能,方式2则规划至2期阶段实施。
05 应用架构设计
应用架构属于技术层面的考虑,关注系统的整体结构。需要考虑公司不同系统之间的对接;考虑新系统在公司战略定位下延伸出的诉求(有时和项目目标有所区别),考虑公司或项目的其他诉求。
系统架构对产品的拓展性影响深远,需要和技术及相关负责人充分沟通后才能进行应用架构的设计。
举例:
Z公司TMS项目中,因为业务方当前存在ERP、SAP等多系统同时运行,所以要考虑TMS系统如何和现有系统架构进行结合,不同系统模块之间如何进行更好衔接。
复杂的暂且不论,简单的如物料基础数据是通用数据,多系统维护成本较大,后续要进行多系统复用;所以从技术实现成本、降低数据偏差异常、减少用户重复工作等多方考虑;基础数据以SAP系统为准,其他系统进行数据调用。
温馨提示:
- 产品设计和规划不是一经确认就固定不变的,而是随着设计深入、业务发展、环境变化而变化,是不断进行调整的。
- 设计系统结构时需要考虑满足现状,同时兼容未来发展,满足系统的拓展性。
- 系统小的调整经常有,大的调整只有业务模式发生较大范围或本质变化,功能模块才会出现结构性的变动。
以上。
本文由 @耳目不染 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自Unsplash,基于CC0协议
- 目前还没评论,等你发挥!