幻风阁|kent.zhu'sBlog

首先，写这篇文章的一个重要性的冲动诱因在于我这个刚入行的移动互联网产品设计新手在查找资料的时候被太多的前辈恐吓了很久，我最终决定站出来反击一下。

我们看到无数的移动互联网前辈们说，移动互联网产品设计相对于Web设计而言实在太多限制了，太难搞了。你看，屏幕就那么点大小，当Web端主流分辨率停留在1024*768的时候手机上主流的分辨率确还是240*320（注意我是说主流，别说iphone4的640*960）；我们可以在Web上使用鼠标+键盘来顺畅的浏览而在手机上只有键盘（触屏目前还是灰主流吧）;当Web设计已经花哨到泛滥的时候手机上还是个梦想…..好吧，够了，够了，实在是够了

可是事实是这样吗？我不认为！我认为在手机上的设计要比在Web上的设计相对更简单。

更小的屏幕意味着你只需要考虑更少的内容设计；更单一的交互意味着你只需要思考更简单的信息设计和更单线程的流程设计；更限制性的硬件意味着你不再需要考虑哪些花里胡哨的“假动作”，你只需要关注是否能更快速的帮助用户解决需求就足够了…..

一般而言，在手机上的产品设计分为2类，从Web端移植功能到手机端、全部由手机端开始设计。这2类设计实际上都适用以下要说的原则。

一、拥抱约束，习惯在局限下设计

这是一句正确的废话，每个人都知道真正的自由并不在于完全自由，真正的自由在于完全自由与限制性之间的平衡。而这点在手机产品设计上表现的尤为突出。在手机端做设计首先必须要具备的思想就是阉割，当然，这点在Web端的设计上我曾经也认为是最重要的。

《简单法则》里提到一个方法，SHE：缩小（Sherink）——>隐藏（Hide）——>附加（Embody），然后把这些被简单过的元素有组织的放在一起。

以从Web移植产品到手机端为例，①把Web已有的功能模块全部列出来，排序；②尽可能的砍，把可以减少的功能尽可能的减少；③隐藏，把不可减少，但是并非十分必要的功能隐藏起来；④考虑手机端用户需求与Web端用户需求的差异，然后附加一些手机端特有的需求与功能进去；⑤有序的组织上述元素。

这样的做法既做到了简单，同时也避免失去了固有的价值感。这样一顿阉割之后你会发现，其实在手机端这样的环境下去实现这些功能是很简单的了，因为有太多不必要的东西都不需要了。其实，就是用最核心的功能去满足相对局限的条件，在做手机产品设计之前，最需要做的工作就是最小化和剔除不必要的工作。想好不做什么，然后再去做！

妥善的组织能使复杂的系统显得比较简单。比如iPod的按钮设计就经历了一个这样的过程，在最开始的时候iPod的按钮设计成了滚轮式的，在第三代的时候iPod将转盘外围的4个按钮抽出来放在了转盘的上面，变成了一排小按钮，这显然让iPod的交互变得复杂而混乱了，于是在第四代的时候我们发现所有的按钮重回转轮之上，并且完全一体了。这是一个典型的从一开始简单到变得复杂又简单到不能再简单的案例。

（图片来源：腾讯科技）

二、智者知止

过度设计这事这几年在Web产品上时有发生，仿佛产品设计师们觉得如果某个页面他们不“加工”一下就显得不专业，但是往往是越加工越不专业。 每一个设计都有它的核心诉求点（中心思想）和所有传达的信息，凡是引起用户感到迷惑和无关主题的信息都是需要避免的。哦对，这个东西有个专业术语，叫做“噪点”。

在手机端的设计上需要时刻跟“万一……，索性还是加上去吧”的思想做斗争。不为20%的用户需求买单，不因为20%的用户而丢失80%甚至更多的用户。最好的产品体验，我个人认为是用最简洁的方式，最优雅的满足用户的需求。

三、单线程浅层次的信息设计

因为更多的限制，所以手机上的信息设计无法像Web设计那样的无限制的以网状延伸，而必须是相对很浅的。不要在同一个页面里展开多个流程，使用清晰的布局，准确的提示等等。关于这点推荐围观@默契的这篇PPT 。

好吧，你可能意识到了，我并没有提到超过12000种终端的适配问题。是的，这是真正的问题，我跟你一样，都很无奈….但是，每个产品的用户群是一定的，也许，缩小范围后问题会相对简单一点。当然，也许你会认为未来类iphone的机器会成为主流，但是，别忘了，那是未来。而，事实就是这样！

在开始这篇文章之前，我首先要像感谢国家一样的惯例性的做出一个很艰难的决定，在360和QQ这个事情上，我不支持QQ，但是，我更他妈的希望弄死360这只疯狗，有360在中文互联网将永无宁日！

从2010年1月开始，以QQ医生3.2版正式亮相为起点，360与QQ之战爆发，这场持续了10个月的战争在PC用户的桌面右下角来回厮杀，详细的过程请参见“企虎演义”。在这场中文互联网罕见的旷日之战中，我无法判断谁是最大的赢家，但是用户显而易见的是最大的输家（抱歉，我又代表了一下“用户”这个群体）。

这场战争让之前在饭桌上一直八卦股市与房子的同事们同时转变了话题，他们很不解的问我说为什么360要这么疯狂的撕咬腾讯呢？我觉得有2点原因，QQ杀入360苦心经营多年的安全市场了，这是一块很肥的肉，360肉疼了；中文互联网目前的局势太过稳定了，任何一个新入场的选手都很难获得多大的市场份额，就连老谋深算的李开复都去做了移动互联网，所以，某个天生嗜血的疯狗要把这个稳定的市场打乱，好从中谋得更大的利益。

在目前的中文互联网中，腾讯就像是“人血馒头”，所有的互联网企业都想捅它一刀，然后沾点他的血分一杯羹。

不错，腾讯是挡在几乎所有中国互联网企业面前的一座大山，这座大山以其形成的根深蒂固的用户关系为基础，配以“等-仿-推”三字真经到处染指。几乎所有试图在中文互联网中淘金的人都被搞的半死不活，因此腾讯被扣上了霸权主义与扼杀创新的帽子。但是仔细一想，确实是这么回事吗？

有人反驳说腾讯扼杀创新，那么容易就被弄死的创新你觉得这叫真正的创新吗？每个产品都有一个自己无法被模仿的基因，这个基因不会因为外在的东西而动摇，这才是产品真正的核心竞争力，你好意思说你的产品有核心竞争力？为什么淘宝没站出来骂，京东没出来哭？生意不好怪柜台，你们不脸红吗？从产品体验层面你们那些哭着喊着叫嚣着的家伙谁敢说自己比腾讯做的好？

说起垄断，腾讯只能垄断我网络生活的关系部分，而作为系统底层应用的360却可以把我所有的应用都垄断，假借安全之名！我一直很想问下周鸿祎先生，浏览器你觉得别人的不安全；IM你觉得别人的不安全；杀毒你也觉得别人的不安全；搜索你还觉得别人的不安全，操作系统你更觉得别人的不安全，那请问您觉得什么是安全的？绿坝和GFW算吗？

许多年前的时候，流行打土豪分田地，大家都觉得土豪可恨，凭他妈的什么他就有那么多土地那么多女人，老子每天穿个漏蛋蛋的裤子还喝不上稀饭？于是就一呼拉的都上，打倒土豪劣绅，分他们的田睡他们的女人。可是，最后呢？…..可是谁想过，土豪天生就是土豪吗？……可是谁想过，带领我们打土豪的那个家伙最后会不会成为最大的土豪？……

那谁说来的，安全之事大于天，从潜意识里我压根不放心把安全交给一个以流氓起家的眼里和嘴里都是江湖的人来做。人品定产品，如果一个人的品行就是邪恶的，你能指望他做出什么正义的产品吗？当“安全”被他们当成一种恐吓用户的手段来玩的时候，你还对这款产品抱多大的期望？

我一直搞不明白一件事，360公司区区几百人吧，但是我们总是能看到不时就出来一个360的员工揭秘一下这家号称“维护用户权益”的让人不耻的黑幕，而腾讯员工的人数是360的数十倍，为什么迄今为止除了泄漏一些内部资料外我没有看到任何的人站出来爆腾讯的黑幕呢？后来，我看到这篇从投行的角度分析360与QQ之战的文章，心中之惑顿消。这家成立5年多的企业在5年内已经高举“维护用户安全利益”之刀对瑞星、阿里、金山、百度、腾讯等多家公司砍杀过，而成立了12年之久的腾讯公司迄今而至只出刀一次，那就是在隐忍许久后砍杀了360。网易制作的专题说“腾讯今天能封360，明天就敢杀460”，呦呦呦，您真大无畏！你的网站首页广告是没被屏蔽过吧？从这出刀与嗜血的脾性看，谁像是更会再出刀的人？

其实，周鸿祎为什么敢于发动战争，并且能赢得绝大多数互联网同行的支持与同情，互联网从业者们都心知肚明，因为，腾讯是中文互联网的“人血馒头”！把自己变成中文互联网的人血馒头，这是腾讯12年来最大的成就。所以，当一只疯狗咬上腾讯的时候，狐狸、小狼、网蚁纷纷寻找机会也扑上去咬一口。这是腾讯的悲哀，更是中文互联网的悲哀！

引用微博上的一句话说，你们别嘲笑腾讯公关不专业，或者行动比较傻，激怒用户。他不高明，说明他不善于整人；相反周鸿祎就是达人了，整个一延安时期的毛泽东嘛，发动群众斗地主。但我宁愿要马化腾，这人不是靠野心上位的。

最后，再引用一句微博做结尾吧，@rivery说，360是岳不群，背地里坏事没少做却打着道德的幌子骗人；腾讯是令狐冲，明明没做错事，在最爱的人面前反而嘴拙吶呐百口莫辩；新浪是欧阳克，总想着趁火打劫占点便宜；可惜的是，当世的中国互联网，并无萧峰。

写在最前面：任何工具都容易造成沉迷，Axure也一样；沉迷工具有害健康，过渡钻研Axure不利于职业发展！

1、什么是变量

变量的全称应该是“中间变量”，变量用于在HTML原型中进行点击时的页面之间的传递和存储数据，这样变量能在页面之间保持下去。Axure文件中可最多使用25个变量。变量可以在交互设计和逻辑条件中使用。

简单说就是，在2个页面之间添加一个桥梁，用以延续交互动作。这个东西最直观的理解就是我们在做几何题目的时候通常需要在2个条件之间再取一个中间的条件，最后达到证明这2个条件是一致的，如：a=b，b=c，所以，a=c。

在Axure中可以通过“线框图”（Wireframe）——“管理变量”（Manage Variables），来增加或者管理变量。
Axure会默认一个变量叫做“OnLoadVariable”，必须使用字符和数字做变量名，不能大于25个字符长度，且不能含有空格。

2、变量的使用情景

1）动态显示输入的字符
2）动态统计并显示输入的字符长度
注：这里变量只能实现计算字段的长度，但是不能做加减乘除运算，所以想要实现“还可以输入XX个汉字…”这样的交互目前在Axure上还无法实现。
3）页面之间的锚点跳转，详见之前的这篇
4）下拉列表的联机动态加载
5）Tab页签的变换
注：较常规的动态面板也可以实现该功能
….

简单说，变量的使用一般程序：添加变量，修改变量值，判断变量值，加载对应内容。

特别说明：
1）变量的使用过程中需要用到每个组件的标签名称，所以，必须要先给需要用到的组件添加标签，不然就全部显示“unlabeled”。
2）在“设置变量和组件的变化值”这个交互动作的时候，一般的格式是：变量的值“a”等于组件值的长度“b”；组件中的文本“C”等于值，然后后面有个编辑文本。
点击进去之后可以编辑的是动态显示的具体内容，你可以输入的是一些修饰内容，无关紧要，最主要的是，要记得插入变量“a”，这样整个交互才能起作用。

3、实例
之前设想过的一个微博输入框为例，点击这里查看。

P.S：
一个容易忽略的地方：Axure在处理多个交互动作的时候，实际上你是可以手动设置他们的发生顺序的。在“交互属性”弹窗的右上角有个“高级编辑器”，点击里面的箭头来对交互动作的发生进行排序。这个主要应用在如：弹窗XX秒后自动消失等交互上。

当年，百度豪气万丈的进军电子商务并喊出“要购物，先百度”的口号，淘宝迅速出招封了百度的爬虫。1年之后李明远离开百度电子商务事业部，淘宝推出的大淘宝计划席卷了中国电子商务市场。现在，淘宝的电商之城已经越筑越长，百度的矛也转向了生活相关的电子商务了。二者的入口之争还在继续….

我个人认为百度提出的“要购物，先百度”这口号本身没甚问题，如果理解成在你要购物之前百度可以帮你做出购买决策，告诉你在什么地方买，买什么比较合适的话。但是，百度一出手就是C2C平台，直接进攻淘宝最强的地方，虽有差异化，但是市场尚未成熟，这些细节的差异化都迅速被淘宝学习了，加之公司内部的战略倾斜，导致百度有啊直到现在依然是空城一座，而核心团队也几乎全部流失。

在百度有啊出现之前的淘宝（注意这个时间点）实际上主要是抓住了“卖家”，创造了一个商品信息的大集市。当用户有明确的购物需求的时候淘宝可以给出满意的解决方案。但是，当用户购物需求不明确的时候呢？淘宝无法回答。但是，这个时候，这个问题，百度可以回答，百度贴吧、百度知道、百度搜索都可以回答。

再后来，淘宝推出“大淘宝战略”，在囊括了卖家信息之后试图解决当用户购买需求不明确的需求，淘江湖、淘心得、陶女郎、…包括即将上线的 etao.com，在etao.com中除了包含了商品的基本信息之外还会包含商品的资讯信息、社区信息等等。淘宝试图在打造一个足够完整的用户购买需求解决方案。

当然，淘宝的大淘宝再大也不可能在中国的电子商务市场一家独大。未来的市场会是大淘宝、B2C及具特色化的电子商务企业三分天下的局面。下面拉回来扯一下我个人认为的百度的电子商务布局：

从电子商务涵盖的商品属性不同我将电子商务分为3个大类别：纯实物类商品（服装、3C等看得见摸得着的）、半实物类商品(充值卡、点卡等)、纯虚拟类商品（服务类商品）。

纯实物类商品，就是我们最常见的比如图书、化妆品、母婴用品、3C数码这样的商品。其特点在于用户首先关注的是商品本身的属性（易用性、性价比），其次才是 商家的服务态度，同时这样的商品也是比较容易标准化的。而纯实物类商品的网购与实体店购物的最大区别在于用户无法实体感知，不能摸也不能当场试穿（3D虚 拟购物无法完全解决这个问题）。所以，可以继续沿用有啊之前建立的“标准库”来帮助用户作出购买决策。

这个基于SPU建立起来的标准库可以联通该商品的其他属性，如点评信息、资讯信息、用户使用信息、求助信息、百科信息等。可以在用户购买之前解决用户无法实 际感知商品的问题。同时，标准化的商品也更利于用户浏览。

最重要的一个问题是，这套标准库不仅可以应用在C2C平台上，更可以应用在外部的B2C平台上。完全也可以聚合其他B2C的点评信息到这个标准库里来。到后期，甚至可以考虑基于这个标准库容纳其余B2C的商品来做一个导购。相对于用户而言并不太在于在C2C还是B2C购物，他们只关系这个商品自身的属性如 何，这个商品的出售者信誉如何，要寻找一个最“match”的点。

半实物类商品，就是我们常用的如手机充值卡、机票、火车票、游戏点卡等。 其特点在于用户需要迅速购买迅速消费，用户最关注的发货速度、操作的易用性。所以， 这类商品的操作点在于后台的强大数据处理能力，和产品设计上的用户体验提高。还有一点就是，要让用户能够足够便捷的找到。

这个需求的解决上，百度的框计算有天然的优势。当用户输入“移动充值卡”的时候直接给出一个充值框；当用户输入“魔兽点卡”的时候直接给出一个充值框。估计没有什么用户会反对吧？

服务类商品，就是我们所说的比如鲜花快递、家政服务、婚庆服务等。这类商品是完全的无形的，用户最看重的就是商家的服务能力与信誉度了。换句话说就是，营 造一个口碑氛围极其重要，因为服务类商唯有亲自体验过的口碑才相对是真实的。同时，这些服务不少是“唯一性”消费，比如婚庆、月嫂等，用户的决策将会更加 慎重。

所以，这类商品在处理上不仅仅是要帮助用户找到，更要求百度有啊能够建立健全一套足够完善的信用平级体系和口碑交流平台。

当然，作为一个上市公司，其每一个战略布局都会承受盈利的压力，所以，百度的电子商务同时也需要考虑处理好与大搜索之间的关系。我觉得百度的电子商务与大 搜索之间的关系应该是共赢的。大搜索导入部分流量给百度电商，同时电商对这些用户的需求做更好的满足，再反馈给大搜索，使得大搜索的体验和黏性都有所提高， 这是一个良性的循环过程。

这也包括2个方面的引导，基于商品的引导和基于商家的引导。百度的购物搜索是基于商品的一条线了，而百度有啊推广平台实际上应该是要打造一条基于商家来做引导的线。这2条线相互配合，在一个大的购物社区中汇合并发挥强大的力量。

就电子商务而言主要包括：信息流、物流、资金流，而百度无疑是信息流上最佳的服务者。所以，百度的电子商务立足与“导”，引导用户去购买，可以是实物的也可 以是服务，可以是线上的也可以是线下，这些都不是问题，问题的核心就是要指好路。

最后，百度的流量浪是否能淘到电商金？期待…..

首先，搞清楚商品与单品的区别。例如，iphone是一个单品，但是在淘宝上当很多商家同时出售这个产品的时候，iphone就是一个商品了。

商品：淘宝叫item，京东叫product，商品特指与商家有关的商品，每个商品有一个商家编码，每个商品下面有多个颜色，款式，可以有多个SKU。

SPU = Standard Product Unit （标准化产品单元）

SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。

例如，iphone4就是一个SPU，N97也是一个SPU，这个与商家无关，与颜色、款式、套餐也无关。以化妆品为例，下图是拍拍商城给出的SPU信息：

在商品信息电子化过程中，商品的特性可以由多个“属性及对应的属性值对”进行描述。“属性及对应的属性值对”完全相同的商品，可以抽象成为一个SPU。同 时，这些“属性及对应的属性值对”也在SPU中固化下来，逐步标准化。基于SPU的商品信息结构，可以实现丰富的应用，比如商品信息与资讯、评论、以及其 它SPU的整合。

P.s：从这个意义上讲，我认为比较购物的产品库以SPU为标准来建立是最合适的。

SKU=stock keeping unit(库存量单位)

SKU即库存进出计量的单位， 可以是以件、盒、托盘等为单位。在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示：规格、颜色、款式。

也有人解释说SKU就是库存的最小单位，在服装行业，正常情况是“单款单色单码”，国内品牌有把“单款单色”当做一个SKU、也有把“单款”的几个色当一个SKU、也有把一块面料的几个个款式当一个SKU,这些都是误读。

同时，引申出另外一个概念：SKC：单款、单色。如果一定要打比方的话：SKC是一个桔子，SKU是一瓣桔子，但不管怎么说，一个桔子是桔子，一瓣桔子也是桔子。

不过，SKU是物理上不可分割的最小存货单元。在使用时要根据不同业态，不同管 理模式来处理。比如一香烟是50条，一条里有十盒，一盒中有20支，这些单位就要根据不同的需要来设定SKU。比如仓储批发式大卖场，一定是按照一箱来设 定的。普通大卖场一定是按照条来设定的。烟酒专卖店一定是按照盒来设定的。过去上海等地的街边小店一定是按一支来设定的。这样一支就是烟的最小零售单位。 但要根据自己的业态和服务模式来设定。

P.s:关于什么是SKU、SKC，可以参考阿福先生的这篇博客。

【总结一下】：SPU是标准化产品单元，区分品种；SKU是库存量单位，区分单品；商品特指与商家有关的商品，可对应多个SKU。

ARPU=Average Revenue Per User(每用户平均收入)

ARPU注重的是一个时间段内运营商从每个用户所得到的利润。因此，高端的用户越多，ARPU越高。在这个时间段里，从运营商的运营情况来看，ARPU值高说明利润高，这段时间效益好。

2010年是“T”字年，是微博横行的一年。百度在给贴吧加上微博功能又给空间增加一个微博组件之后再次出招做了一个全新的产品叫做百度说吧，至此百度的微博战斗序列已经有3款产品，不过，即使这样相比腾讯的微博战斗序列而言还是显得逊色了不少….

有人曾经问我“为什么Twitter没有想新浪微博那样的盖楼形式呢？”我想了半天没想好怎么回答他，后来憋出一句，国情使然敷衍了。不过，目前来看，我觉得盖楼形式的微博在信息传播与流动上确实更适合中国互联网，这种140字的微BBS形式让中国网民乐在其中。微社区的玩法似乎要比微媒体在中国更加安全和喜闻乐见。

百度这家公司一直对自己的流量能力很有自信，同时也对自己依托搜索做出来的中文最大的社区相当自豪。不过，他们不得不承认，百度贴吧目前已经发展到了瓶颈，这种产品形态需要革新。我觉得这是百度说吧出现的战略原因。

百度说吧由麦田带队操刀，麦田在各个场合不止一次的说“SNS应该是人、时间、地点的“三位一体”，是Facebook+Twitter+Foursquare”。而目前的百度说吧只是一个类微博或者说是实名制微博的产品形态，我觉得这只是百度说吧的先头部队，麦田一定会有杀手锏出来。而之所以选择微博这种形态，一来它实在太火了，二来目前的微博确实存在一些关系上的问题，所以，他们以此为切入点。

不过，我有些许担忧。如果后续的产品不能很给力的话，“实名制微博”这种产品形态是否会在用户心中留下烙印而让百度说吧的定位无法精准？杀入市场很容易，但是占领市场并拥有绝对优势则很困难。作为一个上市公司的产品，从出生开始就背负了比其他团队多得多的压力。

百度说吧刚出生大家就出奇一致的把枪口对对准了“身份证认证”、“手机号认证”、“真人头像认证”为代表的实名制上。个人认为这些口水都没有喷到百度说吧的G点上，从另一个层面上看，一个产品从出生开始就享受了“极具争议”的待遇，对于其市场推广而言恰恰是有好处的。这是一个无话题不生存，无口水不火爆的时代。

个人认为，百度说吧的核心问题在于，如何发现并挖掘关系，如何让用户觉得有价值，如何让用户乐在其中并且主动创造内容。

当用户觉得“可获利”的时候，用户比聪明的一休还聪明；当用户觉得“无利可图”的时候，用户确实比猪还笨！所以，即使各大银行的网银再难用，即使淘宝网的网页加载速度再慢，即使各个成人网站再难找，用户一样可以随时找到。因为这些服务解决了用户最根本的需求，这让用户觉得有利可图，无他！

实名制是百度说吧设置的门槛，但是当门内能提供的价值足够大的时候，用户一样会毫不犹豫的迈过这个门槛。如果门内无法提供足够的价值，那这个门槛确实是自寻死路。所以，百度说吧的核心问题在于，如何给用户创造足够的价值，如何让那些习惯了匿名使用百度产品的用户主动的来注册。

百度对用户而言是个工具，我们绝大部分人使用的绝大部分百度的功能都是不需要登录的，这种工具的属性要发展关系很困难。百度说吧的价值不在“我们玩真的”，而是由“我们玩真的”所创造的价值，是其背后可能引发的价值。如果这个价值不被挖掘出来并很好的处理，说吧势必发展艰难。当用户的期望与目标有冲突或者模糊不清的时候，社区关系的发展就举步维艰了。

百度说吧的第一批用户是百度员工，第二批用户是互联网混子或者叫“砖家”，第三批用户是蚂蚁网的老用户。这三批用户在骨子里对麦田及麦田的团队都存有偏见（不是贬义词！），这个旧的观念使得他们的想法和说法都会有问题，至少我个人认为是不够客观的。就我个人而言，目前我的百度说吧关系是个熟到要烂了我的熟人网络，这不是我需要的社区，一个社区是可以不断给我push新的关系，新的世界的地方。所以，我很期待百度说吧正式推广之后的第四批、第五批用户，期待他们的看法和贡献的内容，这个时候再去看这个产品

作为一个社区产品我觉得有2个模块特别重要：对新用户的引导、对信息流的把握。现在的百度说吧在这2点上表现很一般。对新用户的引导，个人觉得国内所有的产品无出腾讯其右者，俺想抽个时间专门总结学习一下；而对信息流的把握是个运营问题，跟产品定位紧密关联。举个简单的例子就是，交换手机号这个功能让很多人误认为所有人都能看到并得到我的手机号，而实际上要求是我的好友且我通过其查看的请求之后才能得到，这显然是引导失误。

最后，我最近有2个领悟：其一，如果在新产品上线或者产品改版时候有用户持续的（注意频率）唱衰之并扬言要离开，那这些用户是最不会离开的，具体请参见豆瓣；其二，如果一个新产品上线或者产品改版后没有人骂，那你这产品着实太烂了或者着实太籍籍无名了。不过，对于产品人员而言，学会挨骂是个必须过关的技能！具体参见白鸦的“在杂音中成长的产品人”。

另外，我给百度说吧想了句广告词:上班那点事，下班那点事，还是床上那点事？来说吧！

作为工具，首要的条件就是高效率。高效率的解决问题，高效率的传达，高效率的记录，等等。Axure之所以被称作“快速原型设计”就在于他能高效率的完成原型设计并高效率的传达。而这一切得益与axure的“复用”思想。在Axure中的复用包括2个部分：组件的复用、模块的复用。

先温习一下在axure中什么是组件什么是模块，高手请直接跳过：

组件（控件）是用于设计线框图的用户界面元素。在组件（控件）面板中包含有常用的控件库，如按钮、图片、文本框等。从组件面板中拖动一个控件到线框图区域中，就可以添加一个组件。组件可以从一个线框图中被拷贝(Ctrl+C)，然后粘贴(Ctrl+V)到另外一个线框图中。组件面板工具栏中可以加载已有组件库、创建新组件库、编辑当前组件库、或更新组件库，也可以对组件进行搜索。

模块（Maste）是可以重复使用特殊页面。一些常用模块如页首(Header)、页尾(Footer)与导航(Navigation)。模块可用在页面中或是其他模块中。只要修改模块，在所有引用这个模块的页面中的模块也会相应跟着同步更新。 模块的概念犹如PowerPoint 中母版、Dreamveawer中模板的概念，熟练掌握模块可以大大提高原型设计的效率，并使原型易于管理维护。

组件的复用是axure默认传达的第一个复用原则，axure内置有基本的Web组件和流程图组件。当然，axure还提供了更高级的组件复用——自定义组件库。在Web设计中，为了保持一致性每个系统模块都会有大量的重复设计出现，如按钮样式、链接样式、表单样式、Tab页签样式、翻页样式、图片大小、输入框交互等等等等

Axure的自定义组件可以使用有心人制作的，比如官方提供的基于雅虎风格的Web组件套装和mobile原型设计组件(下载地址)、比如有个牛逼的老外制作的2套Web原型（下载地址）；也可以自己在项目过程中自我总结创建。

在控件面板中点击下拉菜单的“Create library”（创建组件）选项，这时会弹出一个保存对话框让对这个.rplib文件进行命名和保存，Axure会立刻启动另一个执行程序并打开这个刚建好的 .rplib文件。

在新的Axure程序界面中，原本站点地图面板的位置会被组件库面板(Widget Library Pane)所取代。你可以像处理页面一样对组件进行新增、删除、排序。

Axure启动时，如果已经把创建好的自定义组件库(.rplib文件)放在Windows文件夹的―我的文件> My Axure RP Librarie目录中，则该组件库会被自动加载到控件面板中。另外，你也可以手动选择你所指定的 .rplib 文件进行组件库加载。新建立的自定义组件库的操作方式就如同其它的默认组件库一样，以拖放(Drag&Drop)的方式将组件放到画布上进行画面的绘制。

虽然自定义组件和模块都基于组件的组合，但组件与模块的区别在于，组件是针对Axure存在的，在所有基于axure完成的页面中都可以使用该组件；而模块是基于某一具体的axure页面存在的，仅在该axure文件下可以使用，如果打开新的axure文件则该模块不存在了。模块针对某一具体项目以单个axure文件为单位组合复用；组件针对所有axure文件为单位组合复用。

模块的复用常用于在某个产品模块中会重复出现的情况下，如展示商品的列表、未登录的弹层、页面头部、导航、页面底部等等。共同的特点就是，在该产品模块下都需要且表现形式都一样。也就意味着如果要修改就得全部修改，如果出现就要不断的“CTRL+C”在“CTRL+V”，由于这些组件并不是单一的，如果是复制的话很可能复制不全，即使你使用了组合。模块则可以很好的解决这些麻烦。

模块有2种制作方式：在页面中框选住需要转发的组件，右键选择“转化成模块”；在左侧导航部分选择“Add Master”（添加模块）进行模块制作。在实际操作中个人觉得第一种方式应用更多，因为肯定是先在页面中进行了全局设计才知道这些组件是可以转化成模块的，有一个全局的考虑先。

模块有以下3种行为：

• 普通行为（Normal）：模块可以被移动与放置在线框图中的任何地方，对模块所做的修改会在所有模块实例中同时更新。

• 背景行为（Place in Background）：模块应用在线框图中时，会处于线框图的最底层并被锁定。模块实例中所包含控件的位置与在模块中的位置相同，常用于作为模板、布局、底板。

• 自定义控件行为（Custom Widget）： 模块应用在线框图中时，模块实例中的控件与原模块失去关联，模块实例中的控件可以像一般控件一样可以进行编辑，就好像只是进行了复制和粘帖操作。常用于创建具有自定义属性、注释和交互的自定义控件库，例如：具有白色文字的蓝色按钮。

使用一个工具并把它用透，比使用多个工具但每个工具都会使用一点要高效的多。别去追求炫目，追求效率，这是俺在使用工具上的一点小感悟，记录如此。

首先，关于“返点”的相关介绍请参见前文“返利返现返点如鸦片”；其次，关于比较购物市场的问题请参见前文“依旧蛮荒的比较购物市场”；再次，围观相关比较购物网站请参见前文“扫站：比较购物网站列表”。

当电子商务的商家越来越多之后，出现了一种利用意见领袖进行品牌传播、成熟网购用户的消费引导的网站，通常我们叫做购物返点。再之后是电子商务商家商品同质化严重，商家以价格战取胜，用户没有忠诚度可言，这个时候出现了一种试图帮助用户挑选最低价的网站，通常我们叫做比价站。返点站与比价站大多数是重叠的，或者是进入市场的时候同时存在这2个概念，于是很多比价站是先有返点业务再做比价业务的。

不管是“返点、返现、返利”还是“比价、比较”从本质上看其实都属于导购站，只不过返点是以商家为单位进行导购而比价是以商品为单位进行导购，他们都是在帮助用户做出购物决策。

当之前以返点为主业从商家线进行导购的网站进入到以商品为线做导购的时候，必然就会存在一个问题，作为比价的商品是否也可以直接返点？从用户的行为上来看，这个是必然的，先搜索再比价再返点；从网站方来看这种做法无疑是将购物返点化整为零了。所以，购物返点成为了比价网站的标配，“比价”+“返点”的形式奠定了中国比较购物的一个很奇怪的模式。因为，没有人考虑商家的感受….

我们再来说说导购，就是帮助用户做出购买决策。决定一个用户是否要购买的因素有很多很多，不过其中比重较大的几个会是：价格、商品自身的好坏、在线商家的信誉与服务、好友的推荐等。

目前来看不管是B2C商家还是用户都被教导成了纯“价格导向”，用户只认最低价（商品价减去返点所得）。但是，从长远来看真是这样吗？我觉得需要思考。

购买者与要购买的商品之间其实是一个“契合”关系。就是要看这个商品自身的属性是否与他心理的预期最契合，这个才是最核心的一个导购因素，其次才是价格。价格仅是购物决策的一个条件，既不充分也不必要。在线购物与线下购物的最大区别就在于我们无法真切的感知到这个商品的质量如何。在线下我们可以试穿，可以触摸，可以品尝，但是线上这一切都不可能，即使3D试衣间也无法解决这个问题。

那么，线上的这种感知来源于什么？是其他用户的现身说法，是身边朋友的推荐，是第三方机构的说明，也就是我们常说的“口碑”、“点评”。

这种基于商品的点评必须是需要由第三方来完成，这样才是更有说服力的。这个第三方平台不仅仅需要有对商品自身属性（优点、缺点、最佳用途、适用人群）的点评，同时也需要有一个对商家属性（支付、配送、售后等）的点评。这样，基于商品的导购和基于商家的导购就形成了2条横线，而点评就是一条贯穿其中的竖线，形成了一个强力的可以保证用户做出购买决策的系统。

当然，形成一个基于商品的第三方点评平台是需要足够的耐心和足够优秀的运营团队来操盘的，所以很多导购平台开始退而求其次的使用“聚合”点评的做法。依靠抓取其他B2C商家、资讯站等网站的站内点评，然后做出聚合来达到点评的目的。

不过，即使是这样我还是认为应该自己做点评，做好自己的点评是一个从长远而言更有意义的事情。基于自己的平台产生内容不会受制于人同时做大了第三方平台之后的收益是相当客观的，更重要的一点在于自己做点评可以产生关系，而基于关系的推荐才是转化率最高的导购！

总结一下，当购物返点已经和比较购物生下了怪胎之后，返点成为引导用户做出购买决策的一个诱饵，但是，更大的诱饵应该是基于商品自身属性的点评和基于有货商家的属性的点评，还有就是基于口碑的社会化推荐。价格一定不会成为决定用户是否购买的最大要素，最大的因素只能是信任、是服务、是关系！这也是所有B2C商家正在努力的事情，未来的电子商务是社会化的。

还有一点需要提醒的是，做导购或者叫比较购物，必须要撇开淘宝等C2C平台，和B2C一起玩。

平台都是趋于垄断的，一旦实现大统，站内搜索将代替通用搜索成为用户入口，C2C购物搜索失去意义；B2C的专业化特性决定了该领域必将产生众多的细分品牌，其商家及面向终端用户的特点，将带来足够大的用户需求和足够多的商家选择。所以，比较购物的成败与否在很大程度上也取决与淘宝与B2C之战的结果。

多说一句，看大淘宝的策略其实淘宝想把自己搞成B2C了，淘宝就是要把商家以及商家的商品不断的push给消费者；而导购站实际上是C2B，把消费者不断的push给商家。

线报：以淘宝自身产品库为标准库，抓取B2C商家以及资讯站的点评为填充，辅助以淘宝自身点评（site.taobao.com）的淘宝牌站内比较购物“s.taobao.com”已经上线了（示例）；同时拍拍也采用了相同的做法（示例）；而百度有啊更是在1年前做出了2个类别的标准库，采用了跟第三方网站合作的方式导入点评信息（示例）。如果你稍微对电子商务有一些了解和敏感，你都不用想就知道s.taobao.com的转化率肯定要比淘宝大搜索的转化率高…..

我一直对社区和电子商务感兴趣并不断的去学习和了解，现在来看应该再加一个移动互联网，合起来就是移动互联网上的社区电子商务，哈哈，牛逼吧…..呃，不过话说回来，手机上的比较购物与Pc上的比较购物确实有很大的差别，稍后再写。

前段时间千鸟写UCD概念在中国系列的时候，我跟他说你可以写个“产品经理在中国”，千鸟说这个事情太复杂没有经历去搞，等有时间的。于是，我一直期待到现在我想表达一下我自己理解的产品经理了……

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是Product Manager，中文翻译为产品经理，简称PM。我试着从这2个缩写字母来理解一下目前的产品经理流派。

1、产品的经理。P：Professional，专注于做（Design）；M：Management，专注于管理。
2、产品和市场。P：Product，产品设计层面；M：Market，市场运营层面。

第一种流派是目前几个大公司的产品经理流派，每个产品经理最终的发展方向不一样，有专注于设计的有以管理为方向的，然后P1、…、P12，M1、…第二种是我自己杜撰的，基于我自己的理解，个人为人第二种缩写的解释会更适合我理解的产品经理。

产品经理是永远从需求出发的立足于产品的有良好运营思维并擅于团队作战的狼首领。

记得早前在微博上有一条关于产品经理的微博流传甚广，被转发很多次，我是这样回复的：“我们只是：开发里面最懂UI的；运营里更注重用户的；战略中比老板更知道从细微着眼的；销售中比运营更了解产品的；比谁的权利都低但比谁都会运用权利的；产品做好了最容易被遗忘的那个小人物”。这是我对我理解的产品经理的第一次概括。下面详细说下

1、产品经理首先必须要对所从事行业充分了解，先是行业专家。深度了解这个行业的用户行为、行业规则、行业特点，或者至少是资深用户，才能培养自己的同理心，才能把握住整个产品的发展方向，最终去做产品。

2、产品经理是个立足与产品有运营思维的人。之前我说，产品设计师都是自负的，他们思考问题的方式在于这个事情应该是什么样子而不是他现在是什么样子；工程师同学永远都会先考虑功能实现然后考虑是什么样子；而市场运营同学考虑问题在于老板给我的预算额度是一定，我怎么分配这些市场费用能够达到收益最大化。所以，产品经理同学就必须兼备以上的思维，在做某个决定的时候同时“人格分裂”的从这三个方面考虑一遍。

在产品团队中，产品经理必须时刻记得问自己这样几个问题：我的核心用户是谁？他们在什么情况下有这个需求？这个产品的目标与期望值是多少？并且，要让整个团队的人都有问这几个问题的意识。需求，永远都是最根本的，如果产品经理搞不清楚这个事情，那么交互设计、视觉设计、工程师都会跟着错！产品经理草率的告诉交互设计师说我们需要上一个某某功能，交互设计师有责任有义务询问产品经理，为什么要做这个，给谁做？然后才是开始去做设计！否则就只是个工具。

3、产品经理要在团队中扮演寻找满意解的角色，而不是最优解的角色。如上图所示，产品设计、市场运营、工程技术3个部门关注的产品的点是存在重叠的，而产品经理就是去发现这个重叠的部分并很好的利用这个重叠的人。

满意解的意思在于，产品经理是基于“权益”的标准来进行团队沟通的，而不是基于权利或者权力，这个解需要平衡团队所有成员的权益。所以，我一直认为，“马化腾、史玉柱等是中国最好的产品经理”的说法是有问题的，他们应该被叫做“拜用户教”教徒以及“UCD型Boss”，他们算不上产品经理。

4、产品经理的核心技能在于沟通与控制。团队以及合作的观念必须时刻具备，当团队里每个人都受到鼓励、赋予了权利并且被尊重与信任的时候，团队就会有最理想的表现。从另一个层面上看，以团队意识为核心的结果往往会是没有核心，平衡了各方的利益之后，往往把本来最有利的部分完全抹杀了，敢于拍板和为自己的决定负责对产品经理来讲很重要，也就是要讲究控制，或者按照百度的话说叫做“和多数人商量，听少数人意见，自己做决定”。记得之前有位前辈给我推荐过一本书《只有偏执狂才能生存》，受益颇多。

你可以有某个领域不会，但是，你要有能力指使会的人去做。当然，也有必须什么都去做的产品经理。我把国内目前的产品经理分为两个类别：有UED支撑的产品经理（雌雄异体）、全能型产品经理（雌雄同体）。在有UED支撑的情况下，产品经理不太需要去关注产品具体的设计细节，产品经理更加偏重于如何去沟通，去解决问题；而没有UED支撑的产品经理更多的在于学会如何最大限度的利用资源，由于从设想到实现几乎都是一个人来做，所以，偏颇在所难免，寂寞是产品经理最要命的敌人。

5、产品经理一定是最爱自己产品的那个人，并且，我觉得只有自己一个人爱是不够的，同时还需要让整个团队的成员都植入这个观念。这种爱不是溺爱，我觉得有2个方面：擅于且敢于主动的自我阉割，开放的心态接受一切批评意见；不断的向大家介绍你的产品，并推荐之。为了爱产品需要有狼性，如我在微博上所说，产品经理应该明白，资源是靠“打砸抢”得到的，别指望别人施舍；社区的运营与产品设计者也应该明白，要做好社区就必须要有铁血政策，特别是在一个充满刁民的社区，当然，对部分意见领袖的怀柔也是必须的！

6、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。

没开始写之前我觉得我想的挺明白的，可是写着写着发现这些话好像是直接对我微博上说的过的话进行总结与摘抄，然后再读一遍发现好像都是废话…..不过，好吧，也许最难做到的就是那些正确的废话了，我还是记录下来了，我会不时回头看看我走过的路我思考过的痕迹的

从半只脚迈入产品经理这个大门的那天起我就被2个文档的名称深深的纠缠着，他们是市场需求文档（MRD）、产品需求文档（PRD）。先不论你是什么方向的PM，这2个玩意一定会一直伴随你的Title跟着你。这2个文档在不同的团队中有不同的叫法和写法，我也见过有团队的MRD其实就是PRD，不沾半点商业市场分析的边的，当然，这些不是本文探讨的内容。

长久以来，有个很有趣的现象：“有没有PRD模板，PRD该咋写”这个问题已经成为新手入门经典必问题目之一；如果1年以后这个家伙还在这行里混，他一定会抱怨，娘滴，我们的QA压根就不看我的文档、我们的交互（如果有这个职位的话）还是会问我一些我写的很明白的问题、我们的测试拿着文档问我该咋测试、….

Web页面之间的关系是网状的，而Word文档只能树状的表述，这无疑是矛盾的；PRD文档无法做到实时更新发布，我回顾了我第一年写的PRD文档，很多下面的修改栏都是空的，惭愧之至….；所谓一图胜千言，万言刚够文档标准，每个PRD都是臭长臭长的，这样的东西别说交互设计师了，很多PM自己写完了都不想看。所以，我武断的认为，撰写某些PRD文档实在是一个既耽误时间又费劲且不敏捷的事情（很多PRD都是一夜情，写完了就不会修改更不会有人乐意看100P以上的文档），是在让产品经理实现慢性自杀！

个人认为，一个PRD文档需要包含以下的内容：

1、概述
1.1、名词说明：文档中涉及到的名词
1.2、产品概述及目标
1.3、产品风险预估
1.4、产品开发进度：产品开发阶段及责任人与时间节点
2、使用者需求
2.1、使用者需求描述：定义用户是谁
2.2、管理员需求描述：后台管理部分（很多人会忽略这个部分）
2.3、任务流程图：从业务逻辑流程到产品逻辑流程转化
3、功能需求
3.1、功能总览
3.2功能需求分解：界面分解及交互说明和用例
4、非功能需求：与该产品相关联的辅助产品等
5、上下线需求：产品的生命周期
6、运营计划：产品的上线后的反馈与改进

整个文档中，最大的部分其实是对功能需求的分解，但是最核心的部分是使用者需求与功能需求部分。使用Axure后，我发现Axure可以很好的承载我平常写的这个产品需求文档的全部内容，最主要的问题是，Axure是可以网状的展示的。下面是举个例子：

在Axure的站点导航中，默认的Home页面承担了PRD文档的第一部分内容；而使用者需求描述及任务流程图也可以由Axure自带的流程图功能完成；任务流页面的分解本来就是Axure中完成的；最后的非产品功能部分也可以由axure完成（文本块组件）

同时，Axure支持多种格式的输出，一般情况下我是发送给团队Html文件包，也可以是.chm格式的文件（团队协作目前还没有尝试）。该文件包打开后，左侧是整个系统的导航菜单，右侧是相应的说明。最主要在于，原型中的页面是可以相互跳转的（得益与axure的强大交互功能），同时页面有注释功能。所以，整个产品需求文档真正实现了基于产品的模拟，网状的传播，而不是Word式的树状阅读。

1）见过不少新手使用Axure生成的原型有页面是空白的，我问为什么，他说这个页面不知道放什么，但是又不能不命名，否则逻辑上有些不通。实际上，这个空白页面就可以用来放这个页面的流程图及整体的说明。

2）不建议做太复杂的Axure动作，比如使用多个层、动态面板等。因为在工程师等的眼里原型图是不可以点击的（基于viso等的惯性思维），所以，为了避免花很长时间去实现一个很炫的axure交互而最后被埋没，建议把任务分解来画。比如一个输入框，需要画：默认状态、获得焦点状态、输入字符判定状态、失去焦点状态等，按照逻辑分步来展示。（在我特别蛋疼的时候我会先分步展示，然后搞个比较炫的交互放在上面自己玩或者用于演示）

3）在每个页面的下方或者侧边（由页面大小来定）要放一个功能详解的文本块来对本页面的功能进行详细说明。也可以直接使用Axure自带的注释功能（组件注释、页面注释）为什么不推荐用Axure的组件注释功能？因为这个功能在生成的原型里是被隐藏的，有被人无视的可能。

4）使用axure的组件库功能（可自制）和模块功能既可以保证设计的统一性（设计规范），又可以提高原型制作的效率。图中我采用了注册模块。

下面，QA时间（这个QA是问答，文中的QA是技术，呃，注意区分）

Q：为什么我看到有的书上说要写N多文档，带RD的有：BRD、MRD、PRD、….
A：是的，有这样的定义。BRD（商业需求文档）、MRD（市场需求文档）、PRD（产品需求文档）。每个公司的风格不一样，我个人倾向于把BRD与MRD整合，PRD单独做。但是MRD与PRD中会有内容重合，就是会同时提到用户是谁？为什么要做？产品目标是什么？等几个问题

Q：Axure有个功能是可以导成Word格式，把做的原型导入后是归类好的，包含了用例文档，为什么不这么玩呢？
A:没人说不可以这么玩。还是那句话，个人习惯。

Q：除了页面原型之外你塞了这么多东西到Axure里，会不会导致源文件以及生成的文件体积巨大？
A：实际上塞进去的东西都是文本，使用axure的文本组件完成的，体积并不会大。同时，请不要在用axure做原型的时候使用过多的图片，尽量是用组件和模块完成。我目前位置做的最大的一个原型是4.7M，这是一个完整的系统原型。

Q：按照你的写法Axure好像是万能的了？
A：没有不好用的工具，只有用的不顺手的人。人是活的，工具是死的，且Axure目前在mac平台下功能并非很强大，也有很多人觉得axure很笨重，更加喜欢轻量级的原型功能。不过，这些都不是核心问题，核心问题是要让你的团队能够以最高的效率进行合作。使用Axure的人不必鄙视Viso，用excel的人也不必羡慕OmniGraffle，拿Word的人也不必留恋firework。

既然提到了MRD也顺便说下我写这个文档的习惯。一般情况下这个文档是给老板看的，主要是对市场的分析、同类产品的竞品分析、我们产品的盈利预测等等。所以，一般由PPT来完成。你的文档越长老板越反感，你的文档文字越多老板越没兴趣，所以，PPT是最好的方式。

文档这个东西跟流程有类似的地方，大公司会相当重视这个事情，因为要规避风险。流程与文档的核心点在于如何高效传递如何快速执行而不是他如何写以什么形式写。相对于小团队而言，流程之殇大可避免。当然，如果大公司能够以小团队的心态去做大产品的话，定会事半功倍！我更相信小团队大产品的力量，而不是大团队大产品的说法。