前几天我写了《人面不知何处去――blogcn 的失误》，有两个网友的留言很有意思。一个网友说，“楼主好像只点明了blogcn的失误，而没有提出一些建设性的意见”，是的，但我现在的工作和blogcn存在潜在竞争关系，虽然写博客是私人行为，但也没必要为竞争对手提供“建设性意见”吧？所以今后可能还有类似的文章，我依旧只能“解构”，而不能去提供“建设性意见”。另外一个网友和我讨论文中提到的blogcn的博客客户端产品rabo，他认为：“一，網頁上直接寫blog，容易遺失。 二，rabo可以備份blogcn的日誌”，有了这两点，所以rabo“是個好東西”。所以这篇blog就从这个网友的留言开始，从rabo的设计，谈谈我对产品设计的一点想法。

我几乎可以打赌，当初blogcn的决策者决定上马rabo的时候，主要的考虑也就是上面那位网友的两点。（也许还有第3点考虑，就是通过rabo客户端，能渗透到用户桌面，达到对用户的真实控制）。我们以前两点来分析。

“网页上直接写blog，容易遗失”，所以用户需要rabo――这是想当然了。当一个用户在网页上写blog而发表失败时，用户即时地有两个反映：第一，臭骂BSP一顿；第二，继续再用web方式发表――大家可以想想自己是不是这样的。而直到n次遇到发表失败的情况后，用户才会尝试如果web端发表长文章之前，先ctrl＋c复制一下；然后又n次失误之后，用户才会选择先在客户端书写好，然后再提交――直到这个时候，rabo可能才有点用；但遗憾的是，word和写字板的存在，又剥夺了rabo此时的位置：我为什么不能word写好后，复制到web端发表，而非得用rabo这个新玩意儿？！所以这么细细分析下来，“网页上直接写blog，容易遗失”根本不可能促使用户实用rabo，而只能使用户使用word或写字板。

“可以备份blogcn的日志”，所以用户需要rabo――这依旧是想当然了。在说明这点之前，我先说个数据：据我统计，坚持每周至少更新一篇博客文章的blogger只有总blogger的5％。这5%才是真正可能需要“备份”自己的日志的用户。对于其余95％的blogger，想想我们是怎么对待自己的硬盘突然损坏的吧――我们想过要预先每隔一段日子就备份自己的数据吗？没有，我们多数都是等硬盘坏了，才欲哭无泪。同样，用户对BSP服务器的信任会多过对自己硬盘的信任，他们不会想到要按时备份的，一则没有这个用户习惯，二则这95％的人也没发表太多数据值得备份。

Rabo表面上成立的两个理由，细细分析下来，就荡然无存。这样产品设计失误，根源在于设计者有一种本能：多功能症。

我们每个人的内心都是在贪婪和恐惧之间寻求平衡。这点在产品设计上也同样体现，特别是“贪婪”――总认为自己能满足用户的n多需求，而超越了自己的能力。其实以BSP来说，blog是一个低技术含量的玩意，第一是快速，第二是稳定，做好这两点，基本就是一个好的BSP，其余的都是锦上添花的玩意儿。而2005年，blogcn的主要问题恰恰是速度和稳定性，但他们没有解决这个关键问题，去做一些rabo之类的产品，即是因为设计者的“贪婪”――试图即做bsp，又一网打尽客户端。

而web设计中，有太多这样试图给用户“全面解决”的例子，我把它叫“多功能症”。比如大家访问一下新浪天气频道，你看看那么多功能，其实我打赌，估计90%以上的用户在这个频道页面只需要一个功能：我所在城市的、文本的天气预报。那“新浪天气”频道为什么要设计那么多功能呢？估计是因人设事――有了天气频道的编辑，总得做点事吧，就推出了若干新功能，显得自己也挺忙的，页面也挺花哨好看的――并且认为用户也需要这些功能。

但实际上用户并不需要。(观点:满足80%的功能才最需要放在用户立刻能找到的地方)

“多功能症”在软件产品设计中其实早就存在，比如越来越复杂的word功能菜单。这可以说是一个顽疾了。但，软件产品因为是客户端的应用，不牵涉到网速问题，所以其“多功能症”虽然讨厌，但不烦人；而web端的“多功能症”却对用户体验有极大的负面影响，危害非常大。

据说google的创始人曾经仔细数过google首页的文字数目，相比而言，我们新浪之类的门户却是十几屏的首页还意犹未尽。BTW.我本人见过最长的首页是伟大的博客家顺风先生的博客首页，好像超过70屏了――所以请大家打开的时候，务必镇定。