订阅

设计鱼池

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

设计鱼池,需要这样几个步骤:

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

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

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

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

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

  • 核心功能足够突出

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

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

  • 非常用功能可以找到

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

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

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

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

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

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

 

产品的信任感

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

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

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

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

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

  • 通过文案传递信任感

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

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

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

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

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

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

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

  • 通过人来传递信任感

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

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

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

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

信仰的微光

2004年,我第二次高考,终于拿到了一个很好的分数。我想我终于可以走出这个小山村了,好好的看看外面的世界。对于未来,我充满了期待。

于是,我坐了40分钟的拖拉机走出村子来到镇上,然后坐30分钟的小巴车到县里,然后坐2个小时的中巴车到市里,然后坐22个小时的火车来到了我的大学。然而,当我走下火车的那一刻,哑然失笑。原来,我只是从中国中部的一个小地方,长途跋涉到了中国北部的另外一个小地方,于是而已!

在这个荒凉的小县城,互联网成为了慰籍我大学4年唯一的事物。从那个时候开始,我爱上互联网,最终形成了对它无限的信仰,这种信仰一直指引着我,不断的前进。

在别人使用互联网玩游戏的时候,我开始到处浏览网页,获取信息,这个过程中,我不断的感受到不爽。于是,我开始思考,为什么会这么不爽,如果是我来做的话,我会怎么做。后来,我大学毕业,真的就开始来尝试自己改进他们了。慢慢的,我知道,让我不爽的那些什物叫做互联网产品,而我想要做的事情叫做互联网产品设计,我的想法的出发点叫做以用户为中心…..再后来,我不断的改进他们,从最初的按钮摆放的不爽,到后来为什么要摆放这个按钮,再到后来为什么要做这个东西…..后来,我知道,哦,我是个产品经理

4年的时光,一个轮回,对互联网的信仰的微光不断照耀着我走下去,义无反顾。4年的时光,那些同学回到家乡娶妻生子,等待他们孩子的轮回;4年的时光,那些同学在不同的城市吃力打拼,向生活低头;4年的时光,那些同学成为人父,与我聊着世道艰辛……

虽然,谈信仰,在这个国度,在这个国度的互联网,在这个国度的互联网产品设计,是一件看起来很奢侈也是很讽刺的事情。但是,我还是想固执的坚持一下,因为我还年轻,因为我还有梦想。

4年的时光,我目睹了互联网变的越来越封闭;4年的时光,我目睹了太多的互联网产品一闪而过,也目睹了太多的互联网产品迅速崛起;4年的时光,我看到一大批与我拥有同样信仰的人们在不断打拼;4年时光,我看到更多的毫无底线的人在互联网上无耻的抄袭与掠夺……

4年的时光,之前的豪情万丈不断变现。我终于知道,其实,我只需要籍着信仰的微光前行,足矣!我需要的不是去改变世界,改变世界这种小事交给更牛逼的人去做就可以了,我需要做的就是做一个自己喜欢的,让自己足够爽的产品。我要用自己的信仰去打造这款产品,把我的价值观、我的性格融入其中。这是一件足够让我义无反顾的事情,而且,我已经等不急了!

嗯,是的,我等不急了!籍着信仰的微光,义无反顾的潜行在我信仰的互联网。

 

— 2012年10月8日,从北京飞往上海的路上。

说说抽屉式导航

导航始终是产品设计的重头戏,不管在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。

我想要的网盘

忽如一夜春风来,满眼尽是网盘开。设备越来越多,需要协同操作;工作地点越来越分散,需要协同备份。所以,网盘是个很重要的工具。但是,我想要的网盘不仅仅止于此。

网盘不应该只是我的第二块硬盘,它应该是我的一个随身操作系统。

  • 不仅仅是存储,更应该是可以随时随地编辑

允许我将数据同步在云端,然后通过不同的设备同步下载下来,在我的Android、iphone、ipad、pc、mac、…等上进行展示与编辑。对,编辑,这很重要!

存放在“硬盘”里的数据是毫无意义的,仅仅作为硬盘来设计的网盘产品也是不会有持久生命力的,我需要的不仅仅是存储。在网盘的产品设计中,可以采用插件的方式来实现在网盘里直接对数据进行编辑,之后再同步会云端,最后分发到不同的设备上去。

  • 权限应该分级,最终目标应该是可以把任意数据都装进去

不应该限制我同步的数据来源及数据类型还有数据量,如果我达到某个门槛,我就可以备份我某台设备上的任意位置的任意数据到云端,然后通过不过设备下载下来,然后,进行展示与编辑。

什么样的数据是有价值的?这个问题不应该只从网盘本身去考虑,应该是由用户层面和网盘层面同时去考虑。从产品设计角度讲,可以对用户进行分级,只要用户通过努力达到某个阶段,那,他就有更多的使用权限。而至于为了达到这个阶段用户需要做的事情则可以有很多了。

  • 安全性,这个很重要

我应该可以自己对数据进行第二次加密或者对访问权限做加密,因为我的数据会在不同的设备上流转,所以,这很重要。

  • 鼓励分享

网盘这个事情就有点像码头,用户将自己大量的珍宝存放在你这里,存放占地是你的,存放保险柜也是你的,但是,你只能站在门外,对只能站在门外,连往里看一眼都不能。所以,如果可以鼓励用户将他们存储在网盘的数据分享出来,那么,不论是从网盘本身角度看还是从整体的网络发展来看,都是有益的。

但是,网盘能做的仅仅是鼓励,过犹不及,用户始终有全部的选择权。用户可以选择分享哪些数据,什么时候分享,分享到什么平台上。

整体上说,网盘应该是一个平台化的东西,而不是仅仅的存储介质,考验的是大数据存储的能力更是系统化与平台化的能力。

好了,意淫完毕,收工。

产品的自我营销能力

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

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

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

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

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

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

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

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

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

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

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

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

ios设备屏幕实时投影和去掉app某个语言包

标题有点长,其实是想说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客户端
  • 出行生活:百度地图 ,在中国他比较准一点点 ;下厨房 ,有爱的设计 ;快捷酒店管家 ,这个家伙号称开房利器,男人不装会显得很没面子….

基于axure的PRD协作

大约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期

在一整天的会议结束之后,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系统的导航

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

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

(图片来源:Tapworthy

平铺列表

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

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

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

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

标签页

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

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

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

树状结构

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

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

3类导航模式的比较

导航模式

优点

缺点

代表应用

平铺列表

适于信息架构及简的浏览性页面;
内容可自定义且数量可变;
隐喻明显,手势单一;
占用页面空间少;
无法快速进行跳转翻页;
最多只能容纳20个页面;
难以包容滚屏,对长文本不利;
页面指示器不够明显,其他页面容易被忽略;
天气

标签页

点击一次即可访问应用所有的主要功能;
清楚告知用户主要功能和当前所在;
只能显示5个;
应用的大多数页面都会始终占据一定的屏幕空间;
Instagram

树状结构

处理大量的类别、功能和类目;
组织方式的隐喻容易理解;
可直接对内容进行交互,占用屏幕空间小;
适合用户自定义分类;
主功能只有在最顶层才会被显示,不能在每个页面都展现;
主功能和分类直接切换比较麻烦,必须先回到顶层;

Mail

Facebook

导航模式的组合应用

平铺列表、标签页、树状结构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势头可观,但目前不太适合小队伍入场,大团队可先做储备。