当然，我并不是从一开始就使用微信的，所以，在回答这个问题之前我特意去查了一下微信的发家史（见本文最后）。然后，我惊奇的发现，微信其实是个定位“摇摆不定”的产品。1.0版本，微信定位于手机端文字通讯工具；1.1版本开始加入插件，基本冲着通讯中心去的；2.0版本开始往着多媒体通讯工具发展；2.5版本开始是陌生人交友；3.0版本后被官方重新定义为一个生活方式…..

然而，一路走来，不断的迭代不断的发展，这个产品的受众范围越来越庞大，价值也随之增加。过年的时候惊奇的发现一个年近50的叔叔使用着微信跟儿女沟通！我同时也在微博上翻到了微信刚出来的时候很多专家的评语，太垃圾了，连抄袭(kik)都抄不好。不知道现在他们转身再看自己当初的微博的时候是什么感觉？

对了，提醒一句，微信最开始的时候并没有导入通讯录而是一直依赖QQ自身的关系链、用户公司邮箱、微博等去导入用户关系的。第六个版本才开始导入通讯录。

好，言归正传，回答知乎上的这个问题，说说我理解的微信的产品亮点。

基于一个迭代了数个版本的产品去转身看他的亮点，完全算是一个用户的个人感受，算不得什么评论或者其他的。在我看来的很多亮点也许并不是设计者的初衷，很多亮点也许是当初误打误撞出来的也不是不可能。所以，以下观点我纯站在一个用户的角度去感受。

1、对性能的极致追求

在微信的前3个版本的版本介绍里都有这样的一句话，“为了保护您的隐私，微信不会自动扫描和上传您的通讯录。并且不透露信息是否已读，降低收信压力”，这段话直到1.3版本的时候才取消。其次，在低网络环境下，相对于其他App，微信更坚挺。同时，微信对图片的压缩也很值得称赞，可以将图片压缩到很小的KB但是质量却损耗很少。另外，曾经有人对比过米聊与微信的流量消耗，微信胜出很多。

以上的例子只是想说明，性能是微信的第一大亮点。因为我一直坚定的认为，在移动互联网中，应用的性能是最重要的用户体验，就像在电子商务中，系统与服务才是最重要的用户体验一样。在较长的一段时间内，中国的移动互联网用户依旧很在乎流量的消耗，在一段时间内，移动设备的性能仍然是移动产品一个较大的限制。

2、插件系统

微信从第二个版本开始就有了插件系统（早于语音及附近），我认为这是它最霸气的地方之一。这个插件系统最早是支持腾讯微博的私信，后来是QQ邮箱、QQ离线消息、语音记事本、….猜想一下，这个插件系统最早是奔着通讯中心去的，先拿自家产品实验，成为一个移动端的消息中心，也就是微信的第二个定位点。

不过目前这些插件还都是自家的，请允许我继续猜想一下，在不久的将来微信会把这个插件平台开放出去让第三方插件进来，比如附近的优惠、餐馆、酒店、出租车。那个时候，微信就真的是一个生活方式了！

3、群聊，尤其是语音的

微信在第三个版本加入了文字群聊，随后的第五个版本里增加了语音群聊功能。语音和语音群聊的功能是微信一个比较大的突破，引发了真正意义上的用户爆发。

在我个人看来，QQ群和微信群聊都是在满足同样的需求，只是因为平台和工具不同最终实现方式不一样罢了。在移动端微信采用这种方式丰富和简单化了人与人之间的沟通，同时，也让群体的隐私最大程度获得保护。群聊开放之后，我的关系群绝大部分都转移到了微信上，老盆友之间的叙旧与扯淡，新朋友通过语音交谈快速认识与融入。

4、查看附近的人和摇一摇

这2个功能出现在第八个版本和第九个版本，应该是微信的另外2个爆发点。都是充分利用手机自身性能实现产品功能的手法。

值得一提的是，在摇一摇这个功能上，微信增加了很多人性的因素比如来福枪的声音和断背维纳斯并包装成一个大的产品人情味的卖点去宣传，收获颇丰。

5、个性签名、小游戏

个性签名其实是跟附近的人一起出来的，最早出来的时候是只有个性化头像的。把这2个和小游戏放在一起，是因为这3个都是降低陌生人之间勾搭的门槛，俗称破冰。

好吧，问题回答就此结束。微信还在继续迭代，我作为一个用户还在继续使用。在我看来，微信是一个迭代出来的生活方式。微信的起步看起来姿势很难看，但是走起来了之后就越来越有感觉，最终越走越好。事实上，很多产品都是这样的，所以，千万不要轻易对一个还在襁褓里的产品下定断。

在准备结束掉这篇有着强烈的捧臭脚和马后炮感脚的文章的时候发现微信更新到3.6版本。插件系统新增了腾讯微博推荐、腾讯新闻推荐、直接微信回复邮件。还是在继续的整合自身产品，继续其他第三方插件的进入。

另外，3.6版本的微信支持撤销正在说的语音功能，挺不理解的。这个问题之前跟人争论过，我的观点是这种本质上通讯的产品应该不支持语音撤销，就像发出去的文字无法撤销一样，因为消息要“即时”的，而说错了的语音消息会让沟通更符合沟通本身。

最后，附上微信的版本迭代历史（以ios为例，截止到3.5版本），另外，其实微信有一些小的版本，主要是修复bug，没有在此列出。数据来源：微信官方。

导航始终是产品设计的重头戏，往往产品设计中90%的事情就是在做导航。在iphone中预置了3种可以直接使用的导航模式，平铺列表、标签页、树状结构，每种模式都配有不同的工具栏和控件。三种导航模式可以独立使用也可以混搭，让你的用户可以优雅的穿行与你的应用之中。

（图片来源：Tapworthy）

平铺列表

这种方式主要用于只有一个主屏的简单应用。这种方式很适合浏览并发现类的应用，因为他的信息架构简单到极致，没有信息层级也没有组织结构，就像一叠卡片一样。主要信息在卡片的“正面”展示，“反面”就是简单的设置，向左右滑动即可翻页，典型应用比如内置的天气应用。

当然，平铺列表式导航也可以根据你的需要随意的添加、删除卡片。从某种意义上讲，他的扩展性优于标签页式导航，因为标签页模式中类目与顺序都是固定的。

在平铺列表模式的页面底部都添加了页面分页控件，其表现为一排小圆点。小圆点的数量代表了平铺的页面的数量，而高亮的小点则是另外一种形式的导航，他显示了当前所在页面的位置。同时，页面分页控件也是可以操作的，点击控件的左半部分或者右半部分或者直接左右滑动可以切换上一个/下一个页面，不过，页面分页控件每次只能翻一页，而不是直接跳转到某一页去。一般而言，页面分页以不超过10个为最优，超过了20个就会溢出屏幕了….

另外，为了更好的表达”卡片堆“的隐喻，最好不要在平铺模式下设计多个不同的滑动手势。在触摸屏上大家都能在单一方向上进行滚屏，但是2个方向的滚屏需要更好的精度，这种做法有些挑战人机工程学了。

标签页

在ios上标签页一般依附在屏幕的底部，标签栏将应用功能一一归类，点击一个标签就会跳转到相应的页面上，然后该标签以高亮的形式表明你当前的位置。在标签页模式下，每个标签对应的页面都可以有自己的界面风格和特定的内容与功能，看起来就像是在运行一个独立的应用。

标签栏的高度是49像素，每个按钮都会包含一个文本标签和图标，按钮的宽度取决于放置按钮的数量，标签栏限制最多可以放5个图标，超过之后会在第5个按钮的位置出现”更多“的标签。

当然，标签栏以49像素的高度存在其实占用了不少的屏幕空间，所以在某些情况下可以适当的去掉标签栏，典型的就是图书类应用的全屏阅读模式。

树状结构

这种模式简单来说就是将层级信息分类到一棵倒置的树枝上。这种导航模式很适合列表，点击列表中的一项可以看到新的列表，列表可以再进行分拆，直到进入项目的详情。树状结构的一个变形就是表格视图，也就是我们常说的”9宫格”，这种变形更加的图形化。

当然，根据信息的不同，树状模式中的标签也可以进行分组。一个树状模式可以分为若干的组，每个组可以包含任意数量的行数。

3类导航模式的比较

导航模式的组合应用

平铺列表、标签页、树状结构3种导航模式并不是互斥的，完全可以在一个应用里对他们进行混搭。这种混搭可以帮助我们克服单个导航模式的短处。

模态视图

我们经常会遇到在某个路径中滑出一个单屏、进行编辑、查看信息、操作界面的上的内容的情况发生。这是一种应用行为的特定形态，一般带有流程的界面变更的情况发生，比如一张页面临时取代了整个应用程序的显示屏，我们称这种处理方式为“模态视图”。默认情况下，模式视图从屏幕底部边缘滑上来切一半覆盖了当前整个屏幕,模态视图完成和程序主功能有关系的独立任务，尤其适合于主功能界面中欠缺的多级子任务。这种操作会暂时绕开应用的正常操作。

模态视图常常被用来编辑或添加内容，当你需要的时候模态视图一般从屏幕底部滑出而后遮盖先前的页面，当你完成任务后滑出的页面也会相应的缩回去，然后可以继续之前的流程。有些控件和界面元素只在次要任务中被偶尔用到，模态视图很好的把他们暂时隐藏了，并且当需要的时候出现，有效的节约了屏幕空间。

模态视图有点像是导航中的死胡同，为了能够让用户也可以同样方便的回到正常的流程中去，模态视图除了正常的操作之外一般还有加上一个“完成”按钮，或者“取消”按钮。

最后，一个移动产品设计的礼仪问题

当用户从你应用的一个地方跳转到另外一个地方再原路返回来的时候，应用应该主动恢复到他上次离开的样子（千万不要重新加载，你懂的！）。这玩意学名叫状态恢复，这种保持不变的礼仪对移动产品的体验来说相当重要！

曾经有个朋友问我，从Web设计到移动产品设计你感觉最大的差异点是什么？我觉得，最大的差异点在于用户使用场景的变化，场景的变化引发了交互方式巨大的变化，从而也使得信息呈现方式有所不同，再加上硬件设备的差异，最终使得2者千差万别了。所以，移动产品设计之设计应该首先从用户的使用场景出发，同时考虑用户的硬件设备差异，综合以上2点去帮助用户完成某个任务。

当然，从生态系统的角度而言，移动生态系统也是迥异与互联网生态圈的。移动生态系统可想象成拥有许多层的系统，每一层都依赖于其他层，他们相互依存构成了无缝的端到端的体验。

运营商在最底层，他们是移动生态系统正常运作的基础，他们负责基础设施建设并维护与用户的关系；运营商运营着无线网络，而网络能力同时也受制于设备与与天线的类型；而由于不同设备对工业标准解释的不同直接早就了移动生态系统最大的挑战，移动设备碎片化；软件与服务要在设备上运行就需要有平台，移动平台主要分为授权平台、专有平台、开源平台，其中我们熟知的有Java ME、iphone、Balckberry、android等；移动平台通常是与他所运行的操作系统绑定在一起的，比如symbain、Windows Mobile、ios、android；而开发者通常能够访问到的就是这些平台的应用程序框架并以不同的语言来开发应用程序。

在移动产品设计的过程中我们也会经常有意无意的涉及到生态系统的某个层面，而哪怕用户只想在移动端做极其简单的事情比如“访问我的博客”，都必须通过这些层，所以，这导致整个的移动环境十分复杂，整个移动产品设计需要具备的能力与素质也相对更甚。

移动产品设计之使用场景的变化

（图片来源：Tapworthy）

没有了舒服的人体工程学座椅，只有拥挤的车厢或者顶着烈日的街头；没有了灵活的鼠标和舒服的键盘，只有晃动的屏幕和方寸间的按钮；你不再是一边放着歌一边刷着网页，而是希望能够迅速的找到你想去的那个店铺；你也不会成天挂在线上，而是会经常担心这个月的流量是不是又超标了……

这种场景的变化呈现给我们的是用户在移动设备上不断的碎片时间的消耗，用户越来越没有耐心。这看起来挺糟糕的，可实际上也是好事，这种使用场景的变化会迫使你放弃做类似Web端大而全的产品设计的想法。相反的，你会聚焦去解决用户在某一个碎片时间段里的需求。这种更聚焦的“单核思维”需要贯穿与整个移动产品设计中（详见：更多的限制，更简单的设计）。

移动产品设计之设备的变化

你的用户会使用什么样的设备来访问你的应用？这个问题是每个设计师在设计最初需要思考的。你的用户所使用的设备需要从多个维度去考虑，如操作系统、使用的网络环境、设备的分辨率等，这些信息都必须被综合起来考虑，最终运用到产品设计中去。对没错，这就是移动产品设计中臭名昭著但又很好玩的“适配”。2个同时使用android手机的人在使用同样一个应用程序的时候可能体验是天堂与地狱的差别，而即使同样都使用iphone但是在不同的网络环境下体验也不一样。这些，都需要去考虑…..

当然，这里有另外一个问题我觉得可以探讨一下，那就是不同平台直接的设计借鉴与移植。我的感觉是ios与android完全可以按照同样的一套架构去设计，只是在具体的交互方式上按照不同平台的特性去做就OK。比如同样是删除在ios上是左右滑动在android上是长按。

另外，这种硬件设备的变化也是移动产品设计与Web产品设计一个很大的差异。在移动产品设计上，一定要充分利用设备本身去完成设计。相对Web产品而言，移动设备自身提供了很多硬件能力，比如光感、磁阻、陀螺仪、….对这些能力的运用是移动产品设计的起点（详见：移动产品设计之硬件能力）。

移动产品设计之交互方式的变化

整个移动产品的的交互过程可以概括为，用户触发某个任务跟客户端发生交互，客户端将该任务反馈给服务端，服务端向后端请求数据并做数据拼接同时反馈结果给客户端，客户端将最终结果展现给用户。当然，某些复杂的任务实际上需要客户端向服务端并发数次的请求。

考虑与服务器端的交互并不是移动产品设计所独有的，但是却是移动产品设计过程中最需要设计师去“设计”的交互。因为这关乎3个事情，对用户流量的消耗和用户操作的流畅性，同时也是对客户端性能的一个考验。 这是我认为目前移动产品设计的用户体验最重要最根本的地方，保证客户端性能的稳定性，用户可以在低网速条件下顺畅的操作，同时尽可能的帮助用户节省流量，而UI层面的体验问题反倒是其次的。twitter和foursquare不论是在ios和android甚至symbain上都没有花哨的界面，但是他们仍然是我心目中当之无愧的最优秀应用。

同时，从键盘机到触屏机再到多点触控甚至于目前的语音助理，我们发现移动端的人机交互方式在不断的演进。于此同时我们也发现，越是高端的移动设备用户的“惰性”反而越强，用户期望能够使用更低成本的交互更快速的完成任务，这也是移动产品设计必须要面对同时也是移动产品设计师最能有成就感的地方。

最后，单就手机端产品设计而言，对于移动平台的选择

iphone这2年的势头太猛烈了，加之推广渠道单一产业链相对完整，所以iphone客户端的设计、推广都很容易见效且效果巨大；android太过开放，直接结果就是渠道纷繁复杂但无一能处把控之势，所以推广费力且收效甚微，小团队可以在开辟完ios战场并有成效之后果断跟进；symbian？如果可以，迅速放弃吧！WP7势头可观，但目前不太适合小队伍入场，大团队可先做储备。

1年前我曾经写了一篇《我理解的产品经理》，当其时深洋洋洒洒数千言以充满理想主义的呐喊居多，也没有什么体系，只是想到哪里就说到哪里，虽说法都无甚错误但是总觉得落不了地….1年之中结结实实的锻炼了许多次，经历一个产品从无到有、从上线后遇到瓶颈然后推翻从来找到一个新的方向。在这个过程中，有团队之间的磨合，也让自己学习到如何成为一个优秀的产品经理。今天写到这里，作为自己的一个成长记录吧。

产品经理的素质，从整体来看应该包括3个方面：对产品市场的感知与把握，称之为市场，占30%；对用户体验的追求与执着，称之为体验，占20%；对团队的驱动与节奏的控制，称之为执行力，占50%。三者合一，有虚有实，不断检验不断改进方能一举破之终有大成！

每个成功的产品都是特定时间段的产物，这个特定的时间段就是产品市场，在这个产品市场下，每个产品都以“独有的价值”作为驱动力。iPod的诞生与伟大就在于正确的把握了当时音乐市场的变化及技术的革新，而iPod自身的设计只是加分项而言，并没有起到核心的作用。一旦产品市场确定，就意味着找到了正确的航线，在这个过程中航道或有偏移，譬如忽左忽右，但只要始终以航线为中心，便不会有太大的问题出现。

一般而言，对产品市场的认知可以通过3个部分来把握，社会与文化的趋势和驱动力、现有经济状况与消费重点的转移、先进的和新兴的技术的出现。

当方向落定并不意味着就能成功，方向与目标始终要落地，体现在产品设计过程中就是对用户体验的极致追求，确保足够优雅的满足用户需求。可以认为产品市场其实是帮助找到用户的痛点，而对体验的执着即是对症下药。这个过程中，如何优雅的满足用户的需求却还是始终要围绕着“独有的价值”来做。优先满足大多数人的需求，之后再为少数人提供解决方案。

但是，产品设计从来就不是一个人的事情，也永远不存在英雄主义。一个产品的成功永远都是一个团队人共同努力的成果，哪怕这个团队再小。所以，上述产品市场与用户体验真正的落脚点其实是执行力，而执行力我认为是最考验一个产品经理道行的所在。如何驱动一个团队的兄弟又快又好的完成产品设计同时把握好节奏不断的快速迭代是一个产品成败之根本。

在这里有几个尤为重要的地方，让产品方向在整个团队得到认同，有计划有节奏的执行产品设计，灵活反应及时应对可能出现的问题与方向上的偏移。如果团队无法对产品方向达成一致必然不会使出全力，但是光有力道但是没有节奏往往会出现撞南墙的情况。

一个完整的产品流程简单来说就是，发现问题——分析问题——解决问题——验证答案的过程。在这个过程中，只懂市场无处着力，看似都瞧的透彻但永远只是看上去很美，多半会成为砖家；光靠体验容易被既得用户牵着鼻子走，往往深陷泥潭，要么成为理论派要么开始自我怀疑；兄弟同心其利断金，但是更多的时候问题不是出在断金上而是何处是金。唯三者合一方能大成。

三个部分看似简单，然每个部分拆开来讲都包含很多学问与技巧，每个部分也都有很多特有的门道在里面。以我当前的经历与能力尚无法领悟其十分之一，尚须继续努力修炼拿项目来磨砺与提高。

以上，为成长笔记，记录如此仅供自省自查。

关于文案的重要性

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

关于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词了….

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

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

1、需求分析阶段

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

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

2、需求第一次传递

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

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

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

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

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

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

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

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

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

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

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

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

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

我们看到无数的移动互联网前辈们说，移动互联网产品设计相对于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的机器会成为主流，但是，别忘了，那是未来。而，事实就是这样！

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秒后自动消失等交互上。

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

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

首先，产品经理是个舶来品，业界普遍同意的是这个东西源自宝洁公司。其英文说法是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、产品经理需要关注细节，但是不能纠结与细节。这点其实不用上纲上线，写出来只是警醒一下我自己。

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

长久以来，有个很有趣的现象：“有没有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是最好的方式。

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

小D：小Q，我需要一个没有籽的葫芦，能搞定吗？
小Q：葫芦是可以搞定的，但是，没有籽的目前无法搞定，不过，搞定是可以的，但是需要很长的时间。
小D：都是男人，直接点，我在一周内需要，能不能搞定吧！
小Q：这个很复杂，而且目前的工艺还不具备，所以，我实现不了。
小D：好吧，我早就听腻了，我要的是葫芦而已，你跟说其他的有什么用？

故事2，放心大胆的去挑礼物吧
小Q：小D，去挑礼物吧，拣你最喜欢的拿，我付钱
小D：好啊，我喜欢那个2K的兔子
小Q：不行，我只能花20块，重新去挑吧
小D不依不饶又哭又闹，事情变得无法收场了….

故事3，我们种苦瓜吧
小M：小D，小D，隔壁种了苦瓜耶，不少人去围观了，收效不错哦，我们也搞颗来玩玩吧
小D：呃，苦瓜不适合出现在我们的园子里，而且，来我们园子的家伙们不太适应苦瓜的味道哦
小M：为神马，为神马？为神马隔壁搞苦瓜就能火呢？再说了，等我们种了他们自然就能慢慢接受了，说不定能把隔壁的人拉过来呢
小D：……

故事讲完，聪明的你一定也能看出来了，这里小D是个典型的设计师、小Q是典型的工程师、小M是典型的市场运营。是的，就是他们，上面三个故事讲的就是他们三个之间的世世代代都无法理清楚的剪不断的纠葛。

在 传统模式的团队里，市场运营人员从市场的角度来分析产品概念：谁需要某种产品，谁会购买这个产品，产品讲如何被供应和销售，其成本是多少；设计师根据产品 的卖相（视觉）和人机工程学等方面的知识进行测量，设计师更注重的是某个事物应该是什么样子而不是它现在是什么样子；工程师则只会专心的考虑产品技术创新 方面的概念问题，以及开发的技术成本。在这样的产品研发模式下，各自独立的专业分工，不可避免的就是出现三个中心。这也是上面三个故事出现的根源。

首 先，我们必须承认上述分歧是天然存在的；其次，这种分歧实际上对产品团队是有利的，当然，这种分歧是必须要控制在工作范围内的，工作范围外的分歧必然会危 害整个产品团队的发展；第三，控制这个分歧的理念应该是“以用户为中心的设计（UCD）”，而具体执行的家伙应该是产品经理。

一般而言，解决团队的分歧会动用三种手段，分别是：权力、权利、权益。

以权力为基准的协商过程，简单说就是动用等级制度强迫别人做他们不愿意做的事情。其结果必然是产品相互间的矛盾，在协商中输掉权益的一方在今后的工作中往往会需求反击的机会，最终损害整个团队的运转。

以权利为基准的协商手段是运用各种已有的标准、和观点等来解决纷争。这里往往会有输掉冲突的一方，或者必须选择一种折衷的方案。虽然协商各方的权利在设计过程中都有他的地位和作用，但是这种方法得到的结果往往都是常规的，缺乏新意的。

以权益为基准的协商反映了与项目相关的每一个人所关心、期待和需求的事情。我们了解每个人的喜好和工作重点，找到消除障碍的权益措施，从而使所有人所有专业的权益得到兼顾。而更重要的一点在于，用户的利益也被考虑到其中了！

如果我们使用一种以权益做基准的协商手段为主、适当的时候结合权利基准、不得己时小心动用权力的团队协作方式应该可以得到团队效率的最大值。

所以，在一个团队里，我们应该鼓励任何人拿下面的问题去问任何人（注意，是任何人都可以这样问，特别是产品经理最需要被这样拷问！）：我们这个产品的核心用户是谁？我们是在什么情况下，满足他们的什么需求？这个产品模块的市场目标是多少？我们面临多大的技术难度？

最后，四个问题的答案必须的是理性的（有数据支撑的），而不是以“XX这样说”、“我认为”、“以XX的经验来看”。正确答案的格式是：“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”

1、从@YesKafei同学的微博看到的一张图。饭店的盘子等也经常有特别的设计，真是聪明绝顶的设计师。

2、Android耳机的一个小细节，在外侧只有右耳有个小标志，在对比的同时降低了用户的使用成本；同时，很多耳机只在内侧有R,L的标识，也就意味着戴耳 机前要先翻一下，用户使用成本太高…

3、每次看到这种柜台，坐下之后就会有莫名的压 抑感…..取材与交通银行

4、来自必胜客的点餐单，汤与饮品的记录方式采用了格线形式

UpData:有同学问我这个点菜单有什么奥妙，我解释一下：这个单子是负责记录客人点菜和负责上菜的服务员之间传递信息用的。因为披萨等是公用食品，所以不用细分到人，但是饮品与汤是每个人不一样的，那么在上汤的时候就需要注意了。于是这个格线正好可以按照座位的不同进行标注，解决了这个问题。我个人觉得这个方法是不错的，至少不需要再问下“这个汤是哪位先生的？”也不至于打断客人进餐了。

5、这是动车组上提供的杂志，这个贴纸其实并没有卷边。这种人工修饰的卷边效果至少有2个优点：吸引用户的注意，来源与真实的模拟的亲切感。在web交互设计 上这种做法其实也很常见

6、10点11分提交订单，10:43商品出库，14:48配送员出发，京东商城的这个速度确实牛掰。另外，这一排订单处理操作人的设计也确实够唬人，很震撼

7、这个，某组织的EDM邮件，这个退订链接的设置，绝对是故意的！

8、很多公共场所有摄像头的地方都提示：“图像采集区”，而光合作用书店的提示是“摄影中，请微笑”，赞！

9、北京四惠东某外贸成衣店，店门口的位置有个展 板，里面都是挂着这样的真人照片，下面标识出这件衣服的存货情况。该老板在淘宝有店。这种商品展示与营销的方式不错

有的时候想想，很多事情之所以珍贵或者说弥足珍贵就在于那敢于自我阉割的惊艳。

比如，爱情为何让人觉得如此圣洁，堪比金坚的爱情为何万世传颂，其根源就在于，当你选定了一个你爱的人之后，你的心里就再无法放心任何人，TA就是你心里的唯一，从那一刻起你想的就只是为TA了。换句粗俗的话就是，你为TA放弃了整个世界，阉割掉了所有的关于“爱情”的情感，你会去主动拒绝任何异性对你的诱惑。这是一种难能可贵的品质与需要极度责任感的事情，如果怀着这样的思想去经营爱情，那必是让人艳羡的。

说回到产品上来，之前记得我写过的一系列读书笔记中讲到“产品的机会缺口来源于不断对社会趋势（S）、经济动力（E）、先进技术（T）三个方面因素（SET因素）进行综合分析研究”，由这3个因素相互作用会出现很多的缺口。那么，当我们发现这个缺口的时候该如何处理？

个人感觉，想明白做什么不算什么，想明白不做什么才是真正考察一个产品设计者能力的地方。

按照我目前的操作手法一个产品从预感到机会的出现到最终上线会经过这样的步骤：间谍——（阉割）——演说家——（阉割或反阉割）——雕刻家——（阉割）——救火队员——（阉割）——打磨师。

简单说就是这样的：

»当预感到这个市场存在的时候，先伪装成用户潜入到这个潜在市场的目标人群中，观察他们，明确他们的需求。在这个时候数据的作用只用在告诉我这个市场预计有多大，但并不能告诉我用户的真正需求在什么地方，不尽信数据。

»获取到用户的需求，根据这个需求想到能够做出A、B、C3个产品来完全的满足他们，并获得市场占有率。对这些需求进行排序，与现有资源与企业战略目标做匹配。阉割掉那些对目前战略目标没有促进意义的，目前不做死不了人的，目前团队没有精力做的功能，实现第一步阉割。

»拿着被第一次阉割的需求做需求研讨，先做团队内部讨论再到Boss那讨论。这个过程中其实就是个演说家的角色，力求团队的人首先要达成一致目标，然后去PK老板，当然，这个过程中会有第一次被阉割掉的需求再次被提上来，抗住！（如果实在扛不住，那好吧，你可以试着弱化它…）

»根据团队明确的需求，进入产品设计与研发阶段。在这个过程中会有小部分的需求被阉割掉，源自技术的压力以及市场的变化。当在与技术部门周旋的时候，如果一个产品设计者在最开始的时候只做了一套方案，那就会永远被他们牵着走。善于与技术妥协是门艺术！善于妥协意味着原型必须是炮灰，而最终目标（核心需求）一定不能变化！这个阶段实际上就是个雕刻家的角色，小步慢跑，同时要调动资源，平衡利益。

»在产品进入测试阶段开始，需要准备与运营部门联姻了。告知产品的运作机制，产品的亮点与卖点以及怎么卖卖相比较好。同时，进入救火队员的角色，因为根据经验，每个新产品都会有个死角在测试的时候是不会被发现，每个产品都会有让用户痴迷而我们没注意到的地方，所以，如果产品上线不被用户骂，那只能说明产品足够差或者产品压根不被重视。这个时候，要顶住，如果他们骂，就努力让他们多骂一些出来，然后悄悄改掉。根据经验，往往骂声最高的用户也是最愿意为你做口碑宣传的用户。

»OK，现在上线了，但并不意味着结束，恰恰只是个开始，因为新的一个循环开始。这个循环我把他叫做养孩子，就像恋爱谈完了，婚也结了，孩子出来了….一个有生命力的产品是每天都会有变化的产品，当然，肯定不会是在前台，更多的是在后台的优化….

所以，我最近常常感觉，做产品设计，其实就是个自我阉割的过程，越是优秀的产品设计越是善于阉割。

在我憋着一口真气一鼓作气的敲完上面的字之后，兔子跟我说，你这不是教人犯错吗？我想，肯定会有人没看完就直接说，你的意思就是让人一直砍一直砍，砍到最后就只剩下个小裤衩了呗….

其实不然，这篇文章的核心不过一句话耳：审时度势，在正确的时间做正确的事情，顶得住诱惑。阉割掉的需求不等于全部抛弃，有的是需要扔进“需求池”去浸泡的，在适当的时候再返回来考虑。在产品设计阶段，其实还是之前说过的那篇：做最多的，展示最好的。如是而已…..

P.S：最近思维比较混乱，所以说的很不明白。其实，我只是认为一个好的产品经理至少需要具备这样几点：有产品信仰，不惟钱；有理性思维，不惟心；知道变通，不惟己；有坚持，不惟他。

而购物篮（车）的出现解决了销售中一个很核心的问题：帮助并刺激消费者继续他们的“即兴购物”行为。因为消费者并不会按照我们设想的那样是列着单子到商店取货的，他们总是在选购了第一本书的时候往往会对第二本书感兴趣，或者碰到其他值得他们购物的商品，这种行为被称作即兴购物。

所以，在零售领域里很重要的一个问题就是解决购物蓝（车）的摆放位置、提供形式、提供时间。比如，购物篮应该散在购物者可能需要它的任何地方而不是只放在商店的进门处（进门处其实并不是个好地方）；是浅口带把手的硬塑料篮子还是像宜家那样的提供手提袋子；冬天时衣服的存放如何与购物篮结合起来？

当电子商务在互联网上兴起的时候，购物篮这个概念被映射到了Web上，我们把它统一称为“购物车”。如下图，简单模拟的电子商务网站购物漏斗（Via），在巨大的推广成本的推动下顾客最终浏览了网站，但是却在购物车环节上有很大的流失。

paypal 在2009年第八次年度商户调研中发现，有大概45%的购物车遗弃率。其中占据前几位的分别是：

• 运费太贵，46%；
• 想做购物对比，37%；
• 钱不够，36%；
• 想找优惠券27%；
• 找不到偏好的付款方式24%；
• 结帐时发现商品缺货或其他原因无法购买23%；
• 找不到客服支持22%；
• 安全的顾虑21%。

Via：emarketer

当然，关于购物车的流失率挽回问题是很多B2C产品经理非常重视的问题，基于常规的非注册用户是否可以直接购买；对付款流程的修改；客服的支持；提高网站可信度等这样的问题不在这里讨论。

那么，基于已经被遗弃的购物车该如何利用？我觉得可以有以下几个方面：

1、在一个只有注册用户才能购物的平台上，如果新注册用户发生了购物车遗弃。可以考虑在一定时间内如15天向该用户投递EDM。内容包括：他们放入购物车中的产品的降价优惠等信息；和被他遗弃的购物车中商品相类似的商品的推荐营销；礼貌的询问是什么原因遗弃了购物车，要求填写调查问卷并发放奖励。对于新用户而言这种做法既能提现客户关怀同时伴随着降价信息的提醒常常会让用户觉得你确实把他当作上帝来对待了，当然，你也可以把这个叫做用户体验….

2、可以利用用户上次被遗弃的购物车中的商品来做关联推荐。一旦用户将一个商品加入购物车，在99%的情况下他是有潜在的购买欲望的，最后迫于各种原因没有结账，而这些原因并不在于商品本身，而在于平台。当该用户第二次再来的时候，如果能把他上次选中但未付款的商品以另外的形式推送给他，这个效果相信是很好的。

3、替代品推荐。这个需要跟第2条关联使用，并借助整个平台会员的UGC力量，最终形成一个独到的“推荐系统”或者说是“需求挖掘”系统。在用户遗弃的购物车中的商品是否有同类可替代商品？这些商品的价格与运费是否可以被其他用户接受，这些商品是否可以推荐给该用户？

4、被遗弃的购物车中的商品如何处理？当坏人在微博上提出这个问题的时候我们在群里曾有过一个争论。坏人认为，在购物车中的商品是用户购物欲望的体现，被用户遗弃后应该转入到收藏夹；而大熊认为，既然用户遗弃了购物车就说明用户此次购物终止，购物车应该被清空。

我的看法是，被遗弃的购物车中商品的转化需要根据不同的平台来进行判断。很多用户其实是想利用购物车来做比较购物的，保留他们所选的商品在购物车中，方便他们在不同的B2C上比较完成之后来下单应该更合适。

5、其实这些被遗弃的购物车数据也可以被比较购物网站所利用。采用OpenID的形式将是比较购物网站的一个发展方向。就比较购物而言，单纯的机器进行数据挖掘是欠准确的，最精准的最好还是基于用户UGC行为的推荐系统数据挖掘。

当然，这里会引发另外几个问题：比较购物网站是否需要购物车，比较购物网站的购物车该如何设计？下回再扯

故事1：要不要再来杯豆浆？早餐需要多点营养哦

从永安里地铁站出来到CBD国家大厦，会经过一条不算长的小街道，道路的右侧是民房，这里的居民一大半是靠贩卖早餐和小吃生活的。

为了赚取多点利润，这里的早餐基本都是搭配销售，比如煎饼再搭配个火腿肠、要了煎饼再来杯豆浆或者有包好的韭菜盒子…..我经常在一个40岁左右的夫妻的摊子那买东西，他的隔壁是一对年轻夫妻。两个小摊贩卖的东西是一样的，但是生意却很有差距。

我举一个简单的例子：
这对40岁的夫妻在你到了摊子前面的时候她会一边做手头的煎饼一边就主动给你打招呼然后问你，要几个煎饼？要不要加肠呢？等煎饼做好，给你打包后你给钱的时候，他会再问你，要不再来杯豆浆吧！早餐要有营养哦，年轻人。这个时候我多半会付钱买杯豆浆….
而隔壁小夫妻经常是这样的：来点什么？一个煎饼。要不要加肠？呃，不要。打包完事他会问一句，再来点什么吧…这个时候我会犹豫（其实是在寻找并决定），然后说，不用了。

问题出在哪？来个煎饼吧（核心功能优先展示）；需不需要加肠（附加功能礼貌推荐）；再来杯豆浆吧（越少的选择越多的被采纳可能）。
就像下面这种图片展示形式，焦点图高亮显示，非焦点图暗下来，用户的注意力在第一时间被聚焦。

故事2：接受第一份传单之后

还是永安里地铁站到CBD大厦的那条小街。每天早上从地铁出口一直到华彬国际路口，这里会挤满了散发传单的人。从海景房到游泳健身到外卖单到保险….

不知道大家是否有这样的感觉，当你在开始的时候接受了一份传单之后，你将很难再拒绝其他的传单；当散发传单的人看到你手上拿有传单的时候，他会把你当作主要的进攻对象。如果你在最开始的时候就不接受传单，那么，慢慢的其他的散发传单的人会慢慢的放弃你。

这个，是不是是心理学上说的那个，破窗理论？

1、5gtalk,我在［北环中心”http://URL”]Check- in(踩点)了
2、我刚在 (@ 咱家人东北菜（总店）)踩了一脚 http://URL
3、在家，阳台对面就是职工公寓。 我在城建四公司职工公寓(双清路14号)http://URL
4、咔呜咔(XX团昵称)刚刚使用XX团iPhone版在 卫星大厦签到. (2010-04-22 14:11:51)
5、我刚得到了’初来乍到’ http://URL  # 网站#
…….
最后列出2个来自Twitter搜索到的：I’m at 夜时尚台球俱乐部 (小营路9号, 北京). http://URL  ；西贡还不错的club名字很适合我 (@ gossip club) http://URL

注：以上文案皆搜索自新浪微博，其中地址信息我以“URL”替代、网站名称以“网站”代替….更多你觉得好玩的关于这个checkin的文案，欢迎补充。

关于foursquare的事情最近爆火，我对这个方面说实话一点研究都没有，但是不断有朋友的消息在我的微博和twitter上浮现，看着这些文案有的时候我笑喷了，更多的时候像吃了口苍蝇！

首先，foursquare的checkin是表示一种状态还是一种动作？哪一个的价值相对更高？作为网站引导用户在某个地方“踩一脚”、“露个头”、“插个旗”、“点个卯”、“冒个泡”、“踩点”、…有什么样的意义？价值何在？
在SNS的范畴里很早的时候有个应用很火，叫做“踩一脚”。从踩空间到踩日志到“逗TA一下”的打招呼等等，这种低成本的用户互动在早期的时候曾经有效的拉动了社区用户之间的关系，但是在移动社区中这个是否适用？我持怀疑态度，而且从产品长期发展上看，这是有害无益的，大量的垃圾信息会充斥整个社区。而移动社区最垃圾信息的过滤能力要远小于PC端的社区。

其次，很多人把foursquare直接当作一个SNS来玩来设计。我觉得这是个错误的想法，foursquare只是从SNS中衍生出来的一个应用。从笨重的SNS中剥离出来的东西必须是轻的，易于操作的且不能产生信息干扰的。
以上的文案信息压根没有任何可读性，试问这样的信息展示如何能产生什么价值？

第三，Checkin这个动作一般都是在用户“业余时间”完成的，多数情况下是在点菜间隙，等人中或者某个事情发生的业余时间完成。也就意味着，这个交互动作的完成必须要快！快速完成，快速反馈。

最后，改进方案
我觉得checkin这个模块可以分成这么几类来设计：
1、直接了当，让部分用户最迅速的标记一下自己的状态：我在XX地方。这里，必须要让用户在最快的时间最迅速的完成这个动作，千万不要让@Liuyaping 这样的同学再出现杯具。
2、状态标准化，根据数据进行分析对某些常用的场所设置快速checkin方式。如某些饭馆类的地点就可以内置“在吃饭”这里的快捷短语，手机上打字很累的。
3、状态娱乐化，整天死板的我冒头我踩点有毛用？这样的信息如何能引起非移动端好友的兴趣？checkin一定要这么死气沉沉毫无生气吗？
4、用户自定义化，这个基本大家都有这个想法了，不赘叙。不过请注意，当用户自定义的时候请在系统中跟你默认的语言进行下匹配，OK？
5、大家说呢？

我看好foursquare这个模式，但是我觉得更有戏的事情不是跟社区结合起来做，而是跟电子商务结合起来做，这会是一个很好玩的社会化电子商务模式。因为有隐私问题的存在许多地方你不会去checkin，即使你很想checkin，比如天上人间。但是当应用到电子商务上之后这个问题将会被稀释掉。