第17章　功能的应用设计

        功能的应用设计，是功能设计三步骤的最后一步，它是对功能使用方式的设计。功能的应用设计将详细设计成果——业务功能规格书转换成用系统要素的表达形式，并在业务设计成果之上增加了系统的操作功能。功能的应用设计构建了“人-机-人”的工作环境，它是决定客户对信息系统价值大小、满意度高低的主要工作之一。

17.1　基本概念

17.1.1　定义与作用

        1．定义

        功能的应用设计，将功能详细设计成果——业务功能规格书（业务4件套）转换成用系统要素进行表达，最终形成业务组件规格书（简称：组件4件套）。同时，功能的概要设计中形成的业务功能一览的内容还会由于业务功能向业务组件的变换时发生调整，调整完成后最终形成业务组件一览。

        2．作用

        从软件工程上功能的全过程看，这是对功能进行的第三次设计，它是对业务功能一览所列出的业务功能，在功能详细设计的业务功能规格书基础之上进行应用方面的设计，功能的应用设计决定了全部功能、实现方式以及用户使用时的效果。由于用户对信息系统的体验主要是通过应用设计的结果感受到的，因此应用设计也决定了用户体验价值的大小，以及用户满意度的高低，应用设计的内容和表达形式也可以让用户和信息系统的相关人在系统完成前就掌握了完成后的效果（包括：内容、布局、操作、过程等）。

        功能应用设计完成时，后续技术设计与开发的重点就是如何实现前面所有的设计结果，原则上就不能再改动之前的设计了，这就是软件工业化设计的基本要求。从需求分析阶段开始到应用设计阶段为止，功能的表达形态经过了两次转换。

        1）需求分析——功能需求收集用户对业务功能的需求，给出需求分析记录——需求4件套。

        2）功能的概要设计（转换1）通过对功能的规划和分类，将功能需求确定为业务功能（活动、字典、看板和表单）。

        3）功能的详细设计——业务功能对业务功能进行详细设计（包括业务与管理），给出设计记录——业务4件套。

        4）应用设计——业务组件（转换2）将业务功能转换为用系统要素表达的业务组件，给出设计记录——组件4件套。

        在概要设计和详细设计中已经将业务与管理的相关内容确定了，与前两个设计用的业务要素表达相比，功能的应用设计重点在于用系统要素表达，例如增加了组件、窗体、接口、功能按钮、权限等内容的设计，这些内容都是因为使用了计算机才出现的，但本书讨论这些内容的目的并非是要进行技术方面的设计，而是这些内容与业务和管理设计成果的实现有着密切的关系，并会极大地影响到用户的体验价值。应用设计与业务设计的关注点和设计内容是不一样的。

17.1.2　内容与能力

        功能应用设计的核心工作是将业务功能转换为业务组件，组件设计的内容又可以再分为两个大的部分：第一部分是应用原型的设计，第二部分是控件的设计

        1．作业内容

        1）应用原型的设计

        应用设计阶段的应用原型与功能详细设计阶段的业务原型之间的区别就在于：业务原型的重点是设计业务的字段控件，而应用原型的重点是设计按钮控件，以及整合详细设计与应用设计的结果。应用原型分为两大类型：窗体类型，表单类型。

        （1）窗体类型：窗体是信息系统中最主要的表达形式，它可以将信息系统的特点与业务设计的内容完美地结合起来，采用窗体形式的业务功能分类有：活动、字典、看板。

        （2）表单类型：表单最大的特点是可以用打印的形式输出数据，与用户传统的数据应用方式一样，采用表单形式的业务功能有：报表、单据。

        2）控件的设计

        在界面上专用于处理数据的控件主要有两大类：按钮控件和字段控件。

        （1）按钮控件：也可以称为“按钮”，其主要是在界面上用来触发数据处理的功能，常用的按钮控件有新增、查询、修改、保存、提交等。

        （2）字段控件：这个部分已在“功能的详细设计”中完成，如无变化，则不需要更改。

        3）汇总组件功能一览将全部设计完成的业务组件汇总为业务组件规格书，经过功能的需求设计、业务设计后，这个资料就是后续功能开发的最终依据了。

        2．能力要求

        功能的应用设计是在具有业务功能的设计能力之上又增加了对系统方面的知识的要求，参考能力如下（不限于此）。

        （1）理解业务设计的理念、主线，具有设计客户应用价值的意识。

        （2）可以看懂业务架构图，掌握功能之间的逻辑关系。

        （3）熟练掌握业务4件套的设计方法，它是应用设计的基础参考资料。

        （4）熟练掌握功能的应用设计方法。

        （5）具有一定的技术设计知识。

17.1.3　思路与理解

        从需求收集、需求分析、概要设计、详细设计直至应用设计的一系列处理过程中，每个阶段都对功能进行了不同视角的归集、设计。经过了业务领域、业务功能、业务组件三次不同视角的分类，将繁杂的原始需求最终转换到了系统中的一个最小控件，为技术设计和开发奠定了基础。这种将对象逐渐地进行拆分、转换，最后形成个体的“零件”，就是软件工程化设计的概念和做法，这种设计方式不但可以提升开发效率，同时用这个方法设计开发出来的系统还具有很强的随需应变能力。

        （1）需求调研——原始需求的收集。对客户进行调研，获取原始需求，原始需求是片段的、无序的。

        （2）需求分析——业务领域的分类。对收集到的原始需求按照企业的业务领域进行归集，这使得原始需求变得非常有序、结构化、业务逻辑清晰。业务领域的数量视业务的复杂程度而定，一般来说，业务对象越复杂，则业务领域的数量就越多。这是第一次抽提共性，抽提是按照业务领域进行的，这个共性可以帮助业务设计师从业务领域的视角对未来的需求有初步的认知，这个分类方法与功能的业务属性紧密相关。

        （3）概要设计／详细设计——业务功能的分类。

        （b）内容按照业务功能的定义进行分类、归集，业务功能的分类只有4种：活动类、字典类、看板类和表单类。这个分类大幅度地简化了业务设计的复杂性。

        这是第二次抽提共性，抽提是按照业务功能的定义进行的，这个共性可以帮助业务设计师从业务功能的视角掌握全部功能，这个共性说明了：不论业务领域有多少种，业务功能的设计方法只有4种，这就达到了用有限的设计方法来应对全部业务功能设计的目的。从抽提的结果（活动、字典、看板和表单）上看，已经找不到明显的业务属性和业务逻辑了，没有业务属性和逻辑的方法才具有普遍的应用价值。

        （4）应用设计——业务组件的分类。再对4种业务功能进行抽提，最终采用控件的方式来表达。不论是哪一种业务功能它的构成都是由有限的控件组成的。这就再次简化了设计对象。控件，是对功能进行的第三次抽提共性，用控件构成的组件已经与业务属性、业务逻辑等领域的业务知识完全没有关系了，原始需求阶段要素带有的业务属性是最多的，经过理后，在到达了应用设计阶段时都变成了控件的要素，其本身就完全没有了业务属性。

        构成组件的控件没有业务属性后，用控件可以组合出任意的业务组件，用这种组合的方式就可以实现任何业务功能，这不但使得系统的开发效率高，且完成的系统本身还具有很强的应对需求变化的能力，这就是软件工程化设计带来的价值。分享功能的应用设计，决定复用的关键在主要由软件企业的研发负责人、开发平台的负责人、产品经理等进行交流的交流会上，讨论到关于如何实现功能复用和产品复用的问题，大家认为：这是为软件企业带来工作效率和经济效益的最佳方式，但是经过了一二十年努力后的成效并不显著，这个目标的达成并非易事。现在做复用的代表性方法可以分为以下两大类。

        方法一：从编码入手传统上解决这个问题大都由技术负责人牵头来做，所以开发者是从快速编码的角度去看如何解决复用的问题，他们以改善编码环境、提升编码效率为突破口来推进研究，用这个思路可以达到一定程度的改善，但是效率还是不太高，因为这个方法离“业务太远”。

        方法二：从业务场景入手

        另外一种就是从业务场景入手，采用“穷尽”业务场景的方法来实现复用，这种方法往往会出现越做系统越复杂、性能越差的问题，因为没有进行抽提，所以无法判断业务的变化规律、重复频率等。“穷尽法”的效果也很不理想，因为这个方法离“业务太近”。这两种方法都因为与“业务的距离”把握得不好，所以效果不佳。实现复用的最佳“位置”是应用设计，它处在“业务设计”和“技术设计”的中间，采用了分离原理／组合原理与基干原理作为基础支持。这个思路就是：将功能／产品看成是一部“机器”，将一切要素构件化。

        1）分离原理／组合原理：从业务层面对要素进行构件化

        （1）将企业对象对象拆分成为业务、管理、组织和物品。

        （2）将业务拆分为架构层、功能层、数据层。

        （3）将架构层拆分为功能、逻辑；将功能层拆分为活动、字典、看板和表单等。

        2）基干原理：从系统层面对要素进行构件化

        （1）用编码开发出控件后，由控件构成组件、由组件构成模块、由模块构成系统。

        （2）将所有的规则做成机制，然后由机制去关联控件、组件、模块和系统。

        通过上述一系列的拆分、构件化的联合运用，就为实现产品和功能的复用打下了基础。

17.2　组件设计1——界面

        应用原型的设计重点就是对“界面”的设计，这个界面涉及很多的概念，有业务层面的，也有技术层面的，因此，在进行组件设计前，首先需要对一些常用词进行定义以方便后续的说明。

17.2.1　组件的概念

        业务组件，是由控件构成的可以独立地执行一个业务功能的系统模块。

        一个业务组件对应一个业务功能（活动、字典、看板、表单），一个组件由一组窗体构成，业务组件是系统中具有独立处理业务功能的最小个体。在系统中还有对应非业务功能的组件称为“系统组件”，例如，权限的配置功能、时限的维护功能等。由于本书的重点是业务设计，因此在后面的描述中如果在“组件”的前面没有特别标注“系统”二字时，这个组件就默认为是业务组件。

17.2.2　窗体的模型

        有了窗体的概念后，下面以窗体为对象建立一个窗体模型，通过这个模型理解窗体与外部的接口和信息的交流

        将窗体上具有的功能分成三个部分，称为IPO，各个字母分别代表的含义如下。

        I：Input，数据的输入。P：Process，数据的处理。O：Output，数据的输出。

17.2.3　界面设计

        前面介绍了组件、窗体的定义和概念，下面就要进入到窗体的内部进行设计。所谓的“界面设计”就是针对一个窗口框所围面积内布置的要素进行设计，为了说明方便，在下面的说明中统一使用“界面设计”一词来代表设计的对象（窗体设计与此同义）。

17.2.4　设计标准

        界面设计的标准化非常重要，因为这是用户认知企业管理系统的窗口，这个标准实际上就是“人-机-人”管理的环境标准之一，这里给出一些设计上的基本原则供读者参考，设计前相关人员一定要统一全部的设计标准，全员必须遵守

        因为企业管理系统不是宣传用的网站，界面风格应该是简洁、明快、可以快速识别信息的，且长时间注视也不易疲劳，要给读者以安静的感受，而不是炫酷和跳跃感。总结：随着计算机技术的发展，计算机的使用领域和用途越来越广泛，界面风格也随之更加多样化，如互联网风格页面、物联网的界面，硬件技术的进步也影响界面风格的变化，如智能手机端、平板电脑端等。它们的设计内容、风格都有所不同，但是上述基本理念、原则等还是适用的。

17.3　组件设计2——控件（按钮）

        窗体上的控件有很多，本节重点介绍与业务和管理的操作密切相关的按钮类控件设计方法。

17.3.1　基本概念

        1．基本功能与管控功能

        作为界面操作的重要功能主要是以“按钮控件”的形式表达的，作用在按钮控件上的功能可以分为两个部分：基本功能和管控功能。

        1）基本功能

        基本功能，指的是对界面上数据的读取、计算、复制、保存、删除等操作，这些功能不论什么系统、不论放在什么组件上，它的作用都是一样的，都是必不可少的。如何实现这些功能属于技术设计师的设计范畴，应用设计师只须理解这些功能的特点即可。

        2）管控功能

        管控功能，是在具有基本功能的按钮上链接了管理规则，在单击了按钮后，除去要执行基本功能的任务（读取、计算等）之外，还要将界面上业务处理的结果与预设的管理规则进行对比，如有违反现象则给出判断，如提示、警告、终止等，如何建立“业务数据”与“管理规则”之间的关系模型就是应用设计师的重要工作。

        2．锁定的概念

        在按钮控件的设计中有一个重要的概念就是状态的“锁定”，状态的锁定与按钮控件的设计有着密切的关系。所谓“锁定”表达的是一种界面的状态，处于“锁定”状态时界面上的全部控件或是部分控件就不能操作了。按钮控件被锁定的原因有很多种，例如，该界面的内容已经通过了审批后就不能再编辑，或是操作的用户没有获得编辑权限等。

17.3.2　“新增”按钮

        1．功能作用

        “新增”按钮，其作用是在界面上为记录新数据而做好准备工作，包括：清空界面数据、导入上游数据、获取业务编号等。单击“新增”按钮是记录一条新数据的第一步，要将操作开始前需要检查的管理规则都链接到这个按钮上，为记录新数据预先准备出一个全空白的、正确的初始状态。

        2．基本功能

        单击“新增”按钮后，系统会进行如下准备（设计不同，处理顺序会有差异）。

        （1）清空界面上所有字段内的数据，呈现一个完全空白的界面环境。

        （2）判断是否有上游导入的数据，如果有，则自动导入或是弹出上游数据的选择窗口。

        （3）获取本次新增数据的业务编号（只限于有自动发号功能的界面设计）。

17.3.3　“查询”按钮

        1．功能作用

        “查询”按钮，用于当给出了关键词或是指定了查询的范围后，从相关的数据库中找出对应的数据。

        “查询”按钮不同于新增、保存类的功能，它不仅是一个技术员写SQL语句的工作，它首先是一个重要的应用设计工作，因为查询是用户频繁使用的功能，所以应用设计师要站在用户的视角，思考如何设计才能支持用户快速查询的需求。

        2．基本功能

        系统中几乎每个组件中都含有“查询”按钮，查询的方式也有很多，这里举三个最为常用的查询方式：精准查询、范围查询、模糊查询。

        1）精准查询

        利用给出的业务编号进行查询，如合同编号、材料编号、员工编号等，只要找到与待查询编号一致的一条数据显示出来就可以了。条形码、二维码等也都属于精准查询。

        2）范围查询

        给出一定的数据范围，如时间段、部门名称、产品分类等，按照这个条件进行查询。这些条件通常是数据表的行或列的标题。一般来说，需要一组符合查询条件的数据时采用这个查询方式。

        3）模糊查询

        模糊查询时，输入关键字或关键词，寻找包含相同字和词的数据记录，不论这些字和词是不是行或列的标题，只要有就都列出来。一般来说，用方法1和方法2都查不到的数据，可以采用这种方式。

17.3.4　“修改”按钮

        1．功能作用

        修改按钮，是对于界面已进入锁定状态的数据进行修改。对没有被锁定数据的修改可以直接通过编辑错误数据的方法进行，但是界面上的数据被锁定后就不能采用直接编辑错误数据的方法去修改了。

        2．基本功能

        1）物理删除方式

        这个方式是直接从数据表上将已保存过的数据删除，然后再追加一条正确的数据。一般来说，这种修改方式仅适用于数据尚未被锁定的情况，或在系统为维护人员特别设置的维护界面上执行删除。

        2）解锁修改方式

        界面已经被锁定，发生了需要修改的数据时，可以通过解锁的方法进行修改。

        3）红字更正方式

        红字更改方式，是在保留记录履历的前提下进行修改的主要方法。

        3．管控功能

        对锁定后的数据进行修改需要受到很多方面的约束，常见的一些场景如下。

        1）权限的约束

        是否可以修改，取决于系统管理员是否赋予了用户修改该功能的修改权限。

        2）时限的约束

        财务相关数据的输入期间都是有时限要求的，过了时限后原则上是不可以再修改的。

        3）审批的约束

        组件上设置有审批流程时，当组件通过了审批后数据将被锁定。如果要修改，必须要设计可以重新进行审批的机制，否则如果绕过了审批也可以修改则审批就失去了意义。

17.3.5　“保存”按钮

        1．功能作用

        “保存”按钮，用于将输入的数据存储到计算机内部或外部存储介质上。

        2．基本功能

        “保存”按钮的功能就是将数据保存到数据库，并且要在保存前检查数据是否合乎数据库的要求。

        3．管控功能

        在“保存”按钮上可以链接管控规则。在保存时，检查是否有违反管控规则的现象。

17.3.6　“提交”按钮

        1．功能作用

        “提交”按钮，用于组件的业务处理全部完成后发出处理完成的信号（关闭组件）。“提交”按钮实际上是一个检查规则的集合体，提交如果获得通过，则表明这个组件内的数据输入和处理全部符合“提交”按钮上链接的规则，可以提供给下游的组件使用。

        2．基本功能

        可以将以下管理规则与提交按钮相链接，单击“提交”按钮后管理规则依次启动。

17.4　组件设计3——业务组件规格书

        业务功能向业务组件的转换是基于概要设计与详细设计的成果进行的，在进入业务组件的阶段，还需要对前面两个阶段的设计成果进行进一步的调整。

        （1）将概要设计的成果——业务功能一览转换为业务组件一览。

        （2）将详细设计的成果——业务功能规格书转换为业务组件规格书。

17.4.1　功能一览的调整

        在概要设计中就已经知道，经过概要设计的架构、功能规划之后，需求分析的功能需求一览被转换为业务功能一览，后者根据业务优化的要求进行了调整，由此也增加了很多内容。

        应用设计的业务组件一览是基于业务功能一览进行的，同样因为应用设计对业务功能的划分依据、标准不同，应用设计在保证业务设计内容不变的前提下，还需要加入系统设计方面的要求，例如，功能共用、性能优化、安全保障等，因此在应用设计中也要对业务功能的划分再进行一次调整，这个调整的结果也会影响到业务组件一览的组件数量。

        注：业务设计的理念、功能和价值在应用设计阶段的调整，原则上是不能改变原业务设计阶段的理念、功能及价值的。

        在业务设计内容不改变的前提下，应用设计还是会对业务功能一览的内容做出很多调整，这种从软件实现的性能、安全等角度进行的调整不但必要，而且还会带来用户体验价值的提升，这也是为什么应用设计的应用设计师需要懂得一些技术知识的原因。再通过下面的对比，理解从需求调研到应用设计的一连串变化。

        ①现状流程：节点是步骤。这个流程记录的是客户工作现状。

        ②业务流程：节点是活动。是从“人-人”做法向“人-机-人”做法的第一次转换，所以在转换中去掉了“人-人”环节中的虚活动（步骤2），这个流程是优化后的最佳业务流程。

        ③系统流程：节点是组件。基于信息系统的特点，对业务流程图的实现方式进行了调整，这个调整对业务设计成果没有本质上的影响，它是充分地考虑了“人-机-人”环境工作时的特点而设计的业务流程图，对比前两个流程，它是真正要实现的流程。

        待所有在业务流程上和不在业务流程上的组件全部确定完毕后汇总出业务组件一览，这个表就是功能应用设计的全部业务组件，同时这个表也是从软件工程中关于功能设计三表中的最后一表，这个表最终确定了需要开发的全部组件。下面对功能设计三种表的变化过程进行汇总、对比。

        1）需求分析——功能需求一览将需求调研阶段收集的，以及通过需求分析（目标需求→业务需求→功能需求）获得的功能需求进行汇总，这一步的需求可以看成是原始的功能需求。

        2）业务设计——业务功能一览以需求分析成果为基础，经过概要设计的架构设计、功能规划，对需求阶段获得的原始功能需求进行确定、补缺、完善，最终汇总。这些功能满足了业务处理的要求。

        3）应用设计——业务组件一览以业务设计成果为基础，将业务功能转换为业务组件，在转换过程中再进一步地进行拆分、组合，以满足系统运行的要求，最终形成了必须要实现的业务组件一览。

17.4.2　功能规格书的调整

        以上完成了组件定义、控件定义以及确定了业务组件一览，下面对应用设计使用的模板进行说明。应用设计阶段采用的对组件设计记录方式，与需求分析和业务设计阶段是一样的，都是由4个模板组成，由于不同阶段的模板相同保证了设计资料的可继承性，但是由于业务设计和应用设计两者描述的主要内容、方法、表达形式都有变化，因此在进入编制业务组件规格书前，先理解一下记录功能的模板“4件套”的变迁过程，功能的设计经历了三次变化，分别发生在需求分析、详细设计，以及应用设计阶段。

        （1）需求分析阶段：产生了功能需求规格书（简称：需求4件套）。

        （2）详细设计阶段：产生了业务功能规格书（简称：业务4件套）。

        （3）应用设计阶段：产生了业务组件规格书（简称：组件4件套）。

        下面就规格书用模板中的4件套在三个不同阶段中的变化做个对比

        1．模板1——原型

        ①需求分析——需求原型：它来源于用户的既存表单的电子版表格、扫描件或其他任何形式（图形、音像）。

        ②详细设计——业务原型：业务原型是纯业务内容的设计（只有字段控件），重点在于对业务处理的完善、优化。

        ③应用设计——应用原型：应用原型是由两个部分的内容构成的，一是前面业务设计的成果②（字段控件部分），二是在应用设计中加入的系统要素部分（导引栏、按钮控件、菜单、…）。

        ④=②+③的合成：最终将详细设计（字段控件）与应用设计（按钮控件）两个部分结合在一起，这就完成了对功能非技术部分设计的全部工作，即④=②+③，应用原型是系统原型的依据。

        ⑤技术开发——系统界面（开发完成后的实际软件）：软件工程非技术设计部分的最终交付物是应用原型④，这个应用原型与开发完成后的系统界面⑤在功能上必须一致（业务控件和功能控件）。

        2．模板2——定义

        （1）需求分析——控件定义：说明需求原型上每个字段的原始含义、计算公式、约束条件。

        （2）详细设计——控件定义：定义每个字段、算式、业务／管理规则、数据来源等。

        （3）应用设计——控件定义：在业务设计成果上，加入按钮控件定义、规则、机制。

        3．模板3——规则

        （1）需求分析——需求规则：对用户需求的补充说明。

        （2）详细设计——业务规则：对业务功能进行优化的说明。

        （3）应用设计——组件规则：将业务功能转换为系统机制的说明。

        4．模板4——逻辑

        （1）需求分析——逻辑图形：用逻辑图说明功能的构成现状、逻辑关系等。

        （2）详细设计——逻辑图形：用逻辑图说明功能的处理逻辑、业务操作流程。

        （3）应用设计——逻辑图形：用逻辑图说明功能的处理机制、应用操作流程。对比这三个阶段的设计内容、表达方式的异同汇总

17.4.3　模板1——应用原型

       在业务设计中定义了业务部分的字段控件，在应用设计的前部分补充了系统的按钮控件，下面就要考虑如何在整体上充分地发挥出信息系统特有的优势，构建一个适合于“人-机-人”环境的业务处理和管控环境，调用系统中所有的数据和信息，为完成好这个组件内业务功能提供服务。下面按4件套的模板顺序结合应用设计的特点，分别介绍业务功能（活动、字典、看板和表单）的原型在应用设计阶段的思考和设计内容。

17.4.4　模板2——控件定义

        首先复制业务功能规格书一份，如果有新追加的字段就插入到列表中相应的位置，如果没有就保持原样。与业务功能规格书相比较，新的业务组件规格书中重点是增加了按钮控件说明部分。新增控件虽然还包括导航栏、工具栏、滚动条等，但对应用设计师来说最重要的设计工作是字段控件和按钮控件，其他控件如无特殊的业务和管理设计方面的要求，可以交由技术设计师去完成。

17.4.5　模板3——规则说明

        在业务功能规格书的4件套规则说明集中在业务逻辑、计算公式等的描述上，不涉及系统功能的内容。应用设计时需要融入很多系统功能相关的内容。

17.4.6　模板4——逻辑图形

        这个模板主要用图形的方式来说明前三种方式说不清楚的内容，图形可以有逻辑图、界面截图等形式。一个组件中可能存在着复数的窗体，窗体间协同作业关系用语言表达不清时，用图形表达非常有效，而且也有利于后续的技术设计、开发者理解设计意图。

        至此，功能走过了功能需求→业务功能→业务组件的全过程，完成了业务功能在设计工程（业务）阶段的全部设计内容，形成的业务组件规格书可以交与技术设计师进行技术方面的设计与开发了。

小结

        本章的核心价值在于让业务应用设计师可以掌握一定的系统功能的设计知识，感受到存在于业务设计和技术设计之间的应用设计的作用和价值。应用设计是一个创新的工作，它可以将客户的传统业务和IT技术相结合产生出全新的生产力。在实际的系统应用设计中，界面的布局和风格会因为业务内容、使用的终端设备，以及采用技术的不同而不同，但不论有多少不同之处，应用设计的核心目的是设计客户体验价值的理念是不变的，在设计过程中一定要不断地思考如何“站在用户的视角”，结合业务设计和技术设计的知识，用应用设计的手法创造出一个最佳的“人-机-人”的信息化工作环境，这个环境可以让用户感受到真正的信息化价值。

        懂得业务设计或技术设计不等于就懂得应用设计，对功能的应用设计需要进行与业务和技术不同的研究，应用设计的主要内容如下（不限于此）。

        （1）设计界面的方法。

        （2）界面模块化的设计理念、建模方法，以及如何快速响应需求变化的方法。

        （3）组件全面的模块化、为后续技术设计和开发的工业化、碎片化应用打下了基础。

        （4）客户体验价值的体现方法、运用信息化手段，为业务处理功能提供服务。

        （5）软件工程的工程化设计方法（统一模板、规范流程、标准）。

        分享  功能的应用设计，价值体现的窗口

        应用价值，是一个整体的概念，它要完成的工作内容至少要包括以下内容（不限于此）。

        （1）从架构层面：从系统的整体上设计，给出诸如“事找人*1”“待办提醒*2”的效果（设计师必须熟知信息化手段）。

        （2）从功能层面：业务处理的步骤最简洁，少出错误，尽可能智能化输入（设计师必须理解业务的处理过程）。

        （3）从表现层面：界面的布局、颜色、合理互动（UI：美工、体验等设计理念）。

        最终，（1）～（3）的设计成果融入到应用用例中并与业务用例相结合，在软件进入开发前就可以给客户展示出未来系统完成后的综合效果。