先抛几个比较关键的调研结论

这些调研数据采到的样本不是很广，但基本具备了代表性，作为参考是不错的。顺便说明下这些结论我认为可以公开出来分享。

• 用户对于勋章的需求既有趣味性，也有功能性。其中功能性包括实质的现实好处、以及在社区中勋章能带来的成就感、荣誉感。
• 80后用户大多数喜欢设计特别、勋章名字俏皮、样子吸引眼球的勋章。也有实用派对本地化活动更看重，但勋章本身的吸引力也是紧随其后排第二。
• 奖章的数量控制在90个左右为佳。
• 基础数据勋章、趣味勋章和运营活动勋章的设置比例大约在4:2:1，会比较好。在这个比例内用户不会因为拿不到勋章而放弃，也不会拿到太多无趣的勋章而厌倦。
• 勋章分类不宜做，用户的理解差异较大，且利益不明。

获益匪浅的收获

其实对于奖章本身来说，并没有很多经验值的增长，因为奖章这东西在策划的时候有80%以上来源于对自己产品和用户的了解。更多的经验是在做策划时宏观和细节上的思考。

1.多维度来分析奖章。维度多少为好？多多益善。这是从老板纯银那里得来的经验。在考虑奖章框架时，我拟好了几个维度：更细分的用户（新用户、中期用户、长期用户，并再细分普通、优秀、特别活跃）、勋章本身属性（基础数据勋章、趣味勋章、运营勋章）。后来做下去时，纯银拟了更多的维度：获得勋章的时间段（7天获得、30天获得等等）获得勋章的难度（简单、有难度、特殊）。于是整个系统会想得更加清楚，也提前发现了策划案中的问题（难度分配不合理等等）。其实这就是个大道理，多角度的去思考问题。不过这次我才真正地明白怎么去实践。

2.站在别人的角度上思考。

虽然我一直知道做产品要站在自己的角度、运营的角度、技术的角度上思考，然而总是不够。如何加强呢？其实也是个习惯问题，做完一个策划案后，立马重头再看一遍，这时已经站在技术的角度上了。懒于复查这个习惯是我从小到大养起来的，小学时做数学题一遍都不检查直接交卷子被老师批；写作文从不检查错别字；及至今日做策划时也积患成疾。其实能够多看一遍、多想一次，这也是大道理。奖章里的各个细节都要考虑到价值和开发的成本，譬如在一个奖章下面加上“最近获得该奖章的人”，这点对于那些获得了有难度有意思的奖章的用户是有益的，但是和开发工作量比起来，还是不值得的。

说来说去都是大道理，但是能下次做事的时候想起来并且运用到，若非多亲历几次，是相当难的。能够没什么经验值就明白这些道理的人，那就是天才。

类似的网志，挑你喜欢的看：

• web社区的内容为王—Friend feed和google buzz为什么不行
• 设计中的边际效应
• shimu将不再对ie6做兼容（更新：已兼容chrome）
• 用wordpress搭建一个网店
• 从腾讯微博的特别收听猜想开去

腾讯微博近期推出了特别收听，用处就是只在这个tab里显示你特别收听的人的广播。群众们的反应暂时不知道。就我个人而言（我的收听人数不多，尚且不需要不同的tab来过滤），没有很大影响。不过我相信这个功能完善起来对于很多收听人数在150+（这个数字来源于一个社会学的研究，人一般至多有150个亲密的朋友）以上的人是很有帮助的。

为什么要有特别收听？

这是因为微博本身的信息量巨大以及质量参差不齐导致的。我们假设一个群众A，他热衷于互联网，收听了很多大牛/小牛/身边的牛，以及一些生活或工作中的朋友。对他而言，收听这些牛主要的“积极”需求是旁观大牛们的妙语，从中获取自己渴求的信息和思想。收听人数一旦增加到一定程度，比如150，他就需要花费大量的时间在微博上把大牛们的信息从其他生活或工作中朋友们的流水帐里提取出来。于是，特别收听应运而生。

我们回到社交的根本来看，在微博上大多数人与人之间是临时连接的关系（temporary tie），你其实根本不知道那人是谁，但是对他的某一条推有兴趣；而你follow的人则大多数是弱连接的关系（weak tie），大家都是道上的朋友，相逢何必曾相识；很少会有强连接（strong tie）的关系，我的密友基本上跟互联网不沾边。由于微博信息量巨大，临时连接和弱连接之间的比值可以说是趋近于无穷大。这也就是为什么twitter会出一个list功能，让人们可以不用follow别人，也能及时跟踪他们的推，也就是说让我可以和临时连接关系的人们用另一种方式交互，同时这些list还是公开的，可以让别人follow，也就是说让更多的人去建立这种临时连接的交互关系。其实twitter也好，国内各个微博也罢，他们的话题也是基于临时连接来做的。

特别收听要比list设计得好。特别收听在全部广播同一水平线上作为一个tab存在，而twitter的list则是在侧边栏，同样的新浪微博的分组也是在侧边栏。侧边栏的关注度远远没有特别收听所在的区域上高。所以除非是高级用户，对list或者分组的使用会小于特别收听。而只有给予了足够多的

为何腾讯微博里没有做list

以下是我的猜想。我们可以回过头去看QQ这个产品用户的行为是怎么样的。我手上并没有数据，但凭这么多年观察身边的人使用QQ的行为可以发现，国内用户对于强连接的需求，是大于临时连接的需求的。很多人的QQ好友都大于300多，QQ群也都塞满了。这些好友和群里估计只有10%不到是最近半年聊过天的，只有5%不到是经常聊天的。这种现象要追溯至QQ红起来的那段时间交友盛行，网上留个QQ号加你太方便，聊过一两句之后下线，下次再见我就不知道你是谁了，而且也懒得去清理（勤快的用户半年清理一次）。也就是说其实是在网上的一个临时连接，但很容易地就在用户的QQ“好友”这个弱连接里出现了。由于临时连接的人数太多，用户开始把经常聊天的人（家人/亲密的同学/真“朋友”）分组，并把那些临时连接扔到默认的“未分组好友”或者“我的好友”里。也就是说相当于在QQ里，把弱连接的人过渡为强连接。

于是我猜想，腾讯微博也是这个思路。这也是国内用户和国外用户之间的区别（国内的IM加为好友的验证机制出台较晚）。用特别收听来打造一种强连接。

继续猜想，特别收听只是个起点

人与人的关系除了三种强度不同的连接之外，还有不同地连接种类。比如我的高中同学和大学同学，大学同学和同事，同事和互联网上的朋友，他们是不同的种类。很有可能我想说给高中同学听的话，大学同学看了不知所云，同事表示认识到另外一个我。于是在信息量巨大的微博产品上面，这种需求会更严重。比如前段时间foursquare刚热起来，很多人不适应foursquare的重度用户在twitter上频繁check in，但这些重度用户的同道们则表示情绪稳定。

腾讯微博的特别收听出来之后，以后会有很多种可能的变化。首先，全部广播和特别收听只占了如此长的tab区一小段，完全有理由期待后面还有更多的tab。也就是可以让用户对不同的收听对象进行分组。学习啊，生活啊，工作啊，吃喝玩乐啊，甚至一起去天上人间的伙伴啊等等，无所不包，真正全民微博。这里可以把自主权完全交给用户，分组的名字自己区，排序自己排，等等可以想象的空间够大，关键是要抓住社交的根本。有了用户自己搞的分组，用户就可以在广播的时候，选择让哪些分组收听到这些广播，这样信息量巨大的微博对大多数人来说就少了很多的“干扰”信息。比方说我的上司收听了我的微博，我刚好想发一条“新来的女同事真好看！”广播，这个给老板听到应该不怎么好，但我又急切地想把这个消息广播给我的同事们……于是发广播给指定的分组就起作用了。听起来很像一个QQ的升级版，由一对一或一对多的信息传递方式升级为一对多或一对所有的信息传递方式。顺便多说一句，新浪微博和搜狐微博在搞的微博群组，是把信息传递方式升级为多对多，多对所有。为啥twitter没有这么搞这么多东西出来呢？你可以试试在twitter上多联系利用hash tag+搜索+list，一样可以满足你多样化的收听需求，但对于发推给某些特定的人看见，目前做不到。

在twitter上国内用户对list的使用远远小于老外们。不用怀疑腾讯对国内用户深刻地理解。这只是我的一篇猜测，网志中的一些理论来自于前段时间流传蛮广的一个google员工研究社交网络的ppt：《THE REAL LIFE SOCIAL NETWORK》，需要的同学可以留言，我会用邮箱发给你（为尊重原作者，不放在网络上下载）。至于未来腾讯微博会怎么样，拭目以待～

类似的网志，挑你喜欢的看：

• QQ2010beta3内置的腾讯微博体验感受
• 腾讯微博初体验
• 社交广告？新的广告形式！
• 设计中的边际效应
• 易用且轻量级的交互设计

何为设计中的边际效应

边际效应大家在《微观经济学》中都学过。设计中的边际效应其实很明显。一个设计做到80分相对容易，几次推敲修改即可达到。从80分上升到85分，遇到的阻力会从各个角落冒出来，非得熬上几个晚上不可。从85分做到90分甚至95分，就相当难了，所耗费的精力成倍增加，所花的时间也自然陡然上升。这就是设计中的边际效应。前辈们常说，产生一个灵感固然令人欢欣鼓舞，但真正要做成一个产品，后面的磨难多得去了。在你打磨产品的时候，投入同等精力产生的效用是越来越少的。

一个产品要做到多少分合适？做到什么程度就可以先上线了？这些都是产品的owner考虑的问题。在产品开发过程中，体验类的细节问题肯定是多如牛毛而且不是同时出现的，如果埋头一个个地去解决，显然是不合时宜的；把所有问题收集起来，然后再做分类、评判，这样似乎缺少了敏捷开发的轻快节奏。在设计师作为owner的时候，需要自己心里有一杆标尺，有个标准，来度量每个问题带来的麻烦、解决每个问题所带来的效用，从而来决定哪些问题优先解决。并且在产品达到一定质量（比如说82分）的时候，让产品上线，并立即准备下一阶段的继续完善产品。

这和产品的核心需求息息相关

大多数情况下，解决产品核心需求问题所带来的效用肯定是比较大的。核心需求必须是用户最关注的、最根本的需求，因此一旦把核心需求做好，用户其实已经喂成7、8成饱了。但这也并不意味着有一把度量各个细节的边际效用的标尺没多大用了。实际情况中，核心需求一难挖掘，二难满足，很多产品均是上线许久才慢慢找准用户的核心需求，现在好评如潮的dropbox当初就是如此。走了弯路不要紧，有那么一把尺子，会让你不会弯得太远、弯得太用力。

这把尺子的度量标准，宏观来看，是可用性因素>易用性因素>其他。这个常理对于不断进步中的设计师来说并不是银弹，关键还在于实践中保持清醒的头脑，提高自己宏观的把控能力。能深挖细节，也能从细节中走出，才是一名成熟的设计师。

类似的网志，挑你喜欢的看：

• 易用且轻量级的交互设计
• 新版支付宝捐赠平台
• 从设计师到产品策划
• 求是设计会Design Camp第一期：”开始”
• 聊聊奖章的策划

原设计方案中，历史记录这块是一个添加联系人控件

上图中的联系人控件功能很强大，交互设计得也不错，看图便知。用户可以在这个widget里面直接选择保存的联系人（有分组），亦可即时搜索；同时还记录最近交易的，方便有连续交易行为的用户。抛开具体环境不谈，联系人控件在这里是一个很有用的工具，它帮助用户选择转账的对象；用户不需要记忆复杂的银行账户信息，只用记得对方的用户名就可以，用户体验应该是不错的。

但是在具体应用环境中呢？

文章开头的那张图是一个刚上线的新产品截图。我们来分析一下，用户在使用一个刚上线的新产品的时候，是否有从联系人中选择的需求呢？实际情况很可能就是大部分用户在两三个星期内只使用过一次这个产品，因为它不是普通用户日常所必须的。少数用户会使用过至多4-5次，如果到了10次，那这个产品无疑收获了巨大的成功，显然在短期内这是不可能的。因而，在可以预见的时期内，用户的联系人控件中只有1-2个联系人，之多4-5个，这样的话联系人控件在这里还有必要么？

如果结论是没有必要的话，联系人控件放在这里其实在交互上并没有消极的影响（用户只不过从有限的几个联系人中选择了一个而已，一样可以不需记忆复杂信息来完成任务）。但它对页面性能（载入速度）却是有影响的，这样一个联系人控件其实是调用了好几个js文件，而对于一个刚出生的新产品来说，页面性能是很关键的一个指标，太多的例子表明，页面载入速度如果提高个一两秒，用户的感受会好许多，自然而然商业价值也会提升。

有没有替代方案？

替代方案就是文章开头的那张图中的历史记录下拉框。这个方案在记录不超过10条的时候会很好用，轻量级且明显，没有多余的（用户在还处于初级阶段时候用不到的功能，比如：联系人分组，搜索等）。如果不考虑安全因素的话，这个历史记录的方案可以非常方便地用cookie来实现；在实际情况中，为了避免银行卡信息泄漏所用到的解决方案也是相当轻量级的。在用户第一次使用时，可以隐去历史记录；而用户下次再来的时候，则把历史记录放出来。等到用户成为“高级用户”了，拥有许多联系人（至少10+），并且将联系人分组了，这时我们可以对产品进行升级，将强大无比的联系人控件放出来供用户使用，这样的用户体验会是很好的。而这也是产品迭代的敏捷开发思想的体现。

本文的小例子绝对不是best practice。交互设计绝不是很多人看来画画白板，选选控件这样机械的活。书本上的知识运用到实践中，需要相当的经验积累以及敏锐的洞察力，这些才是交互设计师的财富。大家如果有好的交互设计经验，也请分享给大家哦。类似的网志，挑你喜欢的看：

• 从需求到功能再到实现
• 网页设计师也该关注页面性能
• 设记系列：Draware手机界面设计
• Draware概念手机界面的flash演示
• 设计中的边际效应

一，背景

在Trilogy实习的时候，在Zozoc这个项目中做设计。事实上当时这个项目的business goal已经很迫在眉睫了。当时Zozoc还没有收费，通过viral提高的UV每周在60%左右，下载产品的用户只占UV的20%，但用户流失率却在50%以上，可以说用户黏度是非常之低。

而项目可以利用的资源也是不容乐观，当时我们有web/wap/sms几个可以利用的资源，其中web方面由于人力原因，项目老大就排除了这个资源。也就是说，我们需要赶在Zozoc收费之前，近1个月的时间，将UV的增长率提高到50%以上，conversion rate要到60%，而用户流失率降低为10%以下，而能利用的资源是wap和sms。

二，前期的挫折

可以说自从我开始接触项目实践以来，这次是压力最大的。每天都在与PM和老大沟通。Goal是非常的清晰了，基本的用户需求其实早已明确，就是用“免费”的短信，或者是说比传统短信通道资费更便宜的短信。但何以用户来到我们的web或者wap之后下载的却不多？而下载产品后流失的却这么多？

如果我们的产品足够好，用户也有这样的需求，按照道理是不会出现这样的问题。毛病在哪？一开始我们认为用户可能不了解我们的产品，对Zozoc的优势并没有清晰的认识，因而都成了inactive user。所以通过brain storming，我们制定了一份通过sms来推广的plan。这份plan具体内容是通过短信通道向下载过Zozoc的用户发送软广告，内容多种多样，极尽勾引之能事。

同时，我也负责改进我们的wap站点，显然，原有的版本并没有基于用户更多的考虑，而是站在我们产品本身的角度来设计的。但这时由于时间紧迫，并没有很多时间来改进设计，只能在原有的基础上增加一些可用性，而这些可用性实际上仍然是架空在用户会花上5秒停留的前提上。

结果很显然，第一次改进并没有取得多少实质上的进展。UV只提高了3%，conversion data维持不变，用户流失率略有下降。

三，反思

事后分析，我们应该是从一开始需求定位上就有错误。的确，我们的目标用户是喜欢免费短信的。相当数量的人在使用各种各样的免费短信软件（当然，随着当时SNS的热潮，很多软件公司也挺进，我当时也头脑很热，认为这是提高我们用户黏性的一个好办法，还向PM提出过，现在看来，这很荒谬）。对于免费短信相关的网关质量、通道质量和客服服务等，用户都有相当的需求。但这些仍然是大的需求，用户为什么会不用我们的软件？这恐怕曾经困扰过很多互联网业从业者。一个产品做出来，设计开发的人自信满满，这么优秀的软件肯定能得到用户们的喜欢！然而结果却很让人失望和伤心，甚至是委屈。究其原因，是我们并没有真正明白用户的需求。

用户的需求80%以上都不是问出来的。我试过问很多身边的朋友和同学，用哪些免费短信软件，即便飞信发其他运营商的手机要收钱，你们为什么仍然要用？答案让我大吃一惊，除去网关、通道质量这些正常的原因之外，很多人都不出个所以然来，为什么自己会执着于飞信。而我向他们介绍Zozoc时，他们更是吃惊的说，原来不同运营商之间发短信也是可以免费的！

问题到这里，实际上有些明白了，原来我们并没有找到细化之后的用户需求来进行改进。还有很多细化的需求：用户可能并不知道自己的手机应该安装哪个Zozoc版本；如果下错了安装包，安装过程中出现了问题，用户可能就会认为这是个骗子软件等等等等。站在产品架构的角度上，对用户的经过细分的需求进行分析，才是可行的出发点。

四，执行

新的plan比起原来的要进步很多，在sms软广告上面，针对很多不同用户的需求，设计了很多短信内容。也提出了用户等级系统，积分奖励等等。用户其实很好玩，虚拟头衔一直是吸引用户的一个大因素，而积分，就算在当前没有多大用处，但是在广告中提到众多用户爱好的东西（从BBS上的帖子搜刮而来），用户也是相当喜欢。而对于那些从来没有用过Zozoc的用户，我们也设置了很多应用情景，通过短信发给他们，让他们尝试着使用。

在wap改进设计方面，更是细化了很多用户的需求。用户不知道自己手机该装哪个version的Zozoc，在经过数据分析后是个大头（从选择版本安装的页面跳出的用户占70%以上）。于是我们决定开发一个automatic-installation的功能，这也是非常符合Zozoc特色的功能，真正care users。同时这个功能的exception handlement也是设计得相当完善，考虑到了不同的场景。这个功能开发出来后，用户只需要访问wap站点，就能自动提示安装正确版本的Zozoc到自己的手机上，中间如果出了一系列问题，则会有向导帮助用户完成版本的手动选择。

同时也在wap站点上加入了很多为用户需求设计的功能，broadcast sms/blessing sms/joke sms/special contact，这些功能都是在这段时间集体爆发出来的点子，给了用户更多的发免费短信的理由。

在设计的过程中，也在不断的和工程师沟通，确保这些功能都能开发出来。实现应用环境的限制实际上也削去了很多不必要的设计累赘，我感觉这种经验是弥足珍贵的。我们往往可以设计出功能不错的产品，但最简洁最符合用户使用习惯的产品却不多。

五，总结

以前总说以用户为中心的设计，而我感觉UCD更应该是从用户需求开始的设计，用户这个中心点不应该靠后，而应该在产品设计最前端的位置，从一开始就指导整个产品设计的流程。

比较让人遗憾的是我由于毕业设计的原因，在项目目标未完成的情况下不得不离开了Trilogy。幸而在后来听PM说，这个plan成功完成了预期的目标，这简直让我下巴掉地上去了。之前我经常挂在口上的是这项目肯定完成不了，Zozoc可能要完了。我非常高兴，同时也带点儿自豪，为这个项目付出了相当多的精力，有此回报，我也很满足。现在Zozoc再次改版，因为开始收费了，我也帮忙做一下visual design。希望Zozoc能就此成熟起来，毕竟一个有“收入”的软件才是真正给用户高质量服务的，才是真正运转的。

P.S. 有兴趣的可以手机登录wap.zozoc.com来看看wap页面，或者用http://a1.timewe.net这个地址来在电脑上浏览类似的网志，挑你喜欢的看：

• 易用且轻量级的交互设计
• QQ2010beta3内置的腾讯微博体验感受
• Draware概念手机界面的flash演示
• 设计系列：Draware是怎么炼成的（1）
• 网页设计师也该关注页面性能