前文已介绍过了，业务功能分为4大类，其中“活动功能”是界面设计中工作量最大的部分，每个活动功能都是客户一个/类实际工作在系统中的映射，客户对包括对业务处理、管理控制方面的需求、优化、改善等期望等大都包含在活动功能的设计中，因此，活动功能设计的优劣直接关系到整个系统的最终效果。活动功能的设计并不简单，设计结果不但要能做满足客户方面的业务需求、管理需求以及易操作需求等，还要满足软件商方面的结构化、易确认、易开发、易复用等要求。
□ 活动功能设计：是将构成功能的界面格式、控件定义、数据结构、操作方法以及相关规则整合在一起的设计过程。
一、活动功能的概念
□活动：指的是客户的实际工作、行为（注：业务流程上的节点必须是活动）。
□活动功能：除用于维护企业基础数据的“字典功能”外，凡用于输入过程数据的功能都属于活动功能。活动功能具有以下的一些特点（以下简称为：活动）
1）粒度：对一个活动大小的划分参考原则是，这个活动可以
□完成一个独立的、明确的业务目标。
□划分的大小有利于用户的岗位分工安排。
□在满足用户业务需求的同时，也符合系统设计规则、运行效率等方面的要求等。
一个活动的内容多少是由客户的工作习惯与系统处理效率之间的平衡关系决定的，最终的决定需要与用户进行商量决定；
2）功能：活动具有的处理功能主要由两个部分构成：业务处理功能和管理处理功能。
□业务处理：指对业务数据进行输入、计算、查看、展示等的功能；
□管理处理：指对业务处理过程中加载的管理规则，这些规则可以保证数据合乎标准；
3）作用
□对数据的输入，以及包括增加、删除、改变、查询等的操作功能。
□客户业务优化的重要对象之一（另一个是流程优化），良好的设计结果可以带来用户工作效率的提升，同时活动也是设置管理规则的主要载体。用户与设计师的想法大多数都要落实在活动的界面上。
作为窗口式的界面形式，完成一个活动需要两个部分的设计：业务设计、应用设计，下面分别说明这两种设计的内容。
二、业务设计
业务设计是从客户业务处理的视角进行的设计，这个设计的重点在如何将现实的工作反映到界面上来，这是活动设计的核心工作。这个部分设计又可以分为两个层面进行，一是对业务处理层面的设计、二是管理层面的设计。关键点：此时不要考虑界面的实现方法。
1.业务处理层面的设计
业务层面的设计，参考包括客户原始的实体表单格式（或全新设计），进行如下工作
1）业务处理目标的确定、业务内容的规划。
2）界面选型（卡片式、主细表式、树形表式等）、字段的布局等。
2）确定数据定义、数据标准、数据来源、数据算式等。
2.管理层面的设计
为了保证正确地输入数据，需要对数据输入过程加载相关的规则进行监控，这些规则来自于企业的管理规章制度、财务规则、生产的工艺工法要求等（注：数据库规则不算管理要求）。只有加入了这些管理规则，这个系统才能称之为：管理系统。
注：关于业务与管理的区别，请参考博文：“分析方法的基础 — 2.业务与管理的拆分，破解难题的钥匙”一文。
3.业务设计，必须站在用户视角进行
对活动的业务设计要点就是要从“业务”视角看界面，因为用户对系统的认知主要来自于界面，而界面的核心内容是业务数据，因此，界面设计的优劣就直接体现了设计师对用户工作的理解，设计师要把这个界面当做与用户进行对话的“窗口”，设计时要不断地与“窗口后的角色"进行对话，如图1所示。
图1 业务设计与用户的关系
1）对话用户（参见图1-①本功能用户）：
□用户要用功能2完成什么业务内容？
□用户要向他的领导②提供什么信息？
□本功能2与上游功能1、下游功能3之间的数据是什么关系？
□用户①、与上游用户③和下游用户④之间的制约关系（数据层面、管理层面）？等。
图2 业务设计的主要内容
3）对话领导(参见图1-②用户的领导)
□功能2的工作标准什么？已有的业务数据是否满足要求？
□为确保①用户的数据输入正确，需要什么样的管理规则来做保证措施？等。
图3 管理设计的主要内容
4.“功能”与“任务”的区别
可以从图2和图3中看出，业务设计与管理设计关注的重点完全不同。
对一个活动，是仅仅把它当用于“输入数据的界面功能”？还是将其看成为“要完成的工作任务” ？这就看设计师具有什么样的设计理念了，如果是前者，那么关注点放在字段的数量、定义就可以了。如果是后者，则在关注字段数量、定义的同时，还要关注是否对业务进行了优化？工作效率有无提升？管理规则上有无漏洞？等，这些都没有问题时，才能确定字段和定义是否满足要求。
三、应用设计
完成了前面的业务设计内容，应用设计的重点就不在业务内容了（参见图4的核心部分“业务处理区域”），而是要考虑如何构建一个“人-机-人”的工作环境，让用户工作得舒服、操作容易、处理效率高、智能化。应用设计相当于为前述的业务设计成果外包上一层“可操作的功能”，用户是通过这些功能来完成对业务数据的查看、输入、控制等操作工作。应用设计包括了菜单栏、工具栏、滚动条、按钮（增删改查等）、上传/下载、其他链接等。
图4 界面的应用设计内容
可以看出，业务设计的重点（图2、3）与应用设计的重点（图4）的内容完全不同。
应用设计的重点是从“应用”视角对“功能”进行设计，也就是将业务设计的功能内容转换成为用系统的构件进行表达，可以说系统的客户价值大小，用户是通过应用设计成果感受到的，因此应用设计的结果优劣直接关系到客户的满意度。
注1：UI设计、美工设计等，都是应用设计中的一部分。
注2：在实际进行软件设计时，业务设计和应用设计的内容可以“合二为一”一气呵成地完成，但是在学习界面设计方法时，这两个部分应该分开理解、掌握。
四、设计结果验证
对上述的设计结果必须要进行验证，验证方法有两个：业务验证和应用验证。
图5 验证的用例
1. 业务验证 – 编写业务用例
业务用例，是利用业务数据编写出一个相当于数据的故事脚本，这个用例中使用的数据可以将全部需要验证的活动功能关联在一起，然后按照实际运行的流程进行推演，如图6所示，业务用例中的数据要从“合同”流向“交付”（业务流程），同时还要包括相应的管理规则（审批流程）。
2.应用验证 – 编写应用用例
应用用例，是在业务验证的基础上，对操作的过程进行检验，包括：按照流程和角色进行多人协同，操作过程是否易用、输入是否智能化、处理是否会有死循环、系统通知、警告、终止等如何发起生效等。
注3：这里谈到的业务用例和应用用例，与开发完成后检验时使用的测试用例不同
□ 业务/应用用例：是以用户的实际业务处理流程为依据设计，不但有业务数据、管理规则的检查，还要有多功能之间的推送、流转是否顺畅的检查。关注点不是“编码bug”的有无。
□ 测试用例：重点检查功能是否正确、有无编码bug等。不是从“业务、管理、操作性”方面的测试。
五、记录模板
掌握了设计的方法后，最后要说明一下记录方法，对界面设计结果的记录形式非常重要，传统上采用长篇文字进行描述的记录形式比较多。我提倡采用结构化、标准化的记录形式，也就是用工程化的记录形式（如同制造业、建筑业的设计相似），这种形式客户容易理解、确认，程序员容易理解、开发，下面推荐用一组模板记录设计内容的形式，由于模板4个为一组，因此也称之为“设计4件套”，4个模板分别记录了如下内容：
■模板1—界面原型：给出界面业务内容的布局、字段的位置。
■模板2—控件定义：用表格方式记录所有字段的名称、字段内容、相关规则等。
■模板3—规则说明：用文章体的方式对该原型内的复杂规则进行详细的说明。
■模板4—逻辑图形：用图形方式表达该功能内用文字难以说明的复杂逻辑关系。
图6 设计结果的记录模板（设计4件套）
顺便说一句，利用这种方式记录非常容易开发出一套软件设计辅助记录系统，这也是结构化记录格式带来的优势。
■小结
可能不少人都有这样的想法：活动功能用的界面设计最为常见，没有什么难的地方、也没有什么技术含量，只不过是把客户需要的字段排列出来就可以了，从“技术实现”的视角看可能的确如此。但是如果从“客户价值”的视角看就不同了，这里要考验设计师的是：是否能够通过功能设计，提升客户的工作效率？为业务正确处理把好关？能否解决客户的难、关、痛点问题？甚至为客户带来效益？这才是活动功能设计的真正意义所在！
■本系列的下一篇：界面设计方法 — 3. 字典功能的设计
关于业务设计和应用设计的详细说明，请参见《大话软件工程—需求分析与软件设计》一书。
