Ami Zhang's UI WorkBook http://blog.sina.com.cn/amizhang Thu, 31 Dec 2009 15:27:55 GMT+8 FEEDCREATOR_VERSION zh-cn Copyright 1996 - 2009 SINA Inc. All Rights Reserved. Thu, 31 Dec 2009 07:27:55 GMT+8 博客搬家啦，烦请大家更改地址 http://blog.sina.com.cn/s/blog_5772b0e7010009d8.html 磨蹭了一阵子，我的博客现在正式搬家啦，放在了自己的个人空间里，欢迎大家访问：
www.amizhang.com
日后此处将不再更新，不过RSS订阅的不会再看不到图片啦～
 
使用RSS订阅的朋友，请更改订阅地址：
 http://feeds.feedburner.com/amizhang
或
 http://feed.feedsky.com/amizhang Feedsky的更新有点慢
 
这里感谢几个人：
同时Kevin，帮我弄了首页显示最新推荐的文章，还指点我解决了数据库的问题；
Xiaoxiao，和Fangle发起了LBS的改造，才让我敢下决心用LBS；
最近生活中遇到一些事，感谢与我分享、陪伴我和支持我的人们～
 
另外，还有其他的订阅方式：
 和 http://wap.feedsky.com/amizhang 
用胖葫芦手机订阅:

胖号:62008848
 
UCD小兔，持续努力中！
]]> amizhang http://blog.sina.com.cn/s/blog_5772b0e7010009d8.html#comment Fri, 08 Jun 2007 08:01:16 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010009d8.html Develop Personas 关于角色的建立 http://blog.sina.com.cn/s/blog_5772b0e701000964.html * 博客搬家过渡中，欢迎访问http://www.amizhang.com/blog
* 或订阅我的Feed:
  http://feed.feedsky.com/amizhang or http://feeds.feedburner.com/amizhang
 
* 本文地址：http://www.amizhang.com/blog/article.asp?id=20

 

   最近和我们的UI设计师一起讨论交互设计的时候，逐渐开始感觉对Persona的需要。 有时候，某个功能到底该怎样设计，方式A好还是方式B好，要看针对什么样的用户。这个时候，如果能举出一个典型的例子，比如某某、在什么样的情况下需要这个功能……就比较能够得出答案。

   那么，逐渐地建立几个比较形象的用户的概念，自然会有助于我们的设计。小兔翻译了些资料作为参考，和大家分享下吧：

   原文：http://www.usability.gov/analyze/personas.html

Develop Personas 建立角色

Translated by Ami Zhang

  • What is a persona? 什么是角色
  • How do we get information for a persona? 我们怎样获得角色的信息
  • What does a persona look like? 角色是什么样的
  • What characteristics are included in a persona? 角色包括些什么特性
  • How do we select a name and photo? 怎样选择名字和照片
  • What are the benefits of personas? 角色的好处是什么

What is a persona?什么是角色

A persona is a fictional person who represents a major user group for your site.

角色是一个代表网站(产品)主要用户群的虚拟人物

How do we get information for a persona?
我们怎样获得角色的信息？

By analyzing what you learned about your users from user research, including:

通过分析从用户调查中对用户的了解，比如：

  • Contextual Interviews 上下文访谈
  • Individual Interviews 单独访谈
  • Surveys (Online) 调查(在线)
  • Focus Groups 焦点小组
  • Usability Testing 可用性测试

Using this information, you identify major user groups of your Web site. You then select the characteristics that are most representative of that group and turn them into a persona.

通过这些信息，你可以区分出网站(产品)的主要用户群。从用户群中选择最有代表性的特征，把他们转换成人物角色。

What does a persona look like?
角色是什么样的？

A persona typically includes a fictional name and characteristics that are consistent with one of the main user groups you have identified.

The following example is only a small portion of a larger persona developed by the U.S. Department of Agriculture's (USDA) Economic Research Service (ERS).

一个角色包括一个虚拟的名字，和与你某个主要用户群一致的特征。下面的例子是一个很大的角色中的一部分，由美国农业部(USDA)经济调查服务(ERS)建立的。

-

USDA SENIOR MANAGER 农业部高级经理
GATEKEEPERS 社会观察人员 

picture of Matthew Johnson, subject of sample persona

Matthew Johnson
Program Staff Director, USDA

  • 51-years-old
  • Married, 3 children, 1 grandchild
  • Ph.D. in Agricultural Economics 农业经济学博士
  • Comfortable using a computer, intermediate Internet user, with a T1 connection at work and dial-up at home
    熟练运用电脑，中级互联网用户，办公室T1网络接入，家中拨号上网Uses email extensively;uses the web about 1.5 hours a day for his work 广泛使用Email，每天工作用1.5小时上网

-

"Can you get me that staff analysis by Tuesday?"
“你能给我在周二给我员工分析么？”

Matthew spends most of his time at work requesting and reviewing research reports, preparing memos and briefs for agency heads, and supervising staff efforts in food safety and inspection.

Matthew大多数工作的时间花在要求和审核报告、为机构负责人准备备忘和摘要，和监督视察员工在食品安全方面的作为。

-

Key Attributes 关键属性

  • Focused, goal-oriented
    专注，面向目标的
  • Strong leadership role
    较强的领导角色 
  • Concerned about maintaining quality across all output of program under direction
    关心在指导下维持一切项目的品质

-

Persona developed by the U.S. Department of Agriculture's (USDA) Economic Research Service (ERS).
角色由美国农业部经济调查服务建立

What characteristics are included in a persona?
角色包括些什么特性？

A persona usually includes:
角色通常包括：

  • a name and picture 名字和照片
  • demographics (age, education, ethnicity, family status)
    人口统计学属性（年龄，教育，种族，家庭地位）
  • job title and major responsibilities
    职位和主要职责
  • goals and tasks in relation to your site
    目标，与网站(产品)有关的任务
  • environment (physical, social, technological)
    环境（物理的，社会的，技术的）
  • a quote that sums up what matters most to the persona with relevance for your site
    一句引用，来概括网站(产品)的什么对角色来说最重要

How do we select a name and photo?
我们怎样选择名字和照片

You make up the persona's name. Select one that resonates with the team as representing that user group. Be relevant and serious; humor usually is not appropriate here.

取个角色的名字。选个在代表用户群体时，和团队有共鸣的。要严肃而贴切，通常幽默在这并不合适。

For a picture, you can buy or license stock photography, although a more casual photo often resonates more with development teams. Don't make it a picture of someone the team knows. Make sure you have permission for the photo that you use. You can tell that you have a good picture if the team sees it and says "Oh, yes, that would be Jim, the Press Guy" or "Oh, yes, that's just what I see when I think of Rebecca, the Program Officer."

你可以从摄影库中买或获得许可获得一张照片，尽管一张更随意的照片经常让开发团队有更多的共鸣。不要用团队成员认识的某人的照片。确认你有照片的使用权。若你的的团队看见照片时说“哦对，这就该是Jim，那个做出版的”或者“对啦，我想Rebecca就是这样的，那个项目官员”时，你可以说你有了张好照片。

What are the benefits of personas?
角色的好处是什么？

Personas bring many benefits, including these:

角色带来很多利益，包括以下这些：

  • Users' goals and needs become a common point of focus for the team.
    用户的目标和需求将成为团队共同的关注点
  • The team can concentrate on designing for a manageable set of personas knowing that they represent the needs of many users.
    团队可以专注于为一组可控的角色而设计，他们代表着多数用户的需求
  • By always asking, "Would Jim use this?" the team can avoid the trap of building what users ask for rather than what they will actually use.
    经常问问“Jim会用这个吗？”团队可以避免绕弯路去设计用户要求的、而不是他们真正要用的东西。(用户有时也无法表达自己真正的需求)
  • Design efforts can be prioritized based on the personas.
    基于角色可以为设计区分优先级
  • Disagreements over design decisions can be sorted out by referring back to the personas.
    当设计上产生分歧时，可以通过回顾参考角色来解决
  • Designs can be constantly evaluated against the personas, getting better designs into usability testing.
    设计可以经常地通过和角色对照来评估，把更好的设计带入可用性测试

According to Forrester, many companies including Ford Motor Company, Microsoft, and Staples develop and use personas and they report many benefits from doing so, including:
根据Forrester(一家咨询公司)的调查，包括福特汽车、微软和史泰博等很多公司都建立和使用角色，并且反应藉此得到了很多好处，包括：

  • a better understanding of customers
    对顾客更好的理解
  • shorter design cycles
    更短的设计周期
  • improved product quality
    促进产品品质
转载文章请注明原文地址和作者，并告知，谢谢！～
 
* 博客搬家过渡中，欢迎访问http://www.amizhang.com/blog
* 或订阅我的Feed:
  http://feed.feedsky.com/amizhang or http://feeds.feedburner.com/amizhang 
* 本文地址：http://www.amizhang.com/blog/article.asp?id=20
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e701000964.html#comment Fri, 25 May 2007 14:01:33 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e701000964.html 改造出一间用户体验实验室 http://blog.sina.com.cn/s/blog_5772b0e70100095m.html * 博客搬家过渡中，欢迎访问http://www.amizhang.com/blog
* 或订阅我的Feed:
  http://feed.feedsky.com/amizhang or http://feeds.feedburner.com/amizhang
 
* 本文地址：http://www.amizhang.com/blog/article.asp?id=19 
 
还记得刚转到产品部的时候，头儿就让我写个实验室的计划。这正是我想做的，那时真是开心～没想到头儿还说弄个有单向玻璃比较高级的那种～这个我考虑了下，也问过白鸦、Panda，最后提出了我的理由，认为不必要单向玻璃：介于我们公司的规模和场地，投入这样的成本、占用这些空间并不是必须的，建立起来后的利用率恐怕也不高；而且这年头，看《24小时》等片子的人多了，不少人会明白单向玻璃是什么东东，届时会觉得自己进了审讯室，浑身上下不舒服。
 
在反复思考适合公司的可用性实验室方案的时候，脑中的这个想法也就越来越清晰：改造出一间用户体验实验室。我想那可能是更合适中小型企业的方案。
 
关键词一：改造
是“改造”，而不是“建立”，Ami的想法是利用公司现有的空间，改造一下加以利用。若不需要单向玻璃，可用性测试无非是需要一个没有打扰的、可以坐下来使用产品的空间。这样的话，一间空闲的办公室、会议室，放上电脑能用软件、能上网，就基本行了，这在公司里一般都不成问题。

记得当初关于可用性实验室，问Panda他们的情况时，他说他们经常也就是用会议室。至于让其他人观察，可以用其他办法代替，比如录屏、录音，有条件买个Morae这样的软件的话，就可以把简单的可用性测试做得很好了。

关键词二：用户体验
对，我的用词不是“可用性实验室”而是“用户体验实验室”，因为在这个实验室里可以做的不只是可用性测试。若有张舒服的沙发，可以用来做访谈；若是间会议室，还可以用来做焦点小组、也是可用性测试报告和讨论的好地方……这一间房间里可以从事的UCD活动可以有不少呢。
本文来自www.amizhang.com/blog
于是乎，自然是认真地侦查了我们公司的各个会议室。无奈，最近公司扩容招新人，办公场地紧张，我看中的第一选择被改造成了办公室——原先那是个有明亮窗户的小会议室，有舒服的沙发，还摆着书橱，之前我的Design Checkpoints就是在那里做的呢～太可惜了。其余的会议室，都是单调的会议桌+椅子，我一度就在那儿算尺寸，哪里可以放下个电脑桌什么的，不过又发现了选择No.2……

第二选择看中的是我们公司的活动室～入口就是有着丰富饮料和点心的茶水间，外面是底楼的小院子，房间宽大明亮，有乒乓桌、台球桌、桌上足球，还有两个舒服的大沙发——再好不过了，用户来了还可以稍微玩一会儿，然后轻轻松松地测试或者访谈。我实地拍照、画平面布置图，兴冲冲地把想法提上去——结果被行政告知：活动室那个空闲的角落，已经被运维隔开要做机房了，5555……[cry]

难道我们公司已经紧张到给我改造的空间也没有了？行政MM安慰我说，原先的一间空闲的办公室将被改造成小会议室，那间房有阳台，会放上沙发……好！[yes](两眼放光)，就要这间了！

http://photo1.bababian.com/upload/20070523/62D9DA97B003BC018904EFE0E978F6E4_500.jpg

这是偶原先的活动室改造成UE Lab的计划图...

之后Boss又让我提了一下房间布置改造的需求，大致如下：
  • 独立不受打扰的环境，舒适，有轻松的气氛；
  • 有个电脑桌来做可用性测试，机器要能流畅运行我们的软件、不会因为后台的录屏程序影响受测使用；
  • 桌子要布置得轻松些，有些文具(备好纸笔也许测试需要)、有些植物，甚至还有几个小玩具，里面还混杂着一个玩具造型的摄像头:P；
  • 要有沙发和茶几，可以做访谈，或者用本本做可用性测试；
  • 若有会议桌、白板、投影仪，那么可以做焦点小组；
  • 若能布置些员工照片，让人感受到温馨气氛和企业文化更好；
本文来自www.amizhang.com/blog
改造出一间类似于会议室+会客室的房间，平时不用于测试访谈时，就还是个会议室/会客室，不需要额外申请什么资源，是个非常节省成本的方案。不必要那种单向玻璃和专业的监控设备，这样的一间房间里你就能做很多事。去接触用户，那才是最重要的。
 
 
* 博客搬家过渡中，欢迎访问http://www.amizhang.com/blog
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e70100095m.html#comment Wed, 23 May 2007 14:30:13 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e70100095m.html Qzone，向全屏进发 http://blog.sina.com.cn/s/blog_5772b0e701000918.html *Note:

最近正在试验搬家，迁移至自己的空间内。尝试各种博客程序中

现倾向LBS，试验地址：http://www.amizhang.com/blog

大家以后可以订阅我的feed:
http://feed.feedsky.com/amizhang
http://feeds.feedburner.com/amizhang

feedsky很不及时，feedburner载入速度慢一些，头痛啊～

 

八百年不上一次Qzone，难得上一次发现了这个：
http://photo1.bababian.com/upload/20070516/2898B5F6558A615A7D4CA59202C57623_500.jpg


点进去看到Qzone推出了全屏Full House的概念
http://qzone.qq.com/web/act/fullscreen_register/index.htm

“业界首创精致主页(Mini Hompy)与经典全屏(Full House)两种模式的个人空间！”
我想该是发现拥挤的小页面的缺陷才开始全屏顺应潮流，不过这一弄似乎跨一大步成了潮流领先者。事实是否真的如此，拭目以待。

http://photo1.bababian.com/upload/20070514/7196D5D7B78D37D43FA42D014073B4C3_500.jpg



吸引我的原因是用了“体验”的概念，另外就是这公测纪念勋章了：

http://photo1.bababian.com/upload/20070514/3A50743DE1A6855AF1993C5AAB95EF0A_500.jpg


http://bbs.qq.com/cgi-bin/bbs/show/content?groupid=172:10041&st=&sc=&messageid=127488&gpc=0&ggpc=0
对类似的概念很有兴趣，推荐给我们的PM~

真正让我隔了八百年上了一次Qzone的原因是魔幻彩蛋大收集：
http://photo1.bababian.com/upload/20070514/B5FCB3A88FD38628433C859BCC113D25_500.jpg http://photo1.bababian.com/upload/20070514/35E50B2A7846BB4B07236444E0032844_500.jpghttp://photo1.bababian.com/upload/20070514/F692F14596A32F98BB4D7912E51FEF32_500.jpghttp://photo1.bababian.com/upload/20070514/B6252EA6265177904637729523DA4F96_500.jpg
http://imgcache.qq.com/qzone/mall/v3/act/default.htm

QQ现在花头筋真是多～ 8过，像Qzone这种东西，我还是不喜欢....

]]> amizhang 体验 http://blog.sina.com.cn/s/blog_5772b0e701000918.html#comment Wed, 16 May 2007 02:02:59 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e701000918.html “注册”比“登录”更醒目？ http://blog.sina.com.cn/s/blog_5772b0e7010008xp.html 这阵子可以体验的新东西还算不少，五一长假回来自然要抓紧体验体验分析分析～不过……？
五一之前上线的Myspace，似乎已经不少人评论过。我在注册时受了不少挫，密码试了几次换上了偶最强的一个才OK，还因为点错了出生年份一度被说“没有资格”注册。好不容易注册了，去登录，输入完用户名和密码后鼠标落到了“注册”上……
我可以理解把“注册”弄得那么醒目是因为他们刚上线，不过等我要登录的时候，这个橙色的按钮要多碍眼就有多碍眼～
 
没想到，过了长假后，又遇到了yoho.cn。又是这样！@#$%……
之前我们设计网站的时候，我一直在坚持把“登录”做得大一点点，“闪电注册”不要也做成按钮以至于比登录按钮还要醒目，难道我错了不成？
我们也希望吸引注册，因此我还没说动去改变因为某项操作而需要登录的页面——左边大块是注册、右边是登录。但我们的首页登录可不会像那种样子！之前提到视线流和鼠标流，总是该想办法让它们流畅地落在需要的地方。就算是在上线初期，非常需要吸引注册，但是那些刚吸引来的人就感到了不悦，这真是个好办法吗？
 
再说个新体验的，atnote.com
注册在哪儿？第一眼去默认的地方没看见，不过找到了：
虽然小小地找了下，但是相比myspace和yoho每次都扰人，注册的时候多瞄一眼真是心甘情愿……
 
登录区域，方寸之地，最需要去斟酌
]]> amizhang 体验 http://blog.sina.com.cn/s/blog_5772b0e7010008xp.html#comment Wed, 09 May 2007 06:56:05 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010008xp.html 考虑搬家... http://blog.sina.com.cn/s/blog_5772b0e7010008y6.html 搬家序曲：
小兔的Feed http://feed.feedsky.com/amizhang
 
看见wkcow说退订所有sina的博客，包括我的，无疑是个警钟，该不该搬家了...
 
当初选择sina，无疑就是因为配图方便，写文章的时候一并搞定，不担心空间，不用别处上传了再在文章里加——毕竟我的文章大多都需要图。但眼看抓虾里订自己的博客图片都是叉叉、眼看文章点击量上去了却没什么留言，实在感觉不爽～
 
搬去哪里？主页空间才30M大小不够，似乎搬去百度最方便，还有搬家工具……但文章配图就觉得麻烦，而且那些模板都傻得很、都是小家碧玉型。
烦哪～去百度想把我的胡萝卜田先清清干净，竟然发现没有批量处理功能，我还有10页杂七杂八的文章>_<……
 
Kid推荐了blogbus，体验中，看上去似乎不错～
 
自己的空间才30M，要自己架blog的话还得去扩展空间～
 
 
]]> amizhang http://blog.sina.com.cn/s/blog_5772b0e7010008y6.html#comment Wed, 09 May 2007 02:01:53 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010008y6.html 当我们接触到用户... http://blog.sina.com.cn/s/blog_5772b0e7010008oe.html 上周末小i智囊团第二次聚会。虽然得咖啡馆里空气闷热导致思维迟缓，之后有些呆呆的，不过还是思考了不少，这次就来谈谈这种活动的形式。

 

我还是挺赞赏这种形式的，几个产品经理、甚至公司其他相关人员（比如运维、市场）和几个用户一起坐下一起用产品、聊聊产品，而用户也以圈内人为主。这种不是什么正规的UCD方法，远没有焦点小组那么正式，但轻松的氛围里人也往往能说得多些，实在不行好歹也算是个圈内人聚会，降低了组织和主持的难度；圈内同行也许不是很有代表性的用户，但更容易获取到意见建议。这个方法适合刚开始形成UCD氛围的公司，上手简单却很有促进效果——无论什么时候，多接触接触用户都是好的。尤其是让产品经理们也去接触用户，据我发现大多明智的PM们都会很乐意去直接接触他们，询问关于产品的看法和意见，这是个促进UCD的好开头。

 

而一两次以后，这种方法会逐渐暴露出它的局限。一是获得的讯息有限：PM可能很乐意接触用户，但并不擅长去问。“你心目中我们的产品是什么样子的？”、“你希望这部分能提供什么功能”，这种问题扔给普通用户是很难回答的。怎样去引导、启发用户说得更多，那可是门学问呀。不擅于问，你也难要求PM很会观察：即使是坐在一起，看我使用产品，我某一时刻皱了皱眉、询问或者埋怨，也很少受到重视，这背后是否存在问题、又是什么问题？要PM去发现，那还是很难。

另一大局限在于，这样的活动是否真正去促进了产品的优化？PM是理智的，并太会因为某一两个用户的一些想法而去修改自己的产品。每次花个几小时在那里聊、认真地还会拿笔记，可真正回去影响产品的有多少呢？而对于认真提供建议的用户，若得不到奖励性的反馈、看不见自己建议对产品的影响，几次后也会失去了动力，这样的讯息也难再获得。说句老实话，要不是因为有这活动，我早就不用小i机器人了，现在用无非是为了下次聚会而做的“功课”——小i有时候某两句话就可以让我关掉不想再去用它，但这样的我摆在他们眼前了，也没见到有多大的影响。

 

以上的缺陷一大原因在于没有UE的介入。访谈、焦点小组、可用性测试都是好的UCD方法，这种活动也集合了这几种方法的优点，应该是可以收益颇多的，但需要专业的人来做。因此我也思考了改善的办法。

首先是活动的人员组织，PM来接触用户是好事、邀请的用户中有些圈内人也是好事，而怎样的交谈能聊出更多，靠UE来主持和开启话题。之前曾经有过那么个小尝试，我，一个用户，和一个PM，聊一个关于社区的新功能。“你希望这功能怎样提供？”，用户一时也没个概念，我在旁做一个启发：“比如，可能可以这样xxx...还可以那样xxx...”之后用户便滔滔不绝了:“我觉得，xxx会很好，我看到别处由xx也很不错，你们可以借鉴啊”另外，人员的比例也很重要。虽然可以赞扬小i出动了那么多人表示他们重视和用户的接触，但人数压过了用户，那太吓人了。可以坐在一起聊聊，也可以分别谈谈或者坐一起来个小的可用性测试，UE+PM和用户的比例在1：2到1：4可能比较合适。

其次是问题和建议的提炼。这是UE该做的事，就像做完访谈和可用性测试一样。可能活动后还要和个别的用户做更进一步的交流，或者搭配可用性测试等等，把个别的建议转化成定性的研究结果，成为真正可以拿来促进产品的东西。

 

我对于自己工作的设想，是有一部分用户也时不时地参与类似的这种活动，经常参与，成为一种核心的小圈子。很多来做可用性测试什么的人，往往是“过客”，但他们是“熟客”，靠两种类型的参与者来一起促进我们的产品。具体怎么做？嘿嘿，计划中，秘密～

]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010008oe.html#comment Wed, 25 Apr 2007 14:51:27 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010008oe.html Design Checkpoints初试 http://blog.sina.com.cn/s/blog_5772b0e7010007is.html 最近着手准备着我们的可用性测试，突然想到把之前的Design Checkpoints拿出来写写～
先复习下从UPA学来的Design Checkpoints:
http://blog.sina.com.cn/u/5772b0e70100079o
 
回头看看，觉得也不必将其和可用性测试特别区分开来，（觉得自己做的还挺接近可用性测试）。方法的名字已经变得不重要，重要的是：对应时机和公司情况的方法，有价值的结果。
小兔那次的Design Checkpoints实践，我把它定义为“非正式的”，“访谈”，为了“评估”网站的改版设计。那时我们改版的网站还是一份需求书的初稿、和一些页面的效果图。不刻意去准备什么，把效果图都打印出来、设计一下问题，就可以开始了。
 
听取了DTE的建议，之前先写了份评估申请，关于评估的内容、目的、方法和时间资源等等。地点选在了我们一个有沙发的会议室（现在改造成办公室了，可惜>_<）,找了几个有工作闲暇的同事，在比较轻松的氛围里聊。
从简单的询问开始，诸如，除了工作平时是否经常去我们的网站(找的都是设计开发之外的人员)。首先是在UPA那个workshop里印象最深的5-second test，然后问问首页上最感兴趣的内容是什么，得到的结果似乎有点矛盾：大多人都会觉得改版后看上去内容丰富很好，但同时很难对首页上某些特别内容有什么印象。看了5秒之后却记不起首页有什么内容，结果还是会按照自己的习惯去寻找自己目的的入口……
Be the instructor，听人来解释我们的每块内容和每个功能，是最容易发现问题的地方。认为下拉菜单是提供分类查找——而事实上那不是；因为一块新闻上顶了个“每周节目单”，把新闻也当作了节目内容……一度这问题演变成了“猜猜这是什么？”让人去猜想，已经是比较严重的问题了，要命的是竟然猜不出、或者猜错……现在面对的还只是纸面原型，若那可以点击进去、让后让用户发现不是自己想要的东西，那有多糟糕？
干脆从这个方向，来问个“功能猜想”。某个页面上有个我们还没有设计完整的功能，让人来猜猜大概是什么样子，探究一下用户的心智模型。“我想大概会这样吧……”那些意见在我们后来关于功能的讨论中起了不少影响。
想要问用户我们该提供什么内容、什么功能，这样问通常不会得到什么好的回答，太大太概括的问题，或者带w的(what,how)，都很难回答。不要期望用户会把自己的心智模型端出来给你。不过关于细节，还是能得到不少建议，来个Be the designer，比如某处用单选框是不是会好些，按发帖人搜索的功能还是非常重要的，等等……
 
也许因为邀请的都是公司里的人，有一份对于自己产品的关心和责任感，聊得都挺开心，第一次的尝试算不错吧～不过报告提上去，相应的改动并不多，除了那个严重得人人都猜错的地方……这说明怎样让评估测试的结果真正促进产品的设计，是还需要去努力探究的，日后再写一篇来讨论这个问题吧。
 
关于具体的方法，欢迎大家来批批，提点意见和建议，多多交流
 
 
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010007is.html#comment Fri, 20 Apr 2007 03:58:30 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007is.html 失意体前屈的趣味 http://blog.sina.com.cn/s/blog_5772b0e7010008j6.html 我们的产品组每天都交流产品的发现和体验，今天分享到了网易播吧：
咋一看是个普通的博客，不过有个有趣的域名：orz.163.com。为什么用失意体前屈的符号？往下一看原来是有个“我拜”和“我踩”：
有那么点意思～土豆把Digg的概念成功地本土化，有“挖”更有“埋”，还有操作的对象——土豆，而播吧的这套概念也挺有意思。
 
有意思归有意思，问题也是有的：
1.上图“请选择理由”是选择拜的理由呢，还是选择踩的理由呢？真是点开了才知道：
 
2.再进去看，那个“请选择理由”是明白了。但是长相真象土豆……没劲
3.既然要用orz来做域名，但为什么“我拜”旁边的图标是大拇指？既然要玩Orz，没有勇气和办法全面贯彻？
首先乐呵地发现“我踩”没有对应的象形符号；
其次，Orz解释为“失意体前屈”也多少和“我拜”的褒贬词性相反；
“给小红花”、“顶”、“挖”和“拜”，给人感觉“要花的力气”也有些差别吧，就算是流行的玩意儿，也不会轻易就拜倒吧……
这么弄，对于不明白的人来说，这播吧只是有个难记的域名而已～
到时候是失望的用户orz，然后你们自己Orz了……
]]> amizhang 体验 http://blog.sina.com.cn/s/blog_5772b0e7010008j6.html#comment Fri, 13 Apr 2007 07:34:02 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010008j6.html 适时的提示和帮助 http://blog.sina.com.cn/s/blog_5772b0e7010008dy.html 一天下班回家，地铁4号线出站，看见一中年男子走向保安求助，不会用自动售票机。4号线已经没有人工售票窗口，原先的窗口只有每天的一段时间用作一卡通退票口，这时候已经没人。那保安努努嘴斜斜头，示意他走到站中心那里的服务中心去。那男人捏着张五块钱，“册那，伐会得用呀”，原地张望了下，又骂了句“册那”，走向了服务中心。
*PS：为了表示清楚这人的文化素质和当时的情绪，不文明用语照实写出来了。
肚子饿的我匆匆地走开了，路上却想起几星期前，我在这里给一卡通充值。以前84我妈代劳就是去人工窗口，自动机器也是第一次用~出于对各种体验都想研究的心理，我想研究个清楚慢慢看。还没看上个一秒，就一中年工作人员站到身边来说“把卡这里放进去啊”。我心里马上就恼了：你当我不会用呀？我只不过想看看你们是怎么安排插卡、输入金额和放钱的步骤么，再说我也没有十分踌躇很久四处张望寻找帮助呀，帮什么倒忙呀？臭美点说我也是个OL吧，谁要充个值都要你帮忙，真丢面子...
为什么我不需要帮助的时候，有恼人的帮助冒出来；而需要帮助的人，却得不到及时的指点呢？
这首先是地铁服务系统的问题，具体什么时候有工作人员、工作人员该怎么工作，具体的规定我不清楚。但还有个问题，94该不该全部自动化。时代报人才做广告，说“乘地铁的十个有九个是牛人”，我可以理解为十个有九个是有文化水准的白领，那另外的十分之一呢？说粗口的中年男子、下岗女工、民工、退休工人等等，有什么本事能让他们都会用自动机器？我可是不只一次在银行的自动取款机的队伍排了好一会儿，就是因为前面的人不会用机器——别指望大家都会用那些玩意儿，事实也证明你们没办法一直有工作人员来指点。
 
不管是地铁的服务系统，还是互联网产品，这些都是共通的：
不要自以为自己先进，你的服务/产品能不能让人方便愉快地用？
提示和帮助总是需要的，但一定要在合适的时候。做不到就帮不到人，做过头反而是种麻烦。
你总该第一想想怎么把使用过程做得简便友好些，然后，在再适时的时候提供恰当的帮助和提示。至于再详细的该怎么做？Angela的那篇《我要如何了解“她”》很有意思~用户的心思也许很难揣摩，但就像女朋友的心思不得不去了解，这就是我们要做的事。
也许有人要说我那天的反应太多了？记住你永远会有爱抱怨的用户，就像个爱“作”的女朋友，很多细节都会导致他们的不快；
也许你要说这些问题你无所谓？别忘了，地铁再挤再怎么还是得坐(除非有车啊...)，你的产品可不会有那么强势。
 
>>后续：
昨天下班发现了新的情况：
竟然有个喇叭挂在旁边不停地重复着“本站实施无人售票，需要帮助的乘客请按求助钮……”然后我才想起来，哦，似乎是的，旁边竖着个玩意儿上面有个按钮的说……Faint，为什么它不在机器上？
]]> amizhang 体验 http://blog.sina.com.cn/s/blog_5772b0e7010008dy.html#comment Mon, 02 Apr 2007 13:49:24 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010008dy.html 小I智囊团线下讨论会 http://blog.sina.com.cn/s/blog_5772b0e70100089s.html    周六有幸应邀参加了小i智囊团线下讨论会。原本觉得应该是个轻松的焦点小组，去了才发现和我预想的有不少区别。Anyway，是个愉快的、有收获的活动。
   人数是四比四——焦点小组理想的是十比一吧~坐下来互相介绍了一番，觉得前半场更像是圈内交流会。没想到遇上wkcow，上次在白鸦博客上的争论让人印象颇为深刻;交谈之中得知他后来把白鸦他们的博客都认真看了一遍。UE不只是关心可用性，还涉及功能、内容等等，所以我始终觉得要看得广一点，和不是做UE的圈内人聊还是颇多启发的~
   聊了好一会儿我主动问，今天难道不聊你们的产品么?我才换了位置坐在了本本前面，和他们的人聊起小i机器人。
   之前自然是做了点预习，从用户的角度提点小建议。也有问过问题，因为我觉得小I和其他产品不同，可以从用户与之交互的过程中得到很多讯息、而不像别的产品一定要寻找渠道去了解。不过事实是这样的数据很大，虽然在做、但是没有没有那么容易做到。之后让他们观察我使用小i的过程。我想Frank得到了只有亲眼观察用户使用才能得到的发现，我发现他在看我使用的过程中拿起了笔纸来记录:)我该算是个非常配合的参与者，会主动去"Think Aloud"，会说“如果是在家里，我想我差不多就会把它关了”~之后也跟着聊了些关于测试的、关于UE的，然后不知觉中，一个下午就没啦。
 
几点心得：
1.不管是圈内人士交流会也好、焦点小组也罢，方法是死的人是活的，找到合适的、有效的就行。
地点选在咖啡馆是个不错的注意，参加者会比较愿意来、轻松的环境里也会说更多；
邀请圈内人士，可以得到不少个方面的建议、UEer在访谈/测试的时候能主动配合；
不过不管是交流会还是焦点小组，需要有人好好的组织主持，这样才能围绕主题、得到想要的讯息
2.当你真正观察到用户怎么使用自己产品的时候，一定会发现之前发现不了的事情，会提醒你去重视用户体验。现在国内不少的公司都是上层开始意识到要去重视用户体验了，但是能在公司里站出来提这件事、带领大家去做这些事的人，还太少。
3.访谈/测试时提合适的问题很重要。并不是每个参与者都能做到Think Aloud，想知道他在想什么？你就得找个合适的办法去问；如果想去探究用户心中关于产品的理想的心智模型，靠问“你心目中的____是什么样子的？”恐怕得不到什么具体的回答，也许在UPA学到的CheckPoints中的"Go shoppoing!"、"Design the Box"会是不错的办法；用户什么时候会放弃任务？也许在家他早就放弃了，却在你面前反复试？……种种问题，还需要在不断体验中（作测试者、也要做参与者）去发现和解决。
 
探索ing!每一天都继续努力吧~
 
 
]]> amizhang http://blog.sina.com.cn/s/blog_5772b0e70100089s.html#comment Mon, 26 Mar 2007 04:50:59 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e70100089s.html 我做什么？ http://blog.sina.com.cn/s/blog_5772b0e70100088h.html 世界睡眠日，中午我和DTE却聊啊聊啊结果我午觉一点都没有睡，聊我们自己定位和分工的问题。不像腾迅或者百度有成规模、分工明确的团队，我们公司里的team实在小得可怜，数数五个手指都用不全。没有很丰富的经验，公司这一方面也不成体系，自己在工作中摸索着尝试着，好像什么都做但都只做一点？疑惑，两个新手之间讨论也很难有答案。他说他觉得自己像打杂的，我说我都不知道自己博客的标题Ami Zhang's ___ Workbook这个空档该写什么了。于是有了UI，你该如何定位自己？
疑惑的第二天，白鸦他们的UCDchina上线了，讨论的就是用户体验设计在团队中的角色，他们要专业得多，但依旧是个说不完的话题。可用性工程师、交互设计师、视觉设计师、界面制作……看着，说着，一些人大概要头昏了
 
迷惘的时候从自己开始：我能做什么？我该做什么？我现在在做什么？
Ami刚进公司的时候，是“界面制作”，我们的网站有“视觉设计”；
做着做着，我偏向了Ryana提到的技能象限图中的Clarity；我在公司里做了些推进UCD的工作，甚至弄了个讲座；我提出要做可用性测试，boss说好啊，写计划；
然后我有机会把发现的一些可用性问题提出来，找UI和技术一起解决，白鸦说可以叫“可用性QA”;
换到了产品部门，我告诉DTE我印名片了职位是UED，他觉得我该叫做可用性工程师；我的上司希望我从需求阶段就参与，希望我从事些用户研究，还希望参与一部分UI……
现在，Ami除了以上的工作之外，还设计问卷、还在计划自己公司的用户体验试验室……
那我该叫什么？
我进公司合同上签的是“UI设计师”，换了部门之后名片上印的是“用户体验设计师”。
具体在公司里做什么？可以肯定的是我不用做“视觉设计”，至于“原形制作”我还在兼psd到html的工作。昨天认识了臭鱼，我形容自己的工作基本是UE细节优化、用户研究和调查、可用性评估。再具体点？说不准了，我试用期还没有结束呢，说不定过阵子对我的形容概括，又要变化了。
 
于是，我打算这样：
名片印好了，不去改；
现在能做什么，就继续；比如翻页功能的设计、验证码、视线流和鼠标流
还能做什么，向有经验的去讨教，然后自己去探索和尝试
脚踏实地做好现在的，然后一边思考一边继续前行
 
敬请期待一个月后、几个月后、一两年后……的UCD小兔Ami
 
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e70100088h.html#comment Fri, 23 Mar 2007 04:48:53 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e70100088h.html 视线流和鼠标流 http://blog.sina.com.cn/s/blog_5772b0e70100087z.html 这个词的起源是前阵子和同事提出优化登录和注册的表单开始的。为了优化我们注册/登录的表单，我把浅议 Web 表单设计发给同事看，然后我们的表单大概是这样子的：
这样的设计保证视觉的注意点和鼠标路径都是一个顺畅的、向下的过程，并且在最后关键的提交时汇聚在一起。每次都说“视线的移动”、“鼠标路径”什么的也繁琐，然后我就擅自发明了“视线流”和“鼠标流”这两个词啦~:P
如图，绿色的是视线流，红色的是鼠标流。我们没有眼动仪、没有鼠标路径研究的方法，也知道实际视线的移动决不像图示的两条线那么简单。视线可能还是Z字形向下的，要看验证码和复选框之后的内容:

但是这样的设计已经基本保证了用户在填写表单的时候，一步一步很顺畅，最后提交按钮出现在顺利成章的位置，一点，就OK啦。
视线流和鼠标流只是大概表示视线和鼠标路径的移动，在用户进行关键的交互任务时，要尽量保证它们的流畅，也尽量汇聚在一起。
一定要说，只是关键的交互任务，比如填写表单，因为这时候用户的注意力都在这里。用户浏览网页时视线可能在整个页面里灵活变动、鼠标可能在右侧操作滚动——可见鼠标滚轮的发明是件多么好的事，视线流和鼠标流就不会扯那么远了。
 
之后另一个设计的优化又是和视线流、鼠标流相关的：
一行一行的数据，鼠标悬停的这一行背景颜色变化，这样也帮助鼠标流和视线流的汇聚：
然后，在这个的基础上我们有这样的交互：鼠标在这里悬停几毫秒后浮出一块：
问题就出现了~若这一块出现在鼠标的坐标位置上，就会遮住一部分这一行要看的东西，于是，要把它挪到下面；又考虑到用户可能让鼠标指着一行一行往下看，这一块东东不能挡住鼠标往下移；又因为需求里要求这一块浮动的区域也可以点，还要给用户鼠标移到区域内点击的机会……
最后的设计是这块东东出现在了鼠标坐标右下方一定距离的位置，保证横向、竖向的视线流/鼠标流都流畅，也有可以移动到该区域的鼠标流：
恩，这样就OK了~结果是“鼠标流和视线流都流畅”，这般和开发、产品一起沟通解释起来就方便了，一次优化就基本达到目的。
 
PS:弄这两个词儿出来不是要定义某种概念，只是小兔为了方便UI和开发之间沟通时候的一种描述方法
 
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e70100087z.html#comment Thu, 22 Mar 2007 09:07:21 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e70100087z.html 小兔的UE Motto集-(2)不要只看见UE http://blog.sina.com.cn/s/blog_5772b0e70100086f.html 小兔的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...
对于我们来说还做不到，比较理想化，但我们会去努力。
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e70100086f.html#comment Mon, 19 Mar 2007 14:40:38 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e70100086f.html 用户体验RPG http://blog.sina.com.cn/s/blog_5772b0e7010007xy.html 前一阵子要为技术部的同事们做一个关于UCD、UE的讲座，怎样说能让大家理解和接受？当时可谓绞尽脑汁，我的boss也提了一些意见。讲座的前一天晚上突然想到了这个点子，兴奋得失眠就为了整理这个~
灵感来在DMMT中提到的“好感储存器”和一些和Persona有关的概念。我游戏神经不咋的，这样打比方可能有不恰当不完整的地方，欢迎大家补充赐教。
 
首先，我们把用户使用我们的产品的体验过程(暂且局限成'访问我们的网站'吧)想象成玩一个RPG游戏。听到这字眼，也不必想得很复杂，回到n年前最最简单的RPG：
一般屏幕的左上角都有这样的一个人物头像和数值条：
在RPG的游戏里这一条一般都是代表着HP(SP什么的我们暂且不去想)，而在这里，这一条是UEP。
一般情况下，用户刚来访问网站时，UEP是满的。但是可能有很多因素/事件影响UEP，比如在DMMT里见到的这张图：
手机拍的，看个大概。详见DMMT第10章-可用性是基本礼貌
首页上看不到想要的信息，也许UEP就减了10；找东西很费劲，减了20；碰到问题FAQ里也没有答案，又减了30……
减着减着，UEP也许变成黄色了，不多了，用户已经不高兴了；再减减，红色了，已经明显给用户造成了消极的体验；最后减到了UEP=0，耗尽了用户的耐心，这里生成游戏的失败条件：
 
当UEP减为零时，用户完全失望，会离开我们的网站。
 
这里也包含了一个我的观点：UE设计的细节会累积、然后影响用户对于我们的总体感受与评价。
但恐怕游戏的失败条件还不止一个。我们有同行业竞争者，用户可能还在访问他们网站/使用他们的产品，也就有了UEP'、甚至UEP''……用户用脚投票，当他们觉得另一个更有用、更好用，就会离开我们而投奔去我们的竞争者，即使我们的产品也做得还算不错。这就生成另一失败条件：
当UEP'＞UEP一定数值时，用户会离开我们的网站，选择别的产品。
 
但人是不同的，有些人耐心比较足、有些人天生要求高、有些人用什么东西都会很快上手……就好像在游戏里，不同的玩家有不同的等级、HP最高值、攻击力等等~UEP初始值为多少、遇到什么样的事情UEP减少多少？为解释这些问题，我们把上面这个超~~简单的RPG再完整一些。
 
游戏里应该会有这么一个人物属性界面：
不同的人会有不同的等级、属性、能力等等。在用户体验的RPG里，用户也会有类似的属性：
人的耐心可能影响UEP上限，就像游戏里体力影响HP上限；
一些人在体验过程中容易受挫，UEP下降得快，就像游戏里防御低每次受攻击就减血多*；
某些人对某方面的要求比较高(比如视觉效果)，那么视觉效果对他的UEP影响就更大，就像游戏里火属性的受到水属性攻击时伤害可能是1.5倍*；
游戏里人物有等级，谈论UE的时候我们也会说“新手·专家·中间用户”*；
也许我们还有些特殊的访问者，使用屏幕阅读器、或者是色盲，如果可访问性没有做好可能就造成“致命一击”*；
…………
诸如此类，最后形成用户体验RPG的专用人物属性表：
属性探索整理中*
我们可以采用类似Personal的办法，建立典型用户的属性表，来分析出一定的用户需求，找出产品设计的侧重点。
 
通过这样一个简单RPG的比喻，Ami向同事解释UE在用户使用我们产品过程中可能造成的影响。当然，这样的解释可能是表面的，也不能解释大部分的UE要点，但是起到了“入门”的作用，相信要比一大堆理论来说更容易理解和接受。
而且我打算把这个有趣的比喻好好整理，成为自己的独家理论^o^ 文章里有不少*，那就是以后会补充完整的地方，希望大家能多给意见:P
 
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010007xy.html#comment Mon, 12 Mar 2007 14:57:10 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007xy.html 小兔的UE Motto集-(1)眼光要既专注又宽阔 http://blog.sina.com.cn/s/blog_5772b0e7010007zy.html 关于UE，我始终还在积累经验、持续探索的阶段，每天的努力中，都会有一些心得和发现。在这里和大家分享我的Motto，在工作和学习中都不断督促自己。
要说我的第一Motto，该是那句“用户体验从细节之处累积”，这句会结合以后的文章来解释。今天就结合白天工作感触说说：
  • 做UE，眼光既要专注又要宽阔
专注，这很容易理解，UE就该一切从用户的角度出发、致力于提供尽可能好的用户体验。但对于一个好的UE来说，这些远远不够。
举例比如我之前写的再说验证码，单纯从UE角度来说，当然是不该有验证码，但是这种情况要考虑相应的技术安全问题；
又比如今天：我们产品的UI要坚持一个细节的设计：固然那样做的确可以给用户体验加分，但是技术实现却很复杂，最重要的是开发进度紧得很技术部都加班了——这个设计的确好，但一边嫌开发进度拖延一边为小事情动大干戈，这样好么？如果它好，这个小细节可以不在1.8的大改版推出、放在日后1.8.1么。这里的UE，还得考虑技术实现和开发时间的问题。(互联网时代不是大鱼吃小鱼、而是快鱼吃慢鱼，类似的意思PM肯定说过吧)
之前在白鸦的博客上曾经引发了对于UE话语权的热烈讨论。我认为，UE的话语权除了靠公司重视你赋予你权利之外，更重要是靠UE自己争取而来。一方面靠自己的能力、提供合适的建议来使大家信服，一方面要学会去沟通去融入整个团队，不能死脑筋地说我们就该这样这样做，不管技术问题、不管时间进度……这样肯定不会把话语权交给你。(不软弱不盲目妥协，但适当的时候要学会妥协和寻求另一种办法)
如果要对这句Motto做个简单的解释，那就是UE始终最重要的、第一的是从用户的角度出发，但同时也要眼光宽阔，去综合考虑技术等其他的因素、沟通的时候也为团队中的其他人想想。
 
小小心得，欢迎大家的建议~
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010007zy.html#comment Wed, 07 Mar 2007 13:10:12 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007zy.html 一些"用户体验改善计划"的收集 http://blog.sina.com.cn/s/blog_5772b0e7010007ya.html 收集起来挖个坑，以后陆续补充完整~
 
这种办法的道理其实还是类似spyware(虽然不是spyware，都要经过用户同意)，好处是不必特别邀请用户过来观察他们是怎么使用的。但缺点是我们也不知道用户使用软件时想些什么、有什么感受。
关于技术上的实现问题，有空找开发人员问问去~
 
MSN的：
 
 
在界面上点击“了解‘客户体验改善计划’的更多信息”后，弹出下面的对话框：
 
这是MSN“客户体验改善计划”的更多信息：(点击查看正常尺寸)
 
 
Office的：
右下角弹出气泡~
 
暂且只收集到了微软的。微软很多产品都有CEIP，不过是每个产品分别让用户选择是否参与该计划。
 
Microsoft 客户体验改善计划：
http://www.microsoft.com/products/ceip/zh-cn/default.mspx
 
Microsoft?客户体验改善计划隐私声明
http://www.microsoft.com/products/ceip/zh-cn/privacypolicy.mspx
 
 
= = * 小公告 * = =
最近搬家，比较忙，要写的东东都在草稿箱和脑袋里，过阵子整理了放上来:P
 
 
]]> amizhang 体验 http://blog.sina.com.cn/s/blog_5772b0e7010007ya.html#comment Sun, 04 Mar 2007 01:53:21 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007ya.html 再说验证码 http://blog.sina.com.cn/s/blog_5772b0e7010007lh.html 有了在水浒Q传里糟糕的验证码体验之后，我对验证码变得很反感。不过今天在公司里讨论，我却是"暂时不要撤销验证码"的一员。不是说我的想法变了，如果理想的说，我还是绝对提议不要验证码的——不该让用户来分担技术安全的问题，验证码是接近实现模型的东西；而是作为一个负责的UI设计师，要综合考虑各方面因素来作出决定。
 
如果除了验证码，网站的技术措施没有办法抵制攻击和控制秩序，那就该考虑考虑是不是撤销验证码。为了这一方面的用户体验的提高，可能是冒着造成更大恶劣体验的风险：当用户看见大量恼人的广告贴、当用户看见满屏的刷贴、当服务器承载不住攻击的流量而当掉……一旦它们发生了，负面影响可比验证码来的大得多。就算靠维护人员去删，那也是亡羊补牢避免问题扩大而已。
可能是因为身在技术部，可以说我更容易为自己人去考虑问题，但我始终是以为用户考虑为第一——权衡取舍，为尽量给用户提供最好的体验。
 
若暂时还不能撤销验证码，那我们把它做得方便简单些：把英文数字变成纯英文、输入时自动换档全部大写；减少验证码图片的噪点，少做文字变形；选择容易辨认的清晰的字体。我们想过很多，甚至想过把验证码换成简单数学题(不过很快就被枪毙了，机器要遍历答案很容易；用户会认为我们把他们当傻瓜)，而且最开心的是我们的开发人员会主动去想代替验证码的安全措施——和他们沟通合作我觉得很愉快。
 
一日大家凑在一起找合适的验证码字体，上百个字体一个一个看过来。这里有些选择验证码字体的小经验可以和大家分享：
 
通常为了找容易辨认的字体，都会先注意粗细适中的无衬线字体，比如这种:
但不见得它们就合适，往往C和G和相像、I会被误认为是1(我们要用纯字母了，但用户可能还会以为有数字啊);
PS:如果不知道什么是有/无衬线的字体，拿个有衬线的来比较下：
 
粗体的固然醒目一些，但是比较拥挤而且笔画造型容易导致困惑：
比如上图的J,L和Q
 
找一个比较合适的：
我们要求是：
粗细适中、笔画圆润简单的无衬线字体;
每一个造型都容易辨认；
G,I等细节处都有区别；
可以有些大小变化，但不要拉伸变形影响辨认。
 
这就是我们暂时的对策了。既然还撤不了验证码，起码把它做得简单些、减轻一些用户的负担。暂时性的对策还可以考虑：未登录发帖需要验证码，登录后不需要——对注册用户我们相对可控，而且可以鼓励注册登录。
 
最近工作的两大关键词：权衡.沟通。 还是坚信这一点：从点滴之处开始努力，可以累积起良好的用户体验。
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010007lh.html#comment Thu, 08 Feb 2007 13:15:49 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007lh.html 翻页功能的设计 http://blog.sina.com.cn/s/blog_5772b0e7010007lg.html 看见带页码的翻页体验与设计比较的时候真是及时，马上参考用在了工作里，把原先的翻页功能改善了下。和开发人员讨论后，设计成了这种样子：(不上图了，文字表示一下)
 
<上一页 1...5 6 7 8 9 10 11 12 13 14 15...50 下一页>
 
<上一页 1 2 3 4 5 6 7 8 9 10...50 下一页>
 
大致的设计思想是：永远显示第一页和最后一页的页码，当翻页无效时灰色显示。视觉上的设计每个页码和都是有个小框的，当前页的页码采用不同的颜色、无框。
 
什么时候显示省略号、页码显示多少个，都需要有个约定，所以又设计了相应的规则。具体数字可以作变化，用类似公式的方法表示：
 
每页最多显示n+m+n个页码。第一页和最后一页显示m'+n个页码，当总页数小于等于m+2n时，不会出现省略号；
中间的m个页码，从n+2到n+1+m起左侧显示省略号，至k-m-n-1到k-n-1右侧显示省略号
 
关于这里的几个变量：
n: 从功能上说，显示第一页和最后一页就可以了，也就是n=1。但可能让这两个页码显得很孤立，所以淘宝的设计是n=2，如图：
不过我们的页码有了框，孤立感不明显，n=1
 
m: 除了第一页和最后一页，中间显示的页码数。m=11的好处是显示3~13、25~35这样完整的一组页码。不过后来和我们的产品讨论，考虑到我们的总页数不大，改成m=7
 
m': 出现在第一页、最后一页时显示的页码数，m'<=m
 
k: 总页数
 
这逻辑看上去比较复杂，不过定下来之后就没有那些变量了。再说，具体的规则是写给开发人员看的。不敢说是很完善的设计方案，只是在原先<上一页 1 2 3 4 5 6 7 8 9 10 下一页>这种简单的设计上进行了改善。
 
不过我坚信，从点滴之处开始努力，可以累积起良好的用户体验。
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010007lg.html#comment Tue, 06 Feb 2007 07:14:05 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007lg.html 关于标签云集Tag Cloud的疑问 http://blog.sina.com.cn/s/blog_5772b0e7010007fy.html
那天看到了UI花园的文章，中文网站的Tag Cloud:
http://www.uigarden.net/chinese/zhong-wen-wang-zhan-tag
看完之后立即想到了公司网站的tag cloud...那个页面印象深刻啊，第一眼可以用“惊讶”来形容~ 大量的标签，分了类别，也用通常的方式——热门标签突出颜色和尺寸。这个页面让我感受到了“标签云集”这个直译有多形象(虽然我们是叫标签总览的)——就像是片云，汇满了n多的水珠。
 
文中提到的中文Tag Cloud不突出尺寸是很有道理的，很欣喜知道网站改版后Tag不突出尺寸，颜色的选择也合理了些。但是我们的Tag这般雄伟的量却没有改变，这让我又不得不思考。
 
Tag Cloud的第一个作用可能是导航。但清晰的导航基本也该符合或者靠近7±2原则，也就是说，只适合少量的标签。
第二个可能是分类。乍看和导航好像差不多，但我觉得可接受的数量能大一些，十几，二十几？可以把内容归类检索。导航的数量也可能是到这一级别的，有时也颇为无奈，只能算是比较差的导航。
第三是关键字。可能是标签最适合出现的一种形态。豆瓣啊，土豆啊~这种类型的网站，标签的量都是可观的，上百、甚至上千。如果没记错的话，土豆的视频就是靠标签来作为关键字搜索的(某个播客有很多动画片，但主人标签都不好好设置，然后用土豆搜索相应的动画时，就搜不到该播客的结果。按名字搜不到？多奇怪)
 
其实，对于某个人的博客或者某个个人用户来说，标签是可以成第一、第二种作用。比如某人的博客，标签可能有UCD、用户体验、CSS、摄影、生活……等等的标签，访问标签云集的时候可以当作分类或是导航。但是对于一个网站来说，标签很有可能就是海量的，比如抓虾、豆瓣，他们的标签多得数不清楚，还会有些不规范的对别人没用的标签(我用抓虾就有时会打上“等待详读”的标签，有时没有看完但是打开后抓虾都会标记成已读)，量是没有办法控制的；但我们公司的网站又有些不同，标签是编辑打的，只随着我们提供的内容增加而有变化，虽然量也很大，但却是可控的。
 
但我依然迷糊：就算标签的数量是可控的，还给标签分了类，但标签云集依然是好大一片密密麻麻，这能给用户提供怎样的信息检索功能？数量太多的结果恐怕是引入你眼中的只剩下那些热门Tag，成了热门标签推荐？
 
那到底，什么样的访问者会用到标签云集？在什么情况会需要用到标签云集？用了做什么？对于标签云集的存在，我依旧不理解。
]]> amizhang 探索 http://blog.sina.com.cn/s/blog_5772b0e7010007fy.html#comment Mon, 29 Jan 2007 13:01:28 GMT+8 http://blog.sina.com.cn/s/blog_5772b0e7010007fy.html