人机界面设计
人的因素
人的因素主要包括
- 人对感知过程的认识
- 用户的技能和行为方式
- 用户所要求完成的整个任务以及用户对人机界面部分的特殊要求。
人对感知过程的认识
- 人通过感觉器官认识客观世界,因此设计用户界面时要充分考虑人的视觉、触觉、听觉的作用。
- 人机界面是在可视介质上实现的,如正文、图形、图表等。
- 人们根据显示内容的体积、形状、颜色等种种表征来解释所获取的可视信息。
- 因此,字体、大小、位置、颜色、形状等都会直接影响信息提取的难易程度。很好地表示可视信息是设计友好界面的关键。
- 用户从界面提取到的信息需要存入人的记忆中,供以后回忆和使用。在设计人机界面时不能要求用户记住复杂的操作顺序。
- 大多数人遇到问题时不进行形式的演绎和归纳推理,而是使用一组启发式策略,这组策略是以往对类似问题的处理中逐渐获得的。
- 因此,设计人机界面时应便于用户积累有关交互工作的经验,同时要注意启发式策略的一致性,不宜受特殊交互的影响。如,undo、exit等有统一的含义、位置和表示。
用户的技能和行为方式
- 用户本身的技能、个性上的差异、行为方式的不同,都可能对人机界面造成影响。不同类型的人对同一界面的评价也不同
- 终端用户的技能直接影响他们从人机界面上获取信息的能力,影响交互过程中对系统作出反应的能力,以及使用启发式策略与系统和谐地交互的能力
- 应根据用户的特点设计人机界面
用户分类
- 外行型:不熟悉计算机操作,对系统很少或毫无认识
- 初学型:对计算机有一些经验,对新系统不熟悉,需要相当多的支持
- 熟练型:对系统有丰富的使用经验,能熟练操作,但不了解系统的内部结构,不能纠正意外错误,不能扩充系统的能力
- 专家型:了解系统内部的结构,有系统工作机制的专门知识,具有维护和修改系统的能力,希望为他们提供具备修改和扩充系统能力的复杂界面
例如:WinXp控制面板的向导功能适合不太熟练的用户
设计问题
- 系统响应时间
- 用户求助设施(user help facilities)
- 错误信息处理
- 命令标记(command labeling)
系统响应时间
系统响应时间指从用户执行某个控制动作(如按回车键或点鼠标)到软件作出响应(期望的输出或动作)的时间。系统响应时间长会使用户感到不安和沮丧。稳定的响应时间(如1秒)比不定的响应时间(如0.1秒到2.5秒)要好。
用户求助设施
关于求助设施,在设计时须考虑如下问题:
- 在系统交互时,是否总能得到各种系统功能的帮助提供部分功能的帮助还是提供全部功能的帮助。
- 用户怎样请求帮助用帮助菜单、特殊功能键还是HELP命令。
- 怎样表示帮助另一个窗口中、指出参考某个文档(不是理想的方法)还是在屏幕特定位置的简单提示。
- 用户怎样回到正常的交互方式做的选择有:屏幕上显示返回键、功能键或控制序列。
- 怎样构造帮助信息平面式(所有信息均通过关键字来访问)、分层式(用户可以进一步查询得到更详细的信息)还是超文本式。
错误信息处理
交互系统给出的出错消息和警告应具备以下特征:
- 消息以用户可以理解的术语描述问题
- 消息应提供如何从错误中恢复的建议性意见
- 消息应指出错误可能导致哪些不良后果(比如破坏数据),以便用户检查是否出现了这些情况或帮助用户进行改正
- 消息应伴随着视觉或听觉上的提示,也就是说,显示消息时应该伴随警告声或者消息用闪耀方式,或明显表示错误的颜色显示
- 消息应是“非批评性的”(nonjudgmental),即不能指责用户
命令标记
在提供命令交互方式时,必须考虑以下问题:
- 每一个菜单选项是否都有对应的命令/li>
- 以何种方式提供命令制序列(如Alt + P)、功能键还是键入命令。
- 学习和记忆命令的难度有多大令忘了怎么办/li>
- 用户是否可以定制和缩写命令/li>
黄金原则
- 让用户拥有控制权
- 减少用户的记忆负担
- 保持界面一致
让用户拥有控制权
- 交互模式的定义不能强迫用户进入不必要的或不希望的动作的方式
- 提供灵活的交互
- 允许用户交互可以被中断和撤销
- 当技能级别增长时可以使交互流水化并允许定制交互
- 使用户隔离内部技术细节
减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直觉性的捷径
- 界面的视觉布局应该基于真实世界的隐喻
- 以不断进展的方式揭示信息
保持界面一致
- 允许用户将当前任务放在有意义的语境中
- 在应用系列内保持一致性
- 不要改变用户已经熟悉的用户交互模型
实现工具
- 创建设计模型后,通常可使用相关的工具开发界面原型,由用户检查,然后根据用户的意见进行修改,这些工具被称为用户界面工具箱或用户界面开发系统(UIDS)
- 它们把一般应用程序定义界面时所必需的界面元素,如窗口、菜单、窗口中的控件(如命令按钮、对话框等)预定义为对象,并预测每个对象可能需要作出的响应事件(例如单击鼠标或按键等),将这些预定义的对象组织成构件库,每个对象有自己的属性、方法和事件过程。
同时UIDS提供以下的内建(built-in)机制:
- 管理输入设备(如鼠标和键盘)
- 确认用户输入
- 处理错误和显示出错消息
- 提供反馈(如自动的输入响应)
- 提供帮助和提示
- 处理窗口、field和窗口内的滚动
- 建立应用软件和界面间的连接
- 将应用程序与界面管理功能分离
- 允许用户定制界面
使用UIDS软件工程师可以不必一点一滴琐碎地编写界面,而把主要精力集中在要解决的问题上
同时,在同一平台上开发的应用程序能有一致的界面风格,相似的任务总在相似的外貌的界面上运行,使用户在操作应用程序时感到得心应手,并对其结果有信心。
设计评估
- 一旦建立好操作性用户界面原型,必须对其进行评估,以确定是否满足用户的需求。
- 对任何一个应用系统,评估计划必须包含长期持续测试的方法,以便对界面在整个生命周期里出现的各种问题进行不断的评估和修正。
- 对于关键系统的界面设计,需要开发出特别的评估计划,例如核反应堆等系统的人机界面。
- 有效的设计评估包括专家评审和可用性测试。
专家评审
- 正式的专家评审需要依托专家作为支柱或者顾问,这些专家往往具有丰富的应用领域或者用户界面领域的专业知识。
- 专家评审可以在设计阶段的前期或者后期进行。
- 对于评审的结果,可以由进行评审的专家们出一份正式的 告,其中包含评审中所发现的问题以及对其修改的建议,或者由这些专家与设计人员或者管理人员直接进行面对面的讨论。
- 专家评审的方法包括启发式评审、指导文档评审、一致性检查、认知尝试和正式的可用性评审。
启发式评审
评审人员对界面进行评判,以便使其与一系列的设计启发规则相符合,如果评审人员熟悉这些规则并能够理解应用,那将对评审非常有利。
指导文档评审
检查所涉及的界面与组织内的指导文档或者其他的一些指导文档是否相符
一致性检查
检查所有同类界面的一致性,检查内容包括实际界面中的术语、颜色、布局、输入输出格式等与培训材料或者在线帮助是否一致。
认知尝试
专家模仿用户使用界面执行典型的任务。以执行频率高的任务作为起点进行尝试,但执行较少的关键性任务,如错误恢复等也都要尝试到。
正式的可用性评审
专家们组织一场讨论,整个设计小组的成员也参与其中,仲裁设计的利弊。
专家评审可能出现以下问题
专家对任务或用户缺乏足够的理解,且对项目目标有不同的意见,所以必须选择熟悉项目,经验丰富的专家组成专家小组
可用性测试
- 可用性:指的是产品的使用效率、易学性和舒适程度。
- 对界面进行可用性测试和评价,是确保产品可用性的重要手段。
- 通过各种可用性测试及早发现界面存在的可用性问题,不仅可以节约开发成本,提高产品的品质,还可以降低用户使用产品的心理负荷,减少操作错误,提高工作效率以及对产品的认可度和满意度。
- 可用性测试可以要求用户完成一系列任务,对用户的完成过程进行记录,再对记录进行评审。这可以给设计人员很大的启发,及时发现缺陷并改正。
虽然可用性测试有很多好处,但也至少存在两种局限性:首先,它强调的是首次使用的情况,其次只能涉及到部分的界面。因为可用性测试不能延续太长时间,很难确定长时间使用后的情况。
例如Microsoft公司的Msn Messanger产品的“用户帮助改进计划”,就是相当庞大的一个可用性测试计划。当然虽然问题可能会不断地出现,但在适当的时候,必须果断地完成原型测试并交付产品
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!