[理论] 掌握可用性规则
--------------------------------------------------------------------------------
□ 作者:stiff(整理) 2004-1-13 17:52:08
1. 为实际工作设计
这意味着你这次的资料收集,与客户打交道的目的,不是只为了能够做出手头上的一张光盘。这是你的一次人生经验,对以后接项目都很有帮助。现在谁都知道:客户喜欢花哨的东西!这就是重用;不要对客户讲技术,这也是重用。为实际工作设计,就是要抓住软件用户的需求。“让用户参与到这个过程中,但不要盲目接受用户或客户提出的功能需求。”,这是老外的客户,中国的客户呢?就象liubopxn在http://www.mobiusclub.com/dispbbs.asp?boardID=7&ID=140中阐述的一样。更多从重用规则需要我们自身来完善,这是莫比斯俱乐部把大家汇集在一起的目的:整体提高,告别单一的埋怨与低效!
2. 不要急于具体化
或许是用户太过于挑剔,但实际过程是怎么样的呢?接到一个项目,然后和客户坐在一起商量一下怎么做,因为客户不懂技术,所以你谈话时也会避免这一点,但作为一个项目需求分析人员,这样做就是你不对了!好的项目需求分析文档能够将专业的软件需求用通俗的、大众化的文字描述出来,以便让客户能够看懂。你提出技术上的要求,将其转化为通俗的文字,解释给客户听,客户同意了,在你的合同(协议)上签字,这才是你应该接着做的事情。和客户草草聊过之后就急于制作演示是我们容易范的错。后果就是无休止的返工。因而造就了这个行业的哀声载道!
3. 避免为创新而创新,不要成为时尚的奴隶
这里我不谈论界面在艺术的创新,而是指软件运用的技术上的创新。什么是创新?什么是时尚?客户喜欢看Flash动画,因而他提出这个要求,这不是创新,因为Flash普及到一个不懂电脑的人都知道了,这已经变成了大众化的需求。如果说,用户既要加Flash,又要加视频,这是很传统的要求。我们的创新可以体现在“不可辩识的控件、可读性差的布局、不能工作的导航设计”上,“用户界面设计有自已的流行趋势,重要的是保持现状。”
4. 努力建立有效的交互
有效的交互来自于对客户需求的收集。很简单,一个演示应该具有“上一步”、“下一步”、“播放”、“暂停”等按钮。后来就增加了音量控制按钮,他包括两种:一种是带音量开关的,一种不带,二者都有音量大小控制滑杆;不要试着建立一个文本类型的菜单,这需要用户按住鼠标不放然后滑动来选择菜单,也不要尝试使用过多的右键菜单,一般用户很少会想到这一点;不要将你的程序直接退出,多加一个询问是否退出的对话框;为演示增加一个最小化的国内按钮;不要试图将所有的按钮都集中在一个地方;也不要吝惜界面的空间而将按钮隐藏起来。导航条应该随时随地清晰可见......
5. 为实际工作试用界面
软件做完了,检测分两步,一是自己的功能性检测,二是用户的操作性检测。这就对你的程序提出了要求,你必须做到程序有接口,与界面的基本脱离,这样,不管用户界面怎么变,你的代码不用变动,因为你知道功能,你的任务的完成功能需求。用户会要求添加几个按钮,添加一些转场效果,这是合乎情理的(大家不要骂我哦)。不要指望一次交货成功,用户的意见应该成为你积累的资本,把用户的唠叨当做是软件的检测吧!不要一味的抱怨,这解决不了问题,努力寻求用户与技术间的结合点,我们才会做的开心一些!
掌握可用性规则之二
细致的用户界面设计是高质量软件的标志之一。设计良好的用户界面使用户与软件的交互更有效率、更能减少用户的错误倾向,更快地学习和更富有成果。好的界面设计不仅仅是屏幕布局周全的考虑,它着眼于在充分理解需完成的工作的基础上创建一个用户界面与系统的有效架构。下面这些规则将能帮助开发小组提高项目界面设计的质量。
1. 为实际工作设计
软件是一个使能工具,让我们更快更有效率地处理事务并延展我们的能力。除了一些入魔的技术专家和全心的质量至上者外,大多数人使用软件不单单是为了享受运行其他人代码的乐趣。不管是用它在互联网上查询明天的天气还是控制微波炉的热量来加热汤,或是为病人远程诊断,软件总是一个工具,一个实现目标的方法。考虑到这点,开发者和设计者就能正确地理解用户要完成的工作和为了成功实现用户需求。
关注实际工作需要考虑为什么用户在完成一项任务时要采取不同的操作,注意不要迷失在实际工作之外的管理和其他事务上。同时要避免技术的诱惑。实现一些很酷的软件特性而试图解决实际不存在的问题,结果只是使用户界面混乱和易于混淆。
留出时间和努力去充分收集相关信息和分析软件用户的需求。让用户参与到这个过程中,但不要盲目接受用户或客户提出的功能需求。毕竟,用户可能是应用领域的专家,但他们对软件的设计和分析有可能并不熟悉。保证在开发过程中引入一种有效的方法,能够收集、组织、验证支撑工作的信息。学习问题领域的描述语言,掌握工作的流程,理解每个需求是怎样以及为什么有机结合成为一个整体项目。然后整合分析成果到界面设计过程中并应用这些认识驱动整个软件的设计。
2. 不要急于具体化
开发者一贯倾向成为一个解决方案的提供者,喜欢解决问题并希望能尽快看到努力的结果。有时这种快速获得结果的倾向性导致的是一个平庸的解决方案。现今的可视化开发工具更是鼓励了这种倾向,纵容我们简单地通过在屏幕上拖放预先定义的组件来解决界面设计问题。举例来说,通常很少考虑组合框还是一个下拉列表是最好的选择。在开发早期不要急于具体化,开发者和小组在开发过程中可能创建更可用的设计并提出高超的用户界面设计方案。不要过早定义实现的细节,而应在更好理解所需完成的工作和更好把握用户工作流程中的每一个步骤的意图之后。如果开发小组已经跳跃到实施具体方案的阶段,应注意在设计过程中将那些想法置于一个“反馈—提出”的循环中。
一些技术如抽象原型,能以一种通用的方式在贴纸上表达必需的用户界面元素,可以帮助开发小组先关注整个用户界面结构。抽象原型技术能够保证软件提供所有必需的组件,也能保证逻辑地安排这些组件,而非早早地进行界面图形设计和界面组件选择。
3. 避免为创新而创新,不要成为时尚的奴隶
界面设计中新的东西并总不是好于旧的东西。应用得当的话,新的界面组件和交互设计方法将是一个强大的工具并将占领市场优势。过不多久界面设计领域里真正先进的的方法就会被拷贝流传而成为标准设计词汇的一部分。但是,许多创新的界面设计比传统的界面组件和交互设计可用性更差。
另外要注意的是避免为艺术而创建艺术品。我所见到的一些可用性最差的软件就是图象艺术家或即将成为图象艺术家的作品,他们迷失在视觉效果里最终导致不可辩识的控件、可读性差的布局、不能工作的导航设计。效率和美学并不总是互斥的,相反,最好的软件是两者的结合。虽然人们的艺术的才能总是有限,但是可以集中注意力创建有效、高可用性的满足用户需求的软件。
最后,不要假定界面设计应模仿一种特别的微软模式或应用至少一种最近的界面组件。用户界面设计有自已的流行趋势,重要的是保持现状。新的组件和交互术语(idiom,Alan Cooper 的称呼)每天都在产生。就象房子、车子或者衣服,软件的风格在变化和进步,但只要简单地看看用户界面设计就可以跟上当前系统设计。特别地,如果设计的软件的运用与微软的应用紧密结合或关联,在很多情况下,这是一个合理的选择。然而,追随领导不是一个通用的解决方案。有一个例子,是我领导评估一个模仿Microsoft Excel界面设计的货币交易系统的可用性。设计的决策使得用户可视分析信息非常困难,从而导致笨拙的、低效率的导航。货币交易员需要的新交易系统并不是微软电子数据表的界面设计。
4. 努力建立有效的交互
没有人喜欢乏味、笨拙的工作。确认你的软件没有增加其他人工作的不愉悦感。计算完成一项普通工作所需的击键次数和点击鼠标的次数。让简单的事情简单处理、常用的交互快捷完成。不要将重要信息或关键处理淹没在多个窗口之下或者隐藏在一个“名不符实”的菜单里。应用建模技术如导航映射来帮助设计高效的工作流和避免过长或导致死结的导航路径。只要在纸上画一个原型,用户界面设计的原则如基本效率、任务一致性和任务可见性就可以用上,并且能指出问题所在区域。
正如令人难忘的Dilbert 的漫画指出的一样,一些软件开发者为用户设计了额外的无意义的步骤,惩罚用户犯下的任何错误,让用户象跳圈一样完成日常工作。如果小组里某些成员显得憎恶用户,让他去见见临床医生,而不要在“Edit”菜单里加上”Other”。
5. 为实际工作试用界面
作为最后一个保证用户界面设计质量的措施是:让每个设计和开发软件的成员最少连续半小时使用它,连续使用一个小时更好。使用实际的数据——用户实际使用的数据。如果由于保密或安全的原因不能使用实际工作的数据,可以让客户或用户建立足够多的“伪数据”(不仅仅是10 到20 条记录),能精确反映实际数据的复杂性、潜在的错误和模糊性(subtleties)。作为一个独立的校验,确信测试了所有数据域的最大长度,正确性和过率检查。经常令人惊讶的是在数据库正确定义的域在用户界面上却是长度不够或定义不当。如果定义的数据域是25 个字母的长度,试着输入25 个字母。你能在屏幕上见到所有的25个字母吗?如果需要的话,邮政号码的输入框能处理国外字母和数字混合的编码吗?
是的,在许多公司这些问题都会归结于质量保证和数据库设计部门,但是,令人吃惊的是它一直被疏忽。所以,应用用户界面试用的经验来测试系统自身。注意到测试的过程象是汽车装配线的最终检查——客户将要看到和体验到。如果界面包括了数据输入域,输入50 或100 条记录,而不仅仅是1 到2 条记录。如果应用程序工作在不定的光照和噪音情况下,在这种环境条件下试用它。如果必需快速输入或屏幕快速反应,将开发小组所有成员置于同一个时间限制的压力下,然后问自己:每天我都想使用这个软件吗?我希望这些技巧能帮助你或开发小组回答:“是的”。
莫比斯俱乐部