第十章 典型用户和场景
10.1 典型用户和典型场景
①怎样定义典型用户？
我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。
- 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”
- 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的
典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户
②从典型用户到场景
有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。
③场景怎么写？
- 首先针对每一个场景，设计一个场景入口（描述场景如何开始）
- 接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）
- 然后给场景划分优先级，按优先级排序写场景
④场景之间如何区分呢？
- 找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素
- 把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础
10.2 用例
和典型人物、典型场景的方法类似，用例（UseCase）也是很常用的需求分析工具。用例有这样一些 基本元素：
- 标题：描述这个用例要达到的目标
- 角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一些和时间相关的场景时有用）
- 主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的
- 步骤（Step）：描述每一步的交互（例如一套正常的ATM取款流程）
- 扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况（例如取款时账户余额不足）
10.3 规格说明书（Spec）
①规格说明书（Specification）简称Spec，分为以下两种：
1. 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）
2. 软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）
②写好一个Spec
第一，定义好相关的概念
第二，规范好一些假设（Assumptions）
第三，避免一些误解，界定一些边界条件
第四，描述主流的用户/软件交互步骤
第五，一些好的功能还会有副作用
第六，服务质量的说明
第十一章 软件设计与实现
11.2 图形建模和分析方法
思维导图、实体关系图、Use Case Diagram
11.3 其他设计方法
形式化的方法、文学化编程
11.5 开发阶段的日常管理
第十二章 用户体验
12.1 用户体验的要素
用户的第一印象
从用户的角度考虑问题
软件服务始终都要记住用户的选择（长期的使用只会使软件更好用）
短期刺激 长期影响
不让用户犯简单的错误
注重用户体验和质量
情感设计
12.3 评价标准
对于一个软件的用户界面，我们有没有什么评价标准呢？可以参考费茨法则（Fitts law）、Nielsen启发式评估十条原则以及其他经验。下面是邹欣老师在自身实践的基础上总结的一些原则：
1. 尽快提供可感触的反馈系统状态
2. 系统界面符合用户的现实惯例（Familiarity，Avoid Surprise）
与用户沟通，软件系统要使用用户语言而不是开发者语言，所用的概念要贴近生活实际，而不是用学术概念或开发者的概念。我们说的生活实际，最好是目标用户的实际生活体验。
3. 用户有控制权
操作失误可回退，要让用户可以退出软件（很多软件都没有退出菜单，这是导致用户反感的一大原因）。用户可以定制显示信息的多少，还可以定制常用的设置。
4. 一致性和标准化
在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有“帮助用户收集生词并且背诵生词”的功能。这个功能要有明确一致的称呼，不能混杂着叫“单词本”、“生词本”、“Word List”、“Word Book”、“单词文件”……等等。
5. 适合各种类型的用户
6. 帮助用户识别、诊断并修复错误
7. 有必要的提示和帮助文档
不需要文档，用户就能使用自如，当然更好，必要时还可以提供在线帮助。如果软件和用户的工作相关（而不是简单的游戏），那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤，并且不要太冗长。