一直以来，小兔推行UCD都把心思放在怎样创建UCD氛围、推进UCD实践和具体的做法上。但是随着逐步推进和实践的累积，发现怎样把努力转化成实效，一样不容忽视，这关系到今后如何继续和进一步地推进。不论你是一个关心用户体验的设计师、开发、产品经理，或者专职的可用性工程师，当你提出一个可用性相关的修改意见、或者提交一份可用性的评估/测试报告时，是否遇到过这样的情况：

提出的意见/报告犹如石沉大海，没有任何反馈，相关的人爱理不理；

PM或者设计师不肯接受你的意见，反对、争执不下；

人家觉得你是在找他们的茬、指手划脚干涉他们的设计。

是时候想想怎么把事情做出应有的效果了。

我有几点建议：

一、提升自身素质

在用户体验概念获得越来越多人关注的今天，其间其实也混杂了很多不甚了解的夸夸其谈者。研究下哪个按钮该怎么放，就扬言说自己是搞用户体验的了。连半杯水都没、就几滴水的素质，就想去指点别人，不仅不是对同事和产品负责，更是对自己不负责任。 (全文…)

UCDChina曾经有一期的话题是“交互设计做什么”，当初还没有比较成熟的想法，没有写。这次招聘交互设计师，稍稍聊一些吧。

最近面试的两个交互设计师，为他们准备了一道题：

一张打印的截图，是一个社区的帖子，下面有个简单的输入框和回帖的按钮；

准备的文具有A3、A4纸，铅笔彩笔，n次贴，还有透明塑料膜；

现在给这个社区在发帖回帖时增加贴图的功能，可以外链图片或者上传本地的图片。图片有格式大小限制，上传后还会经过审核，不通过的会被删除。请设计这个功能的交互

我希望看到的：

展现你的逻辑思维能力。Junchen有建议过出逻辑题，不过HR装题库的磁盘损坏了，还是决定直接出题；

是否考虑到了整个流程的“交互”。是否在现场的设计中考虑到了我陈述中包括的可能情况，如图片格式不对、上传之后图片被删除，甚至我没有提及的情况；

是否能简明完整地把设计表现出来。给的文具可以用也可以不用，但是你怎样把设计传达给接收者？今后工作出怎样的交付物？点了某个按钮之后会怎样，如何返回上一状态……

是否考虑用户和产品的上下文。虽然面试题无法考虑得那么复杂，但是是否有这个意识，也很重要。这样的交互对于用户是否适合、对于产品是否适合？ (全文…)

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

M前阵子被提做了产品经理，负责一个产品的全新改版上线。规划产品的结构和功能、设计算法、和设计师一起讨论交互设计…忙得不亦乐乎。在这个网站里查看信息可以按分类查看，也可以按分数等进行排序。

不过一天，开发和运营跑来问，“默认”排序是怎么排的？

默认？就是按默认的排啊。M这才发现自己没有考虑过这个问题。
查看大量复杂信息的时候，我们往往会考虑给用户提供按不同的属性进行排序，比如按分数降序、按价格升序/降序、按时间、按数量等等……以方便用户浏览有条理的信息，并更快找到自己需要的信息。但是，在用户进行排序方式的选择之前，我们用什么顺序来展现信息？而且，排序方式的选择更多是高级用户使用的操作，对于那些初来乍到和新手用户来说，我们怎么展现信息呢？ (全文…)

在可用性测试中，最主要的两个角色，一个是受测(Test Participant)，另一个是测试员(Test Facilitator)。这回小兔来说说测试员(Test Facilitator)在可用性测试时应该做些什么、说些什么。
之前有翻译过Test Facilitator Guide（可用性测试开始前），那么开始之后该如何呢？这里有一篇文章，拿来作为例子说说，小兔也和自己的做法对照比较一下，好借鉴改善。

WAI Site Usability Testing Questions
原文：http://www.w3.org/WAI/EO/Drafts/UCD/questions.html
小兔翻译：http://www.amizhang.com/?p=59

文章包括了四个部分：
Pre-test Questions（测试前问题）、Participant Tasks（受测任务）、Post-test Interview（测试后访谈）和Post-test Survey（测试后问卷）。这是WAI（Web Accessibility Initiative）网站可用性测试，测试员 (Facilitator)在测试时提的问题和任务的设计。

Pre-test Questions（测试前问题）
测试前的问题是用来了解受测的，WAI的这个例子里，可以看到问题关于受测对于可及性(WAI的主要内容)的了解、平时访问的相关站点、阅读习惯、工作背景等，以及大概的心智模型。了解受测，才能在之后明白受测的行为，便于进一步分析产品的可用性问题。我们在招募受测时也会做一些甄选，但是都比较简单，而测试前提一些问题可以了解得更真实具体些。根据产品的特性，我们可以设计不同的问题。 (全文…)

Question:
在做一个可用性测试/访谈/焦点小组的时候，你是否告知用户在录像、录音或者有人在观看？

参加User Friendly 2007赵晨的workshop的时候，她愤愤地提到国内不少人在测试的时候不告知受测正在录像。赵晨来自IBM，是个很“学究”的人，知识和方法毋庸置疑来自西方，在她看来这样似乎是违背了做UE的专业精神。另一个workshop，Autodesk的一位美女博士为我这样解释：因为在欧美对于人权非常注重，而且有相应的法律规定，因此这方面非常重视。

这样做似乎是很必要的：我们推崇User Centered，把用户请来体验我们的产品，却偷偷录像不告知，岂不是有违我们尊重用户的态度？ (全文…)

关于可用性测试，对我们来说已经不陌生，现在国内也有不少公司开始做可用性测试。不过基于纸面原型的可用性测试，我猜想就很少了。今天小兔就来谈谈实践之后收获总结吧Ami Zhang

可用性测试并不是只处于流程的中后期。在产品设计最初阶段，如用户需求的阶段都可以使用，在测试现有版本产品或者竞争者对手的产品，用于发现用户需求。在产品开发成型之前，测试原型也是很好的办法，理论上原型都可以测试，不论是低保真的线框图、还是高保真的能交互的原型都可以拿来测。
原型阶段测试，可以尽快改善，形成迭代设计。这就是基于原型的可用性测试的优点1：更早地发现问题，降低修改成本。

另外，基于之纸面原型的测试，不必要有电脑甚至能上网的地方，于是就有了优点2：测试的场合环境要求低，地点时间都更加灵活。www.amizhang.com/blog

(全文…)

快快，趁公司旅行之前再写篇博客。昨儿有点high，准备公司旅行、晚上还有个创意讨论会，加班回家精神还很好，发现怪兽上了呜啦 。

哇哦，又一嵌入式的Twitter～我的些许质疑马上被乐趣挤掉了，这个还挺有意思的。记得之前给怪兽提过建议，我有“看朋友们最近发布的宝贝”的需求，那时我想该是个和我的宝贝对应的“朋友们发布的宝贝”，没想到怪兽最后用了这样的方式呈现，不过，的确解决这个需求啦～

貌似Twitter已经不是个产品的名称，而是一种功能的代名词了。

在国内，我们有饭否、叽歪de、滔滔，也有豆瓣的广播(语录)和怪兽的呜啦，连小兔和同事聊自家产品功能的时候也聊到了类似的想法。当初老外做Twitter是个极其简单的东西，没想到在中国出现这样的变体～总体来说觉得饭否是做得成功的，像是一个生活和头脑的广播站——我曾经也想过是不是在饭否也可以来条“Ami在怪兽秀了一个宝贝：XXXXX”，但这不见得是个好的办法。比如和我同事的一个MM，就觉得饭否有点吵闹了，信息太多了点。从这种分离出来的需求说，豆瓣的广播/语录还算是蛮不错的东西，在这个产品范围内Twitter，也不需要绑定IM那么强势，就是来的时候，知道友邻们在读些什么想些什么就可以了。豆瓣从语录到广播逐渐成型，倒给了怪兽一个不错的榜样。

在呜啦上感叹产品内嵌Twitter风，的确有其存在的价值，1stcool回应道“总觉得Twitter作为一种应用，不太适合独立成系统，更适合锦上添花”。的确Twitter作为功能来说，很适合这样。回头看看Twitter最初的价值：让朋友们知道你最近在干什么。这年头的人都太忙碌啦，和朋友的沟通也比较少，Twitter让我们互通近况更保持联系——那么内嵌作为功能的Twitter，就是加强了在某个网站内用户之间的信息传达，可以促进更多的互动，更2.0，用户更“活”了。

有意思的是，Twitter的应用也因为名字而有各自的特性。饭否，顾名思义，“吃饭了没有”，是Twitter本地化很好的一个名字；叽歪de，叽歪么，感觉小小的、杂碎的、有意思的小消息；豆瓣语录，带着点读书人的思考味；而呜啦，轻松，随性而至，甚至还可以绕口令或者唱歌(貌似我起到了促进作用^o^)

1stcool 无敌的绕口令，班干部管班干部。无人可快速连续说10次以上。约 6 分钟前
vivian 东风市场卖混纺，红混纺，粉混纺，红粉混纺粉红混纺，金混纺。混纺上面绣凤凰，红凤凰，粉凤凰，红粉凤凰粉红凤凰，金凤凰。约 10 分钟前
……
Ami Zhang 呜啦因为名字的关系，出现了一种新的twitter内容形式：绕口令/唱歌:D约 17 分钟前
……
Ami Zhang 呜啦啦，哇啦啦，拉拉拉拉啦啦啦～ 今天有点high约 34 分钟前
……
1stcool 呜啦啦 呜啦啦 啊足哦呐 咖达啦 咖达啦 啊足咖呐 呐呐哩 达lio哆 莫哆呐呢 啊呢哩 啊呢哩 啊呢哆内 he衣呀 D衣呀 he衣呀呢啦呢哆 哦几哆 莫哈呐 咖lio咖嘛约 40 分钟前
……
得瑟er 呜呜啦啦约 42 分钟前
1stcool 呜啦!约 48 分钟前
师妹 呜啦？约 52 分钟前
……
上邪起解 呜啦呜啦呜啦啦,我爱饰品约 1 小时前

Twitter可以做成产品，像腾讯做滔滔这种，应该不会做砸，但是我觉得真厚脸皮。相比之下，给自己的产品嵌一个Twitter，根据自身特性变化而给产品锦上添花、甚至起到革命性的变化，是蛮让人期待和感兴趣的事。

今天在公司内部的讨论区里，有人发了一个贴——“以人为中心的设计是有害的”。产品的讨论区是大家经常探讨产品创意，新产品体验和小兔宣传UCD的地方，冒出这样一个专题，“嗡～”感觉爆出了一个小小的炸弹。
很认真地看过了，原来是原载于UI花园的
http://www.uigarden.net/chinese/yi-ren-wei-zhong-xin-de-she-ji

这篇文章，不得不反驳。

文章里提到了以行为活动为中心的设计，其实本身就是以用户为中心的设计中的一部分，关注的是“用户的行为”，行为是由目标和需求驱使的。跳来跳去，还是在如来佛的掌心里啊～

“以人为中心的设计坚持的一个基本信念是由技术来适应人”
UCD并不是一味地“让技术适应人”。技术是为人服务的，因此尽量让技术去适应人肯定没错。若是有新的、好的技术、产品或使用方法出现，它们也会有被学习、甚至被适应的价值。把UCD片面地概括成技术适应人是不对的。

的确有很多优秀的产品，他们的设计并没有基于大量的用户研究，那是因为非常出色的设计师，有着优秀的洞察力、了解目标用户和领域、有着非凡的创造力。充分的用户研究有助于设计更好的产品——但若反过来强调一切从用户研究中来，那就太教条了。

“对于某个人（或一个群体）的关注也许能为这些人改进产品，但这是以牺牲其他人为代价的，一个东西越是为了某个特定的喜好、厌恶、技巧和某个特定的目标人群而进行特别设计，它就越不可能适合其他人”
产品有一定的针对性绝对没有错，理发师用的打薄头发的剪刀不适合你去剪日常的纸张。这个作为反对的理由太荒唐。

“过多地倾听用户”
把这个列为UCD的缺点，是个很肤浅的错误。用户说要什么我们就做什么——那就不叫做UCD。我们关注的是用户真正的需求——用户自己说的，只是作为参考(用户常常自己也不知道自己要什么)。但为了发觉真正的需求，去倾听用户是很必要的。

对于作者这样写，我只能做以下三种猜想：
1. 在UCD越来越热的时候提这样的标题观点，吸引注意吸引点击量
2. 对于UCD的理解过于肤浅
3. 如果不是2的话，指出一些UCD的片面肤浅的认识和做法

我觉得根据作者陈述的理由，不能得出“以人为中心的设计是有害的”这种结论。顶多，指出了可能存在的缺陷。
看到这篇文章，说实话是有些怒的，这标题岂不是否定小兔我工作的价值？会导致很多对UCD了解不够的人，对UCD的质疑。但反过来说，这的确也给UCD从业者们一个警示，不要让自己盲目了、片面了。

我们讨论产品的设计的时候，经常会拿着纸边聊边画，不过经常你涂一笔我画一框，随手涂鸦的东西讨论过了就变成废纸。今儿小兔第一次认真地做了一个纸面原型（Paper Prototype）

是一个关于投票功能的设计，该放在哪里、怎样表现？投票了之后怎样变化？干脆做成了一块一块放在桌面上讨论，发现把它们拿来拿去的还真是方便。用得挺开心的，记录一下芝麻绿豆般的小心得吧～

纸面原型最大的好处无非是快，比你用ps或者其他软件快，所以千万别把它当手工课一样做，太复杂了——纸，笔(准备几个颜色的马克笔还是不错的)，尺，剪刀，就可以啦～

另一大好处就是表现交互～要做一个表现交互的demo很麻烦，但是用几张纸片表现却不难：“投票后，这部分就变成这样”、“没有投票的时候，是这样”——换一张纸片或者挪一挪就行啦。

从这点延伸出来说，如果想在设计过程中尝试Paper Prototype，用这种容易表现而且效果明细的来上手是最好不过的了。
不过，并不是什么原型都需要用纸面原型，有时这种方法并不快捷。建议在讨论布局、电脑平面难形象地表现交互的时候用。

另外，Paper Prototype的好处，是紧张工作时候可以用手工调剂一下，然后轻松地讨论~ [smile]