场景化服务设计

场景在应用层的定义

我们在应用中通常提及的场景可以这么理解：

某个角色（who），在某种场合下（when & where），出于某种目的（why），利用一系列工具方法（how），完成一系列事项（what）。

who	when & where	why	how	what
护士	早上在分诊台	完成工作	* 查看挂号信息 * 查找复诊病例 * 确认医生上班	分诊
程序员	在工位上班	产品上线	* 看看bug描述 * 尝试复现问题 * 设置断点 * 增加日志输出 * 上网查找相似问题 * 复制粘贴“解决问题”的代码 * 检查问题解决没有 * ...	修正一个bug
思考
想想自己，一个真实的人	明确的空间和时间范围	目的单一	* 下意识的做 * 无固定模式	* 关注短期结果 * (忽略)长期价值

很多时候做产品设计，喜欢从系统角度去分析描述用户的目的。但真实世界中人的目的和系统描述的目的是不同的：

从上面的表格中能看出：

系统描述的“目的动机”，更像是what这一列的内容，而人的目的往往更纯粹更直接，俗称“人性”。

处理真实的目的，可以发现两个特征：

总结一下：

再通俗一点，工具方法可选越多越好，路径越短越好。那么解决一个目的，其实工具方法是要运营的，路径是傻瓜化的（机器自主学习的）。

捷径是原来IOS平台的独立应用Workflow，后来被苹果收编了，从名字就能看出这是一个以流程编排为基础的应用。

捷径中心

IMG_2267.PNG

捷径概要

IMG_2268.PNG

捷径详情

IMG_2269.PNG

<br />这是一个很好的工具和方法库，以自定义和共享的方式让用户找到某个场景的解决方案；但整个应用解决的其实都是客户的一类目的：提升效率。

来看一个真实的捷径例子：

名称	泡茶计时器
依赖系统应用	无
捷径中心分类	早间日常
步骤	1. 选择茶的种类 2. 系统根据种类自动给出冲泡时长 3. 自动开始计时，结束时震动提示

这个应用面临的真实场景是：用户想喝茶，（却又不知道怎么泡茶最科学？！）

所以单纯从这点上可以看出，这个捷径其实只是解决了部分how的问题，而对于when \ where（什么时候喝在哪喝）只是给出了一种类似价值主张的建议——把这个捷径归到了“早间日常”中。

表面上来看，who 和 what 并没有直接体现，但是从运营的角度，这个恰恰是体现数据价值的地方：

在数据运营的驱动下，这种带有明确场景目的的数据可能才是其真正的价值。（纯属猜测）

从上面的例子不难看出，系统帮助达成的目的只是用户目的（喝茶）的一部分，那么如果把“选择茶的种类”的前置环节也考虑进去，这个捷径就有了统一的输入。

借鉴小米最近搞的小爱Siri联姻行为，捷径可能会变成IOS生态连接真实用户场景的桥梁。

当你用一个智能茶壶泡茶时，捷径直接给出泡煮的定时，并链接到你的下一个场景...

Fabulous是一个以习惯养成为目的的应用，看上去和捷径有一丁点像，它：

它把人的另一种本性也暴露了出来：对自律的渴望 VS 自由的天性。虽然可讲的点很多，但这里就不赘述了。

IMG_B353A7802087-1.jpeg

乔帮主和张小龙的代名词我理解是偏执和善良，看似和产品设计没有什么关系，但是其实都在强调那个why的问题？

所谓的深度，是忘掉表面的、容易看到的、执行层面的，剩下的那些。

回到场景设计这个话题下，我们可以借鉴性的来回顾那几个要点：