假设要把《软件方法》的“业务和软件需求分析”，与“用户体验设计”关联到一起，那么可以讲，前者就是提出产品要求的过程，后者就是提出产品解决方案的过程。
在“业务和软件需求分析”的阶段，软件系统用例（何人使用系统做何事的“何事”）是不共用的，即不同角色看起来像做同样的事情，但只要是不同的角色做的事，我们就把这些事区别对待，我们不做归纳设计，而保留原本的做事“要求”要点。
到了用户体验设计阶段，我们采用ajax之父j esse James Garrett的用户体验五要素分层，直接穿透到范围层，开始进行产品需求功能的归纳，以期做出来的产品即符合用户使用，又简约好用，还考虑平衡成本因素。
系统外部表现的功能范围层面，虽然不像内部系统设计一样需要把需求解构成各类组成对象，建立各类组成对象的关联关系，以及将所有的操作，都解构成用户角色和组成对象之间的关系。但是外部表现功能，也需要重新排列组合，即将各功能的能力点打散，归纳，重排。
而范围层，就是解决“打散”，“归纳”的问题。
1. 各角色做的完全相同的事情，可以考虑是否归纳到一起
例如，组织内部人员使用的采集系统，数据采集人员和采集管理人员都可以现场使用系统采集人口数据。软件两个采集人口数据的软件用例，涉及到的采集相关功能，可以归纳到一处。
但是并非所有的情况都可以，假如数据采集人员，和数据采集管理人员，使用的终端，一开始就已经定义成两个终端的话，则我们没有必要去做这样的归纳的动作。
2. 各个角色的操作细节，最终汇集到一处的时候，这一处，可以考虑功能是否可以归纳到一起
例如，我们针对人口采集，做了很多的统计给到领导使用，有每日/周/月人口采集数统计，区域人口采集数统计。
这些统计最终都会下钻到：“根据xx条件详细查询人口”这个子功能。那么查询人口是否可以归集到一起，统一一个人口多条件查询功能？最终即可以满足用户的查询需求，也没有降低系统的使用体验，又能减少系统开发的成本，而且说不定这个多条件查询的功能，还可以有更多的隐藏的用途（当然，这个更多的用途视情况而言，怎么有用，好用，用的爽，还是具体问题，具体分析）
3. 谨慎识别看起来好像相同的操作，实际细节上会有所不同的操作功能，避免归纳之后提高设计的复杂度。
有些操作看似相同，其实细节有一点弯弯绕绕的不同。而因为这点弯弯绕绕的不同，会提高设计的难度，增加用户使用的难度，而且也可能引发开发的难度。
例如，上面的例子，假如“根据xx条件详细查询人口”，在不同的场景下，要体现放大的人口特征有所不同，有些需要放大人口的年龄数据，有些需要放大人口的户籍数据，那么，这几个场景下的“根据xx条件详细查询人口”就不能考虑归纳到一处了。
所以对于细节上有些许不同的操作，要加以辨别：是否归纳之后会“满足需求，超越需求”，如果并不能，而且会引发其他的问题，那么，我们宁可把他们当成两个独立的功能，更易于用户直接操作处理。
4. 归纳，还可以往上归纳一层，对功能做简单的领域分类，形成功能模块。
领域指代“功能涉及的细分业务”，例如任务的处理，安排任务，处理任务等功能，都可以归纳到“任务管理”这个大功能模块里面。领域分类的好处是，为下一个阶段的重排做好准备。
而下一阶段的重排，我们从信息层面和任务层面进行重排。
信息层面的重排，我们称为信息架构。
任务层面的重排，我们称为交互流程。
参考书籍\《用户体验要素》Jesse James Garrett\《软件方法（上）》，作者“潘加宇”
文\帅春风（微信公众号：帅帅春风，产品经理一枚）
网友评论