后台产品设计路线；结合用户旅程及scrum方法
背景介绍
应公司运营业务的增多，提升运营活动发布效率、用户精准度的要求。
产品定义
满足运营活动发布需求，提升发布效率、用户精准度。
设计及落地流程叙述
一、确认需求
1、在确认需求前，需要先了解需求方及关键人是谁。
比如在这个案例中，在运营中台的直接需求方是运营部门，但是运营暂时归属产品部门管理，那么间接需求方、关键人还应考虑产品部的负责人，比如产品总监的对中台的要求。
2-分析运营中台这个产品，有什么特点， 特征
A、管理型工具产品；
B、与用户终端关系紧密，偏前端控制。
3-业务规则、模型是核心，重点。
运营人员可能是一口气表述出自己的所有需求，想法丰富但可能杂乱，产品对需求方提出的需求进行分析，与需求方确认需求，记录确认的需求。也需通过手绘低保真形式，浏览其他产品案例等形成引导用户思考，表达自己想要的。
然后产品需要与需求方确认核心业务及规则（模型），表现形式，作为首要商讨梳理部分，纳入基础backlog。
纳入的backlog需求需要明确什么运营位展示给用户，是什么目的，可以带来什么收益？
这个是核心中的核心，需要集中花精力尽早确认落实。
注意：专业名词上需要达成理解一致，确认名词唯一的描述。
示例：
4-梳理用户业务流程
以确认的需求为基础，整理出用户业务旅程。更多确认的需求归属在对应的流程点下（类似卡片分类）。并留档。对于不确定的归类做出标记，后面再讨论。
5-形成用户业务旅程，和用户确认。
（1）编写用户故事，编写用户故事，尽可能多的故事。
（2）查漏补缺，联合测试，需求方，研发共同，考虑异常，极端情况，梳理处理流程，进一步补全用户故事。
6-质量保证思考
引导用户给出对产品质量（多指产品运行，运转压力方面等）方面的期望，完善用户故事。
7-核心业务mvp设计验证
制作核心业务的低保真原型和用户确认页面功能，信息及页面流程。
低保真要尽量简单，快速成型。一个矩形+页面名称+功能名称+信息名称+页面链接即可。
8-制作核心业务中度保真图
用户操作使用，作为真实使用的初步验证。判断是否要调整用户故事，界面设计。
涉及需求分析，更多参考需求分析相关，及scrum相关进行思考。
二、进入开发前的准备
1-版本迭代规划
（1）产品结合用户在描述故事的情况，产品给出史诗范围，版本假设，基本，增强.....对应一个或者多个版本文档（不一定要在jira或者管理系统中操作，可以以表格文档形式讨论，修改方便，个人建议）。
（2）与需求方，研发，共同商讨确认，史诗范围，发布版本、sprint阶段包含用户故事。
这个步之前，可以把用户故事录到系统，可以利用系统的便利性在，系统中挑选。参考之前完成的卡片分类层级划分。
之前提到用户故事要尽可能的多，全。为了是，用户和研发人员从需求优先级、架构设计上选取适量、合适的故事方式sprint中。
注意：用户故事的编写是重要的，可以结合用户故事写在原则及公司开发基础，按实际情况编写。用户故事在选取过程中可能会删除过小的故事，组合到另一个关系紧密的故事中，也可能将故事拆分到几个小故事。可以和开发同学一起商量而定，进行故事的调整。
例如参考：
2、文档整理
（1）梳理功能架构，业务流程，核心功能流程，异常流程，全局通用规则，交互说明文档。
（2）制作完整低保真原型，按sprint的完整设计并演示，与需求方、研发确认。
3、识别任务开发方及关心内容
（1）运营活动载体客户端 样式，位置，显示效果，站内交互，极端（上限，空状态）情况。ui配合做高保真效果图。
（2）载体服务端 运营位可以出现页面及参数，过完故事后，确认sprint后商讨提供——过需求时，双方了解到的信息一致，形成约定。输出接口文档。
（3）中台服务端 向载体服务端请求什么——运营位出现的页面及运营位相关参数;储存什么，数据库构建（数据表结构）;平台功能的逻辑规则，多线操作同一业务时的冲突。服务载体接口字段约定，载体。
4-制作完整低保真原型，文档与需求方，研发确认。
5-制作阶段仿真实案例，高保真完整设计，制作演示脚本及说明
6-模拟真实情况演示设计。
7-查漏补缺，完善设计。
