交互设计原则优漫动游

  行为原则(描述产品在一般情境与特殊情境中应有的行为);  

  界面原则(描述对于特定的活动或过程,不同的人们有不同的心理模型,但人们很少按照计算机如何行动的机制来想象自己的心理模型,每个用户都自然地对软件如何执行任务有一个心理想象,用户通过这种心理想象来寻找原因而后深入了解机器的行为。  

  (2)少就是多;  

  在不断减少界面元素的情况下仍旧保留产品的功能。产品设计的极简主义方法就是努力理解目的,此类产品的用户想要达到的目标是什么?没有了这种目的,交互产品就是混乱的技术功能的集合,例如Google的搜索界面是一个经典的极简界面设计,其中的每一个界面元素都是直观而有意义的;iPodshuffle,HogBay软件的WriteRoom;但是一味要求简单化不值一文—减少是一种平衡活动,需要对用户心理模型的好的理解,前面提到的iPod有点奇怪,即用播放和暂停来关机,用菜单键来开机,一个经典的关系是视觉的简单会引起认知的负担,在这种情况下,这些行为很容易学习,出错的可能非常小,所以对整个产品的成功影响非常小。  

  (3)让用户直接操作产品,而不是强迫用户与产品讨论;  

  不应当把界面想象成与用户的两方对话,用户更愿意与软件进行和汽车一样的交互,这种理想的交互情形不是对话,更像是在使用工具。  

  (4)工具就放在手边;  

  为新手和中间用户提供的工具一般在工具栏或控制面板中,对专家用户来说,工具可以用键盘命令来得到。  

  (5)提供非模态的反馈;  

  当需要为用户提供信息或者反馈时,可以有多种表达方式,常见方式是在屏幕上弹出一个对话框,这种技术就是模态的,它让程序处于一种模式,在返回常态之前也就是在用户能够继续任务这前必须处理。通常通知用户更好的方式是非模态的反馈(无论在什么时候,用户的信息在主要界面中显示,而且不会停止系统的正常任务流和交互那么这种反馈就是非模态的)。例,Word2003中,需要了解文档中字数有多少,必须从工具栏中单击“字数统计”按钮,出现一个对话框,若想返回工作状态,则必须单击这个字数统计对话框中的关闭按钮,这个行为有悖于非模态的反馈,但在Word2007中得到了交互改变。  

  (6)为可能的设计,为可能做好准备;  

  程序员被按照能够创建处理多种可能的软件的能力来评判,然而不大可能的条件充斥在复杂的逻辑系统中,这并不意味着应把罕见的不平常的可能性直接带入到用户界面中,边缘情况突兀的出现是程序员设计软件的糟糕赠品,每天都使用和一年也用不了一次的对话框,控制选项一起出现在界面上。  

  (7)提供符合情境的信息;  

  展示信息的的过程也可能是扰乱用户知觉的过程,数量或者数值就经常被滥用,视觉展示信息的专家说过,数量的展示应该回答一个问题“与谁比较?”信息的含义应该视觉化的显示,数字只是辅助。  

  (8)提供直接的操作和图形输入;  

  软件经常以图形方式显式数值信息时失败,更罕见的是软件完全具有支持图像输入的能力,很多软件都要求用户输入数字,然后命令中将这些数字转换成为图形,很少有产品让用户画图,然后在命令中将图像转为数字向量。当一个清单需要重新排列时,用户也许想按照字母顺序排列,也有可能希望按照和个人的关系排列,所以应该能够把这些项目直接拖放为自己希望的顺序,而没有算法的干涉。  

  (9)反映对象和程序的状态;  

  (10)避免不必要的报告;  

  (11)不要用对话框来报告常态内容;  

  (12)避免空白的状态;  

  PowerPoint每次新建一张幻灯时都要求你选择基础类型,如果能够记住常用和最近用过的类型或模板并且作为新文档的默认设定都能够更好用。  

  (13)请求原谅,而不是许可;  

  当提到交互产品时我们常常说到“思考”,但这并不意味着软件应该有智慧并且试着通过推理论证做出正确的决定;相反,它应该做多数情况下可能是正确的事情,并且为用户提供强大的工具来帮助其进行第一次尝试,而不是仅给用户一个空白的状态,要求其接受,这种方式应用程序不是在请求许可,而是在请求原谅。  

  (14)要把命令和设置区别开来;  

  设置和启动一个功能之间差别巨大,前者也许包含后者,然而后者不应该包含前者,通常,任何一个命令启动10次,可能才设置1次,因此最好使用户在10次中的一次清楚地请求设置,而不是10次中有9次用户拒绝设置界面。  

  (15)提供选择,而不是提问;  

  用户不喜欢被问,不断的提问向用户暗示程序的特点如下,无知,健忘的,功能不强的,不主动的,不能自理的,烦躁的,过分要求的。  

  (16)隐藏弹射座椅的操纵杆;  

  (17)优化响应能力,调节延迟时间;  

  不同的交互方案会由于响应时间而非常“昂贵”你应该提议尽可能小的响应时间下尽可能丰富的交互设计,同时也要提供可以适应已经选择了而无法重新回退这类情况的设计。当响应时间是不可避免时,与用户交流状况为他们提供取消导致延长任务的方法,或者能够让他们在等待时进行其他工作。  

  交互设计原则:常见附加工作陷阱  

  不要强迫用户到另外一个窗口中完成影响本窗口的功能;  

  不要强迫用户记住他将事物放在层次文件系统中的哪个位置;  

  不要强迫用户调整窗口大小,当窗口在屏幕上弹出时,程序应该为其内容调整合适的大小。不要让它大而空,或者小而需要不停地滚动;  

  不要强迫用户移动窗口,如果桌面上存在空闲空间,将窗口放在其中,而不是直接将其放在已经打开的程序之上;  

  不要强迫用户重新进入个人设置,如果已经设置了字符、颜色、缩进或者声音,确信他不需要再做一遍,除非他想改变;  

  不要强迫用户在填充字段时满足完整性,如果用户想从交易登录屏幕中忽略一些细节,不要强迫用户输入,假定他不需要重输入,数据库的完整性不值得强迫用户;  

  不要强迫用户请求允许,这通常是不允许用户在输出的地方输入的症状;  

  不要让用户确认其行为,这隐含存在健壮的撤消功能;  

  不要让用户的行为产生错误。  

  交互设计原则:窗口行为  

  整体的视觉隐喻是用户能否理解系统的关键。  

  避免模态,模态是一种程序可能进入的状态,在这种状态下用户操作的效果与正常状态有所差异,它实质上是一种行为的转向。  

  层叠窗口,层叠窗口的概念是好的,但在真实世界中却不太实际,屏幕上同时运行3个或更多的应用程序或文档用户就得经受考验。也因此促使微软引进了任栏,而苹果公司则发明了Expose,Expose很吸引人  

  可以用来追踪所有打开的窗口,不过由于和Dock上最小化的程序集成的不好,所以使用起来公平是有些问题。  

  多窗格应用程序  

  微软的Outlook2007是多窗格应用的例子,多窗格的好处在于独立而相关的信息可以轻松地在单个独占屏幕上显示,并能将导航和窗口管理的附加工作几乎减少到零,对于任何一个复杂的独占应用程序,相邻窗格的设计尤为必要,特别是在一个窗格中提供导航或构造块,以及在相邻窗格中支持数据查看或数据构造的设计,似乎代表一种可重复的有效模式。现在的客户端技术比如Ajax,Flex本身已经可以提供类似于窗口的行为。  

  交互设计原则:对话框是另一个房间,去之前要有个好理由;把功能置于需要它们的窗口中  

  AdobeLightroom比Photoshop(调节亮度对比度的对话框)进步了很多,关键的操作都按照用途被安排在一起,在主窗口上靠近了被调整的的位置上直接展现出来。  

  交互设计原则:正确运用对话框  

  一个糟糕的设计就是用户界面上充斥大量的模态对话框,用户不得不在对话框的迷宫中前行,这这创造流畅的交互带来了很多困难。  

  把主要的交互操作放在主窗口中  

  很多设计师认为对话框是GUI中最主要的用户界面的习惯用法,这在很大程度上是对话框太容易实现的原因造成,于是很多应用程序使用对话框来提供用户和应用交互的主要手段,因此在大多数应用程序中,使用者被迫在主窗口和很多对话框之间跳来跳去,不可避免地带来疲劳和沮丧。  

  对话框适合那些主交互流之外的功能  

  我们需要把使用者从主工作流中强制带出来,让他们集中注意力关注在某个特别的交互上,这时对于这种交互主流程之外的功能或特性来说是合适的。任何可能会让人困惑、危险或者很少使用的功能放在对话框中可能都会有利。一些容易产生混乱的行为对屏幕图像产生立即和总体的改变,这种改变在视觉上对用户干扰很大,应该将其与不熟悉的用户隔离。对话框常适用于表达不常使用的功能和设置,可以用对话框将这些操作与更为频繁使用的功能和设置隔离开,对话框也非常适合集中于某个主题相关的信息,与该主题相关的所有信息和控件都放在一个地方,使用者无须在界面上到处寻找,从而减少了导航浏览的附加工作。  

  对话框非常适合用来整理关于某个主题相关的对象或者应用功能  

  对话框主要为两个主体服务,即熟悉程序的频繁使用用户,用它们来控制更高级或者更危险的设置:不熟悉程序范围和使用的用户,以及使用对话框学习基础知识的用户,这意味着对话框必须是紧凑和功能强大,快速而流利的,并且在使用上清晰和具有自我解释性。  

  交互设计原则:对话框的基础结构  

  每个对话框都必须有一个标题,来标示它的用途,如果某个对话框是一个功能对话,那么这个标题就应该包含这个功能的动作,一般采用动词;如果对话框用来定义某个对象的属性,那么其标题就应该包含该对象的名字或者描述,总之在属性对话框的标题中使用对象名;每个对话框至少有一个终止命令控件,被触发时会让对话框关闭或者消失,比如“确定”和“取消”,另外右上角的关闭按钮也是一个终止命令的习惯用法。  

  

猜你喜欢

转载自blog.csdn.net/UIKKA/article/details/132560693
今日推荐