写在前面：刚开始接触移动产品设计的时候对着设计指南懵懵懂懂的感知了一下，但是还是不甚寥寥。最近读《触动人心》，发现作者对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等，这里不再赘述。

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

知乎上有个问题问“除了 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、二维码定位：

在产品设计的路上一路走来，经历了几个阶段：初入行时奉很多东西为圭臬，因为然，所以然；之后慢慢深入开始想为什么是这样而不是那样，对已经这样了的产品也少了很多指责，更多的是探究其之所以如此的原因，知其然，知其所以然；再后来是，知其所以然之后不禁叹息，如果努力是否可以做的更好，是否能够解决障碍呢？知其然，使其可以然。

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

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

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

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

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

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

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

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

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

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

基本上，熟悉我的人都知道，我是个低俗的人。然后我最擅长的事情是用黄段子举例子讲道理，这点看过我的文章的人都知道。倒不是我拿低俗说事儿以为低俗有多牛逼，而是我的经验证明，妈的，黄段子比较能让人记忆深刻。前2天我正在微博上严肃的用一个段子很正经的在讲述文案的重要性，然后坏人把这个段子复制到了UCDChina的群里，之后这帮人就开始了黄段子与用户体验的讨论…..我总结一下，列到博客里，虽然白鸦在微博上已经发了一部分

关于文案的重要性

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

关于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篇文章大致来表述对于两者之间关系的我的一些观点，在“我理解的产品经理”中我认为产品经理需要同时关注产品设计、工程技术、产品运营3个方面；在“基于axure的PRD写作思考”中我简述了在没有交互设计师辅助的情况下产品经理如何做一个更像样的“破画图”的。今天，结合最近的一些项目经验，总结一下产品经理如何更好的跟交互设计师合作。

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

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

1、需求分析阶段

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

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

2、需求第一次传递

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

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

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

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

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

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

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

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

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

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

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

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

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