中台设计 - 场景服务
场景化服务设计
场景在应用层的定义
我们在应用中通常提及的场景可以这么理解：
某个角色（who），在某种场合下（when & where），出于某种目的（why），利用一系列工具方法（how），完成一系列事项（what）。
| who | when & where | why | how | what |
|---|---|---|---|---|
| 护士 | 早上在分诊台 | 完成工作 | * 查看挂号信息 * 查找复诊病例 * 确认医生上班 | 分诊 |
| 程序员 | 在工位上班 | 产品上线 | * 看看bug描述 * 尝试复现问题 * 设置断点 * 增加日志输出 * 上网查找相似问题 * 复制粘贴“解决问题”的代码 * 检查问题解决没有 * ... | 修正一个bug |
| 思考 | ||||
| 想想自己，一个真实的人 | 明确的空间和时间范围 | 目的单一 | * 下意识的做 * 无固定模式 | * 关注短期结果 * (忽略)长期价值 |
在场景中挖掘真实目的
很多时候做产品设计，喜欢从系统角度去分析描述用户的目的。但真实世界中人的目的和系统描述的目的是不同的：
- 人的目的 - 自生自发
- 系统的目的 - 加入了管理诉求
从上面的表格中能看出：
系统描述的“目的动机”，更像是what这一列的内容，而人的目的往往更纯粹更直接，俗称“人性”。
处理真实的目的，可以发现两个特征：
- 尝试帮助用户达成目的，需要针对性的开发how这一列中的工具和方法组合，不存在一种完全通用型的方案
- 达成目的的路径有很多种，也会很长，但目标只有一个
总结一下：
- 工具方法开发是内容导向的
- 路径开发是结果导向的
再通俗一点，工具方法可选越多越好，路径越短越好。那么解决一个目的，其实工具方法是要运营的，路径是傻瓜化的（机器自主学习的）。
几个还不错的例子
捷径（IOS）
捷径是原来IOS平台的独立应用Workflow，后来被苹果收编了，从名字就能看出这是一个以流程编排为基础的应用。
捷径中心
IMG_2267.PNG
捷径概要
IMG_2268.PNG
捷径详情
IMG_2269.PNG
<br />这是一个很好的工具和方法库，以自定义和共享的方式让用户找到某个场景的解决方案；但整个应用解决的其实都是客户的一类目的：提升效率。
来看一个真实的捷径例子：
| 名称 | 泡茶计时器 |
|---|---|
| 依赖系统应用 | 无 |
| 捷径中心分类 | 早间日常 |
| 步骤 | 1. 选择茶的种类 2. 系统根据种类自动给出冲泡时长 3. 自动开始计时，结束时震动提示 |
这个应用面临的真实场景是：用户想喝茶，（却又不知道怎么泡茶最科学？！）
所以单纯从这点上可以看出，这个捷径其实只是解决了部分how的问题，而对于when \ where（什么时候喝在哪喝）只是给出了一种类似价值主张的建议——把这个捷径归到了“早间日常”中。
表面上来看，who 和 what 并没有直接体现，但是从运营的角度，这个恰恰是体现数据价值的地方：
- 谁，喝了什么茶？
- 茶的时长设置是否合理？
在数据运营的驱动下，这种带有明确场景目的的数据可能才是其真正的价值。（纯属猜测）
捷径的延伸
从上面的例子不难看出，系统帮助达成的目的只是用户目的（喝茶）的一部分，那么如果把“选择茶的种类”的前置环节也考虑进去，这个捷径就有了统一的输入。
借鉴小米最近搞的小爱Siri联姻行为，捷径可能会变成IOS生态连接真实用户场景的桥梁。
当你用一个智能茶壶泡茶时，捷径直接给出泡煮的定时，并链接到你的下一个场景...
Fabulous（IOS）
Fabulous是一个以习惯养成为目的的应用，看上去和捷径有一丁点像，它：
- 更封闭（体系化知识）
- 更简单
它把人的另一种本性也暴露了出来：对自律的渴望 VS 自由的天性。虽然可讲的点很多，但这里就不赘述了。
IMG_B353A7802087-1.jpeg
借用大师的眼光来看场景设计
乔帮主和张小龙的代名词我理解是偏执和善良，看似和产品设计没有什么关系，但是其实都在强调那个why的问题？
- 为什么做这个产品？
- 需要坚持什么？
- 用户感受到了什么？
所谓的深度，是忘掉表面的、容易看到的、执行层面的，剩下的那些。
回到场景设计这个话题下，我们可以借鉴性的来回顾那几个要点：
- 强调why，但不要刻意，因为用户的目的具有不确定性、随机性，也很单一。
- 为 who \ where \ when 找入口，善意的为用户考虑。
- 弱化how，为用户屏蔽用什么工具、参考什么经验；除非用户想要。
- 把确定性的，有价值的what传达给用户。（说到这里，我有点理解张小龙说的推荐问题：用户需要的是不断优化的场景和事实结论；而不是不成熟的推荐）
场景在平台层的定义
| who | 产品假设 | 用户画像 |
|---|---|---|
| when / where | 产品设计 | 场景分类、入口（支持API） |
| how | 服务化流程 | * 用户行为流、系统数据流 * 服务编排能力 |
| what | 数据及交互设计 | * 数据采集、内容沉淀 * 交互反馈 |
| why | 学习型匹配过程 | 构建 - 发布 - 匹配 - 执行 - 迭代 |
在平台设计中参考这个框架，系统的描述场景、解决方案以及用户反馈，也许才是真正解决用户目的的唯一路径。
手稿附件
场景服务设计手稿.JPG
