幻风阁|kent.zhu'sBlog

基本上，熟悉我的人都知道，我是个低俗的人。然后我最擅长的事情是用黄段子举例子讲道理，这点看过我的文章的人都知道。倒不是我拿低俗说事儿以为低俗有多牛逼，而是我的经验证明，妈的，黄段子比较能让人记忆深刻。前2天我正在微博上严肃的用一个段子很正经的在讲述文案的重要性，然后坏人把这个段子复制到了UCDChina的群里，之后这帮人就开始了黄段子与用户体验的讨论…..我总结一下，列到博客里，虽然白鸦在微博上已经发了一部分

关于文案的重要性

某日尿急，遂窜进一家酒店豪华卫生间。走进小便斗一看，上贴几个大字“不要用坏了！”，我心中轻笑，我等素质人士，受过高等教育，天安门前拍过照，五星饭店睡过觉，什么场面没见过？事毕，自动感应，自动喷水，水量超大，湿了一身，恍然大悟：日，打个逗号会死啊！

关于Web的美学必须以满足用户需求为根本

“牛吃草”的故事，说一个牛人拿出张白纸绘声绘色的跟听众讲解说这幅画画的是一只牛正在吃青草，草儿青青牛儿肥….然后听众问，草呢？答曰被牛吃了；又问，牛呢？答曰吃完草自己回家了……

关于用户往往是会夸大他的需求

小白兔蹦蹦跳跳到面包房，问：“老板，你们有没有一百个小面包啊？”
老板：“啊，真抱歉，没有那么多”
“这样啊。。。”小白兔垂头丧气地走了。
第二天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包啊？”
老板：“对不起，还是没有啊”
“这样啊。。。”小白兔又垂头丧气地走了。
第三天，小白兔蹦蹦跳跳到面包房,“老板，有没有一百个小面包　啊？”
老板高兴的说：“有了，有了，今天我们有一百个小面包了！！”
小白兔掏出钱：“太好了，我买两个！”

关于引导用户不能完全依靠利益驱动

小白兔跑在大森林里,结果又迷路了,这时,它碰上一只小花兔,这回小白兔可学乖了,跑过去说：”小花兔哥哥,小花兔哥哥,你要是告诉我怎样才能走出大森林,我就让你舒服舒服。”
小花兔一听,登时抡圆了给小白兔一个大嘴巴,说：”我靠,你丫是问路呐,还是找办呐？”

关于不同特征的用户群，需求不同

第一天，小白兔去河边钓鱼，什么也没钓到，回家了。 第二天，小白兔又去河边钓鱼，还是什么也没钓到，回家了。 第三天，小白兔刚到河边，一条大鱼从河里跳出来，冲着小白兔大叫： 你他妈的要是再敢用胡箩卜当鱼饵，我就扁死你！

关于用户的核心需求

小白兔和大狗熊两个蹲在树底下拉屎。
大狗熊对小白兔说：你掉毛不
小白兔说：不掉
大狗熊随手抄起小白兔给自己擦了擦屁股扬长而去……

最后，是一张图，你们懂的

只是说一个在手机端小的交互细节而已。

在Web端做表单设计设计师考虑更多的事情是表单的布局方式、表单的提示语言、表单的长度、甚至表单的判定状态。这些东西有无数的人写了无数的文章。但是在手机端，对于表单的设计似乎没见太多的讨论。即使有讨论，设计师们也把目光集中在了如何精简表单上，但是对用户输入的关注却很少。

在移动端产品设计上，一个应用是否足够友好不仅仅取决与其自身的功能对用户是否足够友好，而也应该考虑这个应用对其他应用是否友好，当用户在调用这个应用去完成其他应用的时候他们是否会发生冲突。

得益与android生态的足够“开放”，android上存在着很多输入法应用；受利与android系统的足够“包容”，android上的输入法可为千奇百怪，输入法应用程序的界面高度也百怪千奇，应用开发者们照例要为这些开放买单。于是，设计师们在做需要调出输入法进行相关表单操作的页面的时候又多了一项课题——如何不让提交按钮和输入表单被软键盘遮挡……

以登录/注册表单为例，从Google自身开始，这个问题就存在，不管是其自带的输入法软键盘还是第三方输入法软键盘。一般来讲，用户的操作流是：找到输入框——点击弹出软键盘——输入——点击下一个输入框——输入——寻找按钮提交——没找到，于是搜索屏幕——哦，在屏幕的最右下角——点击完成，把软键盘放下去——点击按钮提交。

这个流程中，很多小白用户直接迷失掉，很多老用户也很郁闷的每次长途奔袭一次去把软键盘关掉…..

那解决方式呢？

1、将提交按钮挪到右上角。这样虽然不是很符合用户的视线流，但是相比长途奔袭到页面右下角的话稍有改善

2、将提交按钮设置成固定“悬浮”与软键盘上方，这样当用户填写完表单之后能够最快速的找到提交按钮。但是也会有2个问题，视觉上如何跟软键盘的颜色做区隔，不给用户的输入造成干扰。Twitter在android上的解决方式较为可取，同时Gowalla让整个页面随着软键盘的打开而上滑的做法也不错。

另外，在android上常见的需要输入简单内容的表单可以采取弹窗的方式完成。弹窗的形式相当于在一个新的界面上只有输入框和软键盘了，相对而言可操作区域变大，用户的视觉有所聚焦。不过，这种弹窗方式不太适合常表单的做法，比如android自带的这个Wifi连接表单就杯具了…..

其实，在iphone的应用设计上也会存在这个问题，但是没有android严重。而iphone系统本身也试图教育用户利用软键盘右下角的“Join”按钮及其变种来完成表单提交的，不过，过多的小白用户还是一样迷茫….随着iphone机器的普及，这种用户会越来越多，也许是时间该考虑一下他们了

在最早的时候产品设计大多采用瀑布模型方式做迭代，上一个流程完毕之后才进入到下一个流程。这种模式有一个最大的好处就是下一个流程的准备相对充分，但是缺陷也显而易见，那就是迭代成本太大且显得笨重。随着互联网行业的发展，“快”成了这个行业最重要的一个口诀，于是类似“唯快不破”成为大受追捧的产品设计哲学。于此同时，很多项目的设计周期被缩短。

在这个快字的指导下我们省去了对详细MRD的撰写，采用了列出功能点的方式向研发团队讲述整个产品的逻辑与核心需求点；因为要快速，所以我们采用初略原型的方式直接像工程师展示我们需要的产品架构和页面逻辑；因为要快所以产品人员在描述的时候很激昂的描述了我们要做的高优先级系统，并且说这些系统是我们最至关重要的地方，我们高优先级先把这些重点搞通；研发人员在听完整个的需求描述与初略的原型之后迅速做出评估，给出研发排期，于是群情亢奋的就开始干了……

这一切看上去很美好，不是吗？我们比以前快多了，我们也有突出的重点了。但是事情真的是这样吗？

当大体的排期做完了，需求也通过了。下面研发人员开始做后端的架构和程序逻辑的架构了，产品人员开始对之前的需求做梳理，对原型做细化，设计师也开始尝试视觉风格了。这次我们采用了并行的方式，我们要比之前进步多了吧。

很多时候，事情就是这样奇妙，不梳理不知道一梳理吓一跳。原来当时我们在考虑展示部分的时候没有考虑到不同的用户流导向的页面不一样啊；原来一个简单的数据提交过程有如此多的分叉口并导向不同的后端数据处理策略。产品人员认为，这些都是应该重新归纳出来的，于是之前一个展示页面被细分为N个不同的展示样式；之前的一个提交流程被分拆成M个不一样的处理策略。挨个模块的这么梳理下去之后原来简单的一个原型被弄的好生完美，原来一个看似美好的页面结构被修剪的异常丰满。而之前产品人员认为“比较简单，重点突出”的系统被证明是一个很复杂的很重的系统。当然，这个过程是后端工程师和产品设计师共同梳理完成。

这个时候，问题出现了。按照之前的需求描述和原型讲解研发工程师预估的时间在每个系统上都多出来了一倍多。产品人员在不断的“完善”页面逻辑和产品架构，研发工程师在不断的增加研发成本。最终，当研发周期过去大半的时候我们发现，靠！刚做完第一个阶段…..于是，大家都急了，咋办？！砍功能吧，把低优先级的东西先干掉，先做“核心”的事情。一阵的手忙脚乱之后，还是比预期的晚了几周，上线了一个勉强过的去的版本。

那么，在这个案例中整个产品研发过程的问题出在哪？自我反思，我认为是产品人员造成“细节黑洞时间”过长，导致工程师对研发过于乐观，项目开发周期评估失常。不过，问题的症结还是在于快的过头了，因为快所以忘记了一些虽然笨重但仍旧行之有效的方式。

在需求的初期，产品人员并没有能够很好的将业务逻辑转换成产品逻辑。整个业务的核心链条是什么？用户被什么动力所驱动，这些动力在产品上由什么来体现？围绕这个核心链条哪些是我们必须要做的产品模块？

业务逻辑的转换凌乱必然导致产品大的架构凌乱。按照我个人的习惯，在任何一个产品甚至产品模块开始之前都需要先画一张产品架构图，这个架构图会存在在MRD的最前面和原型图的最前面。这样有2个好处，产品自己可以很好的梳理整个产品的结构及每个支点如果有风险会影响的范围；需求被传递的时候下一个流程能够先很清晰的有所认知。

当大的产品架构出来之后接下来要做的事情是按照每条支线模拟一遍流程，使用流程图的方式来做，每个模块都需要。一般的处理方式是直接用相关的页面原型来走流程图，每个页面的下一个页面是什么，有几个支线，分别导向了什么页面。这样走一遍之后就能最大程度的避免“细节时间黑洞”。

是的，就是这样，因为要快，所以我们在赶进度，我们忘记了产品逻辑，凌乱了产品架构，忽视了页面流。这部分时间在排期的时候被忽略了，而这就是个大大的细节时间黑洞，这个黑洞影响着我们每一个产品。如果在研发过程中，我们发现之前的逻辑是错误的，那么问题将更加严重……

当然，这个案例中提到的情况还是相对可控的，因为产品人员有相对独立的控制权。如果再有权力高层掺合进来，不断的增加功能，不断的释放需求，那么，整个产品研发过程将更加糟糕了。最近微博上流行一张图，那才是真正的纠结（点这里围观）

最后，提到“唯快不破”，忍不住多唠叨一句。不要被“互联网产品唯快不破”带到沟里了，这句话原本没错，但是要注意2个前提：第一枪一定要打响，不然以后你就算再勃起的高也没人看了；在快的同时需要考虑自己是否有能力应对“快问题”并及时完美解决掉，是否有足够精力应付快之后被拉长的战线，不然就是快刀子也容易剌到手！

特别说明：细节黑洞时间这个词来源于一条微博，作者画了一张很大很纠结的一个产品研发流程。看完颇多感受，结合自己的感受写出了以上文字。

以下，是我在知乎回复的一些问题的备份，记录于此，无他。不过，需要申明的是，这些都是我自己的理解和某些理想状态下的答案，肯定是有错误的地方的，想挑刺的就别看下去了，想探讨的欢迎留言。

问：产品经理的核心技能是什么？

答：我认为一个真正的产品经理应该是这样的：发现用户的需求并定义客户价值，同时准确传递这个需求与价值给团队成员，并推动团队去很好的满足这个需求最终将价值传递出去。所以，核心能力显而易见了

问：产品和运营的关系是什么？

答：我从一个产品设计师的角度来理解一下这个问题吧。
产品设计与产品运营之间的关系应该是，如果这个产品没有产品运营，依靠自身的产品设计用户一样可以玩的起来，在设计的时候就需要考虑去搭建一个生态循环；产品运营的作用是推动其更良好的发展，发现产品设计的问题及新机遇。
而产品运营的核心在于告诉用户他将要得到什么，而不是，他已经拥有什么。

问：在将Web产品移植到App的时候是如何砍需求的？

答：首先这个问题本身是有问题的，因为一个产品从web端到mobile端其实并不是简单的移植，同时也不一定全是砍需求，更多的时候会是变更或者添加。当然，既然问题是这样问的，那么，就问题本身而言，我的答案如下：
之前看过一本书叫做《简单法则》，虽不是讲移动产品设计的，但是确实给我很大启发，按照书中的原则，我大体提炼了一个方法：缩小——隐藏——附加——组织。
①把Web已有的功能模块全部列出来，排序；
②尽可能的砍，把可以减少的功能尽可能的减少；
③隐藏，把不可减少，但是并非十分必要的功能隐藏起来；
④考虑手机端用户需求与Web端用户需求的差异，然后附加一些手机端特有的需求与功能进去；
⑤有序的组织上述元素

最后，附赠一条发在新浪微博的微博，给走在产品路上的自己

你砍，或者不砍， 需求就在那里，不伦不类；

你排，或者不排， 优先级就在那里，不高不低；

你捋，或者不捋， 流程就在那里，不清不楚；

你分，或者不分， 周期就在那里，不紧不慢；

抓核心快迭代，或者大而全啥都想要；

用户，市场

需求，产品

P.s：我没有知乎的邀请码，请勿在回复中索要。当然，你要是愿意留言索要我也没办法，不过我不得不先告诉你，我已经将“邀请码”设置为Spam词了….

半年前，我跟一个朋友聊天，我说，在不久的将来一定会出现一款产品，这款产品能够完整的在网络上还原现实生活中的你。然后这款产品可以像你的情人一样懂你，知道你最喜欢吃的口味知道你最想听的曲子知道你最爱的女优知道你最喜欢的体位….

Google利用Rank将所有的网页进行分析，然后当你想要的时候他会告诉你什么是你最想要的，然后Google成了网络的霸主；后来一个叫Facebook的家伙出现了，他正利用Like将所有你喜欢的网页做整理，在不久的未来他一定会比Google更懂你。我将这个转变成为从机器到人的变化，从机器统治互联网到人统治互联网的变化。

先说3个现象：

1、地球公转的速度没有变化，但所有人自转的速度都在飙升，所以“我忒忙”成了流行语；人们在自觉和不自觉间都被“碎片化”了，所以我们所追捧的东西都越来越小，包括钱包，当然，屁股和奶子除外；我们在被碎片化的同时也将自己的生活与气息散落在了四面八方，网络生活中的我们越来越多的变化成段正淳。所以，我们看到最近不少“强迫型”产品很出位

2、上帝是公平的，每个人都只有24小时，上帝又是不公平的，每个人都有无数的事情做不完。当网络侵占我们越来越多的时间，将生活也搬上网络的需求越来越强烈。所以，整个互联网势必是要“下沉”的，人们急需一个生活的互联网

3、人们的生活环境和状态越来越差，但是，人们对所有事物的挑剔程度却越来越高。人们已经不再满足于简单的罗列这里有什么，人们更需要的是这里有什么是适合我的，注意，是适合而不是最好。所以，有人说搜索将去，推荐上位

矛盾就这样产生了，我是这样的享受着碎片化的生活和网络，但是我更期望你能告诉我这么多有趣的事情中哪些是适合我的；我是这样的在意消费的品质，但是我却没有了独立思考的时间；我是这样的深爱着网络，但是你却总是不能读懂我的心….那么，分歧终端机呢？

应该有这样一款产品，他负责对你所有的碎片化信息进行整理与分析，然后将网络中的你还原成现实生活中的你，他会是全世界比你还懂你自己的。当然，这里存在如下几点：

1、重点不在于对信息的收集而是在于建模分析，利用语义化的方式消化掉

2、用户甚至不需要在这里花费什么精力来提交信息，利用开放的API就可以搞定

3、隐私会是问题吗？我认为不是，只要你能够提供的是用户真正需要的，隐私的问题会被用户忽视掉

4、这是一个“养成型”的产品

之前friendfeed做过这样的事情，后来GoogleBuzz在我看来也是这个思路，不过，很遗憾，他们都挂掉了。根本的原因在于，他们只是做简单的信息汇聚，但是，他们没对这些信息做过什么分析，也没能很直接传递出这些信息会给我们带来什么好处。

未来，我看好2个类型的产品：养成型的、推荐型的。养成型产品的精髓在于要有“鸦片”，推荐型产品的精髓在于要有“春药”。

一直以来产品经理与交互设计师之间的话题不断，有人认为交互设计师可以算上是半个产品经理，也有人认为交互设计师的生存空间太过狭小，基本成了一个破画图的，等等说法不一而全。之前，我写过2篇文章大致来表述对于两者之间关系的我的一些观点，在“我理解的产品经理”中我认为产品经理需要同时关注产品设计、工程技术、产品运营3个方面；在“基于axure的PRD写作思考”中我简述了在没有交互设计师辅助的情况下产品经理如何做一个更像样的“破画图”的。今天，结合最近的一些项目经验，总结一下产品经理如何更好的跟交互设计师合作。

首先，我理解的交互包括2个层面的交互，单页面的交互和系统层面的交互。单页面的交互是最常见的对交互设计师的定位，比如把一个注册和登录页面做到极致，把一个搜索框体验做到最好；而系统的交互则是各个页面之间的交互，各个页面之间如何更好的联系在一起，目前显见交互设计师谈到这方面的话题了。

按照传统的瀑布模型，需求分析 – 产品设计 – 产品研发 – 功能测试 – 发布与维护 ，在这套流程中下一个节点必须在上一个节点完全搞定才可以开始。所以在大部分的情况下是产品经理先做需求分析，然后开始撰写足够详细的(注意这个程度)产品需求文档，交互设计师根据PRD文档开始做交互设计，完事后交付给视觉设计师做效果，最后交付给技术人员做开发。而在这个过程中，从最开始的需求到最终开发出来的东西往往很难保证其需求传递的准确性，也让交互设计师的生存空间大打折扣。于是，最常出现的情况就是“我明明想要的是齐天大圣，可是最后你却给了我一个孙猴子”。为了避免这样的情况出现，我们尝试将流程做了如下改进：

1、需求分析阶段

产品经理在产品调研及需求分析阶段产出一份调研报告，这个报告需要说明这个项目的项目背景、项目收益、需要满足用户的核心需求点、为了满足用户的这些核心需求，我们需要使用哪些功能模块。在这个过程中，产品经理只需要考虑如何最大程度最优雅的满足用户的需求，完全不需要去考虑技术实现难度。一定切记不要让某些技术思维使你的思维被僵化或者局限了！

在整个需求分析完成一次之后产品经理需要做的一个重要事情就是跟开发工程师确定需求实现的难度，哪些需求是立刻可以被实现的，哪些是需要长时间开发的，哪些时目前技术无法实现的，….。然后对需求做第二次的筛选与分析，同时试图寻找替代方案，目前无法实现的可以暂时存入需求池，排入工程师研发规划中。

2、需求第一次传递

需求分析迭代完成并通过评审之后产品经理需要开始将需求可操作化并做第一次传递。一般包括，需求的优先级排序、如何将这些需求衍化到一个可操作的产品中去、以怎样的形态进行展示等。在这个阶段需要输出2个东西，需求概述和产品架构图。需求概述主要对需求分析阶段得到的经过团队成员统一意见后的做总结，其实是继续准确的描述“解决什么人在什么情况下的什么问题”；而产品架构图则是该阶段最为重要的产出物，他是承载整个产品的根基，包括产品包括哪些模块，各个模块之间的关系如何等。

产品经理将需求概述和产品架构图交付给交互设计师，由交互设计师来完成需求的页面化,包括产品架构下的页面逻辑确定、单页面的交互逻辑确定。打个比方的话就像是产品经理提供给交互设计师一颗颗的珠子，并告诉交互设计师这些珠子的串联规则，而交互设计师需要完成的就是将这些珠子串联起来，以最动人的形式展示给用户。这个过程中，产品经理需要给交互设计师足够的信任，但前提是二者对于产品的核心需求点理解一致，由交互设计师主导完成珠子的串联，产品经理做方向把握。最终，产品经理和交互设计师共同接受原型评审，同时完成产品需求文档并做第二次传递。

在产品设计流程中，相对于其他环节的需求传递，产品经理将需求传递给交互设计师的环节最为重要，交互设计师对需求的理解和把握会直接决定后续需求传递的效果如何。

3、需求的第二、三次传递

经过上面的传递后产品需要满足的核心需求得到认同，产品的框架与产品逻辑都得到确认，在接下来的传递过程中，主要涉及到视觉设计师、开发工程师，问题已经不大，面临的一个核心问题就是排期。这里可以直接采用《用户体验的要素》中提到的方式“不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段的工作”

图片来源：用户体验的要素

另外，由于移动设备的特殊性，移动互联网产品设计较传统的Web设计又有其他差异，交互设计师、视觉设计师提供的效果不似Web设计可以在真机上完全模拟。所以，在移动产品设计中，必须要加入交互设计师、视觉设计师的真机效果确认。

絮叨了半天，其实总结起来就是这么几点：

1、满足什么人在什么情况下的什么需求之过东西，必须在每次传递的过程中被准确的传递，同时整个团队形成统一认知；

2、专业的人做专业的事，交互设计师是整个流程中最至关重要的需求传递环节，最好由产品经理提出初略的产品需求纲要，由交互设计师来完善这个纲要，然后向下传递

3、不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作

4、移动设备产品设计的特殊性导致必须要求各个环节最终效果都在真机上做一次回归

5、交互设计师是一个可大可小的职业，这，完全取决于你自己

首先，武断的胡乱提下本文的观点。单纯的签到式lbs已走向衰落，典型如“我在这里”，“我和xx在一起”已然从曲线的顶峰开始滑落，签到期待更有附加值的形态与功能；checkin最终会成为一个产品的模块而不是产品的全部，即我之前认为的“checkin只是一个开关”；不过，如果商家不愿意玩lbs，lbs这个市场会依然凄凉与小众下去。

前段日子有博客引用LBS 鼻祖Foursquare 和 Gowalla独立访问数停滞不前的数据提出lbs激情已退的观点。个人认为这是一篇典型的以偏概全的说法，这个数据只能说明“签到”的激情在消退，原因应该有2点：越来越多的sns网站开放了“签到”功能；单纯的签到使产品太过单薄难以持久发展。我曾经在之前的一篇文章中提到checkin的文案应该创新，checkin的形式也大有创新空间。时间过去大约半年，foursquare已经可以在checkin的同时添加照片；国内lbs服务的代表街旁网在可以发图的同时增加了图片特效功能。不过，我依然觉得在这方面有可扩展之处，当一个网站让用户留在上面的自己创造的内容越来越多的时候，用户离开网站的成本就越高，相应的用户依存度也会提升。

随着产品市场的发展，一切有利于poi的数据每个社会化网站都会鼓励用户去分享，社会化网络会慢慢让用户感觉不到线上与线下的差异，基于真实存在的社交网络是大势所趋。所以，我们看到几乎所有的社会化网站都推出了“位置组件”服务，facebook、twitter允许你在向好友分享信息与状态的同时标记位置信息，真实性与存在感让社交网络更加良性的发展。

当然，以上2点其实显而易见，也并不是本文的重点。这里我试图思考另外一个问题，商家可以利用lbs做些什么？在lbs中l（Location）是基础，s（Service）才是重点之所在。同时s又包括2个部分，lbs网站所能够提供的如交友、足迹记录与分享等；Location本身能提供的各种服务。如果Location真实的拥有者（不是地主）无甚可提供的服务，那么，lbs将无从谈起。长远来看，未来的营销是社会化的基于人的营销，lbs结合微博也是一个很好玩的值得商户重视的方式。

典型的如将签到次数跟优惠和促销进行挂钩的形式可以继续深入。有一种lbs服务应该是可以允许商户有自己的管理后台并依据营业情况随时发布任务信息，并自我监测营销效果，同时商户还可以有自己的官方营销账户随时与消费者进行沟通与交流。在这种情况下lbs服务商其实成为了营销平台服务商，每个Location信息将更加丰富与有价值。

目前散布在各大LBS网站上的签到信息其实完全没有被挖掘过，我认为这是一座巨大的真实的实时的极具价值的数据金矿！因为这些数据是实时的与真实的（虚假签到的情况应该可以想办法刨去，这个是数据挖掘的问题），相对行业报告而言更具可信度。可以分析消费者在竞争对手签到信息的分布从而知道竞争对手在什么时段生意最好；为什么有些曾经在自家签到过的消费者最终一直在竞争对手那里签到了，是否可以通过跟他们沟通的方式了解原因；虽然你也有签到优惠策略，为什么消费者还是愿意去隔壁签到；…..

是否有一种方式可以让商户在社会化网络上的官方帐号与lbs服务中的Location名称一一对应，这样商家可以直接在社会化网络上跟消费者进行沟通。我是“幻风阁”这个商户的老板，我的poi信息在各大lbs存在，同时我在微博上有一个官方id叫做@幻风阁。当有消费者在我的商户签到并将签到信息同步到微博之后我就可以得到一条@ 信息，有一套cms系统对这些同步过来的签到信息进行分析，当出现有消费者的抱怨信息的时候@幻风阁 这个id会主动跟消费者沟通哪个环节的服务出了问题惹怒了消费者。cms系统可以进行配置，对那些系统化的签到信息直接忽略。当然，即时是不同步到微博的话lbs服务商本身也可以搞一套这样的cms系统放在商户的管理后台中，不过，商户本身对签到信息没有删除的权利，只能有回复的权利。

不过，每一个优秀的产品都是特定时间段的产物，这是产品设计的最基础，即产品市场，其次才是解决什么人在什么情况下的什么需求。所以，我上面说的都是在扯淡，博各位一笑吧。

另外，基于图片的社会化分享正在酝酿爆发，如何在移动设备上打造优秀的图片分享体验将是一个重要的设计师课题。目前很多需要分享图片的服务在移动设备上都是将用户定格在图片上传页面，只能盯着“图片上传中”发呆，这种糟糕的体验亟待改进。之前提到的picpiz在android上的处理方式挺赞，点击上传后进入后台执行上传操作，用户可以继续操作，如果在上传过程中网络中断的话会提示因为网络问题上传中断，等待有网络后可以选择续传。

想想挺搞笑的，去年大概也是这个时候，我写了一篇“盘点：我的Firefox插件集”介绍我正在使用的firefox插件。仅1年时间我就叛逃了….闲话不提，下面开始介绍我正在使用的chrome插件集

一、界面美化类

无！因为我不需要，chrome默认的界面已经够我用了

二、常规工具类

1、AutoPager Chrome
自动翻页工具。泡BBS、豆瓣等社区网站人士福音，基本功能跟firefox下一样。

2、Bookolio
书签展示工具，强烈推荐。可以直接在 Chrome 新标签页上按照书签分类显示你所有书签的扩展，而且在页面顶部还集成了热门的搜索引擎，包括 Google、Bing、Yahoo、维基百科等等。

3、Clickable Links
将URL,Email文本转换为可点击的链接

4、Docs PDF/PowerPoint Viewer (by Google)
在 Google 文档查看器中自动预览 PDF 文件、PowerPoint 演示文稿和其它文档。

5、Ease Link
修复迅雷、QQ旋风、快车、RayFile、纳米盘和QQ临时聊天专用链接，转换网页上的上述种类 URL 文本为超链接。

6、IE Tab
这个不用介绍了，你们都懂的

7、Sexy Undo Close Tab
安装后会在 CHROME 右上角工具栏生成一个小图标，点击该小图标就可以看到最近关闭的标签页，默认收录最近20个关闭的标签页，用户也可以通过扩展的设置页面改变这个数值。在最近关闭的标签页列表中，还显示网站的 Favicon 和从标签关闭到你点击图标的时间，可以更加精准的确定你将要重新打开哪一个标签，另外扩展的设置页面也有很多让使用更加方便的设置，比如显示列表中网址的 数量、改变弹窗界面元素的风格等等。

8、快捷工具（由Google提供）
Google官方出品的工具，支持自定义快速访问菜单，保存未提交表单数据，快捷键，网址一键通，原始图片查看，图片放大镜，设置图片为桌面背景，独立视频。

9、网页截图（由Google提供）
截取网页为图片，支持窗口截图，区域截图和整个网页截图三种方式。支持水平和垂直翻页截取超大网页，新版引进自动截图保存功能。

三、社会化工具类

10、FaWave(发微)
All in one的微博插件，多个微博服务同时同步发送。目前支持的微薄有新浪微博(sina)、Twitter、搜狐微博(sohu)、饭否、做啥、嘀咕(digu)、人间网、雷猴、豆瓣、Google Buzz、网易微博(163)。

11、Google的短网址服务
使用Google的短网址服务对长网址进行缩短，同时可以查看该短网址的点击情况、还可以使用由google生成的属于该短网址的二维码

12、One Number
只需要一个图标就可以查看四个Google服务（GMail, Google Reader, Google Voice,  Google Wave）的未读信息数目，Gmail提醒也支持使用Google Apps的邮件监视。安装这个扩展后，点击扩展图标跳转到Google输入Google账户用户名和密码即可启用。监视的服务列表，检查频度，未读数显示颜色等等也都可以在扩展的设置中自己设定。

13、PostRank Extension
GoogleReader重度用户必备工具。PostRank 有一套自己的评价系统，通过综合考量条目链接在 Twitter、Delicious、Digg 等社会化分享和收藏系统的传播次数、文章评论数、Google Blogsearch、Technorati收录、点击率等一系列指标来得出 PR 值，你可以按照这个Rank值对你未读的文章进行筛选，在未读条目1000+下灰常好用。

14、Super Google Reader
该扩展可以让你直接在 Google Reader 中阅读任意网站的文章全文内容，安装该扩展后会在 Google Reader 的每个条目中出现 Readable、Link、Feed 三种内容读取方式，Readable 就是调用文章全文，Link 是直接以 iFrame 方式嵌入，Feed 是调用默认RSS内容。

15、TinEye Reverse Image Search
这是一个以图识图的扩展，在任意一张图片上点击右键选择TinEye后就可以非常精确地在整个互联网上匹配你要查找的目标图像。寻找无水印图片，某图片原始地址的利器！

16、Web2PDFConverter
将任何网页转换为PDF文档。作为景德镇人民，这年头也就硬盘存储相对比较靠谱了。

17、Google Chrome to Phone Extension
这个扩展程序可让您将谷歌浏览器中的链接和其他信息发送至 Android 设备。不过需要在手机上也要安装这个应用程序（搜索“Chrome toPhone”），同时电脑和手机需要处在一个相同的网络环境下。

四、进阶工具类

18、KB SSL Enforcer
在目前的互联网环境下，这个扩展十分必须，你懂的！这个扩展可以自动检测用户当前打开的网站是否有 https 版，有的话将自动跳转。当然用户也可以设置黑白名单来手工确定哪些网站不需要/需要跳转，检测的结果将被保存在缓存中，这样第二次打开同一个网站时就不会拖慢速度了。

19、Chromium
我目前在使用由@vforchrome 提供的Chromium。这个版本是便携版，解压即可使用，最重要的是支持SSH客户端。解决了在chrome下有选择性的穿越长城的老大难问题。安装后在设置里有个“SSH主机主机管理”，添加SSH后可以在当前浏览的页面中选择是否使用代理，跟在Firefox下使用AutoProxy一样爽！

我目前一共使用了以上19个插件，chrome的运行速度和工作效率依旧很快，这让我这种一直使用低端机的用户感觉很爽。另外，有很多插件一样很优秀，别问我咋没介绍，因为我没用过，无法为之背书，谢谢！

如果不是又收到域名续费的通知我甚至都不知道2010年就要完蛋了，在约1个月没有更新Blog后我咬咬牙告诉自己说，时间就像乳沟，于是，我终于能够坐下来带上耳机赶在2010年的最后几个小时里写下一篇故事汇。

2010年于我是个充满邂逅的年份，生活和工作皆是如此。

在2010年里我邂逅了一个跟我一起生活的人，从性格上看我们都是好强偏执的射手座，两个产品人的生活从一开始的针尖对麦穗到我慢慢把自己变成麦穗，从一开始的工作生活不分到我们尽力克制自己不把工作带入生活，生活在慢慢走向融洽；在2010年里我邂逅了我的第二个职业方向，从Web产品设计到移动互联网，从电子商务走向生活服务，虽有差异但又很自然；在2010年里我邂逅了我的第三个雇主，从一种公司文化向另一种公司文化迁移，虽有不同但我很喜欢，并迅速适应。

2010年，我属于互联网和产品设计。

我信仰并偏执的喜爱着互联网，这是一件可以让人不知疲倦的投入其中的事情。我坚信未来的互联网是属于生活的，三年来我从电子商务平台转向电子商务的上游做电商导购再转到生活服务，其实在我看来本质上都是一样的。

3年前我的第一次面试，被问到你觉得自己适合做运营还是做设计？我一时语塞，我说我不知道，因为我还在成长，我的潜能还在被挖掘，我没法定性自己，不过我倒是可以试试先做设计，因为运营这事其实是个需要“经历”的活计。3年以后，我的Title从产品设计师变成产品部门经理再变成产品经理，但是我仍旧不敢在人前大声的说我是一个产品经理，我觉得我现在只是个产品（后面没有了）。产品经理是个需要“经历”的活计，这个职位不是你有本事就可以做，更看重的是如何驾驭本事和驾驭比你还有本事的人，需要的是对方向的把握对观点的偏执对细节的执着，而这些我远远不够。

2010年的中国互联网可以用2个字来概括，那就是墙和咬。

优秀的互联网企业墙起来，有骨气的互联网企业逃出去，中国的互联网始终绕不开那堵墙；而墙内的企业除了相互咬还是相互咬；第一梯队之间互相撕咬，争夺势力范围，尽显无耻本色；第一梯队不断龇牙冲向第二梯队第三梯队疯抢人家挖掘的新的机遇。在中国做互联网如果不既是当裁判又下场踢球的，你都不好意思跟人说你是中国互联网的牛逼企业，这就是他妈的中国互联网现状！

……

2011年，

从一个新手开始，移动互联网、产品经理，我仍然属于操蛋的中国和乌烟瘴气的互联网！

最后，这是一篇杯具的跨年未遂的Blog。2010年12月31号早上我信誓旦旦的说我今天要写3篇Blog，然后我到了公司就被事情赶着跑，好容易晚上没事了，巴拉巴拉敲了半天字，正准备发布呢，刷新一下页面发现，我靠，域名停止解析了….因为，域名到期了，而我一直没时间续费…..

图片来源：（山居 疏影）

写在前面：是的，这是一篇彻头彻尾的软文。虽然我也写了不少软文，但是像这次这样鸡冻兴奋的写软文还是第一次…..

记不清是7月还是8月的某个下午了，elya跟我聊天的时候聊到她去年找工作的一段经历，没去跑什么招聘会也没去搞什么海投而是通过在新浪微博上检索关键字找到跟招聘信息相关的微博，然后跟发布招聘信息的人沟通或者递上自己的简历。这种找工作的方式往往迅速就可以得到回复，且命中率比较高。

然后elya跟我说，如果我们能搞一个基于微博的APP，专门帮助那些应届生来找工作会不会很有意思呢？我当时正在做比较购物相关的事情，大概的评估了一下，觉得这个事情其实玩起来不难，最主要的是这个APP比那些无意义的求包养算缘分求签什么的APP有价值，于是我们两在展开了长达一下午的不断争论之后我画出了微伯乐的第一个产品架构图和原型页面。之后我们把这个想法说给王江听，王江也很感兴趣，于是他承担了网站的开发工作，微伯乐就这样被生出来了。

我们要做的事情就是通过新浪微博的API接口向新浪微博请求数据，把跟招聘信息相关的微博过滤出来，然后对这些数据再做一次清洗、去重、按照我们设置的权重进行排序，最终以一种适合用户浏览的形式呈现在我们的网站上。用户可以使用自己的新浪微博帐号在微伯乐上登录，并对自己感兴趣的招聘信息执行“评论”、“转发”、“收藏”等操作，这些操作最终都会被返回到新浪微博上去。用户也可以自定义关心的职位信息，以后每次进入微伯乐之后优先显示他定制的招聘信息。

简单说就是对微博的信息做“垂直化”过滤后展示在微伯乐上，节省用户对信息筛选的成本，用户再对这些经过筛选的信息进行“消化”，最终会产生更多有价值的信息返还给微博。这是一个完整的信息价值链传递。

目前传统的招聘模式下信息的流动方式是：需要招人的人<——>HR<——>招聘网站/猎头<——>找工作的人 ；这样的一个信息流动系统中真正需要招人的人和真正找工作的人之间隔着HR和招聘网站，信息的流动是不顺畅的，HR通过传统的渠道总是无法命中需要招人的人的真实需求。

去年在易购网的时候我曾经有很长一段的时间求产品经理和网页设计师若渴，HR通过智联招聘等网站搞过来的简历用惨不忍睹来形容一点都不为过。后来我实在忍不住了，就自己在微博上发布了一份招聘信息，不到1天时间就收到30多份简历，这些简历中至少再没有什么车间主任来应聘产品经理的了….

我从08年4月开始玩Twitter，我一直认为twitter并没有出落成它最终的形态，这种形态的产品最终会重塑我们的网络生活，表现在对信息流动的革新和对关系的重塑。当然，它在革新的同时也带来不少烦恼，最显著的就是信息流动过于快速，碎片化的信息和关系使得很多有价值的信息被埋没了。

从10年3月开始随着互联网行业的复苏，加上新浪微博的爆发，我观察到越来越的微博“强节点”用户在利用微博发布招聘信息，且都收获颇丰。一方面微博的关系属性让需要招人的人跟需要找工作的人直接碰撞，并且双方都可以通过微博对对方有足够真实的了解；另一方面微博的新媒体属性使得信息的传递更加高效，这使得微博招聘的命中率比传统招聘要靠谱许多。

是的，微伯乐要做的事情就是帮助用户从汹涌的碎片化信息河流中把有价值的信息捞出来晒在广场上，然后用户直接在广场认领就成了。而当用户看到自己满意的信息后再跟发布信息的人发生的一切交互关系微伯乐目前无能为力….不过，这不是微伯乐想考虑的地方，微伯乐目前只考虑做一件事情：尽最大可能的把微博中跟招聘信息相关的微博筛选出来，然后以最合适的方式展示给用户，over。

最后，是elya小宇宙中爆发的火苗和她对这个事情不断的努力与推动还有王江同学辛苦的开发才使得微伯乐最终能跟大家见面，还有其他几位朋友的努力。谢谢各位，你们一并出现在这篇软文的落款处…..

啊，对，最后，我说了半天，介绍一下这篇软文的主角：

网址：http://tbole.com
微博地址： http://t.sina.com.cn/tbole