幻风阁|kent.zhu'sBlog

标题有点长，其实是想说2个ios系统的小技巧。

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、你会给自己多久的时间来适应和学习？

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

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

我有个习惯，每天晚上睡前会搜罗一遍最新的App用用。最开始的时候ios的App还相对比较朴实，强调功能的实用性，后来不知何故吹起一阵ios的App必须足够精美的怪风。于是乎，各类App纷纷上演换装游戏，一个比一个做的精美，即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……

比如，为了高雅和精美某个支付网站的首页上弄个美娇娘抱着个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客户端
• 出行生活：百度地图 ，在中国他比较准一点点 ；下厨房 ，有爱的设计 ；快捷酒店管家 ，这个家伙号称开房利器，男人不装会显得很没面子….

大约1年多前我写了一篇《基于axure的PRD写作思考》，其主旨思想是将文档版本的PRD与线框图及流程图结合起来，统一由axure来输出，降低PM与研发之间的沟通成本及交付物的传递成本。

当时这个文档是基于我做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年的最后1天基本上也就快完蛋了。花了15块钱吃了一份有饭有肉有肠还有汤的田老师之后，到家已经是22点。我终于有时间有毅力有决心的打开电脑开始写2011年的故事汇…..

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

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

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

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

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

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

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

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

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

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

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

……

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

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

有个故事，是这样的：

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

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

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

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

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

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

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

…..

以上，欢迎任意联想。

写在前面：刚开始接触移动产品设计的时候对着设计指南懵懵懂懂的感知了一下，但是还是不甚寥寥。最近读《触动人心》，发现作者对ios的导航模式的总结实在太棒了，于是写下这篇读书笔记。

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

（图片来源：Tapworthy）

平铺列表

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

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

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

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

标签页

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

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

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

树状结构

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

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

3类导航模式的比较

导航模式的组合应用

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

模态视图

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

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

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

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

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

按照我的理解，场景、任务、用户可以称之为设计的三要素，每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的。同样的设计遇到不一样的场景就会有不一样的方式，从Web设计到移动产品设计亦然。

曾经有个朋友问我，从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等，这里不再赘述。

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