从Buzz推出之后，纷纷扰扰的看法就从未停歇过，对于Google强推的一款社交产品，Buzz确实值得获得分析与讨论。
胡诌需求
如果我用的观点来定性Buzz与twitter的区别，我会这么说：Buzz是沟通工具，而twitter则是一款传播工具。
很多用户抱怨Buzz内的自动置顶给他带来信息干扰，以及默认同步好友并公开关注列表让用户觉得个人隐私被出卖了。诚然Google的做法也是令人反感的。但工具本身并无好坏之分，关键在于是否用在正确的场景中。而Buzz的目的并不在于帮助你发现更多新奇有趣的信息，不在于帮你扩展你的社交圈（手机上的Nearby功能除外），如果以twitter使用习惯强加于他，你会觉得处处受困。Buzz的目的只是用于你现有社交圈的沟通方式的拓展而已。
那么有没有一种沟通情景，很符合目前Buzz的需求设计呢？Google团队在解释为啥 Google Buzz 没经过太多内测就提前放出就有涉及到：
Jackson说当Google员工内部测试这个产品的时候，他们从未想到过要mute掉任何同事的对话，他们的邮件联系人列表里的同事就是他们在Buzz里follow的人。很显然，对于那些不在Google工作的人来说他们并不需要这样的配置，所以Google后来紧急发布了一系列针对隐私保护的新功能。——摘自谷奥
从以上的描述中，我们可以大致了解到，Buzz的沟通情景，适用于那些对内公开，对外封闭的实名小圈子。如某个企业内所有成员，如某种爱好者组织团队……
实际上，Buzz所具有的即时性，储存性，以及半公开性，尤其适合于这种小圈子的讨论，或者用kentzhu的话说：信息的局域化传播。
想象一下公司内决定举行一次旅行。正常的沟通方式是：
秘书群发一封邮件给大家通报情况。
IM群上开始狂轰滥炸的讨论，如好不好玩？风景好不？美女多吗？
各种各样的问题蜂拥而来，秘书在IM上被烦死。
临时有变动，惨了，秘书再发邮件。
临行前，秘书要给所有人发个短信确定一次。
几个丢三落四的家伙没有看到之前的信息，临行前只能给秘书打电话。
我想，等事情都安排好了，秘书都泪流满面了。这样不仅繁琐，且容易丢失信息。暴露了传统沟通方式的缺失：
邮件缺乏即时性（接收者无法即时接收到信息，所以秘书要发短信告知变更情况。）
IM缺乏储存性（没有记住之前和秘书在IM上面说的内容，只能给秘书打电话。）
如果换个方式：
秘书在Buzz上发布旅游公告。
大家直接在Buzz上版聊，而且不必一直盯着它，过几分之后来看也不必担心漏过信息。
秘书可在Buzz上直接公开的回答，避免了重复提问。
临行有变动时，秘书直接修改Buzz内容即可，与此同时Gmail的Inbox内，提醒邮件也会自动更新。确保你永远收到的是最新的消息，而且信息保存在邮箱内，方便回头检索。
丢三落四的家伙没有看到之前的信息，可直接在Buzz上和秘书聊天获取及时信息。
从这中角度上说，我个人非常的看好Google App内Buzz的推出，对于Buzz这种新型的沟通方式而言，Google App是我认为他大展拳脚的方式。顺便提一下，即使微软，也不是推出了Office talk吗？
胡诌信息单位
在Buzz中，所有的信息都一个完整的，按照时间线的方式呈现。从个人理解上讲，Buzz扩大了产品的最小信息单位：他不像微博，任意的一句话，一个回复，一个RT，都当作一条新的信息单位来处理；而是把这一整块的信息，都打包成为一条Buzz。保持了Gmail中对话模式以及论坛帖子相同等级的信息单位结构。
而这种处理方式，不仅有效地降低了用户普遍在twitter中遇到的信息过载问题，同时，它让信息的呈现变得更加地具有层次之分（主题与评论），并且易于追踪和回顾。
从这种角度上说，Buzz其实是一种更加便捷的论坛功能，对于论坛中流行的直播，版聊等微信息交流行为，如果移植到Buzz上，将会有更好的体验和呈现效果。
胡诌设计
Buzz的信息单位过大，虽然降低了信息过载。带来的问题是，单位信息量巨大从而让用户难以即时消化。那么从呈现上说，他不能学twitter那样，将信息呈现简单化到只有文字与链接，利于扫描和浅层阅读。Buzz必须让信息的呈现多样化，丰富，利于阅读和思考。
那么，在设计上，Buzz传承了Gmail邮件的会话模式风格，把操作功能收起来，给每条Buzz足够大的展示空间，让用户沉浸与阅读Buzz中；同时，为了避免用户深层阅读容易导致的导航迷失感，Buzz尽量的让所有的信息都在单个页面内呈现。而不是像twiiter那样，更多的导航，更高的跳出率，满足操作感。
就如同之前我所说的高度认知与低度认知差异一样。Buzz的低度设计非常的明显，这点我们从Buzz的主题折叠以及twitter导入功能可以看出。Buzz并不实时同步twitter，目的就是不让twitter的信息干扰用户的深层阅读。
