因为前段时间我们团队做了个微信公号，叫做“订酒店”（加订酒店为好友即可）。在微信上实现了在线预订快捷酒店的功能，已被众多微信公号模仿，基本上成为了微信公号利用地理位置的标杆，算是小有创新吧，所以，最近很多媒体朋友找我约稿，问我怎么看微信的开放平台，问我微信的出现会对移动互联网的发展有什么影响？

这一问，真心把我问住了，我向来看的都比较短浅，远没有把握行业发展趋势的能力，做产品也是打到哪儿就走到哪儿。关于微信“订酒店”这个公号的由来，之前在知乎已经回答过一次，不再赘述。当然，这篇文章我也谈不出来任何关于微信开放平台的看法，只是最近在做产品的时候想到个事情，随手记在这里。

我们都知道，链接是整个互联网的基础，在Web时代，相互的链接让整个互联网充满活力。以浏览器为载体，各个产品之间相互链接，用户在不同产品之间流转，形成一套系统。以链接为基础也衍生出“入口”这个词，典型的如搜索引擎、导航网站等。而一个产品在不断的衍生下会形成各种子产品，这些子产品继续通过链接跳转来细分用户，并在一个网站中完成用户的所有需求。

然而，在移动互联网时代，这种链接在很长的时间里，不work了。取而代之的是一个个独立的APP，APP之间是孤立的，不能相互链接与跳转。这种形式使得APP产品从专注的满足用户某一个独立的需求出发，反而做出另外一番繁华。

但是，越来越多的APP，且不说手机容量如何，即使是整理也是一个费劲的事情。我之前说，APP被用户下载了，只是万里长征的第一步，下面还有是否会被打开，是否会被保留，是否会在使用的时候被记起来，等等…..之前我的手机里面装了超过200个APP，但是经常使用的却非常少。很多APP在用户的手机里根本没有曝光的机会….这是每个做APP的产品必须要面对的问题。

在很长的时间里，大家坚持做一个细分的APP来满足用户，很多大公司也坚持把自己的APP分拆出来，做成APP群，每个细分产品一个独立的APP，去运营，去获取用户。原因只有一个，用户不需要大而全的APP，独立的细分APP可以做的更好，体验更优秀。但是，用户真的是不需要大而全的APP吗？我保持怀疑。

微信的出现，第一次使用了“插件系统”这个形式。当时，我就说，这是微信最伟大的地方之一，也是未来微信最具有发展潜力的地方之一。因为插件系统的出现使得一个APP的扩展成为可能，同时，插件系统是一个用户自助的系统，且很灵活，这真是个天才的想法！

后来，微信实现了与APP之间的相互调用。通过APP分享一条信息给微信，微信判断用户是否安装了该APP，如果安装了，直接调起，然后进入该信息的展示页面。这太酷了，这不就是入口吗！那些坐拥巨大流量，号称着开放的大产品，你们在想什么呢？

微信的这种开放性尝试，第一次实现了APP之间的“链接”。这种链接是如此轻巧与共赢的，第一次，用户在移动互联网上也可以实现跳转了，虽然看起来不是那么轻盈，但，这已经很酷了。

实际上，微信订酒店在微信上的尝试，是我的另外一个思考。作为小的APP开发者，在市场推广完全无法于大鳄们抗衡的时候，我们是否可以通过其他途径来突围？我向来认为，弱小的时候傍大款是个很好的方式，只要你能保持住品牌的独立。所以，借助微信的开放平台，我们做了这么一个事情。

Allen Zhang看完我们的微信公号之后说了一句话，在未来，每个微信公号就是一个APP。说实话，第一个版本的时候，我其实没太理解这句话的意思，因为只能实现基础的查询与电话调用。后来，我们再继续往下走，我们发现，在微信上，可以实现完整的产品流程的，用户查询酒店，在线预订，管理订单。这事跟在APP上可以实现的功能完全一致，只是我们换了一种方式去交互。是的，在微信上，每个微信公号真的可以就是一个APP，一个有完整的体验流程的APP。

微信这种做法，跟之前调起APP是一个思路，让APP之间形成链接，去建立不同APP之间的联系。然后再往下，这真是个牛逼的思路啊！就跟360消灭了IE6这个毒瘤类似，微信是否会让HTML5重现光明？我很期待.

媒体朋友们不断问我，你怎么看微信的开放平台，微信接入电商是否有戏，微信做O2O会不会成功，微信会不会成为移动互联网的入口，….我，真的不知道。我也不关心，我只关心，微信是否真的足够开放，我的用户是否在微信上如果需要订快捷酒店了，那会是什么样的场景？他们需要我们给予什么样的帮助，我们需要怎么去解决这个问题。因为，我是个做产品的。

有的时候，我常常无法进入状态，这个时候我会选择看书。一本好书有一种力量，一种代入感的力量，会让你随着做着的逻辑一路陷入进去，慢慢的将内心的浮躁都洗去，让你沉静下来，然后整个人也跟着沉了下来。

最近书荒，我甚至都开始重新看《金庸全集》了，因为那些写书人的套路似乎都固定下来了。如果是写个产品的书，来来回回就那么点事情，反反复复的那种结构，看的了无生趣，就连举的那些例子都让你觉得厌恶了；如果是写经济的书，总觉得敲不到点子上，看着看着就走神了；如果是写小说的书，唉，还是算了吧….

一本好书，跟一款好的产品类似，要有一种“代入”的力量。能够让用户跟着你设定的逻辑一路走下去，一种心无旁骛的沉静。每个章节，每个功能模块，都如同空气，似有如无，但是又让人欲罢不能。平淡无奇的呈现反而最有杀伤力，柴姑娘的《看见》就是这样，真实，自有万钧之力。

学会平常说话，平淡无奇的呈现，反而是最有杀伤力的，这是柴姑娘自己职业成长的体会。读到这里，心里猛然一震，这不就是我近1年来一直堵在我心中，不知道如何表达的东西吗？

做产品这事，其实完全一样。

刚开始做产品那会儿，我常常想，这个地方是我做过设计的，我一定要想办法告诉用户，拼了命的产品里做提示，想让用户知道。你看，我这里做了设计了哦，多酷啊，我想了好久才设计出来的哦，你来看看….在我的眼中，这就是设计，一个功能一定要加一点修饰，这样才叫“设计感”，这是一件多牛逼的事情。

再后来，我发现，其实除了那帮同样是做产品的人之外，平常用户根本不买账，这真是件自作多情的事情。然后有些刚入行的朋友会给你评论，“这个交互做的真赞”，“这个导航的样式处理的真好”，“这个很创新”，“这个图标很有设计感”….开始的时候，自己沾沾自喜，你看，还是有人识货的吗！但是，偷偷观察用户操作的时候，傻眼了，没人跟你想像中的那样操作，因为，这是你的“设计”，你的眼里只有设计，没有用户。而那些同行的评论完全都是在黑你啊，因为压根不是你的用户…..

于是，慢慢的，我的产品里很少有刻意的设计，即使有，也不会刻意的提示用户。躲在后面观察，如果用户觉得不爽了，立刻拿掉。我开始去思考背后的事情，那就是，“如何讲好一个故事”，如何去设计一种“代入”的感觉，如何帮助用户更顺畅的解决问题，用一种接近与平常的形式。

我告诉跟我合作的设计师和研发，我们不是在“设计”什么东西，我们是在帮助用户达到，达到他的目标。比如，在寒冬的夜晚，找到最近的一家酒店落脚；在一个陌生的地方，下了火车，知道怎么去他预订的酒店。这些东西，需要设计，但是，不是之前的那种设计。

我们所用过的所有的优秀的产品，其核心必然都是以一种很平常的接近于我们的生活的形式来表现的，这是一种设计，一种真正的设计。

但是，当一款产品成功之后，会有很多人基于结果去评论，用他们的标准去评判，觉得这是“招式”华丽的结果。当你看多了这种评论，你真就觉得，招式很重要，投入过多的精力去做界面的设计，交互的设计，唯独忽略了对产品本身要解决的问题的思考。其实，这些就跟会点水袖功夫一样，上阵杀敌时一概用不上！

对产品本源认识有多深，呈现才有多深。而你越接近这个深度，你越感觉到，其实，那些华丽的修饰，完全没有必要，一种平常的展示就足够了，足够直指人心！

最后，感谢柴姑娘这本好书。

这是一篇和科技博客“雷锋网”的聊天备忘录，简单分享一下快捷酒店管家这款产品的一些设计思路，以及快捷酒店管家团队在运作过程中是如何相互配合的。没有什么建设性的意见，只是一些犯过的错误的总结。

Q:酒店管家产品团队目前都有哪些主要成员，分享一下你们各自的经历吧。

Kentzhu：快捷酒店管家主要成员10个人，清一色的帅哥。

我在拥有中国最好的煤炭专业的辽宁工程技术大学学习，在一个理工类学校学习的经贸专业。上大学的时候发现自己其实对经贸并不是很感兴趣，偶尔接触到互联网，从此沾上极为严重的网瘾，无法自拔，于是，毕业之后直接钻入了互联网。

刚接触互联网的时候，经常会遇到很多功能自己用的很不爽，于是开始思考，如果是我来做，我会怎么做，怎么做才能让自己觉得很爽。之后，开始尝试自己做，在这个过程中一路跌跌撞撞，有一天，一抬头发现，哦，原来自己做的事情是产品经理。

我目前在快捷酒店管家的职位是产品经理，负责快捷酒店管家的整体产品架构与设计，以及客服类的工作，和部分运营的事情。

Q:谈谈你们的团队，如何形成这种扁平化团队的高效沟通合作的（相信绝大多数创业公司做不到你们这种标准），决策过程中如何走流程、解决问题，多给一些我们这样的效率低下土鳖开发者些建议吧。

Kentzhu：这个问题的帽子有点高了，哈哈，因为我们本身就是土鳖的开发者，也还存在很多可提升的空间。

如前面所说，快捷酒店管家的主要团队现在共10个人。其中，1个人整体负责产品，2个客户端研发（iOS、Android），4个服务端研发，1个运营，1个BD，1个CEO。当然，具体视觉设计的事情由公司的设计团队来给予帮助。

在快捷酒店管家，其实没有相对非常明确的分工，在我们决定要做什么事情之后，这个想法的提出者会跟所有人讲一遍，然后，大家给出建议，之后，他就全权把这个事情做了。

比如，我们最近基于微信做的“订酒店”，需求的基本想法来自于我，但是，研发同学在做的时候，增加了比如地图展示、输入数字给出更详细的信息这些更为丰富的功能，都是负责开发这个小产品的研发自己做上去的，非常棒！

再比如，我们的CEO会经常想出很多好玩的运营活动，比如之前我们为了庆祝十八大闭幕，做了一个“普天同庆巨蟹座”的活动，就是我们CEO的主意。然后，我们30分钟出来策划文案，直接就上线发布了。

说起流程什么的，在快捷酒店管家更加的简单粗暴。我们压根没有什么MRD、PRD什么的，只有几张流程图，稍微复杂的写个1，2，3，4说明以下就完了。更多的需求是直接在白板上确定下来的，大家直接在白板上把草图画出来，然后拍照记录一下就开干了，干的过程中如果有疑问再对着白板讨论一下。当然，作为PM，会有一个简单的存档，以便后续回顾与优化修改。

另外，我们每天都会有站立会，大家说一下昨天的工作及一些问题讨论，然后是今天的工作安排，这是一个我们一直坚持的传统。因为团队每个人的工作必须透明，这样各个角色才能最好的配合起来打仗。

在快捷酒店管家，我们比较崇尚的几个东西：一句话需求，用一句话把要做的事情概括出来；简单粗暴，只为90%的用户服务，暂时不考虑10%的用户；一定要让实际执行的人先搞明白为什么做，然后才是开始去做。

Q:为什么想到做快捷酒店管家款产品，做这个产品是想解决什么样的问题？

Kentzhu：做这个产品的想法很简单，我们无法重新发明快捷酒店，但是，我们可以改变人们在手机上预订快捷酒店的方式。

充分的挖掘智能手机自身所具备的特性，重新的去思考用户在移动场景下的需求与痛点，是完成这个想法的核心方式。整个快捷酒店管家的产品试图去解决这样几个问题：在陌生的城市，找不到附近的快捷酒店；找到了快捷酒店，但是不知道怎么过去；随时随地随手订快捷酒店，提升出差的效率与心情。

Q:以什么方式解决这个问题呢？产品的设计理念，产品都有哪些特色，能给我们一些具体例子吗？

为了达到这个目的，整个快捷酒店管家的产品基调是高效、时尚、好玩。这是一个很好玩很高效的快捷酒店预订应用，所以，你会发现我们很多的设计很多的细节都故意做了设计。

比如，我们用全日房/日房来区别2个不同的类型的房间，我们在全日房那里放了一张床，伴随几丝呼噜声；我们在日房那里直接就放了一卷手纸，简单直接。

比如，我们为了减少用户的输入成本，直接采用了地图拖动到什么地方就可以给你展示什么地方的酒店的方式，然后，在地图的正中央放置了一个小人，他就像是一个“准星”一样，很多用户觉得这个设计非常的好玩。比如，为了更纯粹一点，我们把很多不常用的功能，比如个人资料啊，收藏啊，搜索啊什么的，都放到了侧边的“抽屉”里。再比如，在用户的预订流程中，我们整天采用了“机打发票”的拟物化设计，模拟了在酒店前台付款订酒店的形式。再预订成功之后，我们再盖上一个钢印，提示预订成功。

这些都是非常好玩的地方，而且你会发现，这些好玩的地方丝毫不会影响我们的高效，相反的，在给用户一种很好玩的感觉的同时，也让用户记住了我们。

在快捷酒店管家，我们每天都在创新，在不断的体验创新带来的乐趣，看着自己的创新不断被大家接受，被行业接受。比如，最早的时候酒店预订app采用地图展示酒店的时候都只给个价格，我们认为这样很不友好，所以我们展示了酒店品牌、最低价、房态信息，我们看到越来越多的app在采用我们这个形式，行业老大携程的最新版也已经改成这样了。

Q:快捷酒店管家目前都有哪些商业模型，已有的和有构想的都可以跟大家谈谈

Kentzhu：这个商业模型其实也很简单粗暴，如大家都能猜想到的一样，与快捷酒店分成是主要的商业模型。同时，作为一个典型垂直的LBS应用或者说O2O应用，快捷酒店管家在商业模式上与其他O2O应用有同样可思考与扩展的空间。

但是，细节的模式我们没有时间去思考，因为，我们并不认为现在是思考这些的最佳时间。如何继续打磨产品，做更好的体验才是当务之急。

Q:你们有做竞品分析么，自己对行业趋势都有哪些判断？

Kentzhu：关于竞品，或许说出来你会觉得我装逼，但是，实际上，我真的很少关心和关注竞品，也很少去体验竞品。主要有2个原因，最主要的是因为我不希望自己的想法受到竞品的感染。当你看竞品越多，他们的一些想法和做法就会潜移默化的影响你，让你偏移你最初的想法，不经意间就很有可能被别人带到沟里了。另外，快捷酒店管家目前的模式，并没有在国内找到竞品，呵呵。

我不太清楚你这里的“行业”是如何定义的。如果这个行业指的是移动互联网，借用王兴的一句话，所有没有被移动互联网改造的行业，最终，都会被改造。

Q:给其他的开发者一些建议吧

Kentzhu：并没什么有建设性意义的建议，只想说，如果要选择创业，那就别有太多的想法。先问自己，这事好玩不，和这帮人一起玩爽不。如果觉得好玩，大家一起搞点事很爽，那就开始干吧！

当然，如果你一定要我再给个建议的话，那就还是2句话：千万别看任何国内关于创业的报道和专家的微博，当然，也包括我写的这些。千万别把创业当成一个工作，他首先是一种兴趣，其次才是一份工作。

Q:给一张你们团队的集体照吧，我们放在文章里

Kentzhu：现在的快捷酒店管家的开机封面，就是我们团队所有人咯。这也是我们团队文化的一部分，所有的成绩，团队所有人一起分享。

原载：http://www.leiphone.com/s-inn-team.html

阿福说，做社交类产品其实就像是在建国家。我没有那么高的觉悟，对我来说，做产品就像是在设计鱼池，用户则是游弋其中的鱼，运营和产品就像是水流和鱼池的构造，引导着鱼的活动。

设计鱼池，需要这样几个步骤：

了解你要放进鱼池的鱼的习性，我们把这个叫做目标用户定位；

根据鱼的习性，设计一个可以让他们快速成长，直到可以被卖掉的鱼池模型，我们把这个叫做用户价值定位；

设计鱼池，让鱼较为自然的在其中游弋，我们把这个叫做产品体验设计；

不断引入活水，控制水流方向与鱼池的设计一致，我们把这个叫做营销与运营。

我们单独重点来说说，如何设计鱼池。也就是产品体验设计的过程。鱼池的设计概括起来看就3点：

• 核心功能足够突出

在鱼池中，需要有一个足够宽阔的主干道，大部分的鱼都按照规矩游弋其中。当新的鱼进入鱼池的时候，要首先就能感受到这个主干道，然后跟随着鱼群在其中游弋。这个时候，还同时需要水流流向的辅助（运营引导），让新进入的鱼适应水流，适应主干道，最终形成一定的习惯。

这个就是我们在产品设计中经常说到的核心功能足够突出，同时，不断通过运营的方式去引导用户，去形成用户的习惯。一旦用户形成了习惯，很多事情就很简单了。当然，之后，再改变这个习惯也相应的很困难了。

• 非常用功能可以找到

在鱼池中，一定也会有一些稍微窄一点的道路，有一些稍微有“思想”的鱼会找到这个道路，去完成一些非从众性的需求。这个窄道没有必要被放置的非常明显，也没有必要去做运营，当鱼需要的时候，他扭头或者眼睛稍微找一下就能发现了，这，就足够了。

这个就是我们常说的，非常用功能，藏起来，只要他稍微一找就可以发现就足够了。长按一下、拖动一下、点击一个按钮，你需要的东西就呈现出来了，足够了。

• 禁止的功能封堵的足够彻底

在鱼池中，一定不能允许有鱼逆向游弋，因为有水流来保证；也一定不能允许有鱼横着游，因为有篱笆来保证。

这个就是我们常说的，产品需要有取舍，需要有足够彻底的底线。禁止的功能一定要封堵的足够彻底，以保证产品的纯洁性。

当一个鱼池运作一段时间以后，绝大部分的鱼都应该适应了鱼池里水流的方向以及鱼池中设置的篱笆。假如之前搭建的鱼池无法再承受越来越多的鱼进入，那么，需要做的就是改造篱笆或者在旁边新建一个更大的鱼池。这个就是我们常说的改版和开发新产品了。

互联网产品设计，说到底，其实是设计一种人与机器的交互过程。如同人与人之间的交互一样，信任感是一个极为重要的因素。

作为产品设计而言，如何通过设计去表达这种信任感，去向用户传递“我是真诚的”，我是“可被信赖的”着实是一门很重要的学问。在快捷酒店管家的产品发展过程中，有几次我们走了弯路，最终才在产品设计的信任感上略有小成，记录一下，算是反思。

• 通过第一印象传递信任感

早前的时候，快捷酒店管家的名字其实是“酒店管家”，但是，快捷酒店管家又是一家只能提供快捷酒店预订的APP。所以，很多用户在使用的时候会很失望，他们说，我面前明明就有一个万豪，但是为什么你们不显示呢？这都不显示，你们叫什么管家？

于是，我们就反思，为什么会造成这个情况。后来，我们发现，是因为我们给用户传递了错误的信任感导致的。后来，我们把名字修改为快捷酒店管家。从此，再无用户如此反馈了。

• 通过文案传递信任感

快捷酒店管家是一个采用与快捷酒店进行直连来在线预订快捷酒店的APP。简单说就是，酒店有多少房，我们就会显示有多少房，而不是像OTA那样只有一部分的房。在我们最开始上线的时候，我们一直被用户误认为还是OTA，简单说就是我们的库存优势无法展现出来。于是，后来，我们就把预订按钮的名字修改为“官方直订”。但是，修改之后，用户以为这是通过官方直接预订的，预期是点击之后跳转去官方，还是不够好。最后，我们把这个按钮修改为“官网直销”，从此世界清静了不少。这个“直销”，虽然有一些拗口，但是很大程度上缓解了上面的问题。

• 通过流程提示传递信任感

早前的快捷酒店管家预订流程是这样的，用户点击预订，直接跳转到一个新的填写表单的页面，这个页面跟前一个页面从流程上看跳转很生硬。有用户在跳转的过程中，感觉很疑惑，不知道自己到什么地方了….所以，我们在新的预订流程中，当用户点击了“官网直销”之后，跳转到了一个填写表单的页面，这个页面的顶部会显示用户进来之前选择的那个分店及房型。这样，用户就知道了，哦，我是因为要预订，所以要填写表单，感觉顺畅了很多。

• 通过制造门槛传递信任感

在产品设计中，作为中间方，信任感一定是双向的。快捷酒店信任我们，所以向我们开放全部房态，且不需要担保即可预订；我们当然也需要用户给予足够的信任，才会把房间给你们预订，这是一个生意。所以，我们在给用户制造足够信任感的同时，也希望用户能够给我们一些可信任的。从用户那里获取可信任的感觉，是通过制造门槛来实现的。

快捷酒店管家的第一次预订流程相当的痛苦，你必须填写姓名、身份证、手机号，而且，还需要对手机号做短信验证。在产品刚刚上线的时候，不少互联网的蝗虫用户很不解，很气愤，各种投诉，说找不到注册按钮，说预订个酒店为毛线要验证手机号。幸运的是，我们最终抵挡住了这批蝗虫的攻击，后来他们纷纷离开，我们继续采用这套方式在运作，更多的实实在在来订房的用户完成了这个流程，在下次预订的时候体验了快感，同时，感受到了快捷酒店管家的不一样的快捷服务。

这是一个人为制造的门槛，目的就是为了获取信任感，无他。因为，我们坚信信任是双方的。

• 通过人来传递信任感

在快捷酒店管家，微博客服、电话客服全部是由我来完成的，由产品经理亲自来解答。你发给快捷酒店管的每个@ 每个Email，都是我亲自拆阅，亲自回复的。我认为，这会传递一种感觉给用户，我们是一个“活”的团队，是有实实在在的人在做产品的。

• 通过制造恐慌或者恐吓来传递信任感

在这个方面，某数字公司是最拿手的。当然，也是因为他所在的安全领域的特殊性决定的。简单来讲，比如“您的系统有XX个严重漏洞”，再搭配上醒目的红色和跟你的财产相关的破坏性提示，这是一个无形的推手。

当然，信任感同样需要把握度。不要让信任感的传递变成一种王婆卖瓜或者一种没完没了的唠叨。比如，某个APP在加载的时候会弹出一个提示，“XXX上市企业”、“拥有XXX”…..这些，还是歇歇吧

导航始终是产品设计的重头戏，不管在Web端设计还是在mobile的设计中。之前曾经在读《触动人心》的时候写过一篇“移动产品设计之ios导航模式”，其中的导航模式基本都是基于ios系统自身的一些模式，随着ios新产品的不断出现，新的导航方式也随之更新，这里说一下“抽屉式”的导航方式。

当然，抽屉式导航是我自己给这种导航方式取的名字，至于学名叫什么，我也不知道。这种导航模式一般采用将导航主体隐藏在app侧边的方式，以一个按钮来呼出导航，在使用完成之后在使用相同的按钮隐藏起来。一拉一缩，从形象上与抽屉类似，于是我这样称呼他。

根据我不完全的考证，这种导航方式始于Facebook。在最早的Facebook App中，一直采用了比较保守的九宫格导航方式，随着FB的发展，这种很重的导航方式会导致用户Timeline的展示被很大程度上弱化，虽然FB也曾尝试在用户进入App的时候直接进入Timeline而不是这个九宫格导航，但是，显然这种优化还不是足够好。于是，在2011年11月左右，FB发布了新的ios和android客户端，其中一个重要的变化就是导航模式的变化，推出了新的抽屉式的导航，同时强化了对Timeline的展示。

FB推出这种新的导航模式不久，Gmail的ios版本同样采用了这种导航模式，再之后path 2.0版本也采用了这种抽屉式导航并将其演变到极致。至此，这种抽屉式的导航模式迅速窜红与ios产品设计中。

简单的定义

一般控制抽屉的把手出现在App的左上角，以按钮的形式出现，点击按钮之后抽屉被拉开，按钮被拉到App的右上角，左侧区域被拉开（抽屉）后显示出导航内容。导航的内容可以是以列表形式展示的常规2级导航，也可以将一些非常用的快捷操作入口直接放进来，如FB的搜索。具体形式如下图

当然，这种抽屉也存在一些变种，目前以path和sparrow较为突出。path不仅将主导航作为一种抽屉，同时底部的操作按钮也是一种变种的抽屉；而sparrow则增加了抽屉的层级，在一级抽屉被打开之后还可以再继续拉开一层抽屉。另外，米途订酒店则将全部的酒店预订过程化作一种抽屉，也是一种很不错的形式。

另外，对于一些需要用到消息提醒的应用，抽屉的出现会给消息的展示带来新的麻烦，因此，很多的抽屉导航会将消息展示在Title区域里，以一个入口的形式来展示。典型的如Facebook、快捷酒店管家。

抽屉导航的核心思路

抽屉式导航的核心思路是“隐藏”。隐藏非核心的操作与功能，让用户更专注于核心的功能操作上去。个人认为，隐藏的思维是移动产品设计中最核心的一个思想。上周在极客公园分享了关于如何应用缩小、隐藏、赋加的思路来做移动产品设计的话题，而这个思路中最最核心的恰恰是隐藏。

Facebook中，用户核心的操作是阅读Timline，所以抽屉里隐藏了所有其他的操作；Path中，用户的核心操作还是看好友的Timeline，所以抽屉里隐藏了其他的操作，同时UGC的操作又必不可少，因此path在左下角也用了一个抽屉；在Sparrow里，用户看新邮件的频率大于查看归档邮件的频率，因此抽屉里隐藏了邮件类型等操作，同时为了平衡发邮件的需求，在右下角单独留了一个入口；在快捷酒店管家里，用户的核心操作是通过地图寻找附近的快捷酒店，所以抽屉里隐藏了切换城市等其他操作…..

3月份的时候我曾在微博上说，这种导航方式会逐渐流行，推测的依据就是随着移动产品设计的演进，越来越多的产品设计师开始认识到只有让核心更突出才能提高整体产品的体验，只有不断降低用户的干扰才能不断提高用户的使用效率。

不适合抽屉式导航的App

需要用户不断在导航间进行切换的App、没必要有太多导航的App、或者核心功能就是一堆入口的App。

在快捷酒店管家2.0上线之后，有不少产品同行提了很多很棒的建议，当然，也有一些“体验问题”其实是我们有意违背“用户体验原则”来做的。集中在这样几个问题上：

地图展示房态：红色表示满房、绿色表示有房、黄色表示房态暂时无法获取，这个是有背视觉设计原则的。从视觉设计的原则上看，应该是灰色表示满房，因为满房了，用户无法预订，所以要在视觉上弱化；而红色应该表示有房，因为有房，所以要在视觉上做突出，引导用户去做预订。

地图展示酒店信息：当前是不管有没有房，全部列出来同时以不同颜色去展示，这个是有背用户体验原则的。从用户体验的基本原则上看，如果某个项目没有了，那就不应该展示出来给用户看，降低用户的筛选成本。所以，如果无房的话，那地图上就不应该再展示这家店了。

没有独立的注册流程：如果用户第一次进来的话，只有一个登录按钮，但是找不到注册的入口，用户不知道怎么注册。这个也有大大的有被用户体验原则的，因为要给用户明确的入口。

OK。以上的问题，如果单从“用户体验”本身来看，确实都是问题，而且是很显而易见的问题。不过，针对这些问题，我在做这款产品的时候确确实实是都仔细反复考虑过的。我认为，当前我们的做法恰恰是超越用户体验本身的另一种好的体验。

地图展示房态的问题其实是延续了快捷酒店管家1.0的设计风格。为什么没有替换掉这个违反了视觉原则的设计呢？原因很简单，我们发现很多用户会在微博上截图晒房态信息。比如在情人节、周末的时候因为大片的满房导致出现一大块区域都是红色的情况，很多用户会截图发微博，戏称祖国山河一片红。换句话说，这种设计已经被快捷酒店管家的用户所接受并形成了用户习惯。同时，这种设计也让整个产品在无形中多了一些自我营销的能力，用户可以根据这个颜色的出现来配合特定的时间来形成话题。

地图展示酒店的信息，认为要将没有房的酒店直接从地图上拿掉的看法其实是纯站在了用户的角度分析这个问题。然而，快捷酒店管家不仅仅是给用户（要订房）的人用的，有部分用户是订完之后看酒店的路线的，同时我们希望快捷酒店的店长们也可以加入进来，以及其他对快捷酒店关心的人也在使用。当然，预订酒店是这个产品不可否认的最最核心的功能，但是，在不影响这个核心功能的前提下它还可以更多的承载一些事情。比如，类似房态展示的话题性产品自我营销；比如用户对某个区域的房态评估，以决定行程；比如，店长对快捷酒店生意的直观判断等。

关于独立的注册流程，这个在最初的版本设计里确实太过粗暴。原因在与我过份的低估了之前的一些产品对用户的洗脑作用，要先注册才可以使用，或者即使不使用也要注册一下，留个尿迹神马的。在这个模块的设计里，我们认为通过在线预订而成为我们的注册用户才是真正有价值的用户，而没有经过在线预订而进行注册的用户显然不是。所以，我们将注册流程混合在在线预订里了，这样后续我们对用户价值的评估就会更简单。虽然，这是一个看似违反用户体验原则的设计，但是，从其背后我们需要达到的产品目的看，我认为我们的尝试是合理的。

实际上，除了第三个问题之外。前面2个跟体验相关的问题都是我们有意为之的。我们故意违反了用户体验基本原则，因为这样做可以达到其他的目的，而这个目的对产品而言相当重要的。因为，作为一个工具类的产品，这个产品必须要具备自我营销的能力，这个能力要在产品设计的初期就由产品经理定义清楚并通过设计的手段去实现。

在快捷酒店管家2.0的设计里，还有其他非常多的具备自我营销能力的细节。比如，为用户津津乐道的日房/全日房图标，一卷卫生纸和一张床；比如，当日房不在预订时限内的替代界面；比如，在在线预订过程中你将你的名字写成“测试”或者将手机号填写为“13800138000”，比如….这些都是我们在设计过程中不断思考的如果让这款产品显得更酷更好玩更适合我们所定位的都市潮人的一些体现。

最近关于什么是好的用户体验的话题引发了一阵不小的骚动性讨论。在我看来，好的用户体验就是要帮助产品达成产品目标实现产品价值。这才是真正的用户体验的价值。当然，在这个过程中，你可以将用户体验神话掉，但是，任何脱离了产品本身来谈用户体验的做法都是无意义的，错误的，和误入歧途的。用户体验其实是个很朴素的事情，只要你站在产品的最源头去看这个事情，想象着整个产品是一个系统，你要利用所谓的用户体验使这个系统很好的循环起来，那就足够了。

最后，打一下广告，欢迎下载体验快捷酒店管家，一款被用户戏称为“开房利器”的快捷酒店在线预订软件，不但找房准、订房快，而且还很好玩哦！（p.s：当前只有ios、android版本，WP7版本我们正在开发中。）

常常会收到一些邮件，问题类似，就是说自己做互联网有段时间了想转行做产品问是否可以，如果要是转行做产品经理的话需要注意哪些东西，根据当前从事的工作还需要有哪些提高。给我写邮件的朋友描述各自当前的情况各有不同，但是归根结底的问题都类似，所以，我给归类拿出来回复一下。倒不是我懒，也不是其他的，只是觉得存在共性，为了减少重复沟通成本所以总结一下。当然，也欢迎继续深入交流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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势头可观，但目前不太适合小队伍入场，大团队可先做储备。

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

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个前提：第一枪一定要打响，不然以后你就算再勃起的高也没人看了；在快的同时需要考虑自己是否有能力应对“快问题”并及时完美解决掉，是否有足够精力应付快之后被拉长的战线，不然就是快刀子也容易剌到手！

特别说明：细节黑洞时间这个词来源于一条微博，作者画了一张很大很纠结的一个产品研发流程。看完颇多感受，结合自己的感受写出了以上文字。