胖胡斐：发现 美好

由 胖胡斐 撰写 　http://www.panghufei.com/?p=10191

      我们谈互联网产品之间“打通”这个话题。照例，为了说明道理，我们会拿别人网站的案例来解释。

      先看案例：新浪网的新闻、UC聊天、微博之间。
      在访问新浪新闻时候，右下角会有一个浮动窗的标题栏。说要不要跟一起看这个页面的人聊聊。

      点开之后发现是新浪UC聊天室。我于是可以说话了。还被提示可以跟某人私聊。（其实这里解决了很大的“用户互动”的问题，这次不表。）

  
      我的问题出现了，我在这写，跟新闻评论有什么关系吗？写了一句，发现没有关系。聊天内容不会写入评论。
      可其实我是想发一句评论的，于是重新在评论内容里写。发现，这里面写的时候“还可以发到微博”，而且默认是勾选的。

      发完之后在微博里会马上写入一条。

      看到吗？这里面是三个产品之间所谓“打通”的情况。管UC聊天室的人会说“太爽了，我们截获了大量新闻评论的用户。”并且他一定会因为此次“打通”获得赞赏。管微博的人会说“新闻评论成了我们重要的内容来源。”这次打通因为默认的强制输入而获益颇多。而管新闻评论的呢，只能对UC聊天室“门口截流”的行为恨得咬牙切齿，也暗骂“微博的东西还不都是老子提供的。”
      其实这是一个不太好的状态，我们看看他们的关系：
  
      我们会发现，新闻评论是个“被攀附”的角色，可能就因为他最老最强大吧，于是扮演的多有“长兄为父”的意味。

      我不晓得新浪网后面的故事，就事论事的说，这并不是真正意味的“打通”。那么在我看来，“打通”是怎么一回事呢？

• “打通”是运营层面的问题，也是一个“方向”。

我坚持认为“打通”是需要运营来考虑的。运营需要考虑，我这个产品需要怎么推广；用户从哪里来；我的用户和什么产品的用户重合度比较高；在别人的产品使用中，我怎么渗透进去；我怎么让用户用完别人的产品到我这来看看……

做产品的同学会把运营提出的“打通”需求简单化，认为“提供几个API”或者“调用人家几个API”就完事了。殊不知，
如果把自己产品独立来看，别人页面上的小块，是一个很重要的用户接触点，无论是什么地，都要细细耕耘呀。
如果把整个网站做一个整体看，各个产品之间的关系，会让用户有很多不同的感受。

• “打通”≠ 布点，应该是双向的。

很多时候我们的同学把“打通”理解成“布点”，可是“布点”是单向的，是在别人那“开辟殖民地”，这种掠夺式的东西，不可能被人喜欢。于是，大多数人就会举着大老板的令箭来谈，那就真的是掠夺了。

遗憾的是，大多数人去跟被打通方谈的时候，都是打着“打通”的旗号，行“布点”之事。

这东西更应该想BD，先考虑清楚，我的产品对别人能有什么帮助，别人认可之后再提出你要别人怎么帮你。

当然，形成单向的原因，很重要是实力不匹配，比如新浪新闻评论从UC那可能还真获得不了什么。我想说的是，如果是单向的，麻烦考虑一下别人产品的用户体验，别让人觉得你在人家门口截断了客流。

• 产品设计时就要考虑“被打通”的事儿。 

貌似没人来谈打通的产品不是好产品。呵呵。

于是，产品设计的时候，我觉得应该考虑一下有一天“被打通”的情况。这可能包括：
是否提前准备好被调用的开放APIs，总要有地方能联通得起来，否则“殖民地”就成了人家的“自留地”了。
是否考虑好“被打通”的节点，哪些地方是可以放入东西的，那些不可以。因为，别人打通你的时候，不会替你考虑你的用户体验。想想新闻评论被UC打通的事儿吧，浮层严重干扰新闻评论的逻辑性，可是UC暗爽啊。
好的做法是，当人来跟你谈“打通”的时候，你的方案已经给人准备好了。

• 别让用户同时接受你众多产品的逻辑。 

这还是产品需要考虑的问题。Sh4rk说设计是“用视觉语言去解决逻辑问题”，就是这个道理。

如果用户到新闻页面，看到了UC聊天室，看到了微博，甚至再看到一些其他的新浪产品，他会不会觉得“很晕”“很乱”“不知所措”呢？
如果有，这个页面所有者的责任就大了。

我想说的是，“被打通”应该是好事，但是如果被“喧宾夺主”而影响了你的产品逻辑，或者影响了整个网站产品之间的逻辑，那就是坏事了。
在这个角度上说，新浪这么做危险系数比较高。

      好了，基本上说完了。那么有没有这方面做得好的呢？看看QQ吧，产品之间的关系和打通，很多地方值得我们学习。

      总结一下，我们说的是：运营要考虑打通，但绝不是布点，是双向的工作。产品设计要做好被打通的准备，要考虑用户逻辑。