用户体验设计实例:豆瓣UI设计改进
Web 2.0的重要特征之一，就是更加类似于生物界的自组织现象。用户如同单细胞生物一样，在充斥营养质（内容）的液体中飘荡，直到偶然落在某处营养足够支撑其产生连续、规律的生长（用户习惯）的结构体（网站）上。同时，当汇聚的简单细胞足够多的时候，也会产生质变，影响这部分结构组织营养的比例和方式。所以Web 2.0的技术重点，比如Ruby On Rails，Ajax往往都放在能够快速完全重构，框架部分更新等领域，其实就是推翻不成功的进化模型，重新开始进化试验，保留已知有效的功能模块；最终找到可以生存的范型。
其实豆瓣一直在进行小的调整，相信那些情感化设计啊，交互设计之路啊，用户体验的要素应该都是案头必备书。实际上豆瓣恐怕是一个在UI乃至整个branding过程中最被用户宽容的网站了，因为它的目标受众正是那些受过基本教育，思想开放，充满好奇心的年轻人群。这些人在新事物面前更长于思考为什么是和为什么不是，而不是简单的点击和搜索。坏处就是，豆瓣至今还在使用一个配色和构图很简陋的logo。其实豆瓣完全可以考虑针对性的利用用户的正向反馈，不断地进行小范围的改版测试和对比分析试验，加快进化的速度和进程。下面我说说我对UI改进的一点看法。
1. 交互信息流和非交互信息流的分开呈现。
由于豆瓣是在不断改良中进化到今天的模样的，所以难免会有一些思路模糊的时候。如果没记错，豆瓣是由 评论-友邻-留言-小组-同城-广场 这样的曲线方式发展而来。这个模式很明显是on demand，好处是不会画蛇添足，坏处是没有明显的框架设计概念。由我作为用户的体验而言，我的感觉是，我无法在一个页面里访问所有和我个人相关的交互信息。我可以在我的豆瓣看到我的日记/图片/评论/广播的回复并继续交互，也能看到我回复的一些其他用户的后续进展，但是我至今仍然需要点击小组-我的发言-我的回复共三次才能看到我回复的小组话题的进展。另外，我的同城活动并不会主动出来提醒，豆邮在提醒活动方面并不是好方法，不然微软就不用在outlook里增加日程表了。简单的说，我希望这些都能在一个页面里呈现出来，并且提供有效的组织方法来进一步访问。
其次，关于静态内容部分，比如书影音部分，数据的组织形式过于简单，豆瓣从一开始就提供的tag功能没有起到明显作用，既没有聚合也没有tag云，而是回到了基本分类的形式，豆列的跨媒体和跨类别功能没有能够突出出来（其实我觉得完全可以把别人的评论和日记也加入豆列），这无疑使得豆瓣更像一个多媒体图书馆而非可以持续探索的未知营养液了。
2.交互粒度。
最简单明显的就是，很多人现在都是在使用推荐和回复功能来代替Mark功能，这一点在他们推荐语里面已经很明显了，就是简单的"mark"或者"码"。这是当没有锤子用钳子猛砸钉子的方案，但是元豆们似乎没有意识到也没有反馈回去，至今也没有收藏功能可用。这就是我建议扩展豆列功能的原因之一。
另外，许多社交网站都提供了互相咬，互相握手乃至互相偷菜的功能，这是为什么呢？就是因为，人类社会的组织形式中，人和人之间是需要冗余信息的交换的，类似于猴子的互相梳毛，起到安定的作用；而不同手势之间自然有微妙的含义差别。从这个角度讲，我们也需要进化出一套网络上的丰富的交往方式，虽然豆瓣没有也不应该照搬偷菜这种无聊的把戏，但是似乎也应该考虑设计出一套独有的肢体语言来，如果能有类似于"wish force with you"的牛逼句子就更好玩了。
还有一样可以参考的东西。QQ最近增加了评论好友的功能，这一点不知为什么豆瓣一直没有。很多时候，我们并非对特定人（某好友）有意见，或者特定事物（红楼梦）有意见，但是对他看红楼梦这件事可能产生了某种反射，也就是说，我希望就此发表简单评论（顺便说一句，豆瓣无法标出看书时的年龄，次数等更细粒度的数据，让我这样小学5年级就看过的人无法找到知音），这将更加类似于我们日常生活中的行为模式。类似的情形还有，我很希望注明某部电影睡着两次，某部电影找不到尿点等更细致，更人性化的信息。
第三点，也是很有意思的一点，就是overheard。豆瓣至今不能知道，我的朋友之间，又没有提到过我，（需要后台的tag索引支持）那么我在提到一个朋友的时候，是否希望他知道等等。这个功能，连同其他功能一起，可以进一步使问题复杂化，使用户交互进入更丰富的层次和领域。
3.交互方式。
豆瓣小组是豆瓣最大的发明创造之一，极大地丰富了豆友之间的交流和沟通，但是也有一些使用不便的迹象。比如刚才提到的收藏功能和没提到的索引功能。其次，没有只看楼主这样的功能，因为相当一部分帖子是叙事性而非讨论性的。对于讨论性的帖子，豆瓣没有采用缩进和分别回复这样的功能进行梳理，而是简单的直列回复，让人遗憾。而且，由于有小组这样的类型限制，广场功能又被弱化，我无法看到我可能感兴趣但未加入的小组的话题，这一点也很可惜了。