软件易用性
转载本号文章请注明作者、出处和二维码及全文信息，否则视为侵权。
今天给大家分享一个同事的工作感言。近两三年做管理类、工具类软件设计，对软件易用性提升和UI设计有一些体会和思考。很显然，软件的易用性与UI设计是直接相关的。下面，我们从软件研发过程来看一下如何提升软件易用性。
1、上下文梳理
上下文梳理是明确研发系统与哪些外部实体存在关系。在梳理软件的上下文的时候，一般会更加关注与软件系统有直接功能交互关系的实体，有时会忽略软件系统的用户，而明确软件的用户，是易用性提升的起点。
因此，在上下文梳理时需要明确软件的目标用户。例如某个软件的目标用户是外部客户和内部服务工程师，那么在上下文分析的时候，应该明确出来，如图
需要注意的是，在对软件首个版本分析上下文的时候，不能只看软件当前版本范围的需求，而是需要看软件所有的需求，例如当前版本做不面向外部客户的特性，但在上下文分析的时候仍然需要明确出来，否则容易遗漏影响架构的需求。
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设计师并不熟悉软件业务，就需要软件设计师在旁边“指导”。由于存在学习和沟通的成本，自然效率不可能高的。更可能发生的情况是：软件设计师可能忙着其它设计工作而疏于“指导”，UI设计师不得不自己摸着石头过河，这样就很容易发生设计方向偏差，从而导致更大的返工。
4、UI低保真/高保真设计
UI的架构设计完成后，UI设计师就可以在UI框架视图的基础上，开展低保真以及高保真的设计活动。
一般通过低保真设计，就能展示出软件会做成什么样子，高保真一般是在低保真方案定稿后才进行，在此之前低保真设计反复讨论评审、迭代优化。现实情况下，这个设计阶段容易出现的问题是：容易议而不决。导致议而不决的原因，大致有如下几方面：
参与评审的意见会很多，特别是如果做的是一款各方关注的软件，那方方面面的意见最好都要征集到。
UI的评审意见很容易提：不需要很懂技术，每个人都能根据自己的审美和体验提出意见，有些能给出与现有设计完全不同的建议。审美相关的意见无所谓对错，也导致了很难做取舍（想以理服人很难做到）。
意见声音的“大”和“小”，也或多或少会影响到设计方案的裁决。
从软件研发的进展来看，议而不决的状态是不能接受的，无论如何UI设计都要在适当的时刻进行基线化，这样软件的研发过程才能继续按计划推进。因此，对软件设计师和UI设计师来说，既要充分考虑各方意见，又要把握UI架构设计确定的原则和方向不丢失、不偏离，同时仔细鉴别真正代表用户、符合使用场景的意见。
如果实在不能和所有人达成一致，那就需要设计师果断裁决，设计必须最终由设计师说了算。
5、软件试用
UI低保真/高保真设计完成后，就进入软件开发实现阶段。在软件交付前尽早组织进行软件试用，是保证软件易用性的一个有效手段。
前面UI设计的评审讨论，基本上还是“纸上谈兵”。软件真正用起来，好不好用立刻就有感觉了，用户可以体验到软件的真实操作响应、页面刷新速度、信息呈现的效果等，这些是无法通过低保真/高保真体验到的。这样软件在交付前可以有针对性进行优化。
因此，尽早组织软件试用是一个确保软件交付时的易用性质量的有效性手段。总之，提升软件的易用性的有效途径包括：
需求阶段明确软件的用户、使用场景和易用性的设计约束和要求。
开展或加强UI的架构设计活动，给出UI框架视图。
在UI的低保真/高保真设计阶段，把握UI架构设计确定的原则和方向不丢失、不偏离，同时仔细鉴别真正代表用户、符合使用场景的意见，果断决策避免议而不决。
软件开发完成后尽早组织软件试用，在交付前可以有针对性进行优化，确保软件交付时的易用性质量。
请搜索“ICT_Architect”加入微信公众号“架构师技术联盟”获取更多精彩内容。
相关阅读
from : http://blog.csdn.net/keenweiwei/article/details/42780805/ 环境是 win7, 64 bit 装了 visio 2013 ， 可以却不能用它来画
目录 前言... 3 软件测试流程... 3 提取测试点... 4 设计测试用例与用例评审... 4 测试类型选择... 5 测试执行与缺陷管理... 7
因为运营工作的综合事项多，细碎事项之多，为了提升运营效率，很多时候我们都会采用采购第三方的平台或软件来帮助运营工作，运营都会遇到
作为传统的To B软件企业，转型升级要从多方面入手。不仅要从商业模式上创新，还要把云、大数据等最新技术真正应用到产品中来，更要找到
音频 Airtime – Airtime 是一款用于调度和远程站点管理的开放广播软件 Ardour – 在 Linux 上录音，编辑，和混音 Audacious