豆瓣在“友邻”里增加了“我的朋友”功能，体验后感受到如下问题：
1、在“广播”和“豆邮”之后，豆瓣首页的右侧又多了一个“类信件”的模块 ── “需要你处理的请求”。使我的“信件来源”过于分散。
2、“别人‘关注’了我”，会用豆邮通知我，豆邮是在主导航上的。可别人“加我为好友”这个“更重要点的事”却只是在首页安排一句话的通知。
3、原本一个“友邻”的概念拆分成了“好友”和“关注”，我重新理解的成本至少是3：“友邻被拆分了”，“什么是关注”，“什么是朋友，如何成为朋友”。
4、“朋友”和“关注”逻辑上看来是一个不错的规划，但这个“不错”是对新用户来说，对老用户并不一定合适。
这个问题类似于：有些人盖楼的时候先盖一两层，以后更有钱了再在上面加盖几层，加盖的过程可能会影响到原来的楼房，评估“加盖”方案是否合理的标准是：“对原有两层楼的影响有多大，影响的时间有多长”。
5、很多人和我已经是“互为友邻”的人了，现在这么一改我们还得再经过一次双方确认才能成为“朋友”，后果就是几乎所有的老用户都得重新倒腾一遍自己的友邻。就像正在饭馆吃饭的时候，老板说“我们觉得这个单间不好，你们现在到另外一个房间去吃”，于是所有人都屁颠屁颠端着碗筷和盘子换个房间吃饭…
6、是不是让别人看到我的某些信息”，确实应该由发出去信息的人说了算（不只是“广播隐私设置”，也可以是“能否看我的好友列表”等）。但，“是不是要收
到某些信息”，应该由收信息的人说了算。靠让发信息的人把友邻分级然后设置要什么人看到什么信息，只解决了“隐私”问题，并没有解决“干扰”的问题。
其实最大的问题根源应该来自于豆瓣在强调的“双向好友”。
1、我个人认为豆瓣的好友添加过程和绝大多数好友添加过程一样：根本不需要“双向确认”。
虽然豆瓣很需要“双向好友关系”来拉动社区的体系，但现在已经有了一种“关注”的弱关系，某种程度上使得“双向”变成了一种相互麻烦确认的一种形式。
有些用户并没有区分“朋友”和“订阅”的需求，而且大部分人在决定“什么人该放在什么类别里”的时候界限很难划清（信息分类向来是设计中最难的问题，更何
况是按照“别人”的规划来分类，而且还只有两个类。 ），非得生硬的把“朋友”和“关注”区分开，不过只是设计者的一厢情愿。
2、之前写过关于好友的看法，引发了麦田和魏武挥的讨论，我又重点说过“双向”还是“单向”的观点。“双向”本来就是一个不符合正常思维逻辑的事情。
3、我一直认为：“双向”只是一个“统计结果”，而不是一个过程，更不一定是“双方”都认为的结论（我认为柴静是我的朋友。她就是。就算她认为不是，我照样认为是）。
4、（不要说facebook的好友就是“双向”。facebook不一定就是对。而且facebook对于隐私的要求特别高，豆瓣并没有那么高。）
也许豆瓣认为“友邻中会有不少人‘不一定是认识的’，可能只是为了关注他/她的评论或是推荐，但也需要加他为‘友邻’”，所以在这次改进中特意比较强调“朋友”和“关注”的不同关系。 我觉得这实在没有必要。
1、只需要给用户提供一种功能让他们可以方便的将“认识的好友”和“只需要关注”的人分开即可，没有必要非得问用户“他是你的朋友还是只需要关注的？”（现在的设计确实有些“非得问用户”的感觉。）
2、对于产品的设计者来说“朋友”和“关注”的概念区分清楚，对于概念区分后的好处也很明白。 但对于用户来说并不一定“有”这个概念和意识，一般只有尝试过“痛苦”（很多好友导致杂乱）的人才有。而尝试过痛苦的人根本不需要我们如此强调，他一样会去用。
比如，以前我参与的某个社区的好友有默认的几个分组（朋友、同事、家人、默认），后来数据显示用户一开始并不按照我们想像的去给自己的好友分组，甚至直接把我们给他的组删除了。
同样，flickr默认把好友分好了组，但实际上用他那个组的人并不多一样（这个没有数据证明，只是观察判断所得）。
3、很多时候加一个人是因为我“喜欢他”。比如，我在豆瓣上发现“柴静”，于是我会去点那个我最希望的──“加为朋友”，而柴静并不认识我，收到“我加她为朋友的请求”便去看了我的资料，对我有点兴趣想“关注”我，可按照豆瓣现在的设计逻辑她会去点“忽略(加为朋友的请求)”。。
矛盾来了：对我来说，“就算柴静不加我为“朋友”，那我“关注”也行，可以一般情况下我点了“加为朋友”就会很欣喜而忽略去点“关注”，(因为这个时候是很有信心会被她‘加为朋友’的)”；对于柴静来说，她忽略了我但想关注我，她必须再专门去我的页面点“关注”。
可见，把“加为朋友”和“关注此人”放在一起的后果可能是：一部分的“关注”会变得麻烦或者不去使用，一定程度上降低了“整体数量”。（起码“加为朋友的请求”处理那里，可以加一个“只关注此人”的按钮）
4、 “关注的人”和“朋友”是两套东西，但老用户是把原来的友邻改成朋友，如果他们后悔了需要再改成只是关注，目前没有好的解决办法，只能删除朋友，然后再去关注一下。
如果我设计这个功能改进的话：
1、保持原有“我的友邻”不变，在里面增加一个“我的朋友”。 而且这个增加只是在“我的友邻”列表的上面加一个“分组”，不会做到主导航上去，等于“增加了一个友邻的高级分组”。
要给用户的感觉是1+1：你原来有一间房子，我现在在旁边又给你盖了一间，你可以选择把部分人放进去然后制定不同的“政策”。
现在豆瓣的做法感觉是1/2：你有一间房子，我把他拆分成了两小间，默认把你原来房子里面的人都放进去了其中比价“低级”的那一间了。（用户会觉得“你侵犯了我”，把我的房子给拆分了）
2、好友的添加过程不考虑“双向”，但在好友列表里用一种不是十分明显的办法告诉用户“你这个好友是不是也加你为好友了”。系统在“推荐机制”算法时提高“互为友邻”的权重。
3、针对于“我的朋友”和“我的友邻”，用户可以自由设置“是否显示他们的各种广播”和“是否让他们看到我的各种信息”。简单说就是：“我想不想听你说话”和“我让不让你听到我说的话”，这样即解决了隐私问题，又解决了信息干扰的问题。 现在豆瓣只解决了隐私问题。
4、用户添加好友的时候依然只有一个按钮“加为友邻”，然后弹出选择“分组”。添加后的通知依然保持不变。
豆瓣在几千人的时候其实是在自己给自己设计产品，需要什么就加什么，(设计)架构上似乎并没有什么大的规划。但现在是在给百万人设计产品，设计人员甚至已经不能称为典型用户了，必须克服两个最大的困难：
1、依然“为自己设计”，强行把自己的逻辑和习惯套给所有用户，不考虑是否合适也不经过“简化和编译”；
2、不是在现有架构的基础上进行优化然后做扩展和调整，而是重新开始规划产品架构（往往重新做一个比改一个容易，但重新做了以后可能也要面临着去改…），过多的打翻老用户的已有习惯。
每一层新楼都得建在现有的“楼顶”上。基数越大，“改版”的风险成本就越大，时间越长系统越繁杂，往往也越“难用”。
豆瓣最近的升级和改动很多，每一次改动都会带来很多老用户的不适应，也会带来新的设计问题。 但愿豆瓣能够更好的平衡系统设计、新用户发展、老用户习惯等各方面问题。
同时建议豆瓣正式把“实验版”弄出来，让每一个新功能经过专门的实验版让更多用户开放性的参与一下，有助于在正式上线的时候减少问题，有助于优化设计，更有助于减少部分老“活跃用户”的意见。
