业务设计认知
业务设计的整体框架：
《用户体验要素：以用户为中心的产品设计》提出了用户体验设计的五层十要素。
业务定义：由用户发起并由系统执行的有结果的商业活动：
- 一项业务是有流程的
- 定义了用户的服务和员工的工作
- 互联网产品是在重构业务
业务设计的挑战：
- 没有考虑内部业务设计：用户体验未包含内部业务
- 没有考虑业务流程设计：以用户为中心的设计对流程强调的不够多，更多强调的是页面设计和简单的交互设计
以业务为中心的产品设计四层次
1 定方向
- 产品战略（明确要进入的市场、要服务的用户和要做的产品范围）
- 战略分析与设计：战略分析描述事实，战略设计根据事实明确产品范围
- 目标设定：企业宏观的指导方针（盈利/增长、成本领先/差异化、进取/求稳）
- 战略实施：执行/协调/监控/调整
- 解决方案（先做什么、后做什么）
- 梳理所有的涉众
- 梳理涉众的期望
- 确定产品的价值
- 确定需求的排期
2 搭框架：功能框架、非功能框架
- 功能框架对功能做挖掘和限定（用例图）
- 避免遗漏需求
- 梳理功能需要有层次
3 做细节：业务流程（流程图）、业务操作（状态图）、信息结构（类图）
4 画界面：交互设计、信息设计
定方向
产品战略
- 战略设计
- 明确产品为谁而做、产品做什么、不做什么
- 通用分析模型：通常作为分析的起点。SWOT、PEST
- 从竞争角度分析：优化企业、击败对手，硬碰硬地战胜对手。波特五力模型、波特钻石模型
- 从差异化角度分析：用户驱动、解决需求，避免硬碰硬的竞争
- 蓝海战略（强调产品的功能或服务要有差异化。重新构建市场边界，绘制战略布局图，超越现有需求，合理安排战略顺序）
- 特劳特的定位理论（从用户的心智出发找到定位）
- 破坏性创新：积极探索、另辟蹊径
- 克里斯坦森的创新窘境理论
- 推动一个刚出现的市场的增长率提升
- 等破坏性创新的市场规划变大后，快速跟进
- 成立一个独立的机构来开发新技术和新市场，避免公司价值观和文化影响新技术和新市场的发展
- 4P理论(Product, Price, Place, Promotion)
- 目标设定
- 企业的指导方针
- 要盈利还是要增长？
- 是成本领先还是差异化
- 成本领先战略
- 差异化战略
- 专一化战略：聚焦某一细分市场
- 是积极进取还是求稳定
- 导入期用探索战略
- 增长期用增长战略
- 成熟期用稳定战略
- 衰退期用收缩战略
- 战略实施
- 强调执行力
- 做好产品设计和开发，做好对外宣传对内协调等
- 执行过程中，还要做战略的监控和调整
机会的评估模型：
- 领域内的机会
- 市场吸引力：市场规模、用户数目、市场增长率和市场潜力
- 新产品的机会：重大环境变化（PEST）、新技术的回报、要求的技术水平（技术开发难度和风险）
- 公司的优势
- 发挥技术优势：研发、生产优势
- 发挥营销优势：销售/渠道优势、广告/营销优势
- 发挥差异优势：巨大的提升、差异化的竞争力
机会的评估方法：
- 评估产品的机会：通过机会的评估模型评估
- 明确产品的目标：理解企业购买产品的目标，从而以目标为导向设计产品
- 开发方目标
- 购买方目标
产品方向评估表：
解决方案
每个模块的解决方案都要解决用户的问题，给用户创造价值。步骤如下：
1 梳理所有的涉众-如何找到涉众？
- 公司角度：公司的客户、公司的组织架构、公司的合作伙伴
- 系统角度：谁使用、查看、维护和使用系统？
- 业务流程角度：现有的主要业务流程是什么？在主要的业务流程中，都有谁参与？
2 梳理涉众的期望
- 挖掘涉众（基层、中层和高层）的工作职责和成功标准
- 先问有哪些业务、再问业务类型、最后问期望
- 针对高层决策人，强调产品的高价值；针对中层管理人，强调产品的意义，如果帮助其完成业绩；针对基层执行人，要良好地沟通，同时评估需求价值，甄别价值不大的需求，避免盲目满足
涉众工作职责简表和详表:
涉众期望调查表:
3 确定产品的价值
- 对企服行业企业的价值：提升人效、降低成本、改善服务、减少差错、提升业绩
- 对使用方的价值：降低劳动强度
4 构建高价值方案
- 什么是解决方案？
- 针对用户的问题和需求，给出的一整套方案，包含产品和服务等（解决方案是从问题出发，目的是为用户解决问题）
- 解决方案是产品、服务等内容的合集（解决方案可能是完整的产品和服务）
- 解决方案从问题出发，而不是从功能出发（解决方案可能是产品的模块方案）
- 构建高价值的解决方案
- 梳理所有解决方案
- 全面的价值点分析
- 明确双方（开发方和购买方）价值高低。只有对双方价值都大，该业务才成立
5 确定需求（研发人员的“期望做什么”，对应用户角度的“我要做什么”）的排期
- 评估需求的价值
- 需求排期的模型：期望程度（必须做，强烈建议做，最好做，待决定），投入成本，迭代因素
- 常见的要延后的功能：逆向流程功能（电商的退货流程等）&非主干流程功能&商业决策和业绩统计功能
- 常见需求排期误区：单纯用重要和紧急程度排期，要结合实现难易程度和投入程度综合排期
搭框架
- 理清业务功能，而不考虑小的功能点
- 理清业务宽度，而不是业务深度
三种主流的搭功能框架方法：用例技术、流程驱动设计、领域驱动设计
用例技术：从用户角度出发，思考用户要做的事，从而做到尽最大可能不遗漏关键的、决定开发成败的需求，并合理划分工作任务。
用户故事是用例的实践、扩充和改造。用户故事和用例是等价的。
用例：
- 对参与者发起的一组动作的描述，系统响应该组动作，并产生可观察到的显著结果
- 是用户在系统上做的事
- 表述为“动词+宾语”
用例的特点:
- 有宽度地梳理业务
- 业务梳理的起点
- 定义功能的起点
参与者：在系统之外与系统交互的人或物。参与者共有两类，一类是和系统交互的人（参与人），一类是与系统交互的系统（参与系统）。
参与人：涉众是对产品“指手画脚”的人（会对产品提意见），参与人是和产品“眉来眼去”的人（和产品进行交互）。
系统：可以由硬件、软件和人组成，大系统中可包含小系统。
分层次细化用例:
- 目标层用例
- 用户在做完一件事后能满意离开
- 员工工作职责是目标层用例
- 表达目标，而不是具体实现
- 实现层用例
- 定义产品实现目标的方法
- 实现层用例是解决方案的子集
- 步骤层用例
- 完成目标所需要操作步骤
- 去掉不必要的步骤
- 可按页面梳理步骤
- 按层来梳理步骤
- 通过步骤层用例的合并划分出设计单元
- 认定原则：大小适中，高内聚、低耦合
层级注意点:
- 思考结构化，但不能过度结构化
- 用例的划分并不绝对
- 层次和数量控制要合适
- 先梳理用例，再提炼设计单元
- 不适合梳理信息和熟悉的功能（适合梳理流程类业务，梳理用例是为了不遗漏需求和功能）
使用用例技术梳理功能框架的操作步骤：
- 找出所有参与者
- 定义出内外系统
- 找到目标层用例
- 思考实现层用例
- 找到步骤层用例
需求的区分:
- 用户需求是用户想要的，用例（用户故事）是用户要做的，产品需求是帮助用户完成所想和所做的
- 凡是能指导开发的，就是产品需求；凡是不能指导开发的，就是用户需求
PURPS+模型:
- 主要需求：功能（动态的交互）、内容（静态的信息）、安全性
- 可用性需求：用户体验、帮助和培训文档等
- 可靠性需求：故障率（MTBF）、维修时间（MTTR）等
- 性能需求：响应时间、并发数、吞吐量等
- 可支持性需求：可维护性需求、可移植性需求
- 其他次要需求：数据分析需求、许可需求、接口需求等
常见安全性需求：
常见性能指标：
常见可支持性指标：
做细节
业务流程
UML活动图（流程图）：为了完成某一特定任务而描述的相关活动，以及这些活动的执行顺序的图形化表示。
活动名称的写法为“主语+动词+宾语”，即人做了什么事。
流程图设计的最佳实践：
- 主流程从上到下，次要流程列两边
- 线条和文字的颜色统一
- 主语单列一行，动词+宾语单列一行
流程图的3个层次：
- 业务流程图：表达的是人和人之间的交互，目标是厘清和设计业务
- 手递手的人人交互（在一个人的一个活动后，必须紧跟另一个人的另一个活动）
- 去掉界面交互
- 去掉系统实现
- 交互流程图：表达的是人和机器之间的交互，目标是指导原型图的绘制
- 涉及规则的步骤要画出来
- 手递手的人机交互（在一个人的一个活动后，系统必须紧跟一个反馈）
- 实现流程图（研发）：表达的是机器在做什么，且表达的内容不可被用户感知，目标是设计软件
- 哪些内容可以在交互流程图中表达：界面层、规则层和数据层
用流程图梳理业务的步骤：
- 画主流程：先粗后细，加入分支
- 完善细节：加入异常，拆出流程
- 加入泳道
用流程图梳理异常（思考异常检查点，要从活动和角色两方面思考）：
- 规则限制：可逐一查看数据库字段，从而找到异常检查点
- 不操作、或操作慢
- 操作错误（交互流程图特有）：输入错误、反复输错、反复点击
- 做完反悔：过程中反悔、全做完后反悔
业务操作
流程图梳理的是一项业务的大致过程，状态图梳理的是一项业务的细致操作。（状态多时画状态图，流程多时画流程图）
描述了一个对象所处的状态，以及用什么操作可促成状态的转变。
状态图设计的最佳实践：
- 主状态从上到下画
- 线条和文字的颜色统一
- 状态用“主语+状态”表述（商品已提交），或两个短语表述（已提交，待审核）
- 进行必要的简化
状态的注意点：
- 有对象才有状态
- 表达“一个”状态
用状态图梳理操作：
- 绘制主干的状态
- 进行状态的拆合
- 完善分支的状态
- 完善角色和操作：例如商家、用户、审核人员&系统
信息结构
信息的常见类型：
- 用户角度：用户信息、内容信息、业务信息
- 企业角度：组织信息、资产信息
业务越复杂，越陌生越需要使用类图梳理信息。
类图设计的最佳实践：
- 梳理出所有的类
- 梳理出数量关系
- 明确信息的属性
- 考虑效率和灵活性
类：对具有共性的一组对象的描述，类是对一组具有相同属性、操作和关系的对象的描述。
对象：对象是类的一个实际例子，对现实事务的抽象，是一个具有边界并包括属性、状态和行为的实体。
画界面
交互设计
规则驱动的交互设计最佳实践：
- 字段规则的交互
- 业务规则的交互
- 外围需求的完善
用例文档的要求是“用最少时间，编写最少内容，且该文档能被研发人员快速看完、正确开发”。产品经理要想平衡这个矛盾，就要不断改进工作。用例文档的要素有流程、规则和外围需求。用例文档的表现形式可以是以文本为主，也可以是原型图加备注的形式。
常见的交互事件：鼠标事件、手势事件、键盘事件和焦点事件
字段规则和业务规则：
- 字段规则定义了该字段的格式要求，通常稳定不变，是全局型的
- 业务规则定义了该业务特有的逻辑，表现为不同业务有不同规则，不是全局型的
交互设计的四大原则：
- 反馈原则：对于用户每步的操作，系统都要及时反馈
- 防错原则：在错误发生之前，就防止用户出错
- 撤回原则：在操作错误发生之后，提供撤回的功能
- 容错原则：指出错误并给出建议，降低用户损失
交互设计的外围需求：
- 前置条件：用例能执行的前提，常见的是是否登录和网络情况
- 后置结果：系统在用例完成后要做的事，包括跳转的页面、创建的数据和进行的操作
- 最小保证：即使用例未完成或发生意外，系统也要做的事。最小保证强调了在非正常情况下出现的结果，包括保留信息和记录日志
信息设计
B端信息设计涉及的页面主要包括列表页、表单页、详情页和组织这些页面的导航；列表页又可分为内容类（商品列表页）、审核类（商品审核）和服务类（订单列表页）。
列表页可分为三个区域：筛选区域（根据业务添加）、查看区域和操作区域；筛选区域又分为Tab导航和筛选项；查看区域又分为列表区域（识别、决策和操作）、排序功能和分页区域；列表页的扩展功能有信息的通知和列表页信息的导出。
业务驱动的BSSP（Business, Scene, Solution, Page）设计方法（目标：挖掘出业务需求）：
- 梳理业务：明确给谁做，要帮助对方达成什么目标（用户画像、业务目标）
- 梳理场景：基于业务梳理场景（用户故事、用户场景）
- 设计方案：思考用什么方案来满足用户的场景需求
- 设计页面：帮助用户决策并完成业务（闭环设计、信息设计）
拓展：应用和思考业务设计
业务调研和业务设计
业务调研的目的：
- 构建商业模式
- 吸引并服务用户
- 构建业务流程
业务调研的方式：
- 查看行业资料（工作职责文档、SOP（Standard Operating Procedure）文档）
- 开展用户访谈（围绕业务的期望、价值、流程和问题方面展开访谈，了解细节）
- 进行观察和实操
- 进行竞品调研
业务访谈：从主澈咄发，不断追问细节，并明确问题
- 目的：梳理业务流程、发现业务痛点，最终设计出新的业务
- 内容：用户提出的痛点问题，以及要提升的价值点，如服务、效率、成本等价值点
- 提问技巧：先主后次，场景代入，用对方工作的专业词，不用产品的专业词
- 访谈记录：包含访谈中总结出的业务流程、信息结构、消息传递等内容
- 产出：用户访谈详表和用户问题列表
灵活运用设计模型
- 用例驱动设计：先梳理业务用例，该方法适合中型系统
- 流程驱动设计：先梳理业务流程，该方法适合中小型系统
- 领域驱动设计：先梳理业务的信息结构，该方法适合行业系统
用例和用户故事
用户故事：描述了对用户、系统或软件购买者有价值的功能
- 一份书面故事描述，用来做计划和作为提示
- 有关故事的对话，用于具体化故事细节
- 测试文档，用于表达和编辑故事细节，也用于确定故事何时完成
用例：对参与者发起的一组动作的描述，系统响应该组动作，并产生可观察到的结果
- 用户故事和用例都在描述功能
- 用户故事用文字描述功能，而用例用图形描述功能
- 用户故事侧重挖掘需求，用例侧重梳理软件设计问题
参考
版权声明：本文为博主原创文章，转载请注明出处。 旭日酒馆