软件易用性(易用软件官网)

本文转载请注明作者、出处、二维码及全文信息，否则视为侵权。

今天给大家分享一个同事的工作发言。在过去的两三年里，我做过管理和工具软件设计，对软件可用性的提升和UI设计有一些体会和思考。显然，软件的可用性与UI设计直接相关。现在，让我们从软件开发过程来看如何提高软件的可用性。

1.上下文梳理

背景是澄清R&D系统中存在哪些外部实体。在梳理软件的上下文时，我们通常更关注与软件系统有直接功能交互的实体，有时会忽略软件系统的用户。定义软件的用户是提高可用性的起点。

因此，在梳理上下文时，需要确定软件的目标用户。例如，如果一个软件的目标用户是外部客户和内部服务工程师，那么就应该在上下文分析时明确，如图所示。

需要注意的是，在分析软件第一个版本的上下文时，不仅要看软件当前版本的需求，还要看软件的所有需求。比如当前版本不面向外部客户，但是在上下文分析的时候还是需要明确，否则很容易遗漏影响架构的需求。

2.需求情景分析

使用场景定义

从可用性分析开始，前面的上下文分析定义了用户角色。这里要围绕用户角色来梳理用户的使用场景。使用场景显示了用户使用软件的目的。

梳理使用场景，即根据用户对软件业务/功能需求的理解来定义场景。基于使用场景，对软件的需求进行分类，便于下一步的需求分析。更重要的是，使用场景是UI设计的重要基础和输入。

功能的可用性分析

需求的场景分析通常按照业务/功能特性的维度进行，围绕系统和外部实体，明确和细化业务/功能特性的功能交互过程。

从可用性分析的角度来看，在进行需求特性的场景分析时，重要的是要关注业务/功能特性对可用性的具体要求，比如需要向用户呈现什么信息，呈现信息的要求，提供什么操作功能等。

易用性分析只是在需求场景分析的过程中增加了一些需求，而不是引入另一个独立的分析活动，在场景分析过程中一次性完成。所以没有必要把易用性分析单独作为一个独立的活动，否则会带来很多重复和工作量的浪费。

软件可用性设计约束或需求梳理

除了具体需求的可用性需求是在场景分析中完成的，软件的可用性中还有一些常见的设计约束或需求需要整理，包括:

呈现风格要求:比如网页的平铺呈现风格，或者传统的窗口风格等。

信息呈现需求:确定呈现信息的风格，如左树右表或其他风格；页面刷新率等。

操作需求:如通过导航组织操作、提供功能的快速访问、操作的响应延迟、操作步骤、集中或分散操作等。

扩展性需求:信息和操作功能的组织和展现可以方便软件未来功能的扩展，比如支持UI可定制或可配置的驱动页面展现。

3.UI架构设计

UI也需要架构设计。目前在架构设计的实践中，更多关注的是软件功能实现的技术方案，基本不涉及UI设计。但是从可用性的角度来说，UI也需要架构设计。

软件架构设计不仅给出了功能视图、部署视图、运行视图等。，还给出UI框架视图。

基于前面分析给出的使用场景和可用性设计约束和需求，UI框架视图的内容包括:

确定UI的呈现方式:比如网页的平铺呈现或者传统的窗口呈现。

确定页面区域布局的方案:包括操作功能和信息组织的布局，以UI框架草图的形式呈现。

用户界面设计原则和限制。

和软件架构设计的其他技术方案一样，UI架构设计方案也需要反复权衡和选择。同时UI架构设计主要是确定后续UI设计的方向，所以现阶段不需要急于具体细节。

最好由软件设计师负责UI的架构设计，UI设计师会参与讨论和评审，给出专业意见。这是因为设计UI架构，需要对软件的产品理念和软件业务的功能场景有深入的理解。

软件的产品概念不仅包括软件是什么，能做什么，还包括软件应该是什么样子。在软件设计过程中，概念的完整性不应被破坏。比如打算做一个专业人士的专业软件，UI需要专业，让用户很容易对软件功能产生信任感。如果UI设计过于花哨或娱乐化，无法体现专业性，就会破坏软件产品概念的完整性，导致软件设计的失败。

另外，UI是表象，软件的业务功能是内涵，UI服务于软件的业务功能场景。

对软件的产品概念理解最准确的应该是软件设计师，对软件的业务功能场景理解最准确的也是软件设计师。所以最好是软件设计师来负责UI架构设计。

由于UI设计师在专业上更有经验，更了解行业趋势和朋友，UI设计师参与设计讨论和评审，给出专业意见，有助于弥补软件设计师在UI设计上的不足。

现实中有这样一种做法:UI设计师负责UI设计。由于UI设计师对软件业务并不熟悉，需要得到软件设计师的“指导”。因为学习和交流的成本，自然效率不可能高。更有可能的是，软件设计师可能忙于其他设计工作而忽略了“指导”，UI设计师要自己过河，容易导致设计方向的偏差，导致更大的返工。

4.UI低保真度/高保真度设计

UI架构设计完成后，UI设计人员可以基于UI框架视图进行低保真度和高保真度的设计活动。

一般来说，低保真设计可以表现出软件会是什么样子，而高保真通常是在低保真方案定型后进行。在此之前，对低保真设计进行反复讨论、审查和迭代优化。现实中，这个设计阶段容易出现的问题是:易议而不决。导致讨论无果的原因如下:

参与评审的意见会很多，尤其是你在做一个各方都关注的软件，最好是收集各方意见。

UI的评测评论很好提:不需要太懂技术。大家可以根据自己的审美和经验进行评论，有的可以给出与现有设计完全不同的建议。审美意见没有对错之分，这也是很难做出选择的。

“大”和“小”的意见或多或少会影响设计方案的决策。

从软件研发的进度来看，议而不决，不行。无论如何，UI设计都要在适当的时候基线化，这样软件研发过程才能按计划继续推进。因此，对于软件设计师和UI设计师来说，既要充分考虑各方意见，又要把握UI架构设计所确定的原则和方向不会丢失和偏离，同时还要仔细甄别真正代表用户、符合使用场景的意见。

如果不能和大家达成一致，就需要设计师果断决策，设计师必须在设计中说了算。

5.软件试用

UI低/高保真设计完成后，将进入软件开发和实现阶段。在软件交付前尽可能早地组织软件试用是保证软件可用性的有效手段。

之前对UI设计的回顾和讨论基本都是“纸上谈兵”。软件真正用起来的时候，有一种直接的感觉就是好不好。用户可以体验到真实的操作响应、页面刷新速度、信息呈现效果等。软件的，不能通过低保真度/高保真度来体验。这样，软件在交付之前就可以有针对性地进行优化。

因此，尽早组织软件试用是保证软件交付可用性和质量的有效手段。简而言之，提高软件可用性的有效方法包括:

需求阶段定义了用户的设计约束和需求，软件的使用场景和可用性。

或者加强UI架构设计活动，给出UI框架视图。

在UI的低保真/高保真设计阶段，要把握UI架构设计所确定的原则和方向，仔细甄别真正代表用户、符合使用场景的意见，果断决策，避免议而不决。

软件开发完成后尽快组织软件试用，交付前进行针对性的优化，确保软件交付的可用性和质量。

更多精彩内容请搜索“ICT_Architect”，加入微信微信官方账号“架构师技术联盟”。