《构建之法》第十章 典型用户和场景

摘至 邹欣《构建之法》一书，以作学习之用

典型用户和典型场景

开发一个软件时，我们都知道要为用户考虑，但是用户在哪里？

由此可见，光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！不能光根据用户的语言就匆忙做决定

---

Visual Studio的典型用户

微软在Visual Studio2005设计阶段使用的几个典型用户（Persona）

---

典型用户的价值

所谓“Persona”，就是典型用户。在产品开发的过程中，我们经常需要描述一组典型的用户。以前大家通常是以一些抽象的名词来表示用户，如“家用电脑初学者”、“经验丰富的系统管理员”，现在我们建议用一个“典型用户”来代表。典型用户不再是一个抽象的概念，而应该是一个活生生的人物

典型用户一般有哪些特性？一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境

在设计软件的过程中，我们（设计/开发者）往往会以自己使用产品的习惯和对软件行业的熟悉程度出发设计，忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下，搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发

---

怎样定义典型用户

怎样才能定义典型用户呢？我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。如果用户有不同的安全需求，切记要定义不同的角色来适应这些需求。如下面的例子：

• 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”

• 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的

典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户

---

从典型用户到场景

有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的（如：购物、卖产品、滥发广告……）。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事（Story）。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。下面是现实生活中一个银行从业者发的一条微博，他体会了“ATM无卡取现”功能的强大：

特意带上手机和令牌不带银行卡，感受一下我行ATM的无卡取现，结果连自助银行的门儿都没进去，不刷卡怎么开门啊……

如果这一重要功能的设计者在做需求分析的时候就模仿用户，设计场景，实地演一次戏，很快就能发现戏演不下去了

场景怎么写？

• 首先针对每一个场景，设计一个场景入口（描述场景如何开始）

• 接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）

• 然后给场景划分优先级，按优先级排序写场景

场景之间如何区分呢

• 找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素
• 把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础

---

例如：
场景

工作项序号128：商户上货，最后修改时间：2007/3/1

1. 背景
1）典型用户：吴小石头[主要]、刘兰[次要]

2）用户的需求/迫切需要解决的问题

• a. 吴小石头：上货过程冗长，要反复输入相似的文字，出错之后不容易恢复

• b. 吴小石头：上传图像文件较慢，各个图像的标定（正面、侧面、缩略图）较繁琐

• c. 吴小石头：上货完成后，最后的商品信息展示的整体效果事先无法知道。还要手工标注哪些是新产品，哪些是老产品

3）假设：

• a. 商品信息展示功能已经完成
• b. 用户订阅某个商家的产品更新功能已完成

2. 场景
关于这个场景的文字描述
吴小石头要把最近处理好的两个石头工艺品放到网上去卖。他先登录Stone网站，如果他设置了“记住我的登录信息”，Stone网站会自动登录
他点击“上传产品信息”，然后就进入了上传页面。页面中各个字段的布局和最终用户看到的一样，这样他在编辑时就知道效果了
他可以选择先上传图像文件，网页可以自动开启后台程序处理图像文件的上传，这样当他