Ami Zhangv3.0

努力的UCD小兔’s blog

分类“小兔理论”的存档»

Zoom In和Zoom Out——人本设计沙龙演讲

Ami Post in 小兔理论

前阵子应Felix所邀,参加了第二届人本设计沙龙,做了一个演讲。关于演讲的主题,之前思量了很多,最后定下了这个主题:
In & Zoom Out ——产品体验的细节和整体把握

演讲的PPT:http://docs.google.com/present/view?id=dgm8fm6w_152hgzrxrg2

演讲的录像(当天全部):http://v.ku6.com/playlist/index_3777603.html
 
总体来说对自己的表现只能说一般般,因为这阵子忙碌的工作,准备不算是充分。演讲就不整体转化为博文了,去掉”路盲的兔子”这个看地图Zoom的例子,也去掉我当年打RO的故事,在此简述演讲想要传达的一些观点:

● 细节是否重要?

你在这一方白纸上看见了好大一块黑色、甚至好几块,觉得难以忍受、不改不行——但其实缩放到整体的视野来看,这些也不过是几个小芝麻粒儿。
所以,别太拘泥于细节。
细节的确有聚沙成塔的力量,每一个细节都在无形中影响你的用户。不过若眼前摆的事情或细节太多,不妨把你的视野zoom一下,把”芝麻”和”西瓜”分清楚,挑出来,抓住关键流程、和界面上的”关键细节”。

● 不同的”高度”,不同大小的视野

“站得高看得远”——不同的高度你能看到不同的风景。五万英尺的高空,你能看到整块的大地图;几十米范围内,你能看到附近所有的细节。所以不妨把你的视图多Zoom一些:
Zoom In, 放大看,能看到细节,能做到专注,做到细致;
Zoom Out, 缩小一些,能帮你在地图上分清小马路和主干道,抓住关键;
古时将军的帅帐里、或是近代战争的司令部里,必有一张大地图——看清全局,才能运筹帷幄,才能谈笑间樯橹灰飞烟灭。
当然,没有人能从整个大局到所有细节全都了如指掌,找对自己所在的高度、明确自己的视野范围很重要。在这个基础上,多Zoom In一些,能把事情做得更细致,从细节提升产品质量;常常Zoom Out,会便于更好地理解产品的整体,不论是目的、定位或者其他。

● 定位自己的视野

知道自己所处的这一块儿在整个地图上是个什么位置,有利于把自己的事情做好。
而关注自己疆域的同时,再把视野扩展开来,看到”邻国”乃至”全世界”,才能在整个市场上看清自己和竞争对手之间的关系,孰优孰劣,如何立足、如何获胜。

● 伙伴间的理解

最后想说的一点由于时间关系略过了,但是在讨论中有所提及,那就是在整个团队中,不同角色间的理解和协作。
若你能把自己的视野暂时zoom到伙伴的这一层,你能明白对方为何对某个细节如此坚持、或者为何要往某个方向锲而不舍,这是一种理解。
而若你不是设计师,而是个PM或是个BCD的老大,别老是拿细节和人过不去,相信他们吧,把握好你所在层次的工作。从产品的战略和定位,到功能、交互和最后的视觉和各个细节,都做好了,才会有真正好的用户体验。
后记:

定下”Zoom”这个主题,灵感来源于多年前参加的一个workshop。那个主持人老外在开始时为我们播了一段视频:镜头从一个躺着的人,逐渐缩放至整块草坪、整个城市、整个地球、整个宇宙……然后比例逐渐回复,回到这个躺着的人,再缩放至皮肤、细胞、甚至DNA、电子……最初准备讲义时,也想把这个例子找来用,可惜没有寻着(后来找到了,有兴趣的同学可以看看http://ishare.iask.sina.com.cn/f/7741933.html)。借别人的不如用自己的——自己画了几张抽象的圈圈点点,Felix提议说表达不清楚,后来我用了”路盲的兔子”作为例子。

Google Maps倒是很好地表达了我想扣的主题,当你的地图缩小一定的比例时,你会发现,周边设施不见了、小路路名不见了、只显示园区和主干道路名;虹口区、普陀区不见了,开始看到周边省市;随着一步一步的Zoom Out,最后连城市和国家名称都不见了,只显示几大洲和海洋。至于你要做的事情,是规划整个城市,还是让某一块小区做得面面俱到,zoom的比例自然不同,”细节”和”整体”之间也有不同的权衡。
 

用户期望的产生

Ami Post in 小兔理论

原发于UCDChina http://ucdchina.com/blog/?p=484

用户来到我们的网站,与我们的产品进行交互时,必定带着他的期望。是否能满足用户的期望,直接关系到是否能带给用户积极的体验。
那么,用户期望是怎样产生的呢?

品牌信誉

首先,用户期望可能基于你的品牌信誉,尤其是对你这个产品还没有初步体验和接触的时候。品牌信誉是从多方面累积建立起来的,产品本身的质量、口碑、公关和宣传……当你建立起一种品牌形象,用户自然会对你的产品产生相应的期望,比如IBM的本本应该有可靠的质量、NOKIA的手机很耐摔……在这次上海的书友会上Sky还举例,如果Google和微软同时推出一款互联网产品,我们很容易对Google有更高的期望——微软相对来说没那么擅长互联网产品,而Google,会让人期待又一个Gmail或者Gtalk、Google Reader… (全文…)

平衡广告和用户体验

Ami Post in 小兔理论

也许不少人都经历过这样的场景:在一个新的页面设计出来时,就有广告销售跑来说“要在这里放一个跨栏的Banner”、“在那里插一块文字链”……发现这样放广告破坏了页面布局、又给用户过多的视觉干扰,于是你以“影响用户体验”为由开始了争论和辩解。一番唇枪舌战后,也许你胜利了,砍掉了一块广告需求;也许你还是不得不妥协,心里暗底埋怨着广告破坏了原有的设计……

听一个同行的朋友说,“有些时候我们的想法和市场销售的不同,出发点不同,比较麻烦。常为了商业利益牺牲了用户体验,很难说服他们。”
做产品或者UED的,就难免要和市场销售或者广告部门有争执么?

所有关心和致力于用户体验的设计师和产品,我们最终的目的是什么?改善用户体验,为的是做出好的产品,而最终的目的,也自然少不了为公司盈利。因此从大家努力的大方向来说,不管是设计师和产品、还是广告销售,都是一致的,不过大家具体所专注和努力的不一样而已。
那为什么还有争执呢?带着这个疑问,请大家听我说说一个动画片吧(本人算半个宅女),或许在里面,你就能找到答案。

狼与香辛料 狼与香辛料 (全文…)

别忘了导航

Ami Post in 小兔理论

原发自UCDChina: http://ucdchina.com/blog/?p=376

很多网站为了某个活动、节日什么的,经常都会做一个专题页面。这些页面往往都和网站其他的页面不同,不用那些循规蹈矩的布局,有漂亮的大块图片、甚至是声色俱佳的Flash~ 这些页面,可能是从网站内部某个吸引人的地方,吸引你点入;也可能是某个软件的网站,从软件里链接出来的;也可能是和别的网站合作,从别处链接过来的……这样的页面的确都做得很吸引人,但也容易忽略一个很基础的问题,比如下图这个页面:

http://photo15.yupoo.com/20071227/101315_2089751484_m.jpg
恩,乍一看还挺精彩的,不过少了一样很重要的东西——导航条。而且,竟然连个网站的Logo都没有… (全文…)

简单经济的可用性测试 上手指南(发于UCDChina,留档)

Ami Post in 小兔理论

读过《Don’t Make Me Think》的人肯定记得,作者在其中提到了简单的可用性测试。不过用个摄像机什么的,似乎不太适合我们这边的情况,在国内的中小型企业,实际的尝试和运用中,还是需要不少变通的。今天就来谈谈我在实践中得出的一些经验。

如果:
你所在的公司刚开始推行UCD,一切都刚起步;
没有固定的人手,没有很多的资源,测试研究的时间和经济成本非常局限;
你看了不少有关的书和文章,但实际开始做的时候还是觉得有不少困惑

那么,希望这篇文章可以帮助你。

时间

测试的时机
理想地说,可用性测试尽早开始越好,也应该是产品开发的一环,可以有一个迭代的过程。但是对于初次的尝试来说,不一定能够做到:也许你的Boss不希望把“半成品”拿出来给人看,也许你们的开发进度紧迫插不进这样的时间,但是也不必放弃,晚测试总比不测试好,实在不行就把发现的问题放到下个版本去修改。亡羊补牢,为时未晚。
当你的同事和上司看到了可用性测试的价值后,你做测试也慢慢上手了,就能争取到加入开发环节的机会、迭代测试和开发的机会。或者你的产品频繁有少量改动的更新,这样子测试问题也不大。
你需要的,只是抽出下面提到的一些时间。

准备时间
测试前,你可能需要在一两周的工作时间穿插可用性测试的准备工作。若是刚开始在公司尝试可用性测试,你应该写一份简单的测试计划——告诉你的Boss你要做什么事情、也帮助自己规划做测试的一系列工作。
然后也许你需要申请一些资源,空间、硬件、人员协助等等~
Check一下这次要测试的功能,设计一下测试的任务。如果是第一次测试,心里过一下整个测试的过程,开始-测试时的引导-结束,有机会做次导测的话会让你更有信心。
还有就是招募受测。这个根据你招募的方法需要的时间不同,具体的招募请见下面的部分。

测试时间
准备好了,和受测也约好时间,就可以开始测试了。
你的受测很可能是上班族,这也就意味着测试会安排在非工作时间,比如晚上、周末。就算你很经济,用的是同事,也可能因为他们工作繁忙需要一起占用午休时间或者下班后多留一会儿。>_<真是辛苦,测试难免会需要你加班。而唯一的好处就是,如果你是在本职工作之余做这件事,对原先工作的进度影响就没那么大了。

分析&结果分享时间
测试结束之后,整理下你的记录(如果有条件录像的话,还要回看录像),分析归纳写一份测试报告,写下发现的问题,附上些截图或者关键录像片段。报告不必弄得很详细,目的是为了把测试发现的问题让同事了解。个人觉得比较好的是PPT,不必很多文字,可以现场讲解问题的具体情况和背后的原因、还可以大家一起讨论修改的方案。如果没时间做presentation,给同事看文档,写简单一些,挑重要的写。
如果你有录像而且有时间编辑,绝对推荐做一些这样的片段:一个受测反反复复就是找不到某个功能在哪里、或者多个受测都在同一个地方犯同样错误的重复片段——等他们坐立不安地看完,然后开发和设计就会主动说,这个,该改!嘿嘿,这时候我总是开心得窃笑~
根据公司的需要或者你的职能,可以针对发现的问题提一些大致的修改方案,或者组织相关人员讨论等等~记得要把测试的效果落到实处,哪怕只能在下个版本中去弥补那些问题。

谁来做可用性测试?
也许就是正在读本文的你。是关注用户体验的开发人员?设计师?或者PM?介于公司规模、产品特性,可能没有专职的可用性测试人员,最初尝试可用性测试,可能只是团队中的一员抽空来做这件事情。这是最经济的做法,不过记得,这个人要:

    [*]客观,不要因为是自己的产品在测试和分析的时候不自觉去袒护它;
    [*]有观察力和分析力,这样才能让测试起到成效;
    [*]与人沟通的能力,引导你的受测、在公司里争取尽可能的资源和协助。

关于人数,一人虽然辛苦些,但是就能完成。若两人搭档更好,尤其是测试时,可以一人引导、一人负责记录。

受测的招募
保密协议?测试费用?如果这些问题让你打退堂鼓了,不妨先请公司同事作为你的受测。不过记得不要请产品的开发或者测试人员啊,我不死心地试过一次,真的不合适>_<。你可以请和产品的设计开发无关的,比如行政部门的美眉、新来的同事、另外一个产品项目的成员等等,不单解决了费用和保密的问题,而且受测招募也很快捷,不过记得要和同事还有上司沟通好哦。

测试招募真正的用户当然最好了。这里有一些很经济的方法:

    [*]去问问客服,有没有一些可以来参加测试的用户?或者请他们在最近接触用户时邀请他们来参加测试;
    [*]你可以靠平时累积一些受测用户的资料,比如抽奖等推广活动等等,去问问相关的同事吧;
    [*]还有,就是发动同事们,大家把可以作为受测的亲朋好友们推荐给你~

关于受测的人数,根据测试的产品变化:只是增加几个功能的小版本,3~5人;全新的版本,可能5~8人,简单的可用性测试,控制在10人以下。关于这个,经典的理论:5个受测发现80%的可用性问题

地点

简单的房间即可
既然是说简单经济的、初次尝试的可用性测试,当然不会有单向玻璃之类高级的东西~你需要的只是一间不受打扰的房间,可以用产品的电脑。可以临时占用间会议室,有条件的话就找个固定的地方,建一个简易的Lab。我们公司的Lab,小小一间里摆着电脑桌和沙发茶几,平时不做测试的时候做小会议室、中午时候是休息室、有人面试时是接待室,超级多用哦~够经济实惠吧~

移动的lab
若你的产品可以单机运行,或者是个没什么带宽要求的互联网产品,那么还可以带上你的笔记本电脑,把受测请到一茶一坐之类可以上网的安静茶坊里,一样可以坐下来测试。请你的用户喝一杯茶/咖啡,就可以了解他使用产品的情况。这个方法,同样使用于做访谈。

-

可用性测试并不是件难事,用Angela的话说,可用性测试早就跳楼大减价啦~ 成本可以降低,门槛也可以降低,尝试一两次简单经济的可用性测试,会是在公司中推行UCD很好的起步。关键是去尝试、根据自己所在企业的情况灵活应变。同样的,你也可以尝试其他的一些方法,或是访谈、或只是在平时注意观察他人的使用、询问他们的意见。

合适的才是最好的,当你找到了适合的产品的方法和方式,一定能帮助你改善产品的用户体验。

互联网的大派对

Ami Post in 小兔理论

今天来说个关于“大UE”的问题,一个关于WEB2.0(社区类)网站的比喻。当初是在去年的UPA年会上听到的,如今的工作中老是想到它、想要提到它,不如和大家分享一下吧~
去年回来的时候已经提过一回:http://www.amizhang.com/blog/article.asp?id=8 今天写,会融进比较多个人的理解和诠释。

http://photo11.yupoo.com/20070926/231619_1391024081_snfbzhau.jpg
这个比喻的本体可以说是个Web2.0的网站,也可以说是个社区型、互动型的网站,关键是“人”、“互动”。
喻体是派对。(^o^我的语文还不算退步太多,对得起偶的语文老师) 派对的关键也是人和互动,因此比喻还算恰当,开始吧~

好的派对一定该有Party Queen/King(派对上最引人注目/最闪亮的美女。不少派对会有评选Party Queen的活动)。他们是大部分人关注的焦点,吸引注意力;他们有很强大的带动作用,带来更多的人来参与进来,或跟风模仿、或呼应喝彩;他们个性和独到的表现,也是派对内容的重要组成部分。而一个WEB2.0的网站/社区也该有一些自己的明星,比如,新浪博客有老徐、或者怪兽“明星”页面里的喵小爱同学等(>_<若有更好的例子,欢迎推荐),这些社区明星带动了进一步的浏览、讨论和发布的量。邀请和培养社区中的明星是很重要的,因此土豆有了豆角儿,很多网站都有社区明星排名。若进入一个2.0社区找不到明星、或者所谓的明星也不够活跃没有魅力的话,我就认为它没戏,像一个平淡乏味的派对。

而事实上,派对的中坚力量,也就是大部分人,应该是那些派对动物(即喜欢去/经常去派对、很Enjoy派对的人)。他们并不见得独领风骚,但总是积极的参与者,精心打扮穿梭在派对会场,积极投入、也积极起哄和喝彩。好花要靠绿叶衬,有了他们才有所谓的Party Queen的存在。这些人可能做的事情和Party Queen/King们也差不多,只不过也许是难得的一两个举动受到很多关注和响应(一个精华贴?)。对于网站/社区来说,其实他们是非常重要的部分,天天来、积极浏览、讨论、发布——粘度高、忠诚度高,我们的目标就该是这样的人越多越好——让他们享受参与的过程,得到一些荣誉感,始终有吸引他们让激情不会冷却的东西。有了他们,我们的派对才会热闹。

派对里难免有的,是壁花小姐/先生(派对中总是一边呆着,不参与进去不和人说话的人,因此有了这样的比喻)。这些人也许会有几种情况:或是因为某个原因偶然光临——或是觉得没意思,不会再来;或是发觉其中的乐趣,逐渐融入成了一个积极分子。当然我想也不能排除这种人,一直来,但一直沉默,这样也是他们享受派对的方式。这种人在Web社区更加常见,大堆大堆的潜水者们,阅读别人写的博客、查看他人发布的照片,难得留言评论一下,甚至一直是一言不发。对于上文两种类型的内容贡献者来说,这种类型的人也是需要的,因为阅读/观看数也是一种自我价值的体现——但更需要的是参与响应的人,因此也有需要把他们培养得更积极一些,靠内容或者其他的方式

最后,还有一种人,就是派对的主人们。他们策划派对、做各种准备、邀请客人……派对热闹时可能还在忙于组织,都没有空闲自己去享受一下。但是一个派对是否精彩、参与的人是否舒适愉快,都是靠他们的努力。互联网派对的主人们,就是我们做产品的和运营的啦。派对主人要考虑的派对主题、形式、参加的人、场地和酒水布置等等~肯定,也要让以上三种人各自有愉悦的体验,大家都Enjoy这个派对。

也许你之前有考虑过网站的目标用户,或者有做过产品的Persona,也值得思考一下,产品有没有针对这些不同类型人来提供良好的体验?希望这篇小文能让你在参加和组织派对、甚至生活中的其他时候,也得到对产品的启发和思考。

PS:最近更新少了,但努力的UCD小兔,还是在努力哦~>_<就是忙了点

视线流和鼠标流

Ami Post in 小兔理论

这个词的起源是前阵子和同事提出优化登录和注册的表单开始的。为了优化我们注册/登录的表单,我把浅议 Web表单设计发给同事看,然后我们的表单大概是这样子的:
http://photo1.bababian.com/upload/20070602/BAA5E0FD76CB6943E011058E51DD09F7_500.jpg
这样的设计保证视觉的注意点和鼠标路径都是一个顺畅的、向下的过程,并且在最后关键的提交时汇聚在一起。每次都说“视线的移动”、“鼠标路径”什么的也繁琐,然后我就擅自发明了“视线流”和“鼠标流”这两个词啦~:P
如图,绿色的是视线流,红色的是鼠标流。我们没有眼动仪、没有鼠标路径研究的方法,也知道实际视线的移动决不像图示的两条线那么简单。视线可能还是Z字形向下的,要看验证码和复选框之后的内容:
http://photo1.bababian.com/upload/20070602/6F2771E6A95406D9A9DE3E082B5BF643_500.jpg
但是这样的设计已经基本保证了用户在填写表单的时候,一步一步很顺畅,最后提交按钮出现在顺利成章的位置,一点,就OK啦。
视线流和鼠标流只是大概表示视线和鼠标路径的移动,在用户进行关键的交互任务时,要尽量保证它们的流畅,也尽量汇聚在一起
一定要说,只是关键的交互任务,比如填写表单,因为这时候用户的注意力都在这里。用户浏览网页时视线可能在整个页面里灵活变动、鼠标可能在右侧操作滚动——可见鼠标滚轮的发明是件多么好的事,视线流和鼠标流就不会扯那么远了。

之后另一个设计的优化又是和视线流、鼠标流相关的:
一行一行的数据,鼠标悬停的这一行背景颜色变化,这样也帮助鼠标流和视线流的汇聚:
http://photo1.bababian.com/upload/20070602/5F07E619D62C79F04F9AE22BE97799FB_500.jpg
然后,在这个的基础上我们有这样的交互:鼠标在这里悬停几毫秒后浮出一块:
http://photo1.bababian.com/upload/20070602/31D22A6F392DA6DDB01B8A43116116B6_500.jpg
问题就出现了~若这一块出现在鼠标的坐标位置上,就会遮住一部分这一行要看的东西,于是,要把它挪到下面;又考虑到用户可能让鼠标指着一行一行往下看,这一块东东不能挡住鼠标往下移;又因为需求里要求这一块浮动的区域也可以点,还要给用户鼠标移到区域内点击的机会……
最后的设计是这块东东出现在了鼠标坐标右下方一定距离的位置,保证横向、竖向的视线流/鼠标流都流畅,也有可以移动到该区域的鼠标流:
http://photo1.bababian.com/upload/20070602/F181859B0E06ED79327DDB2F6014D04E_500.jpg
恩,这样就OK了~结果是“鼠标流和视线流都流畅”,这般和开发、产品一起沟通解释起来就方便了,一次优化就基本达到目的。

PS:弄这两个词儿出来不是要定义某种概念,只是小兔为了方便UI和开发之间沟通时候的一种描述方法~

新浪原文:http://blog.sina.com.cn/u/5772b0e70100087z

小兔的UE Motto集-(2)不要只看见UE

Ami Post in 小兔理论

小兔的UE Motto中最重要的2条:
No.1 用户体验从细节处累积
No.2 眼光要既专注又宽阔
今天要说的,可能和No.2有些重复,也不是我自己提出来的原话,但我觉得很有道理,暂且就算它2.5吧~

No. 2.5 不要只看见UE

这句话是公司的同事送给我的,一位项目经理。PM要看到的和关注的很多,这样的一句话,很是受用的。No.2.5可以说就是No.2的“宽阔”这部分,上次说过的就不再重复了。
周六和市场的一头儿去参加5G——当然去之前我不知道、甚至还没听说过5G,之后补习了下。去之前所知只是去参加一个IT专业人士的沙龙,Ami的任务是去做个小的问卷调查。
主题是《客齐集:实战,选择》,感觉听IT人说说还是很有意思的,不直接受用但很有参考价值。关于王建硕说一直向用户妥协,其实很想去请教下怎么去妥协,但是那天身体欠佳收了问卷就打道回府了,如果下次还有机会去的话一定要多交流。我很想看看5G里这些精英们怎么看待用户体验~
做UE的有点特殊,因为这个行业在国内还在发展阶段,对于UE工作的定位也是模糊的、各家公司不同;而互联网行业总是风云变化——因此我觉得UE应该是注重观察的,不要放过各种优秀的、新的产品的体验,要留意行业的发展变化,不断学习才行。无独有偶,发现白鸦在北京也参加5G,呵呵~
如果上次说“宽阔”,只说到了要综合考虑问题和与团队融合,那么今天把内容再扩得完整些。除了这种放眼观察的“宽阔”,我想也许还有一种“从产品出发”的宽阔,因为UE不只是顾及可用性。关于这点,小兔要换去产品部啦,我想过阵子会有更切实的感受。

呵呵,谈了那么多“宽阔”,也在说说“专注”,我喜欢把Google的这句话搬给同事听:
Focus on the user, and else will follow…
对于我们来说还做不到,比较理想化,但我们会去努力。

新浪原文:http://blog.sina.com.cn/u/5772b0e70100086f

用户体验RPG

Ami Post in 小兔理论

前一阵子要为技术部的同事们做一个关于UCD、UE的讲座,怎样说能让大家理解和接受?当时可谓绞尽脑汁,我的boss也提了一些意见。讲座的前一天晚上突然想到了这个点子,兴奋得失眠就为了整理这个~
灵感来在DMMT中提到的“好感储存器”和一些和Persona有关的概念。我游戏神经不咋的,这样打比方可能有不恰当不完整的地方,欢迎大家补充赐教。

首先,我们把用户使用我们的产品的体验过程(暂且局限成'访问我们的网站'吧)想象成玩一个RPG游戏。听到这字眼,也不必想得很复杂,回到n年前最最简单的RPG:
一般屏幕的左上角都有这样的一个人物头像和数值条:
http://photo1.bababian.com/upload/20070529/F5BED2E863E5DC90B0EAED40AF0A90AF_500.jpg
在RPG的游戏里这一条一般都是代表着HP(SP什么的我们暂且不去想),而在这里,这一条是UEP。
一般情况下,用户刚来访问网站时,UEP是满的。但是可能有很多因素/事件影响UEP,比如在DMMT里见到的这张图:
http://photo1.bababian.com/upload/20070529/BD015ACE9339AA0FD4788FFDC99549B1_500.jpg手机拍的,看个大概。详见DMMT第10章-可用性是基本礼貌
首页上看不到想要的信息,也许UEP就减了10;找东西很费劲,减了20;碰到问题FAQ里也没有答案,又减了30……
http://photo1.bababian.com/upload/20070529/F3195AA5B3A87DBDE1C124010725AF00_500.jpg
减着减着,UEP也许变成黄色了,不多了,用户已经不高兴了;再减减,红色了,已经明显给用户造成了消极的体验;最后减到了UEP=0,耗尽了用户的耐心,这里生成游戏的失败条件:

当UEP减为零时,用户完全失望,会离开我们的网站。

这里也包含了一个我的观点:UE设计的细节会累积、然后影响用户对于我们的总体感受与评价
但恐怕游戏的失败条件还不止一个。我们有同行业竞争者,用户可能还在访问他们网站/使用他们的产品,也就有了UEP'、甚至UEP''……用户用脚投票,当他们觉得另一个更有用、更好用,就会离开我们而投奔去我们的竞争者,即使我们的产品也做得还算不错。这就生成另一失败条件:
http://photo1.bababian.com/upload/20070529/D685B88DE1AF57ADFF956821BA7A4BF6_500.jpg
当UEP'>UEP一定数值时,用户会离开我们的网站,选择别的产品。

但人是不同的,有些人耐心比较足、有些人天生要求高、有些人用什么东西都会很快上手……就好像在游戏里,不同的玩家有不同的等级、HP最高值、攻击力等等~UEP初始值为多少、遇到什么样的事情UEP减少多少?为解释这些问题,我们把上面这个超~~简单的RPG再完整一些。

游戏里应该会有这么一个人物属性界面:
http://photo1.bababian.com/upload/20070529/D4520D2BFCAF810095A66EDA814C22AF_500.jpg
不同的人会有不同的等级、属性、能力等等。在用户体验的RPG里,用户也会有类似的属性:

    [*]人的耐心可能影响UEP上限,就像游戏里体力影响HP上限;
    [*]一些人在体验过程中容易受挫,UEP下降得快,就像游戏里防御低每次受攻击就减血多*
    [*]某些人对某方面的要求比较高(比如视觉效果),那么视觉效果对他的UEP影响就更大,就像游戏里火属性的受到水属性攻击时伤害可能是1.5倍*
    [*]游戏里人物有等级,谈论UE的时候我们也会说“新手·专家·中间用户”*
    [*]也许我们还有些特殊的访问者,使用屏幕阅读器、或者是色盲,如果可访问性没有做好可能就造成“致命一击”*
    [*]…………

诸如此类,最后形成用户体验RPG的专用人物属性表:
http://photo1.bababian.com/upload/20070529/A809C2D5EEE5C707CC9A5E138A351E14_500.jpg属性探索整理中*
我们可以采用类似Personal的办法,建立典型用户的属性表,来分析出一定的用户需求,找出产品设计的侧重点。

通过这样一个简单RPG的比喻,Ami向同事解释UE在用户使用我们产品过程中可能造成的影响。当然,这样的解释可能是表面的,也不能解释大部分的UE要点,但是起到了“入门”的作用,相信要比一大堆理论来说更容易理解和接受。
而且我打算把这个有趣的比喻好好整理,成为自己的独家理论 [cool] 文章里有不少*,那就是以后会补充完整的地方,希望大家能多给意见 [razz]

新浪原文:
http://blog.sina.com.cn/u/5772b0e7010007xy

小兔的UE Motto-(1):眼光要既专注又宽阔

Ami Post in 小兔理论

关于UE,我始终还在积累经验、持续探索的阶段,每天的努力中,都会有一些心得和发现。在这里和大家分享我的Motto,在工作和学习中都不断督促自己。
要说我的第一Motto,该是那句“用户体验从细节之处累积”,这句会结合以后的文章来解释。今天就结合白天工作感触说说:

做UE,眼光既要专注又要宽阔

专注,这很容易理解,UE就该一切从用户的角度出发、致力于提供尽可能好的用户体验。但对于一个好的UE来说,这些远远不够。

举例比如我之前写的再说验证码,单纯从UE角度来说,当然是不该有验证码,但是这种情况要考虑相应的技术安全问题
又比如今天:我们产品的UI要坚持一个细节的设计:固然那样做的确可以给用户体验加分,但是技术实现却很复杂,最重要的是开发进度紧得很技术部都加班了——这个设计的确好,但一边嫌开发进度拖延一边为小事情动大干戈,这样好么?如果它好,这个小细节可以不在1.8的大改版推出、放在日后1.8.1么。这里的UE,还得考虑技术实现和开发时间的问题(互联网时代不是大鱼吃小鱼、而是快鱼吃慢鱼,类似的意思PM肯定说过吧)

之前在白鸦的博客上曾经引发了对于UE话语权的热烈讨论。我认为,UE的话语权除了靠公司重视你赋予你权利之外,更重要是靠UE自己争取而来。一方面靠自己的能力、提供合适的建议来使大家信服,一方面要学会去沟通去融入整个团队,不能死脑筋地说我们就该这样这样做,不管技术问题、不管时间进度……这样肯定不会把话语权交给你。(不软弱不盲目妥协,但适当的时候要学会妥协和寻求另一种办法)

如果要对这句Motto做个简单的解释,那就是UE始终最重要的、第一的是从用户的角度出发,但同时也要眼光宽阔,去综合考虑技术等其他的因素、沟通的时候也为团队中的其他人想想。

小小心得,欢迎大家的建议~

新浪原文:http://blog.sina.com.cn/u/5772b0e7010007zy