构建之法阅读笔记4

典型用户分析:

写一个软件的时候要为用户考虑,用户在哪里,有多少用户是团队在需求分析和设计阶段要反复琢磨的问题。

百分之百按照用户要求做是不行的,还要

1、找到用户语言行动背后的动机。

一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。

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

首先要定义用户的角色。
正如戏剧中有正面和反面的角色,软件系统中也有受欢迎的和不受欢迎的典型用户。
如果用户有不同的安全需求,切记要定义不同的角色来适应这些需求。

典型用户模板:

(1)名字(越自然越好)。
(2)年龄(不同年龄和收入的用户有不同的需求)。
(3)收入。
(4)代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要)。
(5)使用这个软件的典型场景。
(6)使用本软件/服务的环境 (在办公室/家里/沙发/床上/公共汽车/地铁…)。
(7)生活/工作情况。
(8)知识层次和能力(教育程度,对电脑、万维网的熟悉程度)。
(9)用户的动机、目的和困难(困难 = 需要解决的问题)。
(10)用户的偏好。

2、决定每一个典型用户的目标

用户使用系统想要达到什么目的(如:购物者,产品提供商,滥发广告者……)对于每一个目标,列出达到目标所必须经历的过程,这就是场景,也可以叫故事。

注意;有些场景描述了成功的结果,有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况,在写场景的时候要有针对性。

(1) 对每一个场景,设计一个场景入口,关于这个场景的文字描述。(描述场景如何开始)。
(2)描述典型用户在这个场景中所处的内部和外部环境(内部环境指心理因素等)。
(3)给场景划分优先级,就按优先级排序。
(4)把场景组织成一个故事,这样就能把一个完整的用户与系统交互的流程记录下来,以后进行演示或验收都可以以此为基础。
3、有了场景,下面就由架构设计师和各个模块的负责人一起,沿着子系统/模块的所属关系把场景划分开。
(1)UI层。
(2)逻辑层。
(3)数据库。

我过去的做法:
 在团队编程练习中,我们所描述的软件完全是按照自己的角度添加功能,没有向用户使用的方向考虑。
这导致写出的软件只是一个编程语言的练习,毫无工程意义。
今后的做法: 
写一个软件的时候要为用户考虑,从用户使用产品的习惯和我们对产品的熟悉程度出发设计,搞一个“典型用户”会强迫在考虑问题时从用户的角度出发。

 

posted @ 2017-12-23 09:37  什么名都不好  阅读(80)  评论(0编辑  收藏  举报