一份全面的“界面设计论述”是怎样的？

全部产品所在的店铺地址：https://www.axureshop.com/shop/3039
本人最新项目原型设计（大项目）完整版高保真实战原型(UE&UI)设计(PC端)地址：https://www.axureshop.com/a/674824.html
与此相关的完整版高保真实战项目(UE&UI)原型设计(针对于全息中继器组件)地址：https://www.axureshop.com/a/249709.html
与此相关的完整版高保真实战项目(UE&UI)原型设计(PC端+手机端)地址（这个性价比很高，推荐路过的朋友购买）：https://www.axureshop.com/a/234122.html#comment-287804
与此相关的完整版高保真实战项目(UE&UI)原型设计(手机端)地址：https://www.axureshop.com/a/246479.html
与此相关的完整版高保真实战项目(UE&UI)原型设计(PC端)地址：https://www.axureshop.com/a/298707.html

界面设计论述

1. 什么是界面设计

用户与软件系统交互信息的媒介。

1.1 界面设计概略

1.1.1 应该考虑的问题

• 通过它能够让用户知道他需要的是什么，系统为他解决的问题是什么，能够让用户了解使用它能够达到什么目的；
• 不能只是一味的为了美观设计，还要考虑每一个功能之间合理的功能逻辑，以及要照顾到这些功能逻辑后面支撑的数据关系；
• 是否以目前的需求为设计最终蓝版，要记得判定目前的需求是否具有后续要求，设计的时候是否要留有能够提升适应后续需求的空间，并且还要合理；

1.1.2 所谓的界面设计

• 设计系统通过什么方式接收用户从输入设备录入的信息、发送的指令，通过什么方式将处理过程与处理结果反馈到输出设备上；
• 具有易学性，让用户可以快速学会，节省学习成本和时间；
• 具有易用性，让用户使用方便、流畅、高效、愉快；
• 具有健壮性，让用户少犯错误，犯了错误也不会有恶劣的影响；
• 具有交互性，让系统与用户之间很容易进行沟通和交流；

1.1.2 四大重点

• 从需求分析的角度来考虑问题；
• 怎样才能很好的进行人机交互；
• 界面设计实现的三大形式；
• 什么是架构级设计；

1.2 什么是软件界面

1.2.1 远不止是计算机显示屏中一个又一个的窗口、表单、网页？

所有让用户可以通过视觉、听觉，甚至是嗅觉、触觉感受到软件相关信息的媒介，通过动作、声音，甚至眼神、思维让软件系统能够接收到用户信息、指令的媒介，都输入软件界面的范畴。

1.2.2 不只有单方面的输出，还要有另一方面的反馈？

界面是人与计算机交互的渠道，最常见的人机交互方式是动作与视觉的组合，人通过敲打键盘、点击鼠标向计算机输送信息、指令，计算机将处理结果反馈到显示屏上让用户可以看到，交互不只是人与计算机的交互，也是计算机与人之间的交互。

1.2.3 并不是跟软件系统有关的所有输入、输出都需要软件界面的？

比如感应器、RFID阅读器、接收计算机指令后作出动作的机械手、加热或喷水的装置等，这些都属于输入设备，并不需要输入界面，这些属于机与机的交互。

1.2.4 界面不仅仅只有图形化界面？

一般分为字符界面和图形化的界面，所谓字符界面是操作系统或应用软件的界面，和操作都是字符实现,没有图形。

dos系统就是典型的字符界面。

图形化界面则是由各种可视化非常强烈（比如窗体、文本框、按钮等）的组件构成的界面形式。

2. 界面设计基础

2.1 要以人为本

界面作为人机交互的接口， 要强调“以人为本”。 毕竟， 机器运算速度飞快， 机器没有情绪， 机器不知疲倦， 机器很少犯错误， 而人则不一样。 人的运算能力差（跟机器比起来） ， 人容易厌烦， 人容易疲劳， 人容易犯错。 因此， 界面设计要强调以用户（人） 为中心， 而不是以机器为中心。 以人为本的软件应该做到以下几点 ：

2.1.1 不要让用户难以学习

操作界面简单，减少学习成本，简单培训即可，具有引导性操作，具有帮助性的提示。

2.1.2 不要让用户感觉到厌烦

• 用键盘完成的就不要切换到鼠标，比如大量录入工作；
• 用户操作犯了错误，提示信息令用户难以理解；
• 只让用户做一些无关紧要的操作，并给出了很多提示；
• 一件简单的事，用户却点击半天才能进入目标界面；
• 一大堆功能菜单，操作界面，然而大部分对工作都没有关系；
• 频繁的切换和跳转界面，搞的用户晕头转向；
• 操作功能逻辑凌乱，无法聚焦核心要点，太散；
• 整体风格不统一，用户跳转界面之后仿佛进入另一个系统；
• 数据展示不全面，另外字段没有设立优先级，录入的信息没有主次之分；

2.1.3 不要让用户感觉到恐惧

• 不要让用户犯错误；
• 让用户少犯错误；
• 让用户容易发现错误；
• 让用户可以纠正错误；
• 降低用户错误的影响面；

2.1.4 不要让用户感觉到难以捉摸

• 结合用户的习惯；
• 组件设计要根据规范进行，不常用的或者图表化的按钮要有提示；
• 操作功能与结果有偏差，常给用户带来误导，相同的按钮或者图标却又不同的作用（比如修改和编辑）；
• 用户对某一个功能进行操作，系统要给用户一些简单的反馈信息；

2.1.5 不要让用户感觉到不安全

要有严格化的权限分配，即使有权限冲突，也要给相关用户以提示信息（比如用户填写的日志，是否需要其他可以查看）；

2.2 原型设计

• 设计软件运行的模拟界面，设计系统如何接受用户录入的信息以及发布的指令；
• 表达用户使用软件的操作工程，信息的展示方式，强调的是用户可以做什么，可以看到什么，并强调背后的处理逻辑；
• 是还原用户体验的最直接的手段，也是推进项目最有用的方式之一；

2.2.1 产品原型

基础架构的设立、功能模块的划分、样式风格色值的确定、功能逻辑的动态交互、基础字段和数据优先级的展示，以及用户需求的高度还原。

2.2.2 数据原型

数据之间的关联关系、印证产品原型内的功能逻辑。

2.2.3 原型设计方法

原型设计的方式有很多种， 这里略作介绍，供大家在工作中参考。

2.2.3.1 手画法

使用方式：利用纸笔画界面草图，或者在计算机上通过画板来你画出界面示意图或者是思维导图，非常原始。

使用阶段：需求分析前期阶段与用户进行快速沟通的时候进行此类概要设计，主要确定项目的基本需求和功能，为接下来的工作提供数据依据。

2.2.3.2 Office****工具设计法

使用方式：Word、 Excel、PPT、 Visio等， 都可以用来充当原型设计的工具，其也有专门用于设计界面的图形模具，可以画出效果非常逼真的设计稿，维护性方面要比手画法强。
使用阶段：和用户确定部分主要的需求和功能之后（一般用在不会太复杂且交互过程少的报表功能界面，主要是数据展示方面）。

2.2.3.3 专业原型工具设计法

使用方式：专业的原型工具设计软件有很多， 如Axure RP（推荐）、GUI Design Studio，Sketch，Adobe XD等。其不仅可以制作出非常逼真的软件模拟效果， 而且画出软件界面相关的几乎每一个细节， 菜单如何显示， 包括哪些界面，界面中需要展现哪些元素， 用户做出操作后界面上有何反应等。
使用阶段：与用户最终确定业务需求之后（包括数据原型），是最终的原型设计定稿。

2.2.3.4 研发工具设计法

使用方式：有些快速开发的工具也可以进行原型的设计，如Delphi、 VB等。
使用阶段：在确定用户业务需求之后，使用这种设计方法需要由具有一定编程经验的开发人员介入，也可以是懂前端或者做过前端编程的产品经理和设计师来做，这样才能够将这种设计方法的优势发挥出来，不过相对于其他设计方法，这种设计方法灵活性明显不足，具有很大的局限性，一般不采用。

注意：比起原型设计工具来， 使用这种方式有个巨大的优势， 就是可以在设计过程中编写一些简单的代码， 通过这些代码的执行， 让表现形式更加灵活， 也可以更加逼真地体现出人机交互的过程。 缺点是对于设计者来说， 需要有使用这种工具进行开发的经验， 否则学习起来还是挺麻烦的， 至少比学习原型设计工具要难（这里需要产品经理或者设计师具有一定的编程经验（懂前端或者做过前端编程））。

2.3 快速原型开发模型

关于软件开发模型有很多种， 如瀑布模型、 螺旋模型， 在这里介绍一种开发模型——快速原型开发模型， 这是非常适合一般管理软件的开发模型。 快速原型开发最主要的特点是， 在开发之前系统地设计界面原型， 一般都会采用专业的原型设计工具设计， 所以速度很快， 得到用户确认后， 开发者根据原型进行开发。

2.3.1 一般步骤

采用这种模型一般会经过下面的步骤：

• 业务需求调研；
• 原型设计；
• 原型评审；
• 根据用户反馈修改原型（可能会经过很多次或者几十次的更改，这里就会牵扯到需求的变更）；
• 重新评审；
• 用户确认；
• 根据原型研发软件；

从这些步骤可以看出， 这个模型的优势主要在两方面： 一是在设计阶段， 可以让用户最大限度地参与到软件设计工作中来， 充分发表自己的意见， 从而大大降低了偏离用户需求的风险——如果没有界面原型，
一般用户对软件究竟会是什么样子没有感觉， 很难在设计阶段提出自己的见解， 直到软件开发完成后才发现这也不对那也不对， 做软件的自然都明白， 这是非常致命的； 二是在开发阶段， 由于设计者给出了系统的
界面原型， 对于开发者来说， 理解设计者的思路就变得非常容易——如果没有界面原型， 设计者哪怕把自己的设计思路说得再清楚， 文档写得再完整都可能被开发者误解， 这一点相信大部分软件从业人员都有切肤之痛。

2.3.2 注意事项

通过界面原型设计加强与用户沟通， 有以下一些注意点：

2.3.2.1 与用户沟通要有个度，过犹不及，可能会相反

在设计过程中多与用户沟通， 但绝不是要缠着用户， 恨不得每个字段的名称、 摆放位置都要跟用户确认， 这种情况往往是设计者对自己的设计成果不自信的表现。

2.3.2.2 用户的意见很重要，但并不总是正确的，要有自己的立场

如何设计好界面，对于设计者来说， 应该比用户精通得多， 要考虑的方方面面的关联事项也多得多， 要引导用户、 帮助用户， 不能被用户牵着鼻子走。

2.3.2.3 从用户意见中发现问题，而不是解决办法，要认清自己的定位

对于用户的意见， 要从根本上理解用户为什么会提出这种意见， 它折射出什么问题， 然后分析如何解决这些问题， 而不是依赖于用户提出解决方法——是你在设计界面， 不是用户。

2.3.2.4 不同的项目，可以采用不同的评审方式，举一反三

对于界面原型的评审， 根据不同客户、 不同团队、 不同业务需求， 可以采用不同的方式。复杂的， 可能需要召开大型评审会， 不复杂的， 可能只要在某用户的办公室中一两个人讨论讨论就行了， 有些非常简单的， 甚至通过QQ或者微信远程截几个图就能沟通清楚。

3. 界面设计过程

3.1 界面设计五大要素

• 入口设计：强调如何让用户方便地获得自己需要的功能。
• 功能主界面设计：强调如何划分组件区域 。
• 表单布局设计：强调如何排放组件 。
• 操作设计：强调如何让用户获得功能点包括的所有原子功能 。
• 消息设计：强调系统如何向用户反馈程序执行情况。

3.1.1 入口设计

用户登录进入系统后， 如何才能打开自己需要的功能界面， 这是入口设计需要考虑的问题。 针对不同的功能、 不同的用户， 对入口设计的要求并不一样， 有的功能很少用到， 入口方式就可以麻烦一点儿， 用户多点几次也无所谓； 有些功能用户使用频繁， 就需要考虑如何让用户快速进入； 有些功能面向的用户能力较强， 或者学习意愿比较强烈， 只要能快速进入， 难学点儿也无所谓（甚至通过字符界面敲命令都可以考虑） ； 有些功能面向的用户能力较弱， 或者学习意愿不强， 就需要设计简单明了的进入方式。 当然， 很多时候， 囿于开发团队的技术、 能力、产品框架， 能够供设计者发挥的空间有限， 这虽然让设计者时常感到郁闷， 但也不能不说降低了入口设计的难度。

3.1.1.1 功能菜单

最常见的入口方式是功能菜单， 菜单区可以在上边， 通过下拉的方式展开， 也可以在左边， 通过树状节点加载。 用户单击自己需要的某个菜单， 进入功能界面。

3.1.1.2 工作台

可以给用户建立一系列工作台， 在工作台上罗列用户最需要的信息、 最常用的功能、 当前需要处理的任务等。 用户登录进入系统后通过某种方式打开工作台， 或者系统根据当前用户自动打开属于他的工作台， 用户通过工作台可以完成某一业务领域相关的大部分工作。

3.1.1.3 九宫格

“九宫格”界面即将三行三列九个格子拼在一起的界面， 例如键盘上的数字小键盘， 手机输入法中的九格键盘。 后来， 只要是这种一格一格的界面布局都习惯于叫九宫格或者N宫格了。 用九宫格作为入口的方式， 在智能手机上非常流行， 由于空间有限， 三行三列九个格子， 每个格子放置一个命令图标显得比较合理， 后来手机屏幕越来越大， 排放的图标自然也越来越多。 现在PC端用这种方式作为功能入口的软件也越来越多了。

3.1.1.4 弹出菜单

用户单击某区域， 或执行某操作后， 系统弹出菜单， 用户单击菜单， 进入功能界面， 这种入口方式在C/S系统中相当常见（很多C/S软件的用户都习惯于在任何地方单击鼠标右键碰碰运气， 看能不能弹出点儿什么来） ， 在B/S系统中用得没有C/S系统那么普遍 。

3.1.1.5 快捷方式

对于某些非常常用的功能， 可以通过快捷方式建立快速入口， 如在某面板上放置功能图标， 允许用户建立功能收藏夹， 或者可以让用户输入字符命令等。

3.1.2 功能主界面设计

指用户通过菜单或其他入口方式打开某功能点后， 系统加载的用于使用该功能点的主界面， 用户可以从中获得各种子功能的入口。 将一个“查询类”的界面作为一个有些复杂的功能点的主界面， 这似乎是大部分管理软件的设计习惯， 例如， 一个叫“客户管理”的功能点， 用户从菜单打开该功能点， 系统加载一个客户列表， 显示目前有哪些客户， 并且在界面顶部放置“新增客户”、 “删除客户”、 “编辑客户”这些功能按钮。功能主界面一般会被分成各种区域， 如菜单区域、 功能按钮区域、查询条件区域、 记录显示区域、 详情展现区域等， 各种组件就放置在这些区域中。 这些区域的布置方式， 本书称之为界面结构。 下面介绍一些常用的界面结构 。

3.1.2.1 上边查询条件，下边查询结果

这是最常见的查询类界面， 用户在上边查询条件区域中录入查询条件， 单击“查询”按钮， 系统将符合条件的检索结果显示在下边的列表中。

3.1.2.2 左边大项，右边查询结果

用户单击左边的大项， 系统在右边加载属于该大项下的信息。 列表的上方也可以放置查询条件区域， 用户可以进行更精确的检索。

3.1.2.3 左边树状结构，右边查询结果

用户单击树展开按钮， 树会展开， 用户单击树的节点， 系统在右边列表中加载属于该节点的相关信息。 列表上方可以有查询条件区域。

3.1.2.4 上边/左边主表，下边/右边子表

• 上边主表（“一对多”关系中“一”的一方） 信息， 下边子表（“一对多”关系中“多”的一方） 信息， 用户单击上边主表中的记录时， 系统在下边子表中加载该记录的关联子表信息。
• 用户单击左边主表中的记录时， 系统在右边子表中加载关联信息。

3.1.2.5 树形列表

在列表中展现有上下级关系的信息， 用户单击节点， 可以展开或收缩记录信息。

3.1.2.6 分级列表

表中分级， 用户单击主表记录时， 页面撑开， 显示子表记录。

3.1.2.7 日历

日历结构用于展现与日期息息相关的信息， 如计划、 任务、 日志、资源占用、 上班班次、 上课课表等， 一般包括日视图、 周视图、 月视图。

3.1.2.8 总结

这里介绍的是一些功能主界面设计中常用的界面结构， 在实际工作中根据客户、 开发团队、 设计者的不同， 自然还会有各种其他的结构，如门户型的结构（在功能主界面中展现大量的说明、 参考、 帮助、 提示、 摘要信息） 、 图表结构（在功能主界面中结合报表图表） 等， 作为设计者既要尊重客户的需求、 行业的规范、 团队的传统， 但也不必被这些框框限死， 要做一个有想法的设计者。

3.1.3 表单布局设计

表单上的组件可以分成三大类， 一类是用来接收或显示数据的， 如文本框、 标签、 单选框、 复选框等； 一类是用以响应用户的要求而执行某种操作， 如按钮、 链接、 图标等； 还有一类跟数据、 操作都没有关系， 只是用于界面布局、 标注或美观等， 如分隔线、 矩形框等。 表单布局设计， 就是思考如何排放这些组件， 使界面达到易学、 易用、 美观的效果。

3.1.3.1 平铺

将本界面需要的所有组件依次放置在界面上，用户打开界面时就能看到所有的组件。 很显然， 这种方式只适合于组件元素比较少的界面， 如果组件多了， 这种方式会让用户感到眩晕。 用户在同一区域比较容易接受的信息点一般在7～10个， 如果在同一界面上， 数据元素超过了这个数， 就应该考虑下别的布局方式。

3.1.3.2 分组

分组布局可以理解成是对平铺布局的某种优化， 用户打开界面时同样能够看到所有组件， 但这些组件被分成了若干个组。 在这种布局形式下， 虽然界面上组件较多， 但由于被分了组， 用户首先接受的信息点为组信息， 对于用户来说就有了一个逐层思考的过程， 通过这种方式就可以在界面上放置更多的组件。

3.1.3.3 动态加载

动态加载是一种柔性布局， 用户打开界面时并不显示所有组件， 只有在满足某种条件或者用户执行了某种操作时， 才会显示相关的组件。在这种布局形式下， 由于隐藏了一些组件， 更容易安排界面空间， 而用户打开界面时只看到一部分组件， 也更容易抓住重点。

3.1.3.4 表格

表格布局， 见得最多的就是以Excel为代表的一些电子表格软件了， 在管理软件中这种布局形式也非常常见， 一般用于快速录入信息，但如果每条记录需要录入的信息较多， 或者字段跟字段之间的控制关系较强时， 这种方式就不太适合。

3.1.3.5 TAB页

Tab页布局， 可以说成是分组布局以及动态加载布局的延伸。 当设计者考虑使用Tab页布局时， 往往都是因为界面空间问题， 在某个有限的空间内无法放置需要的组件， 于是将组件分组， 放置到不同的Tab页中， 用户可以切换到不同的Tab页进行操作。

3.1.3.6 混合

在一次需要录入或编辑大量信息时， 在一个表单中同时使用上述多种布局形式也很常见 。

3.1.3.7 注意事项

• 合理安排界面空间；
• 突出重点；
• 信息展现要有层次感；
• 注意组件顺序；

3.1.4 操作设计

• 对于查询类的界面， 由于不需要往数据库中写入数据， 也就少了许多数据组织与验证的过程， 人机交互的过程非常简单， 无非就是用户输入条件后， 系统从数据库检索数据， 再加载到界面。 而对于表单类的界面， 或者表单与查询混合类的界面， 由于用户在操作的过程中系统可能会提供大量的数据验证、 辅助录入、 确认提醒的支持工作（这里特指用以新增、 编辑数据的表单） ， 因此， 很多时候就会有非常复杂的人机交互要求。

• 一个复杂的表单界面可能会提供大量的子功能， 这些子功能一般会通过按钮、 链接、 命令图标、 键盘快捷方式、 鼠标单击、 鼠标双击、 鼠标右击、 离开某组件、 进入某组件等方式提供给用户， 用户执行操作后， 便会触发系统运行某程序。 有时候， 一个看似简单的界面， 其实暗藏了很多子功能， 有些子功能甚至用户都注意不到。 例如， 用户在某文本框中录入数据， 离开时， 系统会验证所录数据的合法性， 这个验证过程其实也是一种子功能， 不过不那么明显， 如果用户录入的数据是合法的， 他甚至感觉不到系统做了这方面的验证工作。

  3.1.4.1 面向****数据库的写操作

例如， 用户录入员工信息后单击“保存”按钮， 这项“保存”操作会将员工信息保存到数据库。

3.1.4.2 不改变数据库中数据的操作

可能仅仅是从数据库读取数据（Select） ， 或者甚至跟数据库中的数据毫无关系， 抛开系统维护类的信息（如操作日志） 不谈，这种操作不会导致数据库中保存的数据发生任何变化 。

3.1.5 消息设计

当用户在界面上操作时， 一个友好的系统会将执行情况根据需要反馈给用户， 这就是所谓的“消息”——系统给用户带来的关于计算机内部的消息。 有些消息只是告诉用户一段程序执行的状态， 如常见的告诉用户保存记录成功的提示消息， 而有些消息是用于接受用户额外指令的，如让用户确认是否删除某记录的提示消息。 系统反馈给用户的消息， 可以通过各种方式表达出来， 如弹出消息框、 显示在某固定区域、 写入日志文件等， 当然， 也不能将消息狭隘地理解成一段文字， 有的时候系统也会通过组件形状变化、 位置变化、 颜色变化、 文字字体变化之类的方式向用户传达消息——这种情况相当常见。 什么时候用什么方式给用户送去消息， 需要设计者确定。

3.1.5.1 消息弹出框

用户执行了某操作后， 系统响应触发事件而执行一段程序， 在程序运行过程中或程序运行结束后， 弹出一个对话框， 告诉用户程序运行的状态或者请求用户干预， 这就是消息弹出框 。

3.1.5.2 消息区

可以在某个区域设计一个消息区， 程序在执行过程中如果有什么消息需要让用户知道， 可以将消息写入到消息区。 用户如果需要， 可以到消息区查看这种消息， 用户如果不想查看这种消息， 对接下来的工作也不会有什么不良影响。 有些软件会设计消息漂浮框， 显示一段时间后自动消失， 不需要用户干预， 这也可以理解成消息区的一种特殊形式。 弹出框需要用户执行额外操作， 而消息区不需要。

3.1.5.3 日志

绝大部分软件都会将系统运行过程中的一些重要信息记录成日志，日志信息可能直接保存在数据库中， 也可能写入到某些日志文件中（一般都是文本格式） 。 日志信息可以包括很多内容， 如什么时候用户执行了什么操作， 向数据库提交了什么数据， 产生了什么重要影响， 耗费了多少时间， 占用了多少资源等。 这些信息一般用于管理员对系统进行监控、 分析、 跟踪、 调试等。 记录系统日志的过程对普通用户来说是透明的， 他们在执行操作的过程中是感觉不到这个过程的。 日志也是系统消息的一种， 只不过它面向的读者不是普通用户， 而是开发者或者管理员级别的高级用户。

3.1.5.4 其他方式

系统向用户反馈消息还有其他各种各样的方式， 如颜色的变化、 字体的变化、 图像的变化， 或者发出某种声音， 或者发出某种振动（手机） 。 一般来说， 这些方式反馈出来的信息比较简单， 只是让用户觉察到自己的操作对系统产生了影响， 或者让用户知道系统正在处理等。 例如， 用户单击某链接后， 链接文字变成另外一种颜色， 这就是告诉用户， 这个链接已经单击过了； 用户QQ上线， 头像由灰变亮， 这就是通过图像的变化告诉用户上线成功； 用户执行某操作， 系统需要较长的时间处理， 为了让用户知道系统在处理， 以及处理的大概进程， 会显示一个进度条， 让用户根据进度条判断大概还需要等待多久。

4. 界面优化

4.1 概述

好的界面总是以人为本的， 具有易学性、 易用性、 健壮性、 交互性等， 本节就从这几个方面来看如何优化用户界面。

当然， 这些方面并不仅仅跟界面有关， 功能是它们的基础， 没有好的功能， 谈这些没有任何意义。

image

4.1.1 时代性

跟随潮流进行时代性的设计，比如如今流行的设计理念是扁平化、轻量化，那么跟随主流软件进行设计才是最好的选择，举一个反例，当一个系统已经符合易学性、易用性、健壮性、交互性四大元素，但是却是几十年前的设计风格，现在的用户会接受吗？当然不会，这样也不会出现那么多老的系统进行翻新的状况了。

4.1.2 易学性

在易学性方面的优化， 就是让软件更容易被用户学会。 一款容易学会的软件， 可以大大增加用户的使用兴趣， 降低软件的总成本。

可以从以下几个方面考虑如何进行易学性方面的优化：

• 提炼核心功能；
• 追随主流软件；
• 贴近业务流程；
• 统一操作习惯；
• 减少用户干预；
• 倡导边干边学；

4.1.3 易用性

软件的易用性， 指用户使用软件进行工作时是不是高效、 方便、 快捷。 很显然， 易学性是易用性的一部分， 一个很难学习的软件自然说不上易用。 不过， 为了明晰定义， 本书将易用性与易学性拆分成两个独立的概念， 易学性是针对没有学会软件（或软件中某功能） 的新用户， 而易用性是针对已经学会了软件并可以熟练操作的老用户。 根据学习曲线， 用户在使用软件功能时， 刚开始工作效率低， 随着学习内容的增多， 使用频次的增加， 工作效率会越来越高， 但高到一定程度后会趋于一个稳定的值（当然， 不同的用户， 根据悟性、 学习能力等方面的不同， 这个值是不一样的） 。 当用户使用软件处理工作的效率达到这个值后， 称之为老用户。

为了提高软件的易用性， 可以考虑以下这些优化原则：

• 让功能方便调用；
• 让工作容易处理；
• 减少用户录入；
• 减少按键次数；

4.1.4 健壮性

软件的健壮性， 指当发生某些异常情况时， 软件处理方式的完善程度， 这些异常情况包括很多方面， 如断电、 断网、 宕机、 黑客攻击、 资源耗尽、 用户操作错误等。 断电、 断网之类的异常不在本书的讨论范围之内， 这里所说的健壮， 是针对用户操作而言的， 指如何通过软件功能防范用户可能发生的操作失误。为了提高功能的健壮性， 一般可以从这几个步逐层考虑： 不让用户犯错误→让用户少犯错误→犯了错误后容易发现错误→允许用户纠正错误→降低用户错误的影响面。

• 不让用户犯错误；
• 让用户少犯错误；
• 让用户容易发现错误；
• 允许用户纠正错误；
• 降低用户错误的影响面；

4.1.5 交互性

为了避免用户犯错， 提高软件功能的柔性， 让用户用得更放心， 系统在执行过程中需要跟用户进行信息交流， 让用户知道程序什么时候开始执行， 执行过程中发生了什么， 执行结果是什么， 等等。 所谓交互性， 指系统在执行过程中能否与用户进行友好沟通， 让用户获得他应该知道的系统信息， 让系统获得用户应该提供的信息。

要让系统具有良好的交互性， 可以从以下这些方面考虑：

• 重要操作需要确认；
• 不要让用户有石沉大海的感觉；
• 消息是给用户看的，不是给程序员看的；
• 消息需要精准；
• 交互要适可而止；
• 不要滥用弹出框；

5 总结

基础架构、数据印证、功能逻辑、动态交互四位一体方是对设计的最好阐述。

image