《产品经理升级之路》决胜B端之设计篇
2021-07-17 21:08:09 0 举报AI智能生成
登录查看完整内容
产品经理修炼
作者其他创作
大纲/内容
也叫实体建模、领域建模，是针对业务特点归纳并设计对应底层数据模型的过程
构件业务数据模型
基于流程确定页面流转图
具体页面设计
提前规划好系统用户角色
完成权限设计
常见流程
业务调整的灵活性取决于软件系统的灵活性，软件系统的灵活性取决于业务数据模型的可扩展性
事先通过ER图思考是否会存在一对多、多对多的情况，预留扩展性
业务数据建模
基于主干流程明确系统角色和业务岗位
思考各环节在逻辑上的先后顺序与依赖关系
业务流程图
描述用户完成某项工作需要访问的页面及页面跳转顺序
总共需要哪些页面
哪些页面可以重复使用
哪些页面需要定制开发
关注点
重点在于帮助在大脑中构思页面设计思路
不是所有页面都来自于页面流转图
绘制页面流转图
流程和角色
原型 - UE - UI - 前端
界面设计流程
重点在于说清楚界面上的交互功能设计
线框图绘制
系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。
安装程序显示进度条
上传文件显示进度图，并提示剩余预估时间
校验失败，在有误的内容旁边提示错误原因
程序未响应，系统提示用户关闭or等待
eg
反馈原则
系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。
避免采用计算机程序语言的表达方式
要采用符合真实世界认知的方式，让用户通过联想、类比等方法轻松理解程序想表达的含义
隐喻原则
用户经常会不小心操作错误，需要又一个简单的功能，让程序迅速恢复到错误发生之前的状态。
软件系统应尽量提供撤销、重做、反悔的功能，但类似转账交易等是不能反悔的操作
编辑软件提供的撤销功能
点击删除、关闭按钮后的二次确认
电商平台允许一定规则下的取消订单
回退原则
同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致
首页永远放在第一个，个人中心在最后
统一的设计风格
一致原则
系统要避免错误发生，这好过出错后再给提示。
设计时首先考虑如何避免错误发生，其次再考虑如何检查、校验异常
防错原则
让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。
搜索记录
订单提交后的核对页面
记忆原则
系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。
简单、易用，让中级用户用起来得心应手
提供必要帮助，让刚入门的初级用户顺利上手
支持灵活的个性化定制，让高级用户能够以进阶的方式使用系统，充分发挥价值
灵活易用原则
对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息。
重点太多，相当于没有重点
简约设计原则
错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。
容错原则
对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。
尽量在前端交互上做好引导提示
对于复杂的规则和逻辑，可以考虑通过帮助文档来指导用户
帮助原则
尼尔森十大可用性原则
列表页主要为增删改查
实现一套高度灵活的前端控件，即可实现灵活定制
可以向成熟的优秀软件学习
列表页经典设计方案
Google Analytics
百度统计
管家婆云ERP
Udesk
SalesForce
借鉴成熟软件
墨刀
善于使用模板
采用标准控件
界面设计的建议
界面设计
掌握事实、发现问题、分析原因、产生对策
观察、分析问题的视角和思路是报表设计的核心，绚丽的交互知识次要的外在
核心价值
要从用户使用报表和分析问题的角度思考
明确分析目的，需要通过分析发现哪些方面的问题
思考采用什么方法来识别、诊断问题，其中的困难是什么
构建分析体系
设计具备明确业务含义的指标来考量业务
从大的方面拆分出几个方面的观察指标，再进行拆解
定义观察指标
目的是帮助用户准确、快速理解、掌握指标及变化特征
设计呈现形式
管理要用数据说话，报表数据就是诊断和决策的依据
跟踪指标变化
每周分析上周数据走势、变化背后的原因
分析变动原因
跟进处理问题
报表设计与应用流程
SmartBI
FineReport
报表引擎
数字右对齐，直接看出数字之间的大小关系
数字加千分符，帮助快速识别数字的量级；
表头加粗
无数据也要有占位符
二维表格设计
业务分析是报表设计的核心，尽量参与分析体系构建的过程
聚焦业务分析本身
不要急于线上化
上线后不要急于推广
掌握数据体系的逻辑架构
理解数据集市、星形模型、数据立方体等基础概念
理解掌握数据仓库原理
报表设计的建议
报表设计
数据埋点事考核产品使用程度的一个重要依据
申请分析网站账号
获取埋点代码片段
将代码片段埋入网站或App
观察分析数据
数据埋点的流程
什么是数据埋点
Web端埋点工具
神策
GrowingIO
移动端埋点工具
常见B端埋点工具
能量分流图，观察流量的流转情况
桑基图
当日访问的新用户在之后几天的访问百分比
Cohort分析图
访客分析
热力图
埋点工具的数据分析
观察并研究用户对各项产品功能的接受程度、使用情况以及操作习惯
诉求
很多时候只需要分析页面级别的流量和行为即可
方案
B端与C端产品数据埋点的区别
数据埋点
功能权限，指各个角色可以操作的界面、按钮等
数据权限，指各个角色在各页面中能看到的数据范围
权限设计反映了设计人员对整个业务体系中岗位和流程的理解
通常用权限表来描述权限、角色的配置关系
需要在产品设计阶段就准备好
页面、页面元素（按钮、链接等）
功能权限设计
Role Based Access Control
每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合
引入用户组的概念，如果用户较多，可以对用户进行分组，将角色和用户组进行关联
完整的RBAC模型理论成为RBAC96模型族，对角色的继承关系、权限的约束关系等更复杂的话题进行了深入分析和指导，适用于任何业务系统
RBAC权限模型
通过组织机构树控制，这种方式最复杂也最灵活
通过客户地区控制，这种方式简单、容易实现，但灵活性差
常见实现方案
数据权限设计
权限设计
编写时间：前期分析可行性时
受众：老板、投资人
编写目的：论证商业模式的可行性
编写重点：分析市场、产品定位、盈利模式。在业务系统的产品实践中，很多时候是指业务部门提交的需求文档
BRD
编写时间：开发之前
受众：研发人员
编写目的：理解要开发的软件功能设计
编写重点：功能描述、原型描述
PRD
编写时间：立项之前
受众：市场、销售人员
编写目的：说明产品要点
编写重点：概念性的产品形态介绍，描述产品的形态和大纲
MRD
产品设计的好坏，首选取决于需求的质量，很多需求的提出者只是灵光一闪，并没有经过严谨的思考
如果没有一些机制或手段，让需求提交者经过全面思考后再提交需求，则可能会造成需求泛滥，需求质量低下，产品经理需要耗费很多精力去鉴别需求的真实性和价值
问题描述：业务中遇到的问题，需要清晰、详尽
期望目标：期望解决哪些问题，或改善哪些指标
预期收益：预期获得的收益，尽量用客观数字描述
期望解决方案：期望的问题解决方案
风险描述：初步分析需求的可行性与面临的风险
模板
商业需求文档的管理
用清晰、通俗的文字将复杂、抽象的软件设计思路和方案描述清楚
PRD交付或传播之前，必须标记版本号，每次交付前的修改要严格记录变更时间、原因等信息。虽然很多文档版本工具可以协助版本管理工作，但标准文档格式内的版本记录是必不可少的。
PRD修改记录
包括业务现状、面临的问题、解决思路等，需要有数据支持
无论需求有多简单，都要填写此项，让当前、以后的文档阅读者理解此项目的背景
项目背景
具体的量化项目目标，需要符合SMART原则，包含验收和成功的标准，以及预期收益
不容易直接衡量业务价值收益时，可以考量功能的使用情况、满意度等
项目收益目标
简明列举所有核心功能特性，或概述项目方案，包括但不限于产品方案、运用方案和技术方案
项目方案概述
项目涉及的系统、产品，以及项目的影响范围
提前确认项目关联方、影响方，确保项目启动时能准确覆盖所有责任方，避免遗漏
项目范围
项目的假设、约束、产品风险、运营风险、技术风险，以及风险的应对方案
项目风险
术语和缩略语
参考文献和引用文档
系统框架图
数据模型图
业务流程图
业务用例图
状态机图
产品框架概述
尽量采用提炼总结并分段陈述式描述，避免大段的论述行描述
产品需求详解
断网、断电、误操作、数据丢失等，描述这些情况下该如何处理
也可以根据需要将异常处理方案写在具体功能描述中
异常情况处理方案
功能需求
数据埋点
角色和权限
项目配套的运营推广计划，产品设计时就应该确认运营计划
运营计划
待决事项
不必急于写PRD，而要完成模型设计、流程设计、界面设计、权限设计等工作后，再编写PRD
产品需求文档的编写
文档命名要遵循一致的规范
对文档进行版本管理
将文档存档管理
文档管理要点
文档编写与管理
尽量使用简单的方式让别人理解自己的设计意图，不建议使用过于复杂的UML规范，否则导致其他人看不懂就失去了沟通的意义
一种描述实体对象之间关联关系的经典图表
讨论不同对象之间一对多、多对多关系
ER图
可以清晰准确地描述分角色、跨系统的业务流程
尽量使用简单的绘图规则，例如只使用开始、结束、执行、判断四种标记符号
开始结束节点必须用专门的图形来表达，让阅读者较为轻松地识别开始和结束的位置
每个流程只有一个开始节点，但可以有多个结束节点
尝试调整泳道顺序，以便保证流程看起来清晰干净，而不是交叉、缠绕在一起
绘制要点
跨部门流程图
一种描述所有状态机状态之间流转规则的图形
状态值必须是有限的集合，状态的所有枚举值必须能涵盖所有实际可能的情况
状态之间要互斥，不能出现二义性
为了更准确地描述事物，状态还可以具备子状态，例如订单取消可以定义子状态为客户取消、商家取消、系统取消
注意事项
状态应该是能持续一定时长的，而不是很快就会结束的瞬间时态
流程图的一种，用来描述一系列过程
活动图和流程图最大的区别是，活动图可以描述并发工作的执行过程，流程图只有判断节点才能引出两个分支
例如，创建客户根账号后，子账号和门店的创建可以并行发生，没有顺序要求
活动图
从用户视角来描述系统的操作功能，即某个角色在不同场景下能做什么
复杂用例图很少用到，简单了解即可
用例图
UML和常用图表
B端产品的细节方案设计
避免产品过度设计
避免技术过度设计
同一套语言沟通
与技术人员沟通顺畅
预判需求的可行性
评估工时合理性
产品经理是否需要懂技术
技术常识不足以做技术方案设计
对研发的工作指指点点会招来反感
一般情况下不用
技术方案和产品方案会相互影响
技术方案可能导致项目风险
例外情况
产品经理是否要关注技术方案
理解程序设计的基本逻辑
重点是理解程序设计的基本原理
理解一门编程语言
理解数据库及表结构
掌握并使用SQL
网络与通信原理、操作系统原理、微机原理
了解网络通信等计算机常识
《编码——隐秘在计算机软硬件背后的语言》
推荐资源
具备基本的技术知识体系
Modeling View Controller的缩写，即数据模型、前端交互视图、业务逻辑
任何一套软件系统运作的本质都是相同的，用户在前端交互层操作后，系统通过业务逻辑层处理数据层的数据
负责绘制程序界面，完成程序和用户的交互互动
前端交互层
应该尽量将复杂的校验、判断、业务规则都封装在业务逻辑中
前端交互的负担更轻，更容易扩展
业务逻辑层
包括结构化与非结构化数据
数据层
了解程序设计的MVC范式
接口调用方会一直等待被调用方返回执行结果
同步调用模式
接口调用方给被调用方发出指令，但不会等待结果
一般耗时较长的处理工作会采用异步，提供回调接口
异步调用模式
熟悉接口与调用模式
如果不能将软件分解成像积木那样的小模块，系统将彻底丧失灵活性
SOA和微服务本质区别不大，微服务鼓励去中心化，前者有服务编排管理（ESB）
搭积木设计
与ER图呈现的一致
数据库表设计
理解数据库表结构
使用正确的语法函数
语句尽量简单
建议
SQL查询语句
掌握数据库与SQL
B端产品经理的技术知识要求
B端产品经理与技术方案
总体建设流程需要借鉴软件工程自顶向下的设计思路，从抽象到具体逐步展开工作
分为业务问题诊断、设计解决方案、执行并优化解决方案三大阶段
全面研究并理解业务的现状和规划，挖掘并总结业务问题
角色访谈
邀请技术负责人参与业务调研
尽可能收集业务关键信息
业务调研
讲究体系性、结构性
核心业务流程
产品定位
应用结构
功能模块
演进蓝图
包含内容
产品整体方案设计
数据建模，是细节设计的最重要环节，保证产品设计严谨可行的关键工作
角色与流程设计
界面与报表
产品细节方案设计
技术方案设计
往往涉及多个业务部门，需要多个业务系统的跨端配合，如何推进跨端项目？
如何保证项目如期高质量交付
项目管理与实施
产品经理、产品运营、业务运营三者的工作内容分配
运营迭代
B端产品的总体建设流程
B端是为了解决业务问题而设计，起点是进行业务调研，研究业务问题
C端要实现公司商业模式的落地，承载公司的商业目标，设计的起点是商业模式本身的分析与研究，包括市场分析、客户群分析等
设计起点不同
最小可行产品，共性是先做加法，充分讨论、穷举所有需求和可能性，再做减法，选出最核心的需求点，最后设计并落地
B端产品要支持业务整体运作，所以在选取最小功能集合时，即便再简化也要保证一个核心业务流程的运转
C端产品需要解决用户痛点，需要挑选一个核心痛点去打动用户，MVP可能只包含一两个功能点
MVP思路不同
B端关注建模、抽象、角色、权限等问题
C端关注用户体验，需要在交互设计上投入很大精力
细节设计不同
B端上线后要进行全员宣导培训，运营相对简单
C端需要上线后由运营团队持续推广
对运营的依赖程度不同
B端产品与C端产品建设流程的区别
B端产品建设概述
明确调研目标
高管，了解业务战略定位、战略目标等信息
经理或负责人，了解业务的管理思路、经营思路等信息
一线业务人员，获取作业过程、操作细节等信息
选取调研对象
定性法和定量法
确认调研方法
执行调研计划
主要目的是掌握业务情况、诊断业务问题
总结归纳输出
B端业务调研的流程
梳理业务现状、总结业务问题
战略定位会决定具体的经营策略，影响产品方案设计
战略层
客群定位、定价策略、营销策、渠道管理策略、供应链管理策略等
经营策略
集团对下属企业的集权、分权管理策略
管控模式
战术层
梳理组织架构，对组织架构做出优化
明确人力资源计划，从管理角度保障上层策略的落地
管理层
梳理具体业务流程是理解并掌握业务的重要途径
运营层
执行层
B端业务调研的目的和分析框架
想清楚要通过访谈对象了解什么，明确目的
准备好访谈大纲
从概览到局部，从全局到细节
有利于抓住关键问题
从高级别人员开始访谈
对方可能是项目的利益受损方，可能会得到很多干扰信息，对决策和判断产生影响
提前研究访谈对象
借助访谈机会拉进和业务人员的距离，便于后续获取最真实的一线反馈
和访谈对象保持联系
4.3.1 深度访谈
产品最忌讳凭自己的主观感觉进行设计，脱离实际
需要不断和客户沟通、确认，或者直接和客户一起工作，看遇到了什么问题
如果不能投入一线，产品经理的价值将会大打折扣
4.3.2 轮岗实习
控制问卷长度
问卷开头告知问卷设计的目的、预计占用时间
活动礼物
激励用户完成填写
建议大部分使用封闭式选择题
问卷结尾留一到两个开放式问题
谨慎思考每个开放式问题的意义、目的
控制好开放式和封闭式问题
尽量采用中性描述
不要设置非此即彼的问题
可以提供多个描述主观感受的选项，并采用平均切分
避免诱导性问题
提前分析和选择合适的样本，可以反馈真实情况
谨防幸存者偏差
4.3.3 调研问卷
4.3.4 数据分析
研究针对业务相关领域的经典管理案例
研究市面上同类业务的商业软件特点
4.3.5 行业研究
B端业务调研的方法
B端调研目标是分析业务现状和问题，为方案设计提供支撑，最终解决企业的业务问题，提升效率
C端直面终端用户，目标是获取真实有效的用户需求和体验感受，以便以此设计解决方案，最终实现商业诉求
4.4.1 调研目标不同
B端用户是一个组织或机构，调研对象要涵盖组织机构中的不同人员，关键角色全覆盖
C端用户是独立个体，主要基于用户细分和用户画像的代表性用户
4.4.2 调研对象不同
B端的竞品分析是选做的，业务流程、模式不一样导致需要的系统也不同，很难从公开渠道获取、分析竞争对手的业务运营管理机制
C端必须做竞品分析，和同类产品来瓜分用户
4.4.3 调研方法略有不同
B端与C端产品业务调研的区别
B端产品的业务调研
是业务的主干脉络
需要思考业务的各个参与方、涉及的系统
说清楚产品针对谁提供什么支持
是产品概要性的总结和陈述，包括支持范围和功能目标
产品定位
指公司所有产品和系统的整体结构和布局
要考虑如何与现有系统架构融合，不同模块之间如何衔接
应用架构设计
思考业务场景和用户可能的操作
功能模块图是一副完整的规划蓝图，是系统的骨架
常见问题是模块层次混乱，以及后来新增功能的随意摆放
功能模块设计
做减法，确认产品的功能规划与实现节奏
一期聚焦解决最基本的业务流程、核心痛点
二期聚焦解决部分特殊业务刚性诉求
用户体验设计层次：表现层、框架层、结构层、范围层、战略层
遵循自顶向下
演进蓝图设计
B端产品的整体方案设计
《产品经理升级之路》决胜B端之设计篇
0 条评论
回复 删除
下一页
