曾经有个朋友问我，从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的机器会成为主流，但是，别忘了，那是未来。而，事实就是这样！

先温习一下在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的经验来看”。正确答案的格式是：“根据我们拿到的数据进行分析…..”、“我们做的用户访谈说明….”、“根据市场预测并且基于我们产品的成长….”

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

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

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

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

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

简单说就是这样的：

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

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

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

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

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

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

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

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

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

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

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，比如天上人间。但是当应用到电子商务上之后这个问题将会被稀释掉。

首先，我们需要在一个问题上达成一致：我们并不是孤立地去感知和记忆某个事件，而是根据过去的经验和事件发生时的情境去理解和解释新信息。换句话说就是，在不同的情况下，同一个人对同一刺激的认知可能完全不同。这个就是心理学上常说的“情景依赖性”，他主要有四种表现方式：对比效应、初始效应、近因效应、晕轮效应。

对比效应也叫做感觉对比。这是我们最常见和最容易被感知到的一个情景依赖性行为。由对比效应引发出来另一个心理学效应叫做错觉，常见的是错视。
值得注意的是对比效应也是产品设计中最常用的一个设计原则；而销售中也常常运用这个效应，比如商家在劝说用户买下其想要出售的房屋之前，常常会让买家看一所破旧不堪或者标价过高的房子，以利用二者之间的对比效应。

首因效应也叫做初始效应、首次效应、优先效应或“第一印象”效应、开头效应等。
与一个人初次会面，45秒钟内就能产生第一印象。这一最先的印象对他人的社会知觉产生较强的影响，并且在对方的头脑中形成并占据着主导地位，这就是我们常说的，第一印象非常重要的道理。
这个效应没有必要做过多的解释了吧。不过，提醒注意的是，首因效应往往是不靠谱的，所谓，路遥知马力日久见人心….

近因效应也叫做新颖效应。事实上，初始效应是有关进入位置及其对判断的影响的一个总体描述，在多种刺激一次出现的时候，印象的形成往往主要取决于后来出现的刺激。即交往过程中，我们对他人最近、最新的认识占了主体地位，掩盖了以往形成的对他人的评价。
如果人们连续的列出有利原因和不利原因，就会产生很强的初始效应；但如果人们在列出有利原因和不利原因之间有3分钟的间隔，就会出现近因效应。这个技巧也在销售中被广泛应用，销售者常常会鼓励顾客列出购买原因（有利因素）和不购买原因（不利因素），如果在列出各自原因之间没有间隔，顾客就可能在无意间受到初始效应的影响。
近因效应的一个主要表现就是顺序效应，当某一答案出现在所有备选答案最后的时候其被选中的概率最高。当然，这个效应跟被问者对该问题的了解程度成反比，当被问者完全清楚这个问题的时候，这个效应几乎不存在。

晕轮效应也叫光环效应。人们对他人的认知判断首先是根据个人的好恶得出的，然后再从这个判断推论出认知对象的其他品质的现象。如果认知对象被标明是好的，他就会被好的光 圈笼罩着，并被赋予一切好的品质；如果认知对象被标明是坏的，他就会被坏的光圈笼罩着，他所有的品质都会被认为是坏的。这种强烈知觉的品质或特点，就象月亮形式的光环一样，向周围弥漫、扩散，从而掩盖了其它品质或 特点。我们用一句成语来概括的话就是：爱屋及乌。
苹果公司之前推出的imac、macbook、ipod、itouch等不论在品质、设计还是易用性上都得到了较高的赞扬。前几种产品的良好形象为苹果公司制造了一个光环，在这个光环的照耀下，消费者对其推出的其他产品也抱有很高的期望，这就是一种典型的光环效应。
当然，我们目前见人就说美女、美女经济学等现象其实也是一种光环效应….

情景效应处处可见，以至于我们常常会忽略他的存在。知觉本身就是具有选择性，因此在做任何重大决策与判断之前，很值得停下来想一想这些问题：
我看待实物的动机是否收到了某种动机的驱使？我在看待和处理问题时是否夹杂了自身的预期？我是否与那些与我有不同预期和动机的人交换过意见？

于是朱棣很郁闷，欲取建文帝需先取京师，欲取京师则必取山东，但是，山东无法撼动。朱棣倒推了一下，发现，自己没有希望了…..
就在朱棣钻入思维牛角尖的时候，谋士告诉他，我们的目标只是京师而已，去京师又不是只有一条单行道，条条大路都可通京师，我们为什么不绕道山东过去呢？朱棣恍然大悟，遂引兵南京，夺了江山…..

当年明月认为，这里山东就是朱棣的思维盲点，朱棣对江山、京师、山东三者关系的推定就是思维死循环。读到此处恰逢近期也遇到类似的事情，颇有感受。
4月的时候我的房子会到期，过年来了之后我和室友连想到没想直接准备换房子搬家，于是我们找了约半个月的房子无果。我们的问题是，我们可以接受房租比去年稍贵的地方，但必须离地铁近。于是我们拿着这2个标准去对照，发现，根本没有办法做到，地铁边的都超级贵，便宜的都质量很差，同时不满足交通。
就在我纠结与房子的时候，有天我突然问我自己，我为什么要搬家？我搬家的目的是什么？是为了上班方便，同时房租不贵。OK，那，我现在住的地方算不方便吗？不算！那，我现在住的地方房租算贵吗？虽有涨幅但与寻找新房相比相当能接受…..

靠！问题回来了，那，为什么要搬家？又折腾又难找…于是，我说服自己继续住这里。

在做产品设计的时候，我也会经常钻牛角尖，当由于技术的或者其他的阻力的时候我发现我无法按照之前的构想来继续设计，于是，我不断的对之前的那个想法进行改良，不断的堆加新的东西进来进行补充与完善以求可以实现，最后搞的自己累的要死。
突然有一天睡觉之前，我问自己，为什么花这么大的力气来做这个模块或者这个交互？目的是什么？最后发现，靠！完全可以舍弃他，对核心功能没有影响啊，遂释然….

2010年3月的UCD书友会话题是“设计的沟通与协作”，在说到如何向团队成员表达你的设计意图的是时候，Angela提到应该先再次的向团队成员统一我们为什么要做这个？然后再开始布道….其实，也是这个意思，永远不要忘记问题的核心点，不要被横着的马其诺防线挡住，可以试着把他竖着来看！
如果在做产品设计的时候把现在做的东西与我们的目的进行比对，或许会避免出现很多不必要的思维盲点。以此共勉。

系统邮件可以简单分为2类：提醒类(注册提醒、订阅提醒、生日或节日提醒)、EDM(电子邮件营销)。

一、作为提醒类的系统邮件，我个人觉得比较简单，只要把握住：简洁、直接2个要素就足够了。提醒类邮件不需要花哨的修饰，不需要夸张的表达，因为对用户而言他唯一需要的就是知晓邮件的内容同时点击那个他需要的链接就足够了，建议使用文本形式制作。
>>对于发信人：表明身份即可，可以直接使用网站名称。如：Twitter、Flickr Mail
>>对于标题：表明邮件的来处+需要处理的信息类型就足够了。如：kentzhu is now following you on twitter！
>>对于邮件头部：需要有一个固定的头部，一般直接使用网站的LOGO就够了。当然，也看到部分EDM放的是LOGO+网站导航。建议不放，因为提醒邮件的作用在于让用户快速的完成任务，不是推广，区别与EDM邮件。
>>对于邮件内容需要注意：
1) 千万不要使用图片！这点我觉得是跟网页设计最大的区别，网页上设计师都会使用大且带颜色的按钮来吸引用户的视觉注意，但是在邮件设计中恰恰是个巨大的错误！因为，几乎所有的邮件系统在接受邮件的时候都默认不加载图片的。所以，在邮件中最有力的吸引视觉的手法是文字！比如，淘宝的注册提醒邮件，使用了2个巨大的登录按钮，但是，默认的时候图片被屏蔽，于是整个邮件一片空白….
2) 链接地址千万使用明文的！目前主流的提醒邮件链接是一个文字链同时附加一个明文链接地址的做法，也是可以的。因为有的邮件系统可能会过滤文字超链接，所以设置成超链接和明文链接的地址一致的做法可以避免这一点。
3) 如果，你真的要使用图片，那么，请在这个图片上加注“Alt”属性。这样即使图片被屏蔽了也能知道这个图片代表是嘛玩意。比如，Flickr的提醒邮件在这点上就很棒。
>>对于正文：请千万简洁，表述一下这个是什么动作，用户该怎么做就OK了，其他的啰嗦的不要！因为在这个模块里，用户的目标任务是单一的，你需要的是用更单纯的页面来让用户快速的完成这个任务，这就OK了。
>>其他：如果可以请告诉用户如何退订类似的邮件(别学流氓卓越亚马逊！)；可以善意的告诉用户请勿直接回复该邮件。

二、EDM邮件对用户而言，用户可能会更关注其内容的丰富性和视觉效果。因此EDM邮件必然无法纯文字，且EDM邮件的主要目的是吸引用户去网站乃至与去购买，所以会更复杂一些。
>>对于标题：务必吸引人。但是前提是要表述清楚内容同时不要过长。
>>对于页面的宽度：建议控制在650px以下。个人比较倾向于使用650px，因为这个宽度不管是对于2栏还是3栏的设计都比较容易布局(刨除10px的间隙，然后再整除一下，很明显这个数字比较容易搞定)。
>>对于页面内容：因为使用图片无可避免，但是，重要的内容请务必使用文字，哪怕是使用了图片也务必给出文字标识！这点上有啊的EDM做的很棒，有啊的EDM页头是LOGO+主导航的模式，LOGO使用了Alt属性，同时主导航是直接实用的文字链接的形式。这样就算整个邮件图片被屏蔽了重要的信息还是可以显示出来。
>>对于图片的使用：建议给每个图片一个固定的宽度和高度及Alt属性标识，同时，注意不要使用背景图片。
>>对于引导：一般的EDM都会在web端留一个源地址，所以，请在你的EDM的明显位置给出一个超链接，“如果图片无法显示请点击这里查看”，这样就算被屏蔽了也能引导部分用户。
>>关于一致性：如果您会定期发送EDM(这句好似废话啊)，请注意使用统一的风格，主要是页头和页尾的风格统一。如果，你是有期刊号的请将期刊号和时间也一并加入！
>>关于提醒：请将如何退订、如何联系等必要的内容不吝的放在页面的底部，做个彬彬有礼的推广者。同时，如果您愿意提供退订按钮，请务必试着实现一键退订….

>>一些补充：系统邮件的制作应该随时注意按照邮件的玩法来走，打开速度要快；页面不要过长，建议在2屏内。关于具体内的排版与设计且听下回分解。

奉上有啊EDM一枚(故意屏蔽图片)

概括来说，这就是我的产品设计迭代理论。个人觉得互联网的产品设计首先是个快速迭代的过程，其次是个不断的被抄袭、抄袭、再被抄袭这么一个大的迭代过程，整体来看是一个螺旋式上升的过程。
而决定你是否能够成为一个优秀的设计师的条件是，你是否能“抄越”。因为抄习，所以抄越！
当然，不排除你是天才的产品设计师的可能，那么，如果你是个完全就只按照自己脑子里的设计想法去设计而不会参照任何其他人的产品的设计师，请，尽情的鄙视我吧，我完全真诚的接受你的鄙视！

附注：“抄越”一词我从我们团队的一个美女那听来的，后经bian和白鸦同学的演化就成了，“因为抄习，所以抄越！”

最后，用毕加索的一句话结尾：Good artists copy, great artists steal——Picasso

这个感觉就像是看魔术表演，魔术师表演看着很玄幻，搞的他跟个神仙，一旦那个原理被揭开，我们就惊呼原来事情那么奇妙。比如，我们看Gmail，从表面上看他足够简洁，但是功能足够强大，强大到你想到什么他都能提你实现了。我们从表面上能看到的只是Gmail简洁的界面，优秀的用户体验，然而，其背后的东西呢？我们都看不到，那么Gmail的核心竞争力何在？是仅仅简单的界面与架构吗？显然不是！

核心竞争力是个不断被诠释和放大的东西，到底什么是核心竞争力？是Google的简洁？是淘宝的免费？是支付宝的可信赖？是目前电子商务B2C的便宜？
不，这些都不是，核心竞争力恰恰是那些无法被局外人看到的东西，是无法通过模仿得到的东西。
外界总是在说腾讯在模仿，但是他从来没有模仿到别人的核心竞争力他也无法模仿到。当然，他能成功，这是他自己核心竞争力的体现，之所以，我们之前没有发现腾讯的这个核心竞争力，恰恰也是因为，看到的都不是核心竞争力！我们总是看到腾讯在模仿，却没有关注腾讯在模仿的背后的巨大的力量。当我们的目光总是落在外在的时候，我们是无法读懂他的。

看到的都不是核心竞争力，更何况，往往，我们连看都没有仔细的看，所以，我们永远无法超越。

所以，不要去相信什么观察家，观察无法出真知。观察到的东西是最肤浅的现象，是人家故意走光给你看的。
我是个会不断有不同的ideas的家伙，几个月前，Tony和千鸟对我做了个会诊，结论是：我是个缺乏实践的可以培养的学生。那个时候，我总会通过自己的一点观察就下结论，现在等我深入了，我越来越觉得，那个时候自己多肤浅啊。
当你观察的时候，你时常会从一个很单一的维度去做判定，当你深入去做的时候，你发现，原来这个设计是多个维度权衡的结果，而你之前作出判定的那个维度跟其他的点合在一起的时候，那个点是可以忽略掉的，因为，平衡之后的设计是最优化的设计。

设计师们总是在说UED，在说以用户为中心，但是，实际上设计师恰恰是对用户效益最不敏感的一个职业，一直以来。
设计师的产品做好了，市场容易开拓了，运营也好做了，销售更是可以把黄金卖成钻石价钱。但是，设计师们呢？设计师们看到每个月市场与销售们春光满面，看着 运营越玩越有意思，他自己实际上是没有太过直接的感受。说的再露骨一点，没有金钱的刺激，他们感受不到他们好的设计和他们不好的设计的差距。目前好的设计 与坏的设计对于他们最直观的感受就是，看是否有用户站出来骂，是否有用户偷偷的叫好，看老板心情爽不爽。
我再继续把我的观点低俗化一点。想让设计师关注用户，从用户出发有2个可能，设计师本身有深刻且正确的UCD信仰，设计师受到直接的利益的刺激(工资)。

不知道是否已经有公司这么玩着呢？你们玩的怎么样？不过从现在开始的时间里，我要这么玩下去了……