1、如何将ios设备的屏幕实时投影到电脑上

这个问题在android设备上比较容易实现，早先91手机助手、豌豆荚都可以实现了。而在ios上则相对比较困难，后来发现了一个实现的方式。

实现前提：你有一台ios设备且已经越狱

需要工具：ScreenSplitr，越狱后cydia里有；iDemo，这里有售，17.99美金。

操作步骤：

①在ios上安装ScreenSplitr，在Mac或者PC上安装iDemo ；

②在ios上启动ScreenSplitr，再在Mac或者PC上启动iDemo ；

③享受演示的乐趣

iDemo同时提供WiFi和USB方式连接；支持iphone、iphone4、ipad外观显示；支持设备横评、竖屏显示；还可以设置投影的影像的显示比例并且可以设置为铺满屏幕的幻灯片方式。确实是产品演示的绝佳方式啊～

2、如何删除ios软件中的某个语言包

这个也许纯属是我自己的一个蛋疼的需求，因为，我实在受不了哪些原本很优秀，但是被翻译成中文后就陡然让人无比抓狂的应用，而且，我英文很差，还做不到把系统语言修改为英文。比如，夜不能寐你妹啊的path，比如twitter，比如Google+，比如….后来，找到一个简单的方式做修改

实现前提：你有一台ios设备且已经越狱

需要工具：AppSync补丁，越狱后cydia有 ；解压缩工具如Winrar等

操作步骤：

①下载.ipa文件，将后缀修改为.zip后保存

②用zip类的工具打开，删除掉里面的Payload\*.app\zh_CN.lproj目录（zh_**如zh-TW也删除掉），保存。如：Payload\path.app\zh_CN.lproj

③将后缀修改为.ipa，安装到ios设备中

④享受英文界面的优雅

这个方法比较简单，不过每次升级之后都需要再重新删除一次。唯一遗憾的是这个只能修改其界面语言，暂时不能修改其系统提示语言，path的g夜不能寐老子还是没搞定….哎

对于这些问题，我一般分成2个部分来回复

第一个问题是咨询转产品是否可以的问题。我的回答通常都很简单直接，可以，没什么不可以的！如果你想转那就立刻转，没有人天生就会什么，也很少有人能在职业开始的前3年就能准确的找到自己喜欢的且擅长做的事情。所以，喜欢就去尝试，尝试之后就可以知道自己是否合适，是否喜欢去做。如果尝试失败，那也是让自己更清楚自己的一种方式。只要不会因为转行造成生活无法继续或者其他神马原因的，就大胆的去吧，少年！

第二个问题是咨询转行做产品经理的话需要注意什么东西。这个问题的本源其实是想知道什么是产品经理，他做哪些事情。在回答这个问题的时候我会采用问问题的方式来回答，你想转行成为的产品经理是怎样的？你所在的公司目前对产品经理的要求是怎样的？如果真的要开始了，你准备给自己多久的时间来适应和校准？

1、你想成为的产品经理是怎样的？

这是最重要的一个问题，如果你对自己想要成为的角色没有一个概念，那么，后续的事情都无从谈起。所以，我常会先问这个问题，然后捎带上我对产品经理的理解。

产品经理，按照我的理解就是发现用户需求并定义客户价值，准确传递需求与价值给团队成员并达成一致，推动团队成员优雅的满足这个需求并持续的将产品价值传递出去。

这里面分为几个环节：发现用户的需求、定义客户价值、传递需求并提供解决方案、推动实现解决方案、传递产品价值、持续传递产品价值。

发现用户的需求看起来是一个很简单的事情，但是单纯的用户需求也是没有意义的，真正的意义在于这个需求背后隐含的客户价值。说白了就是，你不仅要替人解决问题，更重要的是自己要从中获利。除非你是一个非盈利组织，否则，一切无法盈利的产品都是失败的。

传递需求，提供解决方案，推送方案解决相对被提及的很多，不再赘述。其核心在于设计能力和项目执行力上。

提供了解决方案并不代表事情的结束，在我看来这个事情只是刚刚开始，因为，不为人知的解决方案是毫无价值的。所以，另外一个重要的事情在于产品的运营，如何让用户知道我们帮助他解决了问题是另外一个挑战。

而如何持续的传递产品价值是一个比发现用户需求并定义客户价值更重要的事情，这取决与产品可以走多远，可以维持多久。用户的需求是会随着产品市场等因素的变化而随之变化的，是否能够顺势而为持续跟进不断调整尤为关键。

所以，产品经理是一个相对比较复合化的角色，而且更重要的是，在完成以上工作的时候，你的行政级别上没有任何特权，有的时候甚至需要跟比你高级别的职位斗争。

2、你公司目前的产品经理状态是怎么样的？

你公司目前对产品经理的要求是咋样的，如果你朝着你想像中的产品经理迈步的话，他是否可以给你提供足够的空间呢？如果不能够，那，你是否会因此离开呢？

3、你会给自己多久的时间来适应和学习？

产品这个行当是个吃持久耐力饭的活计，需要不断的学习，坚持不懈的努力。你能给自己多少时间来尝试和学习呢，你能忍受多久这种每天都会有无数并发事件的工作生活，你会乐在其中还是会不久就厌烦倦怠呢。

以上，是我对类似问题的回答，欢迎交流

比如，为了高雅和精美某个支付网站的首页上弄个美娇娘抱着个Mac电脑羞答答的盯着屏幕，可是实际上，这他吗的支付网站根本就不支持在Mac下支付……比如，某个旅游App最近升级之后也学人家增加了一个在页面加载的时候模态提示的效果，不过，一般人家都在这个间隙提示如何操作，有什么功能，这个App则在这个时候吹嘘自己的上市公司经历….再比如，某个阅读App的开始界面做成一个图片被风扇动的效果，意图隐喻这里可以向上拖，可是无数用户都以为那里是个动态图，在开始的时候就狂点击那里…..再比如，看到很多App做首次打开的新手引导，某个App也这么搞，但是足足搞了8张图的引导，这你妹的…..再再比如，某个App升级之后把界面搞的很好看，但是每次操作都会慢的让你想杀人，这就好比一个丑陋无比的坐台女为了卖个好价钱，在脸上擦足够多的粉一样…..

上周末跟Tony和Angela在下厨房喝茶闲聊，我说目前的移动产品设计可以分为2类，一类是做给用户用的，一类是做给设计师们欣赏与收藏的。虽然有些武断，但是这半年来，越来越感觉整个ios的产品设计迷失在精美里，设计师们都在为了设计而设计，为了精美而精美。当然，精美无可厚非，但是精美是一个App成功的必要而非充分条件，App成功的前提应该是需求和功能而不是界面！

有用，也就是需求是一个产品体验的起点，也是最重要的体验，在这个基础是要做到易用和友好。如果没有到达这个层次，精美的界面实际上是无法支撑一个产品长久发展的，不要为了设计而设计！

说到这股精制风潮，还有一个很奇怪的现象。设计师们都喜欢去看当前惹火的应用做了些什么，盯着竞争对手做了些什么交互，然后他们也按照这个界面或者交互的思路去做。然而很少设计师真的静下心来去研究系统自带App的设计还有交互，越来越多的设计师跳过了基础阶段的认知与学习，直接进阶了….

好吧，我的牢骚发完了。（其实主要是因为微博没法评论，我懒得发微博了….），下面是广告时间，推荐几款目前我最喜爱的App：

• 工作处理：Sparrow，最好的Mail客户端 ；Evernote ，随手记 ；微信 ，我用它确实是来工作的！
• 阅读扯淡：Twitter ，原生的就是最好的 ；Path ，其实我只喜欢他的滤镜，还有不裁剪我的图 ；FIT™ 随享新浪微博客户端 ，最好的微博客户端，除了不能推送消息 ；Reeder ，顺手的Google Reader客户端
• 出行生活：百度地图 ，在中国他比较准一点点 ；下厨房 ，有爱的设计 ；快捷酒店管家 ，这个家伙号称开房利器，男人不装会显得很没面子….

当时这个文档是基于我做Web端产品设计的经验为蓝本完成的，这1年多来我从Web端完全转到Mobile端，还在继续的使用着这套方法。在不断的实践过程中略有心得，遂更新一篇，详细的讲述一下这套思路。

当然，肯定会有很多人说axure是个很笨重的工具，从来不用；也肯定会有很多人说我们团队有严格的文档规范，你的这套东西不适用…..是的，你们都是对的。这套方法的最大好处就是快速、直接，适用于扁平化的团队。如果你是产品与研发异地的团队，那么，建议还是有详细的文档比较合适。

关于一个PRD文档需要包含的内容及相关的结构，之前《基于axure的PRD写作思考》已经说的比较清楚，不再赘述。我们为什么要写PRD？简单来说就是把我们具体要做一个什么样的东西很详细的描述出来并传递给团队其他成员知晓，最终一起执行。这里面我觉得有3个点特别重要，详细描述、快速传递、一起执行，一份不管是什么形式的PRD最终都必须做到这3点。

从打开axure准备开始进行原型设计开始，我会把文件分成这样几个部分：修改记录、产品结构、（用例及信息架构）、具体页面原型设计。在具体页面的原型设计的时候会再根据这个页面的负责程度看是否要增加一个流程图页面进去。

修改记录

修改记录模块主要是对该原型的迭代历史进行记录。修改记录可以使用文本面板完成，主要记录比如，什么时候修改了什么模块，原因是什么。每次对原型进行修改都必须记录下来，这种内容迭代的记录方式一方面便于自己后续回忆与总结，同时也对项目管理的需要，每次的修改都有据可查。

产品结构

产品设计本身是个从大往小的过程。所谓大就是指的产品整体的结构所谓小则是具体的交互设计页面布局等。我个人非常不建议一开始就进入到具体的页面设计，即使是一个具体的页面设计也建议先把页面模块及相应模块的布局想清楚，然后再开始填充内容；而如果是一个会涉及到很多步骤的设计，如果流程没有事先想清楚画出来，千万不要动手去设计。

按照我个人的习惯，产品结构部分一般会采用结构图的方式调用流程图模式把这个产品的结构关系画清楚。目的有这样几个：搞清楚用户的主要路径，用户会从什么地方进入产品，在里面会经过哪些页面，然后会从什么地方退出；弄清楚产品的层级关系，从移动端的设计上看，产品的层级关系一定要避免太深；梳理一下整个产品的页面，不要有遗漏。

用例及信息架构

用例之前在Web端我通常是直接采用母板来完成的，最近在做Mobile的产品设计，倍感在画原型的时候把用例标识出来的重要性。个人感受，移动端的产品需要比Web端更加深入的考虑模块复用，一来保持整个客户端的统一性，同时复用的模块在一定程度上是可以减少开发工作量的。

就一个Apps而言，这个部分通常会包括一级页面的页面结构、二级页面的页面结构、三级页面的页面结构、….；弹层的样式及出现方式；是否出现menu键、样式及内容（android）等内容。

当进行需求评审的时候也建议按照这个顺序来说，先介绍一下整个产品的结构，向整个团队成员说清楚我们大概要做一个什么样的产品，他包括哪些部分，这些部分的关系是咋样的；其次开始介绍一下这个产品他从一个框架上看是什么样子的，有一个感性的认知；再次开始按用户任务/流程分模块进行介绍，详细的说明其中的策略问题。

具体页面原型设计

具体页面的原型设计分为2种，1种是页面行为比较单一，简单的几个图加一定的文字就可以描述清楚的；一种是页面行为的流程及逻辑性比较强，有比较多的中间状态和用户行为的分支，这种页面我一般的方式是先画出流程图，然后再相应的给出页面原型。

第一种页面比较简单，设计的时候想着点各个平台的设计规范（指南）就可以搞定。同时可以在页面原型的边上把每个模块部分取的元素内容及相应的策略也写出来。

不过，需要有一个提醒，在移动端会存在不少页面的长度是超过1屏的，在原型设计的时候一定要画出一条屏幕高度基线，将第一屏内容和第二屏内容隔开。一方面重要的内容都必须在第一屏有所体现，另一方面注意节减页面高度，同时在原型评审的时候也让其他角色提前有所了解。

另一方面，如果一个模块涉及的交互流程比较复杂，比如一个输入框，在初始状态、开始输入状态、输入完成状态、输入出错状态（超过字数限制）等不同状态下的表现及相应的操作提示都是不一样的，建议分别拆成几个不同的状态完成。这部分之前在Web端的时候可以直接用axure的交互来完成，但是mobile端的屏幕有所限制，再去做这些交互效果，往往也隐藏比较深，不如拆出来画。

一些关于移动端原型设计的其他问题

1、工具永远都是工具，不要让工具限制了你。axure也好，viso也好，OmniGraffle也好，做出来的东西无分好坏。

2、除非脑子里想的比较清楚了，不要冲动性的就开始用axure画原型。在我看来，画原型只是20%的功夫，更多的功夫应该在原型之外，包括对要做什么，为什么要这么做的思考。同时，纸面原型是更好的选择，帮助锊清思路。

3、在原型设计的过程中需要注意沉淀一些规范性的组件出来。每个团队每个项目都应该有一套自己的原型组件，而不应该是直接找别人要来原型组件然后直接导入（当然，系统通用的组件除外）。

4、原型设计的过程中，酷炫的原型交互需要适可而止。

当然，我并不是从一开始就使用微信的，所以，在回答这个问题之前我特意去查了一下微信的发家史（见本文最后）。然后，我惊奇的发现，微信其实是个定位“摇摆不定”的产品。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版本）猛击这个Google文档。

另外，其实微信有一些小的版本，主要是修复bug，没有在此列出。数据来源：微信官方。

2011年其实没啥故事，如果硬要说的话，那就编一个

有个人，他之前一直在河里游泳，河水很平静河面也不是很宽广，在扑腾了一段时间之后他感觉还挺良好。可是时间长了总想去隔壁的大海里扑腾一下，谁都有对更宽广的大海的向往。到了大海之后，情况完全变了，无限宽广的海水，复杂的水流，高强度的扑腾….他发现之前称手的动作和方式都不再适用了，一浪又一浪的海水打过来，完全需要重新去学习如何拍水如何平衡如何去适应。

累，非常累，甚至经常自我怀疑，但是，在夜深人静的时候，在失眠的时候，自己反复的咀嚼，反复的思考，其实，这种累这种不适应的背后能够带给自己的成长是巨大的。从自己踏进这个行业的开始就已经知道这个职业需要不断的去经历，不断的去犯错，然后才能不断的成长。这种痛苦的背后沉淀下来的是真正的价值！

我，就是这个从河水里游泳再到海水里去游泳的孩子。从土八路一样的粗犷式的做产品到正规军式的系统化完整的做产品；从接手一个60分的产品，试图努力做到90分甚至100分到从0开始参与一个产品，不断探索不断试错努力做到最好…..

这1年多来的感受基本上就是这个故事。当然，在河水里扑腾和在海水里扑腾其实不存在哪个比哪个更好，当你在海水里扑腾久了其实也会怀念河水的。在哪里扑腾不是核心，为什么而扑腾才是重点。

2011年，我把之前的思考与现在的经历做整合，对产品设计对PM都有了不一样的认识，

不再看到一个产品某一个地方做的不好就破口大骂，而是先思考他为什么要做成这样，背后是不是有其他东西在左右；不再认为用户体验就是一切，而是从一个整体的角度去看待体验，努力去做背后的更深次的体验，而这才是用户体验的精髓；不再迷信各种原则各种思想各种所谓的成功秘籍，因为实际上真正的成功只有一种，那就是自己实际动手的去做；不再单纯的从设计层面去看待一个产品，也不再执着与不着边际的产品市场分析，因为，只有仰望星空且脚踏实地才是真正的王道；不再认为一个PM的能力重点在于产品设计或者市场分析，而最重要的恰恰是执行力，如何让一帮兄弟齐心合力的把事情做成。

2011年，我继续属于互联网属于产品设计，

我信仰并偏执的喜爱着互联网，这是一件可以让我一直投入其中且不会感到厌倦的事情。这1年我彻底的从互联网转到移动互联网，从头学起，我继续在移动电子商务里摸爬滚打。你们管这叫LBS也好，叫O2O也好，叫SOLOMO也好，叫MLGBD也好，这事，在未来的2年我会一直做下去，也许会用不同的方式在不同的地方做，但是如2009年所说，移动电子商务，我一直为之努力。

2011年，中国的互联网血流成河，

团购，从开始的血拼大战到后来的血流成河，唯有几家笑傲；电商，从开始的血拼到后来的血流成河，满地菊花残；微博，从开始的血拼到后来的血流成河，阉割者生；上市，从开始的血拼上市到后来的血流成河，坑爹的跌；博客，一整年都是血流成河，血流已尽；SNS，一整年都是血流成河，血流将尽；移动互联网，正在血流成河；中国网络，尼玛，一直都在流血！！！

……

2012年，世界末日，我很期待

2012年，移动互联网，我将继续；产品设计，我将继续

有一天，有一个男人和一头猪还有一只狗一起流落到了一个荒岛上。

在一起生活了一段时间之后，男人萌发了很强的性欲。思来想去发现岛上只有猪和狗，于是男人决定要跟猪或者狗干上一炮。男人在猪和狗之间挑选了很久，最终选中了猪，因为猪看上去比较耐看那么一点点。

于是，男人把猪抓住，固定在了树上，正当男人掏出家伙准备插入的时候，狗跳起来狠狠的咬了一下男人的屁股。男人条件反射的抬脚踢狗，同时用手捂住自己的屁股，这个时候猪就顺势逃跑了。

男人很郁闷的提起裤子去抓狗，当他抓住狗固定在树上再次掏出家伙准备插入的时候，猪却在他后面狠狠的拱了一下。男人踢猪，狗顺势就跑了。于是，男人抓猪，狗咬他屁股；男人抓狗，猪拱他；…..；男人如此这般的循环往复了若干次之后终于累的不行了，累趴下的男人倒地呼呼大睡。

等男人醒来的时候，发现有个美女站在他面前。

美女说，玉帝见男人可怜于是派她来帮助男人实现一个愿望。不过，美女只能停留一个小时。

男人听罢欣喜若狂，直着嗓子吼到，快！快！快帮我抓住那只狗，好让老子能安心的跟那只猪干上一炮！！！

…..

以上，欢迎任意联想。

导航始终是产品设计的重头戏，往往产品设计中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势头可观，但目前不太适合小队伍入场，大团队可先做储备。

在移动设备里，常见可以被利用的硬件包括：话筒、GPS、距离感应器、环境光感应器、影像传感器、磁阻传感器、重力感应器、方向感应器、加速感应器、三轴陀螺仪、RFID、NFC、裸眼3D、温度计、震动感应器等等。

话筒

• 原理：记录/输出声音，进行频谱分析最后以不同形式输出/输入
• 扩展应用：语音输入、语音指令、听音辩曲、游戏等
• 代表实例：语音搜索、导航仪、Shazam、Midomi SoundHound、IntoNow、Ocarina（埙）

GPS

• 原理：由24颗工作卫星组成，使得在全球任何地方、任何时间都可观测到4颗以上的卫星, 测量出已知位置的卫星到用户接收机之间的距离，然后综合多颗卫星的数据就可知道接收机的具体位置
• 扩展应用：定位（关于定位更详细的介绍可以参照之前的文章“移动产品设计之常见定位方式”）
• 代表实例：各类地图应用、LBS相关应用

磁阻传感器（方位传感器）

• 原理：将感受到的地磁信息转换为数字信号输出给用户使用
• 扩展应用：辅助导航
• 代表实例：指南针、地图的罗盘模式

GPS与磁阻传感器的对比

• 二者不会相互干扰
• 磁阻传感器不接收GPS信号，是GPS的补充
• 受到地磁的影响，因此磁阻传感器需要经常进行校正

距离传感器

• 原理：一般都在手机听筒的两侧或者凹槽中，通过发射特别短的光脉冲，并测量此光脉冲从发射到被物体反射回来的时间，通过测时间来计算与物体之间的距离
• 扩展应用：接打电话的时候进行屏幕亮度及开关触屏的调节
• 代表实例：进距离传感器屏幕锁、微信自动切换听筒/扬声器模式

环境光传感器

• 原理：感应出使用环境的光线强度，再根据外界环境的光线强度进行调节
• 扩展应用：屏幕亮度自动调节、键盘灯自动调节
• 代表实例：屏幕亮度调节、阅读模式切换

影像感应器（摄像头）

• 原理：将光线转变成电荷，通过模数转换器芯片转换成数字信号
• 扩展应用：拍照/录像、条码/二维码识别、图像识别/人脸识别、动作捕捉/体感技术、增强现实
• 代表实例：我查查、名片全能王、quick拍、蝶千寻、（AR相关应用可参见“增强现实及其扩展应用”）

重力感应器

• 原理：手机重力感应指的是手机内置重力摇杆芯片，利用压电效应实现，感受手机在变换姿势时，重心的变化，使手机光标变化位置。重力感应器所能测的是手机来自不同轴面的重力，是直线的。
• 扩展应用：横竖屏切换、设备的正反朝向判断
• 代表实例：横竖屏自动切换（部分手机可以实现在查看相册的时候会自动根据拍照的时候是横屏or竖屏进行横竖自动切换）、甩动翻页/换歌、来电翻转、重力球游戏

方向感应器

• 原理：一般手机的上的方向感应器是感应水平面上的方位角、旋转角和倾斜角的。可以检测手机处于正竖、倒竖、左横、右横，仰、俯状态
• 扩展应用：飞行类游戏
• 代表实例：飞行类游戏、赛车类游戏

加速感应器

• 原理：敏感元件将测点的加速度信号转换为相应的电信号。加速感应器能感应到加速度和方向
• 扩展应用：加速度感应、力量大小和方向感应。（在很多电脑里也内置有加速度感应器，基本应用场景就是当电脑跌落的时候保护硬盘不受损）
• 代表实例：求签类应用、保龄球类游戏（Super Ball Escape）、垂钓类游戏

三轴陀螺仪

• 原理：单轴的只能测量一个方向的量，也就是一个系统需要三个陀螺仪，而3轴的一个就能替代三个单轴的。三轴陀螺仪能同时测定6个方向的位置，移动轨迹，加速度。三轴陀螺仪最大的作用就是“测量角速度，以判别物体的运动状态，所以也称为运动传感器“，换句话说，这东西可以让我们的iPhone知道自己”在哪儿和去哪儿“
• 扩展应用：感受手机在各个角度上的变化、感知设备运动状态、辅助GPS定位
• 代表实例：itouch等的定位、测量（ iSetSquare ）、游戏（ Gyroblox、现代战争2、 sensor mouse   ）

重力感应、方向感应、加速感应、三轴陀螺仪

• 重力感应，只能感应到不同轴面的力，是基于直线的感知；
• 方向感应器，基于平面的感知；
• 加速度传感器，能感应加速度和方向；加速力可以是常量G也可以是变量，所以加速度感应的范围要比重力感应器大。也有些手机上说到加速度感应器，实际上就是重力感应器。
• iPhone4里的重力感应器和加速度感应器是同一个设备，叫三轴陀螺仪。能够感应设备在X、Y、Z三轴方向上的重力和加速度，得出来的是运动轨迹；

 震动感应器

• 原理： 压电陶瓷可以把震动转化为电信号
• 扩展应用：设备唤醒、心跳、脉搏监测、测谎仪
• 代表实例：暂无

RFID(非接触式射频识别)

• 原理：在物体贴上RFID标签，当物体进入到读写器的作用范围内时，能够读取到标签中的相关信息。RFID分为2个部分：标签（射频卡），读写器。标签分为主动标签（主动发送信号），被动标签（接收信号）
• 扩展应用：室内定位、电子机票、物流分拆
• 代表实例：手机钱包、一体化检票平台

二维码

• 原理：用某种特定的几何图形按一定规律在平面（二维方向上）分布的图形记录数据符号信息。在代码编制上巧妙地利用构成计算机内部逻辑基础的“0”、“1”比特流的概念，使用若干个与二进制相对应的几何形体来表示文字数值信息，通过图象输入设备或光电扫描设备自动识读以实现信息自动处理。
  二维码不一定都是黑白相间的，实际上它的颜色可以被改变；二维码有较强的识别性，当遮盖面积不超过30%的时候仍然可以被识别。
  （比如这张二维码就是改变颜色增加了个性化内容的，and，还可以参考我的微博头像）
• 扩展应用：打开相关链接、签到、支付、名片
• 代表实例：支付宝条码支付、我查查

NFC

• 原理：由RFID及互联互通技术整合演变而来,在单一芯片上结合感应式读卡器、感应式卡片和点对点的功能，能在短距离内与兼容设备进行识别和数据交换。这项技术最初只是RFID技术和网络技术的简单合并，现在已经演变成一种短距离无线通信技术。
  但是NFC芯片有双向的读写功能，而RFID的id tag只读；NFC要求的距离比FRID要近很多。
• 扩展应用：身份确认（签到）、电子钥匙、电子票务、介绍地标
• 代表实例：签到、刷卡、移动支付

RFID、二维码、NFC

• NFC和目前通用的RFID协议兼容，脱胎于RFID
• RFID主要应用于目标识别（单向），NFC主要实现设备间通讯（可双向）
• NFC要求的距离比FRID要近很多
• NFC的本质是通讯，本身不承载数据
• NFC需要电力，类似蓝牙
• 二维码是单方面的信息读取
• 二维码承载字母，数字，ASCII码，且有字符数量不超过3000个
• 二维码需要去对准读取设备，而NFC只需要靠近，识别工作无须人工干预

裸眼3D

• 原理：简单的说就是不使用偏振镜（3D电影常用），在平面显示出3D立体效果。目前裸眼3D技术有很多，目前在手机上实现应用的主要是夏普的视差屏障（parallaxbarrier）技术液晶屏
• 扩展应用：游戏、地图和导航、视频浏览、3D照片浏览
• 代表实例：Google3D地图、earth3D

温度计

• 原理： 通过热敏感探头实现温度测量。
  不过， 只能测试环境温度，无法测量物体温度，比如无法测量体温。测量体温等需要红外测温装置，目前不易装入手机。 另外，易受到机器温度影响，测温不是很准
• 扩展应用：测量环境温度、体温监测、疾病预报、生活服务（穿衣指导）
• 代表实例：暂无

当然，其实还有最普通的Wifi、红外、蓝牙等基础硬件设备的使用也可以有不一样的交互体验比如Bump等，这里不再赘述。

另外，因为是学文科的，所以这篇文章有很多地方我个人的理解并不是很到位，欢迎懂行的你批评指正。

]]> http://www.ikent.me/blog/3924/feed 11 http://www.ikent.me/blog/3911 http://www.ikent.me/blog/3911#comments Sat, 03 Sep 2011 07:17:39 +0000 kent.zhu http://www.ikent.me/blog/?p=3911 知乎上有个问题问“除了 GPS 和基站定位，目前还有哪些其它传感定位技术？”，正好最近在做这方面的一些调研学习，于是把我了解到的信息整理喽一下做了回答，之后知乎上有其他网页对我的答案做了纠正与补充，这里我一并整理一下发出来备份吧

申明：以下内容感谢徐哲、滇狐、maggie、穆荣、猪头心宇在知乎上的补充。

目前常用的定位方式有：GPS定位、基站定位、wifi定位、IP定位、RFID/二维码等标签识别定位、蓝牙定位、声波定位、场景识别定位。技术上可以采取以下一种或多种混合。

关于GPS与A-GPS定位：

常见的GPS定位的原理可以简单这样理解：由24颗工作卫星组成，使得在全球任何地方、任何时间都可观测到4颗以上的卫星, 测量出已知位置的卫星到用户接收机之间的距离，然后综合多颗卫星的数据就可知道接收机的具体位置。在整个天空范围内寻找卫星是很低效的，因此通过 GPS 进行定位时，第一次启动可能需要数分钟的时间。这也是为啥我们在使用地图的时候经常会出现先出现一个大的圈，之后才会精确到某一个点的原因。不过，如果我们在进行定位之前能够事先知道我们的粗略位置，查找卫星的速度就可以大大缩短。

GPS系统使用的伪码一共有两种，分别是民用的C/A码和军用的P(Y)码。民用精度约为10米，军用精度约为1米。GPS的优点在于无辐射，但是穿透力很弱，无法穿透钢筋水泥。通常要在室外看得到天的状态下才行。信号被遮挡或者削减时，GPS定位会出现漂移，在室内或者较为封闭的空间无法使用。

正是由于GPS的这种缺点，所以经常需要辅助定位系统帮助完成定位，就是我们说的A-GPS。

例如 iPhone 就使用了 A－GPS，即基站或 WiFi AP  初步定位后，根据机器内存储的 GPS 卫星表来快速寻星，然后进行 GPS 定位。例如在民用的车载导航设备领域，目前比较成熟的是 GPS + 加速度传感器补正算法定位。在日本的车载导航市场是由 Sony 的便携式车载导航系统 Nav-U1 首先引入量产。例如在增加了三轴陀螺仪的iphone4里可以利用三轴陀螺仪来辅助完成定位，具体可以参见这篇文章的介绍，不过三轴陀螺仪定位的误差会随着时间逐渐积累。

关于基站定位（cell ID定位）：

小区识别码（Cell ID）通过识别网络中哪一个小区传输用户呼叫并将该信息翻译成纬度和经度来确定用户位置。Cell ID实现定位的基本原理：即无线网络上报终端所处的小区号(根据服务的基站来估计)，位置业务平台把小区号翻译成经纬度坐标。

基本定位流程：设备先从基站获得当前位置（Cell ID）。（第一次定位）—— > 设备通过网络将位置传送给agps位置服务器 —— > Agps服务器根据位置查询区域内当前可用的卫星信息，并返回设备。 —— > 设备中的GPS接收器根据可用卫星，快速查找可用的GPS卫星，并返回GPS定位信息。

关于Wifi AP定位：

设备只要侦听一下附近都有哪些热点，检测一下每个热点的信号强弱，然后把这些信息发送给网络上的服务端。服务器根据这些信息，查询每个热点在数据库里记录的坐标，然后进行运算，就能知道客户端的具体位置了。一次成功的定位需要两个先决条件：客户端能上网 ，侦听到的热点的坐标在数据库里有

PS：苹果用的WIFI定位服务http://www.skyhookwireless.com/ ；这个网站可以通过MAC地址取得位置信息http://samy.pl/mapxss/

关于FRID、二维码定位：

在开始说增强现实（AR）之前，需要先说说虚拟现实（VR）

虚拟现实是从英文Virtual Reality 一词翻译过来的，简称VR。VR 技术是采用以计算机技术为核心的技术，生成逼真的视、听、触觉等一体化的虚拟环境，用户借助必要的设备以自然的方式与虚拟世界中的物体进行交互，相互影响，从而产生亲临真实环境的感受和体验。

典型的VR 系统主要由计算机、应用软件系统、输入输出设备、用户和数据库等组成。计算机负责虚拟世界的生成和人机交互的实现；输入输出设备负责识别用户各种形式的输入并实时生成相应的反馈信息；应用软件系统负责虚拟世界中物体的几何模型、物理模型、行为模型的建立，三维虚拟立体声的生成，模型管理及实时显示等；数据库主要用于存放整个虚拟世界中所有物体的各个方面的信息。

VR技术与三维动画技术的本质区别在于其交互性上。三维动画技术是依靠计算机预先处理好的路径上所能看见的静止照片连续播放而形成的，不具有任何交互性，即不是用户想看什么地方就能看到什么地方，用户只能按照设计师预先固定好的一条线路去看某些场景，用户是被动的；而VR 技术则通过计算机实时计算场景，根据用户的需要把整个空间中所有的信息真实地提供给用户，用户可依自己的路线行走，计算机会产生相应的场景，真正做到“想得到，就看得到”。

根据VR 技术对沉浸程度的高低和交互程度的不同，将VR 系统划分了4 种类型：沉浸式VR 系统、桌面式VR 系统、增强式VR 系统、分布式VR 系统。

而增强式VR 系统简称增强现实（Augmented Reality），就是我们经常说的在手机上应用比较多的AR了。它既允许用户看到真实世界，同时也能看到叠加在真实世界上的虚拟对象，它是把真实环境和虚拟环境结合起来的一种系统。AR中真实物体和虚拟物体与用户环境必须无缝结合在一起，而且真实物体和虚拟物体之间还要能够进行交互，这样才能实现真正的虚实融合。因此增强现实系统具有虚实结合、实时交互、三维定向的新特点。

好，下面来重点说说增强现实（AR）

一个AR系统需要有显示技术、跟踪和定位技术、界面和可视化技术、标定技术构成。

跟踪和定位技术与标定技术共同完成对位置与方位的检测，并将数据报告给AR 系统，实现被跟踪对象在真实世界里的坐标与虚拟世界中的坐标统一，达到让虚拟物体与用户环境无缝结合的目标。为了生成准确定位，AR系统需要进行大量的标定，测量值包括摄像机参数、视域范围、传感器的偏移、对象定位以及变形等。

 相对与智能手机而言，AR就是根据当前位置（GPS），和视野朝向（指南针）及手机朝向（方向传感器/陀螺仪），在实景中（摄像头）投射出相关信息并在显示设备（屏幕）里展示。其实现的重点在于投影矩阵的获取。

当然，在实际开发的时候其实android系统已经将投影矩阵封装的比较好了，可以通过接口直接获取投影矩阵，然后将相关的坐标转换算成相应的坐标就可以了。

移动增强现实系统应实时跟踪手机在真实场景中的位置及姿态，并根据这些信息计算出虚拟物体在摄像机中的坐标，实现虚拟物体画面与真实场景画面精准匹配，所以，registration（即手机的空间位置和姿态）的性能是增强现实的关键。移动AR的运作原理可以以下面这个图示简单来说明。

OK，科普的事情做完了，下面再来说说AR到底有些啥搞头

1、找到想去的地方

1.1找到我想去的那家店

Yelp Monocle 利用 iPhone 的摄像头和数字罗盘把 Yelp 评分和实时的街景结合起来，这样您就可以找出五星级酒吧而不是误入那些自以为酷的小酒馆了。

1.2找到我的车

当你把车停在路边，并掏出手机启动 Car Finder 时，软件会记录下你的 GPS 信息。之后，当你想在茫茫车海中寻找它时，Car Finder 会利用摄像头，GPS，指南针，陀螺仪等多个传感器把你引导至正确的位置。

1.3指引路径

Wikitude Drive增强现实导航应用，用户看到的不是地图，而是前方街道的实时视图，以及叠加在视频上方的导航数据。现在已经在欧洲、澳大利亚、北美市场得到了应用。

2、“碰”到虚拟的东西

AR SOCCER 虚拟颠球，就是你把屏幕对着一块干净的地板，然后屏幕上会出现一个足球，现在你可以用脚去踹它。

3、令现实按我的想法变化

3.1实景翻译

Word Lens是一个实景翻译的应用，不过目前只提供英语和西班牙语的相互翻译。

3.2虚拟试衣

使用Zugara的虚拟试衣间非常简单。你需要一台带摄像头的电脑和一点空间，后退到离摄像头4-5英尺的地方挥一挥手，你选中的衣物会自动“穿”到你身上。如果你觉得没有“穿好”，你还可以通过微调衣物的位置使其看起来与你更贴合。

3.3拍照

在使用“Farrago AR”时，用户可以轻松通过移动设备的触摸屏对图片内出现的物体进行旋转、调整大小、修正等精细操作。而且，“Farrago AR”友好的用户界面使得用户可以轻松创造出2D或者3D的图片外物体。

4、把虚拟叠加到现实上

伦敦博物馆出了一个增强现实的Apps，称其为“时光机器”，把手机对准当前所在的位置，那么系统会帮你匹配当前位置几十年前的样子。

Layar Reality Browser 把摄像头对准周遭的景物，Layar 会把各种数据找出来——巴士站、滑板公园以及房地产价格等等。

Wikitude 被称为“世界浏览器”，它可以帮你探索周围的环境，查找地标的资料。只要你举起手机并打开摄像头，屏幕上就会出现一些标记——包括维基百科词条，带 GEO 标签的 Tweet，ATM 的位置。

Star Walk，增强现实的“天文互动指南”，利用GPS，指南针和陀螺仪教你辨别星座。 还有很多类似的游戏，比如星球大战AR版、AR Invaders（打飞碟）、AR Missile（导弹毁人）、ARBasketball（实景篮球）…..

最后，说一下几个基于AR做平台的

1、高通

高通放出了android平台和ios平台上上的augmented reality develop kit。基于这个SDK开发人员更容易的运用智能设施中的摄像头，开端出实在内容与虚构内容联结的软件利用。

2、Layar

Layar旨在打造的一个开放的增强现实的平台，任何第三方都可以通过Layar的开发接口来打造基于Layar的自己的增强现实应用。目前其官方网站上列出的应用有2029个，其应用类型包括教育，游戏，建筑，艺术，交通，游戏等等；你也可以把Layar看做专门为AR应用搭建的App Store，因为里面的应用有免费的，也有收费的。

最后，说点扯淡的事情

移动硬件设备的发展使得人们在移动设备上的交互有了突破性的进展，以NFC、AR、裸眼3D等为代表的一大批应用形态的涌现给这个领域带来了最够的新奇与动力，创造了全新的用户体验。而在移动产品的设计上，如何利用手机的硬件性能来创造突破性的产品将是未来决定移动产品设计师能力以及移动产品成败的关键了。

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

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

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

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

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

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

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

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

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

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

Keynote，诞生于2003年，是苹果公司推出的运行于Mac OS X操作系统下的演示幻灯片应用软件。
下载：官方正版（648元） ； 破解版

Keynote Remote，通过Wi-Fi将iPod touch/iPhone变成无线遥控器，你便可以自在地在房间的任何角落演示Keynote。更牛逼的是，它不断能控制播放，还可以把备注也显示到iphone的屏幕上。这样就不需要每次讲着讲着还要苦逼的回去倒腾一下电脑翻页啦！

下载：官方正版（$0.99） ； 破解版 ，另同步推可以直接下载安装破解版本

对于Keynote，无需多言，这绝对是目前最牛逼的幻灯片演示程序了，一切尽在不言中。不过，仅有Keynote其实还不算牛逼，搭配上Keynote Remote之后才是真正的牛逼无敌啦！

Keynote Remote使用要求：

1、Keynote ’09或以上版本
2、iOS 4.2.1 或更高版本，支持 iPhone、 iPod touch、 iPad
3、必须使Mac os和ios在同一Wifi环境下

所以，如果正好你的Mac os跟ios设备使用的是同样的WIFI网络，那装比就很简单，直接跟进使用指南操作就可以建立连接，然后开启控制了。具体操作指南在这里（猛击我）。

简单说就是：

1、打开Keynote，在偏好设置里选择“Remote” 并选择启用遥控器；
2、在ios上打开Keynote Remote 应用程序，然后轻按“链接到 Keynote”按钮；
3、在 iOS 设备上，轻按“新建 Keynote 链接”以显示 4 位数密码
4、在Mac os的Remote里会看到ios设备，点击连接并输入4位数密码
5、enjoy it！

但是，如果Mac os和ios不在同一个Wifi环境下（Mac os连接wifi A，ios连接Wifi B），或者演讲时压根没有Wifi环境该如何处理呢？在没有Wifi的时候可以这样使用Keynote Remote ，采用不用路由器直接使用

1、在Mac os下点击“创建网络” ，名称输入你的ios 设备名称（如iphone）即可 ，频道值为默认即可，密码可以为空；
2、在Mac os下选择连接到刚才建立的那个连接（iphone），无线信号图标就变成了一个小电脑；
3、在ios设备的Wifi连接中同样选择加入在Mac os下建立的那个连接（iphone），这样就建立了一个computer－to－computer连接了；
4、打开Keynote Remote ，按照之前的方式完成配对。（如果连接不上，需要进入Mac os的系统设置－共享里打开屏幕共享）
5、enjoy it！

以后有分享如果是需要拿着话筒的话就再也不用苦逼的一边拿着话筒一边说话再一边敲电脑啦~演讲，就该像乔帮主般的优雅！

嗯，对了其实Air video也蛮好玩的。

关于文案的重要性

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

关于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个层面的交互，单页面的交互和系统层面的交互。单页面的交互是最常见的对交互设计师的定位，比如把一个注册和登录页面做到极致，把一个搜索框体验做到最好；而系统的交互则是各个页面之间的交互，各个页面之间如何更好的联系在一起，目前显见交互设计师谈到这方面的话题了。

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

1、需求分析阶段

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

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

2、需求第一次传递

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

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

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

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

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

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

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

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

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

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

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

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

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