Evernote Export
场景的定义
场景(Scenario)本来是一个戏剧领域的词，意思是"剧情概要"，也就是用简短的话描述发生了什么事。
场景的概念用到交互领域，是由Rosson和Carroll在他们的著作中《可用性测试：场景基础上的人机交互》里提出的
将设计工作的焦点从定义系统的操作转变到描述什么人将使用该系统去完成其任务，DOS操作系统用户需要记住很多命令去完成实际操作，诸如此类的命令符才能完成操作
以场景为中心就是人的需求为中心，以人为本，判断一个设计的好坏是看设计的方案能否帮助用户去完成想要的操作，场景处理是发掘用户想要完成的操作
好的设计解决问题，场景是在帮助设计师解决问题，交互设计是抽象需求转换为界面的，需求来源于生活
场景=特定类型的用户(who)在某某时间(when)，某某地点(where)，周围出现了某些事物时(with what)，萌发了某种欲望(desire)，会想到通过某种手段(method)来满足欲望
4WDM
eg：白领小美(用户)在周五晚上(时间)，回家的地跌(地点)，收到了备忘录的提示(出现某物)，想起来要购买周末在家做饭的食材(欲望)，于是打开春播应用(手段)挑选
若干个机会点
在地跌上，可能需要进行单手操作，另外信号可能不稳定，需要注意无线网络等情况的提示
小美有周五购买周末食材的习惯，应用在周五晚上推送的转化率会比较高
小美设置了备忘录，说明她应该经常使用某某应用购买，可以根据购买历史进行推荐
场景定义
添加“商品列表按照价格从低到高进行排序”的需求
刚开始工作的小美(用户)在吃过晚饭后(时间)，在家里的沙发上(地点)搜索某品牌的体恤衫，看到排序按钮(出现某物)先看看这个牌子的最便宜的T恤衫是否喜欢(欲望)，于是按价格从低到高(手段)筛选后继续浏览
设计机会点：
按价格排序的用户在我们设计的应用里多么？如果多，那么意味着用户需要经常操作，所以在设计的时候需要把入口放的明显一点，容易操作
场景的分类
场景的类型：用户场景(客观场景、目标场景、实际场景)，硬件场景(硬件自身的场景)
客观场景：就是用户在生活中遇到的真实情况，一般多是问题的概括，一般来说，客观场景用于发现新需求，也用于了解我们的用户
目标场景使用最多：描述用户使用的产品，来满足他在客观场景中的目标
实际场景：形成产品的适用性评价
场景的应用
确定目标用户
先描述出客观场景，然后找到目标场景，最后在实际场景中进行测试
车载辅助系统：假设某设计团队找到需求，提升司机用户体验的需求
第一步：体验司机身份
人-车关系的生命周期
| 周期 | 行为环节 | 客观场景 |
|---|---|---|
| 使用车辆 | 进入车辆之前 | 目的地及行程规划 |
| 使用车辆 | 进入车辆之前 | 同行车辆联系沟通 |
| 使用车辆 | 进入车辆之前 | 出行前准备(相关信息了解及服务预订等) |
| 使用车辆 | 进入车辆之前 | 远程控制车辆(热车、开窗、空调预热) |
| 使用车辆 | 取车 | 停车场找到车辆 |
| 使用车辆 | 取车 | 出发前的车况检测(抽屉、电量、车况) |
| 使用车辆 | 取车 | 支付停车费并离开停车场 |
| 使用车辆 | 驾驶车辆 | 跟随导航行车 |
| 使用车辆 | 驾驶车辆 | 车辆驾驶控制 |
| 使用车辆 | 驾驶车辆 | 路况了解及线路调整 |
| 使用车辆 | 驾驶车辆 | 轻微故障处理 |
| 使用车辆 | 行车过程娱乐 | 音乐收听 |
| 使用车辆 | 行车过程娱乐 | 电台收听 |
| 使用车辆 | 行车过程娱乐 | 视频观看 |
| 使用车辆 | 行车过程通讯 | 来电处理 |
| 使用车辆 | 行车过程通讯 | 信息处理 |
根据客观场景，发掘目标场景
“先发散后收拢”的梭形
产品需求-场景发散-设计方案
将自己代入场景，体验类似的产品或功能，寻找类似的场景，从而获得目标场景的信息
确定客观、目标、实际场景的时候，注意分清主场景和次场景
人数：预估此场景的使用人数规模
频率：预估此场景的用户活跃度
重要性：用户对此场景感性主观上的评价
满意度：用户对目前使用方式的满意度
易用性：用户目前的使用方式的痛点有多痛
意愿性：用户将来的使用意愿