›设计原则若干集合转载

 

十二个设计原则:   摘自 http://blog.xiaoxiao.com.cn/2009/11/19/gdc-09-review-02.html
1. Have a big idea.
2. Be original. 设计一定是原本无双的。
3. Be memorable. 一定要能被人们记住。
4. Be relevant. 要有相关性。
5. KISS.
6. Simple doesn’t mean dumb.
7. Crooked line, straight picture.
8. Crooked picture, straight line。
9. Be an elephant carver. 不要花蛇添足,把多余的东西去掉。
10. In volvement. 设计让用户自己亲身参与进去。
11. If can’t be copy led or picture led (but it can’t be both) 你要表现文字就不要去表现图形
12. Ignore principle #11。规则是用来打破的,不要理睬上面11条原则,可能你会做的更好。

————–

Microsoft ,Apple,Google用户体验设计原则(转自Alite的网站)

细致的Microsoft

减少概念……增强信心:

你是不是引入了新的概念?为什么?真的必要吗?
你能去掉这些不需要的概念吗?
其中的区别有意义吗?
用户体验会延续同样的概念吗?
小的好或坏也很重要:

哪些重要的“小事”是经常会碰到的?
哪些小问题是你在着手解决的?
少做一些更好。
不要把小事从你的体验中去除。
为深思熟虑的细节制订计划。
修正小的错误。
看起来和用起来都很棒:

你的用户体验哪里最棒?它看起来有那么好吗?
用户第一眼看到的东西能够让人觉得它用户体验很棒吗?
用户体验符合期望吗?
用户很清楚能做什么吗?
是不是只提供了必要的步骤?
要解决的是让人分心的事,而不是可发现性

减少令人分心的事情。
不要让功能自己之间进行竞争。
致力于新的功能。
下列方法不能解决糟糕的可发现问题:
在开始菜单上添加图标。
在桌面上放置图标。
在通知区域放置图标。
使用通知。
提供首次运行体验。
提供功能教程。
旋钮和问题前的 UX :

调低问题的音量。
只问一次。
不要要求配置来获取数据。
这个问题是不是已经问过了?
寻找合并统一的机会。
个性化,而非定制化:

这个功能是否能让用户自己来表述元素?
你是否能够区分个性化和定制化?
个性化是需要成为新的功能,还是可以利用现有的功能和信息(如用户的位置、背景图片或排列方式)?
体验的生命周期:

考虑下列各个阶段下的用户体验:
安装与生成
首次使用与定制
常规使用
管理与维护
卸载或升级
以一个已经使用了 12 个月的用户身份来审视整个体验。它是否具有:
合理的内容
合理的“音量”
为移动人士建造:

所有的 UX 原则对于 12 英寸和 20 英寸的屏幕都是等价适用的。
允许用户被打断。
考虑启动和中断(快速恢复,不要妨碍其他用户体验)。
考虑获取或失去连接。
性能永远是用户体验的杀手。
ps:微软的细致可以渗透到产品中的每一个环节,或组成人机界面的每一个像素,实在令人钦佩。

轻巧的Apple

注重设计过程:

在设计过程中引入用户交互的5个目标:
了解您的目标客户
分析用户的工作流
构造原型系统
观察用户测试
制定观察用户准则 
做出设计决定 
避免功能泛滥
80% 方案
优秀软件的标准
高性能
易于使用
吸引人的界面
可靠
灵活
互操作性
移动性
人机接口设计准则:

人机接口设计准则
隐喻(尽量使用隐喻来描述程序的概念和功能,这样可以利用一些已有的概念和知识。)
反映用户的心智模型(用户的心智模型应该在产品的用户接口的设计中体现出来,主要体现在应用程序窗口的布局,工具栏上图标和控件的选择和组织,以及面板的功能等。)
隐式和显式操作(显示的操作清楚的表明了对一个对象操作的结果。隐式的操作通过一些可视化的线索或者上下文来表达结果。)
直接操作 (直接操作是隐式操作的一种,它会让用户觉得可以直接控制计算机显示的对象。)
用户控制一切(允许用户而不是计算机来启动和控制操作。)
反馈和交互(反馈和交互意味着通过合适的反馈以及和程序之间的交互从而让用户时刻知道现在发生了什么,而不仅仅是当事情出错时显示一个警告。)
一致性(在用户接口上的统一可以让用户使用从其他应用程序学到的知识和技巧。)
所见即所得(用户应该可以找到程序的所有功能。)
容错性(提供充分的容错性以鼓励用户使用程序的各种功能─也就是说,大部分的操作都是很容易恢复的。)
感知的稳定性(为了给用户一个稳定的感知,对于对象以及实施在这些对象上的操作,Aqua接口提供了一个清晰的限制集合;为了不破坏用户对稳定性的体验,程序应该保留用户更改过的配置,例如窗口的大小和位置等;提供程序运行的状态和反馈让用户知道程序正在进行的任务,同样能提高感知的稳定性。)
整体美学(整体美学意味着信息经过良好的组织并且和视图设计一致。)
避免“模式”(尽可能的让用户在任何时候都能做他们想做的事情。避免使用模式对话框来将用户锁定在某个操作中,以至于在当前操作完成前用户不能做别的事情。)
管理程序的复杂性(开发一个易于使用的程序的最好办法就是设计得尽可能的简单。)
设计的优先级
满足最低限度的要求
发布用户期望的功能
让您的程序与众不同
ps:苹果的轻巧不仅体现在它的工业设计上,更多的是它的操作系统和软件的用户体验层面。

简洁的Google

Jon Wiley- Google User Experience Designer 在一次专业分享中,提到了Google 的用户体验设计原则:

有用(Useful):以用户为焦点,关注他们的生活、工作和梦想。
快速(Fast):争取节省每一个毫秒。
简单(Simple):简洁就是力量。
魅力(Engaging):能够唤起新手的好奇心,能够吸引资深用户。
革新(Innovative):勇于创新。
通用(Universal):全世界适用的设计。
盈利(Profitable):为现行的和将来的商业模式做好安排。
优美(Beautiful):外观具有视觉愉悦性,但是不会令用户分心。
可信(Trustworthy):值得用户信赖。
人性(Personable):加入人性化因素。
ps:谷歌的简洁永远是它的产品特色,从谷歌网站的每个界面到浏览器chrome的用户体验与交互,都尽力把复杂问题设计得让用户感觉到最简单。

 ————–

设计师原则 转载自网络

第1条:
不可过分依赖电脑技术,切记,你是一名设计师,不是一名电脑修图员;
Not to rely completely on computer technology, it is a tool only and cannot
substitute your creativity. Remember, you are a designer, not a computer
graphic editor;

第2条:
不可一直追随流行设计风格
Be a creator and not a fashion-follower ;

第3条:
各用10%的精力涉足十门设计学科,不如用100%的精力涉足于一门学科。
Trying ten design fields simultaneously but badly is worst than concentrating on one
field and master it;

第4条:
不可将自己都认为有问题的作品向公众发表;
Be professional and not to release any art works that you don’t like;

第5条:
不可因低价商业项目,而放低对作品的要求;
Not to lower the quality in view of low business value of an art work;

第6条:
不可凭主观意识评价他人作品;不可人云亦云;
Not to criticize other’s artwork merely on the ground of one’s preferences
nor just replicate comment from someone;

第7条:
不可闭门造车;了解一些历史、哲学和人文,将对你的作品大有好处;
Not to create artwork without any ground. Great works usually come from
the understanding of the culture, history and philosophy;

第8条:
不论身份高低,须保持歉虚的态度;
Keep yourself modest to people, no matter you are just a novice or a master;

第9条:
永远坚信:设计可以拯救你的国家,可以改变世界。
Always believe that design can save your country and change the world.

——————————

Categories: 用户体验文集(转)
Comments (0) Permalink

›马化腾关于产品设计与用户体验的培训(转)

昨天听了pony在峰会上的讲座,收获颇丰,晚上回家后把记录的笔记整理了一下,先放上来和大家分享一下。整理时间较短,如有不周全之处,大家谅解:)
背景:pony是公司的首席体验官、首席产品经理。这次在产品峰会上pony将自己平时经验的积累与大家交流,体验较细。这次分享研发管理部,设计中心整理了些材料。主要的案例是qqmailqq影音的内容。以此为demo来讲解。
pony的讲解主要分为三大部分:产品设计、产品运营、交互设计。
在开场首先提到,互联网同类产品竞争激烈,只有抓住用户的心才能持续走下去。产品要赢得用户的心,要从一些小的点来赢得用户。 第一部分:产品设计
这个部分,感受最深的是两个词:核心能力、口碑。这部分还着重提到了pony对产品经理素质、开发人员心态的期望。
核心能力
任何产品都有核心功能,能帮助到用户,解决用户某一方面的需求,如节省时间、解决问题,提升效率等等。
很多产品经理对核心能力的关注不够,不是说完全没有关注,而是没有关注到度。核心能力不仅仅是功能上也,也包括性能上的。对于技术出身的产品经理,特别是做后台出来的,对于性能的关注,如果自己有能力、有信心做到对核心能力的关注,肯定会渴望将速度、后台做到极限。现在很多产品都没做好,一抓问题一大堆。如,前阵子网页速度优化,好多东西可以优化,一下提速好多,之前不知道都做什么去了。之前用户忍受了很久,同时浪费时间、浪费我们的资源。不抓,都没人理,很说部过去。要在性能方面放入更多精力。
谈到核心的能力,首先要有技术突破点。如做影音的时候,不是要做人家有我也有的东西。以前公司做的你有我有的东西,总是排在第二第三,虽然也有机会,但缺乏第一次出来亮相失去用户的认同感。
第一要关注你的产品的硬指标,在设计和开发的时候要考虑到外部会将对它与竞争对手做评测。如播放能力,占用内存。qq影音的核心性能和速度直接超越暴风影音。这样就能看到用户很多的好评和口碑。所以之后如果qq影音不出大问题,发展的势头将会很好。
硬指标评测cpu占用、高清加速,当时也有很多发展方向,如网络播放啊、交流啊、分享啊,也是思路。现在都砍掉,就是要做播放器,是用户的需求,纯用户需求不需要多少钱的。高清的,并不是很多人需要的,但是是高端用户的需求(这个后面口碑创造会再提到)。只有硬指标满足了,用户说,我这个破机器,暴风影音不能放,qq影音能放。这句话说出来,这样口碑就出来了。用户知道你行,差异化出来了。口碑要有差异性
核心能力要做到极致。要多想如何通过技术实现差异化,人家做不到,或者通过半年一年才能追上来。
如,用户总评论qq的时候说用qq唯一的理由是传文件快,有群。于是这些就是我们的优势,那我们就要将优势发挥到极致。我们需要更加深入的去想,要想到要不要做传输速度、中转啊。离线传文件在邮件体现就是一个中转站,超大文件,也不难,就是要去做。产品部门很快的去做,去测试。用户用的量也不一定大,但几个月用一次,口碑就来了。用户会说,我要传大文件,找了半天找不到可以传的地方,万般无赖之下用了很烂的qqmail,居然行了。于是我们的口碑就来了。做了很多测试、逐步放量,看变化,因为到期就删掉,成本也没提升多少。
要做大,要考虑到如何做到极致让人家想到也追不上,我们这么多年在idc上的功力不能浪费,需要我们去做。高速上传、城域网中专站,支持高速地上传……,又发现问题,如不在邮件,在im做怎么体验,这个我们在后面要逐步考虑到做起来。我们的目的是要让用户感到超快、飞快,让用户体验非常好。这些都需要大量技术和后台来配合。
产品的发展都需要产品经理来配合。现在我们产品经理有是做研发出身的不多。而很多产品和服务是需要大量技术背景的,目前我们希望的产品经理是非常资深的,做过前端、后端开发的技术研发人员晋升而来的,刚毕业的人员来做产品经理很人担心。好的产品最好交到一个有技术能力的、有经验的产品人员手上,会让大家更加放心。如果产品人员太烂,让很多兄弟陪着干,结果发现方向错误是非常浪费和挫伤团队士气的。
产品最难的是订优先级和先后次序。要看哪个是用户最核心的。功能好不好不是说有用户用了,用量多少了,写个报告统计下流量证明是好。这个是很错误的,好不好要看用户是不是要用这个功能,用户要用的实时出现。腾讯很多产品经理的激情还不够,做出来的产品比较大路货。虽然挑剔不出很不对的东西,但放出去用户也没有感觉,最后就不了了之。pony有时候很痛心,希望大家在产品设计之初就想的透彻一点。产品经理需要投入更多的关注度,关注度不一样,结果出来的很不一样。
口碑
做产品要做口碑,要关注高端用户、意见领袖关注的点。以前的思路是抓大放小,满足大部分小白用户的需求。但是高端用户这块是真正可以拿口碑的。
如何提高口碑,看最高端用户的关注,这个是在基础功能比较好的情况下考虑。如邮件搜索啊,rss啊,这些是很炫的用户会在博客和论坛里面提及的。做起来也不难,在有能力的情况下保证。在产品已经成型的情况下,要考虑到,对高端用户的心态要不一样。如果想要获得高端用户的口碑,还需要在产品的设计上大气些。如,让用户在我们的qqmail上使用别的邮箱的地址,而不带任何自己qqmail的尾巴。之前我们做的时候不会自动保存别的邮箱的地址,自己心里打个小九九,让别人不方便使用外部邮箱地址,好使用我们的。这些小九九,高端用户都是看的出来,反倒不好。所以要改掉,要做到真正的方便到用户。 改变用户习惯要让他信任你,改变有过程的,需要通过我们的努力让用户慢慢改过来。如,关闭数字帐号,发现很多bug,拍拍都不知道改。如,独立密码,之前不是双密码,而是改整体密码。
需要满足高端用户,让他不要怀疑你、bs你。如浏览器到兼容,可能你会考虑很多浏览器的覆盖率不高而不去做,但在高端用户来看,这是个态度问题,如果你的产品连这个都没考虑,其他的我就都怀疑了。你这个产品团队的意识好不好。再如同文件夹是否对齐,是否会引起杀毒软件的报警,都是小事但要关注。
个性化服务,并不是大众化服务,也是拿口碑的。
一个产品在没有口碑的时候,不要滥用平台,如要im带呀,投入营销资源呀,要marking联系pr公司投放广告呀,广告位提要求……等着人家砍,想一半也够了。产品经理精力好像分布的很好50%产品、30%营销、20%……。如果你在基础处控制的好,也可以。但90%的时候第一点都做不好。如果你的实力和胜算不到70-80%,那么把精力放在最核心的地方。在已经获得良好口碑,处于上升期的产品才考虑这些。
产品经理关注最最核心、获得用户口碑的战略点,如果这块没做透,做营销只是告诉用户过来,失望,再花更多的精力弥补,是得不偿失的。当用户没有自动在增长(用户会主动给朋友推荐来使用我们的产品的时候),看着用户的增长,否则不要去打扰用户,否则可能是好心办坏事。这个时候,每做一件事情,每加一个东西要很慎重的考虑,真的是有建设性的去增加产品的一个口碑。当用户口碑坏掉后,再将用户拉回来很难。
加功能,在管理控制功能上也要有技巧。在核心功能做好后,常用功能是要逐步补齐的。产品在局部、细小之处的创新需要永不满足。作为一个有良好口碑的产品,每加一个功能都要考虑清楚,这个功能给10%的用户带来好感的时候是否会给90%的用户带来困惑。如果有冲突的要聪明点,分情况避免。每个功能不一定要用的多才是好,而是用了的人都觉得好就是好。
做产品开发的时候需要有较强的研发机制保证,这样可以让产品开发更加敏捷更加快速。有些需求,提一下都可以得到很快反应。qqmail也会每天排好规划,为什么能很快反应,如文件加锁。有些产品做个东西写ppt、做汇报……,人家顺手就做了。很多产品不敏捷,大家要敏捷点、就算是大项目也要灵活。不能说等3个月后再给你个东西看,这个时候竞争对手都不知道跑到好远了。
开发人员的心态要关注产品,不要是公事公办的态度。你要知道用户、同行会关注你的产品,在这种驱动下开发人员要自动去完成。不能说什么都要产品做好后,流水线样的送过来我才做。开发人员要参与,40-50%左右的产品最终体验应该是由开发人员决定的。产品人员不要嫉妒有些工作是是开发人员设计的,只有这样才是团队共同参与的。如果都是产品想的就完蛋了,那么这个team做这个产品没有什么机会,必然会产生产品迭代慢的效果这样一个格局太不行了。 运营式管理
这个部分感受最深的一个词:天天用。这部分还谈到了pony眼中产品经理的一些基本要求。
我们的产品不是单机版,需要有强的用户感和技术功底外,很重要的是服务。我们要关注很多很复杂的内容,如架构啊,应用啊,产品需要有更好的架构,这个是需要花很多精力,常态下可能看不出来。所以需要高层从kpi上考虑。这个是考功力,谁做的好,总办领导是看得到的。设计的好的架构不会手乱脚乱。如把核心的东西做成组件模块分发。
发现产品的不足,最简单的方法就是产品天天用。天天去看,去论坛,去博客、去订阅。产品经理要敏感点,找出你的产品不足之处。有的产品经理说找不出来很奇怪,上线的时候坚持三个月天天用,问题是有限的,一天发现一个,解决掉,这样慢慢的已经开始逼近你那个很有口碑的点了。不要因为工作没有技术含量就不去做,很多好的产品都是靠这个方法做出来的。对于高层来说,不仅仅是安排下面的人去做就可以了,一定要自己做。这些都不难,关键要坚持。意识要提高。你要做到每个周末,都心痒痒要去做。心里一定要想着,这个周末不试,肯定出事。这样坚持,到一个产品基本成型,就可以去看下个产品了。
从哪个地方找,论坛啊、博客啊,rss订阅啊。高端用户不屑于去论坛提,在博客提,需要产品经理自己去追出来。如qqmail、影音的产品经理自己去查、去搜,然后主动和用户接触,解决,有些确实是用户搞错了,有些是我们的问题。产品经理心态要很好,希望用户能找出问题我们再解决掉。哪怕再小的问题解决了也是完成一件大事。有些事情做了,见效很快。运营方面要天天去看的,产品经理要关注多个方面,比如说你的产品慢,用户不会管你的idc烂或者其他原因,只是知道你慢。产品经理要全面,服务器端哪个方面的问题能找出来。跟踪用户定位问题。如果pony都能搜索到的问题,没看到产品经理出现,那么就是你没做到位。 交互设计
交互要求我们细致,视觉简洁清爽。
产品经理要想到自己是个挑剔的用户,想像自己是个笨用户,复杂的看不懂。
产品人员的精力有限,交互内容很多,所以要抓最常见的一块。流量、用量最大的地方都要考虑。规范到要让用户使用的舒服。要在感觉、触觉上都有琢磨,有困惑要想到去改善。如鼠标少移动、可快速点到等等。
像邮箱的一个按钮返回放在哪儿,上线测,放右边还是左边,大家都会多放琢磨,怎么放更好,并上线尝试,现在的方案折中比较好。如输入邮箱密码出错,输入框内的内容select上,不用用户清楚可以直接输出。这些都是对用户体验的优化。
如对同个用户发信,在此用户有多个邮箱的情况下会默认选最近用的一个帐号。这些需求都小,但你想清楚,用户就会说好,虽然用户未必说的出好在哪儿。
产品的使用要符合用户的习惯,如写邮件的时候copy东西,更多人习惯用键盘来操作。虽然有些技术难度,但也可以解决。交互,对鼠标反馈的灵敏性,便捷性。
不强迫用户,如点亮图标。如qqmail,不为1%的需求骚扰99%的用户
操作便利,如qq音乐,新旧列表,两者都要兼顾到,如qq影音的快捷播放,从圆形到方形,最后因为影响性能而放弃。
美术、淡淡的,点到即止,如qqmailqqmailui上的启发,不用太重也能做的很好。后来用在大量的产品,如hummer、影音。有图案和简洁不矛盾。
重点突出,防止不必要的低龄化,还提到了一些内容,如产品成功关键点等等,这些在ponyppt上有,没有记下来,大家可以在之后腾讯峰会吧(http://km.oa.com/group/forum)直接看ponyppt最后pony谈了一下有些产品的态度问题——态度很好,不解决问题。只做表面功夫,与其花一段时间写个长长的报告,不如实实际际的去解决问题。
外部也有很多优秀的产品可以学习,学习不是学皮毛,学样子,要学会。
外部可以学习的优秀产品,web类的,googleyahoofacebookapple,非web类的没有记录下来。 总结一下:
1、核心功能要做透,做的人家追不上,自己的优势要尽量的发挥;
2、产品口碑要建立,要关注高端用户,要调整自己心态;
3、敏捷、快,产品迭代要快,快速实现、快速响应,要做到真正的迭代;
4、产品人员要全面,要能找出核心需求,要关注技术(架构、服务是不是好),要关注产品(天天用),要关注用户(还需要出去寻找问题并解决);
5、开发人员心态要好,要有参与感,不要被动的等;
6、交互设计简洁,关注要点,当自己是个挑剔的、笨的用户;
7、想办法利用公司的资源,如pony等人都是大家的公共资源,要争取到pony对自己产品的关注,会给你的产品带来很多好的指导和创意。(这个不是pony说的,是后来jeff提到的,不过很实在,pony做过这么多的产品,有这么好的产品感觉,如果给你的产品提出建议,是对产品很大的帮助)

Categories: 用户体验文集(转)
Comments (0) Permalink

›再见,Google(转)

再见,Google

简介

Douglas Bowman

Google首席视觉设计师,2002年于旧金山创建Stopdesign,为Google、Blogger等公司设计页面及应用,2006年加盟Google,负责视觉设计,2009.3.20离开Google。
 

第一部分[共两部分]
今天是我在Google的最后一天。
约在三年前,我开始了在Google的工作。从零开始创建视觉设计团队、幸运的是我聘请到了一支由非常优秀的设计师组成的团队。我们将视觉设计作为一门学科带进了Google,而且我们一起做了非常出色的工作。我非常为我的团队而骄傲,祝福他们,还将有很多挑战性的工作在前方等待他们,但是于我而言,离别的时刻到了。

我有别的事情在召唤吗?是的,这个问题将包含在第二部分。所以我的离开仅仅是离职[译注:意指不是离开设计],但是我也不会为我离职的原因来涂脂抹粉。Google的经营规模是早期吸引我的一个原因,可能影响数百万人?在哪儿签字?[译注:意指同意加入]不幸的是,我当时没有看到背后隐藏的一个小问题。

当我加入Google并成为公司的第一位视觉设计师时,Google已经七岁了,七年对于一个没有经受过一流训练的设计师的公司来说是漫长的。当时Google的员工中有很多的设计师,但是大多数设计师是计算机学科[CS]或者人机交互[HCI]学科出身。 而且这些设计师中没有一个在高级别,被尊重的管理层职位。没有一个能够通晓设计的原则与要素的人在[或者接近]掌舵,一个公司的设计决策最终被耗为乌有。当每一次新的设计决策出现时,批评者们大喊犯规。没有信念,疑惑滋生,注定失败。“这是正确的举措吗?”当一个公司充斥着工程师,它就工程化的去解决问题。把每个决策简化为一个简单的逻辑问题。从不考虑主观因素,唯数据是从。数据反应不错?Ok,发布。数据反应不好?回到图板。最终数据成为了每次决策的主要依据,这僵化了整个公司并且扼杀了作出任何大胆设计决定的可能。

是的,的确在Google一个团队[译注:意指视觉设计团队]是无法在两种蓝色之间有决定权的。所以他们测试了41种蓝色调[译注:可能是google首页左上方的工具条,我不确定]来看看哪个表现更好。我最近甚至有一次讨论关于Border应当是3、4还是5个像素宽度这种问题,并且要求证明自己的观点。我无法在这种环境下继续工作。我已经变得厌倦了争论这种细小差别的设计决策。在这个世界上还有更多激动人心的设计要去探寻。

我不能说Google这种依赖数据是错误的,而且我不能确切的指出财务问题或者用户数缩减来证明这些做法统统是错的。毕竟,这与数十亿股东资金休戚相关。公司有数百万全球各地的用户,这不是一个简单的任务。Google动力十足,而且管理层找到了良性运转的方式。当我加入时,我本来以为有可能帮助Google改变原有的设计理念。但是我最终明白了在我到来前Google的设计理念存在已久了。Google就像是一艘超级航母,而我只是一个试图把它推到正确方向上的小橡皮艇。

有曾经在Google工作过的机会,我很感恩。我学到的比我曾认为将要学到的更多。我会怀念那些免费的食品,我会怀念偶尔的按摩,我会怀念那些作家、政要和名流们的演讲或演出。我会怀念有机会在那些酷玩[cool toy]还没有公布于世之前去体验。最重要的是,我会怀念曾经和一群我所知道的最聪明绝伦才华横溢的人一起工作的日子。但是,我不会怀念那个将数据视为裁决之剑的设计理念。

Categories: 用户体验文集(转)
Comments (0) Permalink

›About Face 3 交互设计精髓学习笔记

  • 实现模型(Implementation Model)反映科技,心理模型反映使用者的想像,我们设计得是表现模型,越接近用户的心理模型则该设计越成功
  • 优秀的用户界面也采用相同的方法进行平衡。它既不迎合新手,也不迎合专家,而是把大部分工作放在满足永久的中间用户上
Categories: 用户体验文集(转)
Comments (0) Permalink

›时尚:可用性的一种有效安慰剂(转)

转自userfree.cn

原文链接:http://www.usabilitynews.com/news/article5486.asp

让我们极力忍受不适并说出一个困难的真相:有时候时尚比可用性更重要。

为什么说出这句话如此困难呢?也许因为我们花了几十年的时间试图让开发者和设计者关注用户的任何需要。不仅如此,我们还从无到有地建立起一个行业并产生费用,以此证明我们的存在。因此,很难承认简单可用性只是整个用户体验的一个组成部分。

不久前,我们研究了两个版本的手机菜单屏幕。第一个版本显示12个图标,每个图标下对应一个名称;第二个版本显示相同的图标,但是没有图标名称。所有试过两个版本的人都在有名称的版本上表现更好。但是,他们极其一致地偏爱没有名称的版本。为什么?没有名称的版本比有名称的看上去更时尚,而且因为它也不是太难使用,时尚就战胜了可用性。

传统的可用性定义包括三个方面:效率,有效性和满意度。但值得注意的是,有时这几个方面是互相竞争的,效率并不总是胜出。例如,某些时候时尚增加了满意度但却牺牲了效率, 有些时候却又不是这样。

以iPhone做例子。iPhone是公认的一个易于使用的设备,它在市场上取得了惊人的成功。然而对许多任务来说,相比较物理按钮,触摸屏并不是有效或者高效的设备。但是当我们和拥有iPhone的人谈论它时,大部分人会说触摸屏使它更好用。如果你指出触摸屏实际上需要他们花更多时间完成某些常见任务时,他们会承认这点,但坚持认为它就就是很简单。触摸屏太有吸引力了,并且苹果出色的工作已经将触摸屏变成一种时尚标记。

鼓吹良好界面的人们能做些什么呢?我们不能放弃使基本交互简单愉快的斗争,但我们也不能忽视吸引人的、时尚的设计给设备和界面带来的推动。你可能知道安慰剂效应,仅仅相信我们正在被精心照料就能带来纯粹心理上的好处。但问题就在这儿。即使当优秀医疗研究者不遗余力地从他们研究中消除安慰剂效应时,好医生还是尽其所能地扩大它,甚至在他们真正开药时也这样。提供治疗的同时,他们提供一种权威感,让病人知道他们被很好地照料,因此患者不但从化学药物,也从希望的力量中获益。

可用性研究人员应该采取类似的办法。我们应该了解产品的哪些方面使人们更有效和高效。但是,我们也应该随时关注安慰剂效应。寻找生活中实际的例子,某个东西如此美丽和令人愉快,即使它不具备效率或者有效性,也应该被留下来。当然,我们还应考虑是否有可能以某种方式结合起来,两全其美,创造一种既美丽可爱又有效高效的东西。但是,如果你不能做所有的一切,请记住,有时“美丽和令人愉快”更重要。

Categories: 用户体验文集(转)
Comments (2) Permalink