标签归档:移动产品设计

产品设计之尊重常识

749a10588158e10aa9728e5da0c1a54fdb9c73e114ec6-d0XRZ1_fw658我们先来说说常识这件事。

什么叫常识呢?在我的理解里,说出来大家都能第一时间理解,但是,一到实际情况就会被忽略的,大概就是常识了。

比如,

题图是一张关于流量获取的常识,想要便宜且精准且大量,这样的流量臣妾是一定办不到的;

再比如,

想要快,想要便宜,还要服务好,这样的专车,也一定不会存在的;

再比如,

想要设计师很快完成设计,想要高质量的设计,还给设计师很少的薪水,这样的设计师,如果有,请联系我,我愿意出三倍的价钱!

还比如,

用户都喜欢干净简单的页面;

再比如,

用户都不喜欢找,也不喜欢繁琐的操作;

再比如,

如果这个事情不能做,你要提前告诉我,我错了,你要告诉我怎么做才是合适的;

尊重常识就是回归本质,而尊重常识是产品设计理念的起点。

你可以从这个起点延伸出很多理论观点,比如不是以用户为中心来设计的产品体验一定不会好;比如不符合用户基本预期的设计一定是别扭错误的;比如没有合适场景的产品功能一定是无意义的,等等。

尊重常识是如此的重要,又是如此的平常,以至于我们在大多数时候都会忘记它,脱离它,做了很多看上去很美的产品出来。

在2013年的时候,我说在交易类网站,尤其是在移动互联网时代,为什么要让用户登录呢?很多产品不理解,觉得我这是在瞎扯。

但是,这就是一个基本常识,用户来你的网站是为了买东西,登录是你给用户设置的门槛。我从来没见过你去哪个小卖部或者商场买东西,要先成为他的会员的…(当然,高端俱乐部除外)

以上说的是关于产品理念的常识,其实,「做产品」这件事本身,也有它的常识。

这个常识就是,功能的外在表现是要靠内在去驱动。类比起来就是,表皮破了可以很快修复,但是心脏坏了,人就死了。

换句话说,我们要把更多的时候花在思考产品的内在驱动,花更少的时间去处理产品的外在表现。

什么是产品的内在驱动呢?

用户是谁,用户在什么场景下,用户的需求是什么,通过什么途径可以解决这个需求,解决这个需求我可以从中获益多少?

什么是产品的外在表现呢?

产品的基本流程是什么,产品需要多少个频道/类目,产品是APP还是微信公号,产品用什么颜色,产品叫什么名字?

常识就是,我们要花90%的时间去思考什么是内在,花10%的人力去实现外在表现。

我之前说,一个好的设计师一定是要先思考很久,然后才开始打开软件画图;其实,一个好的产品经理也一样,一定是要先思考很久,然后才决定开始一个功能。

回归常识,设计如此,产品如此,商业也是如此,共勉。

 

抽屉式导航的衰退及大屏下的产品设计

2011年11月左右,FB发布了新的ios和android客户端,其中一个重要的变化就是导航模式的变化,推出了新的抽屉式的导航,同时强化了对Timeline的展示。

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

我在2012年7月曾经对抽屉式导航做了总结,在「说说抽屉式导航」中我认为,大部分APP会使用抽屉式导航,核心原因是为了突出核心功能,将其他的功能隐藏掉。

现在来看,这个说法并不完全对。2011年到2012年,是中小屏幕移动设备占绝对主导的时代,中小屏幕,单手完全可以操作,不存在太多的操作盲区。同时,中心屏幕使得可以展示的内容有限,所以,抽屉式导航是最合适的做法。将导航收缩到一个入口,放在左上角最显眼的位置,用户操作也没有困难,其他核心的内容直接显示出来。

2012年之后,大屏幕成为移动设备的一个新趋势。一方面手机从一个单一的工具,逐渐演变成人们生活的一部分,不可或缺的一部分,用户在手机上处理的事务越多,使用的时间越长;另一方面,屏幕尺寸和内容消费效率及阅读舒适度极为相关。所以慢慢的,手持舒适度和携带便利在整个产品设计众多决策里面的重要排序便没有那么高。

所以,我们看到4寸屏、5寸屏越来越成为主流,尤其是iPhone6和iPhone6 plus的推出,大屏幕手机时代就这么不可阻挡的来了。有一篇老外的分析,点击这里查看

手机屏幕越来越大,带来了哪些问题呢?

最简单直接的就是,内容显示变多了,但是,单手操作变难了。曾经有报告显示,49%的用户是单手操作手机的,现在,是改变单手操作的设计的时候了。

157-007

这张图,非常直观明了的告诉了我们,为什么抽屉式导航衰退了。因为,一个需要被经常操作的入口,现在,处在了操作盲区。

那么,伴随着抽屉式导航的衰退,在大屏幕时代,该如何去设计呢?这是每个产品设计师面临的一个新的思考。我有几点感受,可以分享出来

1、手势操作将会变的更加重要。

Android上有单独的back键,而iOS的返回一直依靠左上角的导航。大屏幕下,iOS的左上角点击返回将非常低效,在屏幕边缘右滑返回是最高效的模式。另外,针对信息流类产品,点击顶部迅速返回到最开始的信息的模式,也是一种高效的交互。阅读类产品可以考虑使用双击关闭这类的手势交互。

相应的,一个产品统一使用上滑、下滑来进行导航的产品将会更多。

2、底部Tab模式导航重新受追捧

实际上,底部Tab模式导航在iOS和Android上一直是「最安全」的一种导航模式,他不怎么出彩,但是绝对不会犯错。在大屏幕时代,底部Tab模式的导航更能适应,也更好设计。

3、浮动导航入口有可能出彩

在path的3.0版本,那个浮动在左下角的「+」号曾经一度流行。在大屏幕时代,这种浮动的入口很有可能出现优秀的设计。

4、将提交类操作按钮,放在弹出的键盘的顶部

这个模式,在Android中较为常见,但是同样存在不同屏幕的适配问题,需要仔细考虑。

5、语音交互,谨慎看好

语音交互,始终感觉没有一个好的使用场景。

移动产品设计之到达用户

继续关于移动产品设计的话题。

本来之前我是写了一个「移动产品设计概要」的纲要的,这个纲要囊括从一个 idea 开始到具体上线再到持续迭代的所有环节。后来觉得,还是信笔随写吧,这样比较自由自在的,即使哪天不想写了,也没什么遗憾。

今天这个题目有点怪,当然,这个概念也是我自己造出来的。会简要写几个部分的话题:APP 的版本控制、APP 的名称及描述、APP的 Push 消息。为什么是简要写呢?因为展开太累,同时本身这系列的文章就是我自己在梳理思路,所以,点到为止。

APP 的版本控制,是必须从 APP 最开始就要考虑进行,就要执行的事情。这直接关系着你后续推出的功能能到达多少用户。

对于网页产品,到达用户的路径非常短,因为几乎所有的用户都是在一个版本号下面使用的,直接升级,所有人刷新页面,就看到最新版本了。但是,APP 是以安装包的形式达到用户的,也就意味着,如果用户不愿意升级,那么,你的新功能直接到达不了,到达不了,后续的都是白扯了。

按照我个人的思路,开始做一个 APP 的时候,第一件事情就是把版本的升级策略定下来。提示升级、强制升级分别在什么时候出现,线上允许运行的最低版本是多少。

伴随着版本升级的另外一个问题需要提前考虑的就是版本的升级节奏。更新太频繁,用户会觉得烦;更新太慢,不能在 Appstore 里露脸,会被遗忘;特殊的日子一定要发版本凑热闹。

同时,每个版本一定有一个「特色」功能,即使没有,也要包装一个出来,不然的话,单纯升级版本号是没有太大意义的。

举个例子,春节假期是每个 APP 都不能错过的一场盛宴。一线城市的用户向二三线城市转移,会直接促进大家使用 APP 的交流;假期中基本闲在家里,对手机的使用会变的频繁。所以,必须在这个时候出版本来吸引用户眼球,至于怎么吸引,自己想。

不是一个 APP 一旦被审核通过,就立刻向全部用户 push 升级的,这会存在很大的风险。按照我个人的方式,APP 一旦审核通过,先升级某一个小渠道,观察是否存在致命性的 BUG,比如闪退等。如果存在,立刻撤下来,如果不存在,开始推送升级,如果时间还能恰好赶在周末,那实在是太好了。

说到,APP 升级,我注意观察了蛮多 APP 的名称、描述、升级描述。这些部分的内容,基本都没有经过「设计」。

先说名字,有的APP 的名字跟自身的功能很贴近,不需要太多的设计,不过,有的 APP 则不是。在 Appstore 里进行搜索,名字的权重相对较高的。

举个例子,最早的时候快捷酒店管家在Appstore 里的名字就叫快捷酒店管家。这个 APP 主要是预订如家、汉庭、7天等等快捷酒店的,从名字到具体做的业务还是有点差距,不少人不太容易理解「快捷酒店」的含义。后来,我把他修改成为「快捷酒店管家- 会员价预订7天、如家、汉庭、莫泰、锦江之星、格林豪泰、速8、布丁、易佰旅馆等经济连锁酒店」,这个名称经过设计之后,有2个变化,一是用户可以通过搜索如家等品牌酒店的名称进来,二是很明确的把产品特色表达出来了。

升级描述的「设计」则更重要,因为这个部分的内容会频繁的被用户看到,直接决定了用户对版本的好感。

我们看到很多的升级描述直接是「修复了 Bug」、「优化了性能」,甚至很多 APP 的描述直接就是研发复制了跟 PM 的聊天记录,连名字都没去掉…..

把APP 的名称、描述、升级描述抽象到另外一个事情上,这就好比你在给你的 APP 写一份「求职简历」。APP 的名称就是你的一句话自我介绍,APP 的描述就是你的能力概述、APP 的升级描述则是你每一次的工作经历能带来的提升。我很喜欢求职者的简历里出现具体的描述,比如「活跃用户提高5%」要远比「较大的提高了活跃用户比例」更让人觉得这个人靠谱。

当然,我们也看到很多人在过渡的优化自己的 APP 说明和名称,这完全是在自己砸自己的脚。用一个优雅顺畅的说法,把你的 APP 跟某些跟你业务相关联的热门关键词组合起来,这才是王道。

最后说说 push。有个做内容型 APP 的人问我,我的 APP 发出去了,但是用户的活跃度不高,怎么办? push,是 APP 最基础的运营,尤其是内容型的 APP。

当然,因为很多 APP 的 push 也是没经过「设计」的,所以,大家都超级反感了。不过,如果你留意会发现,大家不是反感 push 本身,而是反感没有技术含量的骚扰性 push。

结合产品自身的特点去 push;设计好 push 到达用户的时间点,想象一下他在什么时间什么场景下接到你的 push;对用户进行分级,针对不同的用户 push 不同的内容,采用不同的频度;对 push 的类型做区分,气泡还是弹窗,纯文字还是带点符号什么的,用什么文案?

举个例子,2012年的时候,大家热议世界末日,于是快捷酒店管家在世界末日那天给 iOS 用户发了一个气泡 push,气泡的数字不是1而是直接显示「2012」,这个无厘头的搞笑迅速在微博上被传播,大家觉得很好玩。

push 一种 APP 最基础的运营,他是需要不断去实验,不断总结,最后行程体系的。观察每次 push 的几个核心指标,理论可以到达的用户有多少,发送了 push 的用户中多少打开了,停留了多久,发送了 push 的用户流失了多少。然后确定自己的 push 策略,持续运营下去。

写的很散,就这样吧,打完收工,敬请期待下一篇。

移动产品设计之场景感

关于产品设计的「场景感」,我重复过很多次,也不断的强调,在整个产品设计过程中,场景感非常之重要。(详见:做产品还是做咸鱼

我不断的重复过,Web 产品设计与移动产品设计,最大的差别在于场景的不同。

场景的变化引发了交互方式巨大的变化,从而也使得信息呈现方式有所不同,再加上硬件设备的差异,最终使得2者千差万别了。所以,移动产品设计之设计应该首先从用户的使用场景出发,同时考虑用户的硬件设备差异,综合以上2点去帮助用户完成某个任务。(详见:移动产品设计之设计

产品之要,首在场景感。没有错误的设计,只有放在错误的场景下的设计。

于是,有很多同学问我,到底什么是场景呢?

场景感,简单说就是一种讲故事的能力。之前我打过一个比方,产品经理就好像是个编剧加导演,你需要像一个导演一样思考,演员在舞台上怎么站位,他使用什么样的台词,他如何走位,他怎么退场。

相应的,产品经理在做一个功能之前也需要去思考,用户当时处在什么样的情况,他想要干什么,他会怎么做,如果他这样做,他会有什么感受?

让我们来举几个例子:

有个同事,平时工作对着电脑的时候头低的特别厉害,他担心老是这样的话,眼睛会受到伤害,于是,他想警示自己要头抬高一点。他就写了个便签贴在自己的电脑上,便签上写着「记得抬头」。

最开始的时候,他把这个便签贴在电脑屏幕的上方。我们一个同事看到了就跟他说,你这样贴不对!你贴在屏幕上方,当你低头的时候,看到的是键盘和屏幕的下方,这个便签没起到任何作用。你应该贴在键盘上,每次次低头时候,正好就能看到这个便签,这个时候就能警示你,该低头了。

这就是一个非常典型的关于场景的例子。警示性的标签最大的作用是预防,那就需要在问题还没有发生的时候提前告诉用户,如果问题已经发生了,这个时候警示已经无太大作用了,因为错误已经犯下。

MIUI 的 wifi 密码输入目前的设计是这样的,默认密码输入框不是明文显示的,但是提供了一个功能就是明文显示密码。我觉得这是一个没有理解场景的例子。

QQ20131223-2

首先,wifi 密码一般都是数字+字母的组合;其次,在移动设备上混合输入数字+字母的成本相对很高;第三,wifi 密码是一个保密程度很弱的密码。那么,为什么不是默认显示明文的密码输入结果呢?

当你在咖啡馆看到一个wifi 密码的时候,点击想要连接的 wifi,主动弹出键盘,焦点置入输入框内,你一边看着提示一边输入,输入完了扫一眼做比对,然后再提交,不是更高效吗?

后来,我看了iPhone 的 wifi 密码输入设计,全部密文;我又看了 Mac 的 wifi 密码输入设计,跟 MIUI 当前的设计一样,勾选了才有显示。

关于 wifi 密码输入这个场景,以上的设计其实蛮奇怪的,不是吗?

我为什么需要这么不断的强调场景,强调场景感,有几个原因:

首先,场景的描述实际上是在构造一个完整的过程。一个场景里面包含了什么人,在什么状态下,遇到了什么问题,他们如何操作,他们得到什么反馈。你把他们连起来一考虑,实际上这个产品就出来了。没有使用场景的产品,就是无源之水。

其次,通过场景描述的方式跟合作方介绍产品与功能,更能让人理解,更快速的知道你要做什么,建立模型。

怎么培养场景感?

去体验生活,去实际操作。从做快捷酒店管家开始,我尝试在不同的城市住不同的品牌酒店,在不同的时间通过不同的方式预订,在酒店的前台观察那些办理入住的人。我们团队的人也不断的实际去酒店前台实习,观察那些入住酒店的人。

不断的练习描述某个事情。一个输入密码的过程分解出来,每一步是什么样的;从下载 APP 到安装 APP 到打开,到执行操作,分别有哪些步骤,如何操作。

尽可能少的使用专业词语。练习在不使用任何一个专业词汇的情况下,把一个问题说清楚,说到即使不是从业者也能听得懂。尽可能多的去消化专业词语,然后用大白话给他描述出来。

当我不知道如何判断一个设计的好坏,不知道如何去设计一个功能的时候,我做的最多的事情是,停下来,开始模拟,模拟我要是一个用户,我会怎么操作,我会怎么想,然后把这些步骤与片段连接起来,描述出来,然后从中发现问题,寻找设计。

产品设计其实没什么难的,要说难,难就难在怎么让他变的自然,变的顺其自然,变的像空气一样重要但是又感受不到他的存在。直到有一天,你失去了空气,你才知道,我靠,原来,那就是最好的,最合适的。

一点题外话,

移动产品设计系列,我会坚持写下去。

从移动设备本身开始,进而到移动产品设计的概要、场景、导航、与用户沟通、版本管理、交互方式、与用户建立沟通、渠道管理等等。

之前写过的几篇:

我是这样做 APP 的

移动产品设计之书籍推荐

移动产品设计之设计

移动产品设计之硬件能力

移动产品设计之导航

跨终端体验的完整性

APP返回键的进化

先说一段绕口令,

产品设计,大部分的事情是在考虑信息与流程设计;流程设计,大部分的事情是在考虑导航设计;导航设计,大部分的事情是在考虑如何让用户「返回」…

那,今天来聊一下 APP 的「返回」设计。

关于返回,在主流的移动平台上,在很长一段时间内,是所有产品经理和设计师们争论的焦点。这些争论包括但不限于,Android 版本到底要不要完全依赖物理键的返回、为什么 ios 的返回键一直在左上角、手机端浏览器的返回应该放在哪儿….

很遗憾,这几个问题我都回答不来。

在实际项目过程中,我们也遭遇到 Android 初期设计规范的混乱,所以,为了保证项目的进度,直接采用了跟 ios 一致的返回设计方式。

当然,根据一些设计原则,如果用户进入的信息层级过深,会直接在左上角提供一个「回首页」的功能,方便用户跳转导航。

不过,最近关于 APP 的「返回」似乎有了一点不一样的进化,几个例子:

APP 返回键进化

1、部分 APP 开始将返回挪到了底部

具体说就是,返回按钮从左上角挪到了左下角,典型的 APP 如,淘宝、知乎日报。

我不知道具体的用户研究结果如何,从我个人的体验来看,我很喜欢。这种改动似乎跟手机硬件要么越来越长要么越来越宽有关系,硬件变得让人无法一手掌握,掌机越来越无法掌握,所以,相应的影响到了 APP 的设计。

2、手势操作有替代按钮的趋势

具体的说就是,用户可以通过滑动来完成返回,而不是一定非要去点击返回按钮,典型的 APP 如,知乎、豆瓣小组。

Android 坚持了好久,始终不肯放弃物理硬件,所以,Android 的返回问题依旧没能完美解决。不过,从整个移动生态的发展来看,用户对这种手势操作越来越习惯,同时,手势的操作确实要比点击效率更高。

所以,可以预见的是,在未来,将会有更多的 APP 加入手势返回操作,甚至成为主要的返回入口。

一般的产品,如果我们把他的信息流程抽象出来,基本可以归纳为。起点——>列表——>详情,详情返回到列表,继续到详情,比如购物类应用、微博类应用等等。将这个流程连接起来看,用户需要不断的以列表为起点进入,再出来,再进入。在这种情况下,返回的效率尤为重要。

向右滑动页面,返回上一个层级,看上去会很大的提高用户的操作效率。不过,在 ios 上对部分列表有右滑出现删除功能的手势操作,所以,如果应用滑动页面返回的话,这个问题需要去考虑。

3、其他高科技的返回

好像某个手机有眼动来着?我曾经一直想来着,万一一边玩手机,发现旁白站了一漂亮姑娘,这个时候该怎么控制啊….

 

为什么要用户登录?

只有登录才能完成相应的操作似乎已经成了很多产品,尤其是交易类产品的一种理所当然的规矩。所以,当你点击购买按钮的那一刻,一个讨厌的登录框就会弹出来,打断了你的操作。

你必须开始思考你是否曾经在这个产品里注册过,你的密码是什么,最郁闷的事情是,你常常还忘记了用户名…..

于是,为了完成交易,你必须再次完成注册,但是,他可能会提示你你的某个证件已经使用过了,你需要更换…..

但是,该证件是唯一的,所以,你又必须开始想办法找回你之前的账户。

好吧,当这一切都忙完了,请问,你还能记起你是因为什么而搞了这么多事情吗?还有,你还有想继续交易的心情吗?

所以,每次在使用交易类产品的时候,我总是想问一句,你们凭什么让用户登录?用户为什么要登录?

快捷酒店管家是一个典型的交易类产品。在最初的产品设计中,我们就最大程度的弱化了“注册”这个概念,同时也最大程度的弱化了“登录”的概念。我们从另外一个角度重新思考并设计了这个交易系统。

用户来快捷酒店管家是要预订快捷酒店的。这个跟你去酒店前台预订酒店,去一个代售点买个火车票完成的任务是一致的。你需要提交的基本信息,然后付钱,然后拿到房卡或者火车票。那,这里有存在登录这么一说吗?

既然是一个交易型的产品,从骨子里说就是,你提供给我相应的信息,我卖给你东西,就这么简单。提供一套账户系统,然后用户帐户名、密码登录进行交易,看似简化了这个交易流程,但,实际上则是增加了用户的负担,也打断了用户的使用流程。

所以,在快捷酒店管家,只会出现2种情况。你之前预订过,下次预订的时候直接点击预订,确认订单,就完成了预订;你之前没预订过,你需要输入姓名、身份证、手机号,确认订单,完成预订。不论是哪种情况,你能感受到的都是顺畅,无打扰,这是一个对现实生活的拟物与映射。

当然,还有另外一种比较折衷的情况。在交易类产品中,默认所有的情况进来都是填写交易需要的表单,但是,提供额外的入口允许用户切换到现有的账户模式,这个时候再进入登录页面。也能一定程度上保证用户操作流程的完整流畅。

在移动端产品设计中,因为移动设备与用户的更亲密的结合的存在,强制让用户进行登录,其实是个很反人类的事情,是在折腾用户。更快的完成任务,更顺畅的操作流程才是最重要的。

path 3.0的一些细节设计

今天,只说设计细节。

path一直是个蛮奇葩的应用,它的每一个大版本都会引发APP设计风格的一次突破,但是,它的产品自身却一直没什么突破。

Ptah 1.0,采用了一个横条的缩略图作为图片Timle的主要表现形式,这种风格让以照片流为主的Timeline显得非常有韵味,后来这个风格被不断模仿;

path 2.0,采用了抽屉式导航的模式,这种导航风格大大的扩展了APP的可利用空间,同时让核心功能足够突出,底部将所有的功能性操作缩略到一个按钮上,只要你需要,点击一次就可以执行你操作的功能,直到现在,这种抽屉式风格依然是主流模式;

path 3.0,在APP的交互中加入了声音的元素,对时间轴的使用更娴熟频繁,登录界面由单一图片改为轮播背景。同时,这个版本另外一个重大的风格就是拟物化做的很赞。logo及界面都呈现出平面化的趋势,很有质感。时间轴、轮播背景图的登录界面、平面化应该也会成为趋势的。

path的风格演变

按照我对设计的理解,首先它必须是有一个足够清晰的产品架构,在这个架构的基础上去做优雅的交互和视觉才能够事半功倍;其次,交互和视觉都应该足够的注重细节,细致的细节更容易打动人,同时让产品显得很有档次。

AppFlow是个典型,即使它的交互很酷炫,但是还是很烂,因为它的产品架构糟糕的一塌糊涂;Google Maps是另外一个典型,它的产品架构做的足够清晰,然后加上一些优雅的交互,使得这款地图应用瞬间成为极品。Path的设计,也完全符合我的这2判断点。

当然,今天不分析架构,只说path 3.0让我看到的很用心的几个设计细节。

关于拟物化的设计

进入ptah的商店(shop)页面,首先是一声响铃,商店顶部的雨篷会缩回去,把商品展示出来。想像一下,你在一个幽静的小镇晃悠,看到一家手工艺品小店,你推门进去,挑开门帘,看到了里面的商品,就是这个感觉!

另外,在每个商品的顶部是一个挂钩,而陈列架上都有一盏小的射灯,将光线打下来照在商品上。当你晃动手机的时候,这些卡片会随着你的晃动摇摆,会调用感应器摇摆哦,真的会摇摆哦!!!

当你选中了一件商品,会有一个从上而下再稍微弹起的动画。这个场景就像是墙上挂了蛮多的商品,你看重了一件,主人把它放下来的感觉,有木有!

如此逼真的拟物化,如此细致的细节拟物,反正我是第一次见到。而这些小的细节,会很容易让你感受到,并且瞬间产生联想,然后心底一股暖流,然后不禁想大声说一句,这他妈的才是设计!!!

小细节的雕琢

在Path的主页,头像下面有一类似雨滴的个圆点,当你下拉刷新的时候圆点会随着变成一个雨滴,当刷新完成,雨滴会从上掉下来成为一个雨点,然后页面缩回去。这个小细节看似很平常,但是确实是经过用心雕琢的。

在path 3.0的核心动作中都假如了点击反馈,比如点击拍图、位置、音乐等。点击之后,图片会有一个渐隐的变大,这种点击反馈在APP的设计中很常见,但是,path似乎做的更精致一些哦。

另外,在主页点击封面图片的时候也是会有点击反馈的哦。

关于统一性

Path的主页、个人主页、聊天列表、聊天窗口的风格是统一的。左侧都有一根轴,然后用户的头像穿轴而过,这种统一性让用户比较有安全感,也很舒服。在滑动页面的时候,右侧会出现一个时钟的提示,提示该条消息收于什么时候或者发与什么时候,这个也是一种统一性。

path3.0

一个有问题的隐喻

path 3.0不仅仅是能私聊,还可以跟陌生人私聊,还可以发起群聊的,只是群聊的入口稍微隐蔽罢了。在主页点击右上角的聊天,然后再点击右上角的撰写icon即可发起多人聊天。

这个icon似乎是一个设计错误,作为一个发起群聊的icon,这个撰写框明显不合适。也许它其实的出发点是同时给多人撰写信息?

当然,单从设计层面讲,path确实是目前非常优秀的了。

在这个产品上,从它出生到现在,每次都会让你觉得,原来这才他妈的是交互,这她妈的才是优雅!它总是能在设计层面上不断的去创新,不断的突破自己,但是,杯具的事情是,它的产品层面一直未见有大的突破,这倒是挺让人惋惜的。

移动产品设计书籍推荐

这是我曾经在知乎上对一个问题的回答,最近也有好几个朋友在公号里向我提问,对于做移动产品设计,有没有一些比较值得一读的书来推荐。我把这个问题重新梳理了一下,更新到这里。

移动产品设计,狭义上的理解就是设计手机及Pad上的应用和Wap站,包括ios、android、WP等几个主流的平台。这个答案也是围绕着这个狭义的定义来的。

1、各个平台的设计指南,也就是我们常说的Guidelines

这是当前而言,所有的移动相关的书籍中,最最最最最基础的,也是最最最最最为重要的。所有的从事设计相关工作的人,都必须至少读3遍以上,甚至更多。

在Guidelines中,以ios的编写最为规范与完整。这套指南会很详细的告诉你,ios系统是一套什么样的系统,为什么要做ios的设计,什么样的ios设计是适合与这套系统,然后告诉你有哪些基本的模式,再然后是具体的设计。迄今为止,还未发现讲ios设计的资料有超越这套资料的。

基本上来说,熟读了Guidelines不看其他什么书问题也不大。强烈建议新入行做移动产品设计的同学,在没有读过Guidelines之前,不要读任何的其他书籍。

2、《简约至上 – 交互设计四策略

副标题看,这是一本讲交互设计的书。但,实际上,这是一本产品设计的入门书籍。讲述如何站在主流用户一边,以及如何从他们的真实需求和期望出发,简化设计,提升易用性。

这本书推荐给所有做产品的人看,同时,建议不要再读《don’t make me think》,这本书其实只需要读标题就成了。里面的例子和内容都不太实用。

3、《Tapworthy(触动人心)

这是一本讲述如何从iphone的角度来思考并设计一款ios应用的书籍。书中有不少的实例。

4、《移动应用的设计与开发

这是一本相对比较老的书,其中有些例子与数据可能不太适用了。不过,书中很详细的对整个移动生态系统做了描述,这是很值得一读的章节。因为,只有我们理解了所处的生态系统,才能很好的在这个系统中去设计应用。

5、《移动应用UI设计模式

很早的时候关注了这个姐姐的博客及要出的书,今天去看了一下,发现已经有翻译版本了,准备入手一本来看看。这本书分10大类介绍了70个移动应用设计模式(包括反模式),用了400多个屏幕截图和图解。基本上,是一个工具书了。

注:

以上书籍收录于我的豆列“移动产品设计书籍”。

另外,补充一些素材网站:

1、pttrns.com

这个网站会不定期的分享一些APP的截图,同时,网站还按照不同的分类将这些APP截图做了整理。

2、mobile-patterns.com

跟pttrns类似,不过更新好像没那么勤快。也是根据不同分类整理APP截图的

3、appsites.com

这是一个收集展示APP网页的网站。简单说就是很多APP的介绍和下载页面的收集整理

4、花瓣网的APP频道

唯一的缺点是网站和APP混在一起的,且内容没经过筛选,质量并不是很高,不过,其中有几个用户的专辑是很赞的!

——

如果,你也有跟移动产品设计相关的书籍、站点、资料推荐,欢迎邮件我哦~

移动产品设计之新手引导

APP的新手引导,原本的出发点很简单,类似于一个简洁的产品说明书,其主要目的是为了向用户展示该APP的核心功能及用法。一般出现在用户首次安装APP后打开的时候。欢迎界面一般为3 – 5屏的全屏静态图,左右滑动进行翻页,有跳过按钮;新功能指示及操作引导一般用蒙板加箭头指引的形式完成。

比如,快捷酒店管家的APP在用户首次打开的时候会出现4屏静态图,左右滑动翻页。第一屏是说我们只做快捷酒店的生意,有全部快捷品牌的货源;第二屏是说在地图上不同的房态如何展示的,因为地图的展示形式有些新颖,担心用户首次接受有障碍;第三屏是说我们额外提供了酒店的电话及导航功能;第四屏是说预订很迅速。然后,进去之后用蒙板介绍一下一些隐藏的功能的位置,因为藏的相对比较深。

快捷酒店管家的新手引导,只会出现1次,APP的版本做了更新之后再次打开,这个引导都不会出现了。因为,你已经是老用户了,新功能是在老功能的基础上迭代的,你不会感觉突兀。但是,现在想来,还是有些罗嗦,接下来的版本中,会把新手引导减少到2屏,会把操作蒙板引导去掉,因为要保证用户能足够快速的进入APP,解决当前的困难。

随着APP设计的发展,APP的新手引导逐渐成为一种标配,而这种标配,很多时候充满了不必要与乱象。

某些APP,生怕他的用户都是白痴,所以,恨不得每个功能都做一个提示,那张操作指示的蒙板,俨然一个刺猬,满界面都是箭头……

某些APP,功能和操作简单到爆,也要来个5屏的新手引导,引导就引导吧,还是上下滑动的,你左右滑半天还以为是APP挂掉了……

某些APP,每次更新都来一轮新的引导界面,真不知道这APP有多少视觉设计师在操作啊……

某些APP,看人家微信弄了个5屏的小文艺引导,也学。学就学吧,还学的不伦不类,搞的酸了吧唧的,完全是奔着写散文去的…..

打个不恰当的比方,你现在憋了一泡屎在裤裆里,着急想找个厕所,路口正好有1个,你正准备冲进去大便,这个时候,门口站了一个大妈,开始跟你说,我这厕所冬暖夏凉,在我这里拉屎蹲坑舒服无比,我这厕所瓷砖都是艺术品…..你几次三番的想冲进去,但是,大妈不说完是不会开门让你进去的,于是,你就只能听着听着,听着,然后,妈的,直接拉裤裆里了!!!

这,就是现在APP新手引导之殇,你他娘的就顾着自己在那煽情,完全不顾及别人的感受,人家只是想让你赶快的定位成功,赶快的展示出来主界面,赶快的帮我解决问题,你他娘的还一个劲的让我翻翻翻,翻你妹啊!!!老子不是来看你煽情的好不好!!!

有人说,你看人家微信,不是每次都是5屏小文艺吗,人家还在新手引导上直接来了一首歌呢,凭什么我就不能这么玩了?拜托,神有神道,人有人路,修为没到那程度,就别练那心法,不然就是走火入魔!微信这种极客范儿的小文艺,很难学的来的,这是一种骨子里的东西。

不信?那,我们来简单看几个例子。老规矩,中枪的算你倒霉!

app新手引导

 左侧第一个,某问答社区的APP。第一次打开后,进入到某个答案具体页面的时候的新手引导。提示右滑可以返回,为了看答案,你得把这个提示消除掉,当你点击那个蒙板,你以为可以消失,但是,他,真的就,返回了,返回了,你妹的,我是来看答案的啊,你给我返回了,你什么意思!

中间那个,你们能猜出他是什么APP吗?这是他首次打开的新手引导第一页。然后,你知道该左滑还是上滑?反正我是亲眼看到某个做产品的人在这里呆了半天….

右侧那个,微信的漂流瓶新手引导。如果你拣到瓶子,立刻就点击了,是永远不会看到这个提示的。只有你捡到了,但是几秒没任何操作的时候,才会出现这个。你看,这才是优雅的引导!

所以,在绝大多数情况下,形式不要大于功能!(注意看,这里有个度的限制)作为设计者,永远应该想到的是,怎么让用户爽,不要做那么多的铺垫,简单粗暴一点更合适。对于APP的设计,有些东西,只是一个简单的辅助,但是一旦辅助变成了绊脚石,那就是问题了。

我是这样做APP的

击中用户的痛点

APP发展时期不同,获得用户洞察的方式也会随之变化。

任何一个成功的APP必然能够击中用户的某一个或几个痛点。帮助孤身一人的旅者、在最短时间内找到陌生城市的落脚之地,这就是“快捷酒店管家”最为核心的诉求,其背后是对现代人天涯孤旅况味的理解和挖掘。再进一步,它抓住的是移动互联时代人们缺失的安全感与日益减弱的计划性。各式智能移动设备使现代人的出行随意轻便,抬腿就走,这一趋势正是“快捷酒店管家”当日预订、当日入住模式的深层支撑。

准确地找到用户痛点,业内主要有两种方式:一种是以竞品分析为代表的数据分析方法,比如搜索引擎公司会设置指标,开展搜索,评估搜索结果,从而对用户需求做出判断;另外一种则是“答案在现场”,开发新产品的团队往往会更多地采用这种方法。我们公司CEO住了上千家快捷酒店;开发团队的成员每人每月都有3次公费入住快捷酒店的机会,亲身体验自己开发的产品是否靠谱;客服人员会通过接听用户电话以及社交网络搜索等方式实时收集用户的反馈;团队成员甚至会在周末去客户的酒店做前台,观察那些拿着手机到前台展示订单的住客究竟是怎样的状态。

发展时期不同,APP获得用户洞察的方式也会随之变化。用户样本量较小的初期多采用现场体验发现的方式,在用户量级达到一定水平后,则可以通过数据挖掘来更好地满足用户需求。比如可以通过分析,帮店长把握其周边客户群体的性质,分析每天有多少人看过他的店,有些人最后没有预订是什么原因等等。未来甚至可以据此探索用户预订酒店方式的改变。

APP不是规划出来的

基本价值定位确定之后,产品的改进、丰满乃至走向,在某种程度上就成为多方力量共同作用的结果。

在某种程度上说,APP产品不是规划出来的。也许听上去不可思议,“快捷酒店管家”永远没有产品规划,甚至不知道2个月之后自己会做什么。举例来说,“在线预订”现在是这个APP的核心功能之一,其实2012年3月产品刚上线时并无这一功能,用户仅能进行电话预订。上线后不少用户反映不爽,因为他们的电话会打到酒店前台,前台再转给400订房专线,因为APP的数据无法传输,400客服还会再问用户在哪儿、住几天、住什么房等信息,整个过程要多花费一两分钟。于是,只需点几个键就能完成整个流程的“在线预订”功能应运而生。

由于用户群体内部存在差异性,产品功能较为显著的调整往往会引发用户的不同反应,此时需要在准确判断主流趋势的基础上拿捏分寸,要渐进柔和地调整,切忌简单粗暴。就拿上面提到的从电话预订转为在线预订来说,其间也经历过“斗争”。一开始我们采用“硬掰”的方式,直接把电话预订的功能隐藏掉了,结果引起不小的反弹,因为有些用户就想打电话。为此我们又进行调整,只是将电话的位置弱化,突出下面的“预订”。

不仅如此,对于像我们这种连接用户与商家的“桥梁式”APP来说,基本价值定位确定之后,产品的改进、丰满乃至走向,某种程度上是多方力量共同作用的结果,需要开发者对相关利益方的需求进行捕捉与平衡。使用早期的“快捷酒店管家”,用户打开地图后能看到所有附近酒店,满房是红色,有房是绿色。用户就提出,我只是想找一间房,为什么把满房的也给我?其实,设为全部显示是为了满足一些店长的要求,他们可以通过APP查看所有酒店的预订情况,与竞争对手进行比较。但更好地满足核心用户的需求才是第一要务,于是我们就添加了一个可选功能,默认“只显示可预订”。

就这样,我们被推着一路前进,用户把“快捷酒店管家”当做预订平台,酒店则把我们当做营销平台,作为第三方的我们努力把桥梁当好。除了通过微博、微信、客服电话、关键词推送等方式对核心用户的需求不断揣摩外,“快捷酒店管家”也渐渐增设了不少体现酒店需求的信息展示功能,如是否有免费wifi,是否有停车场,附近是否有地铁等等,这些都是我们最初做产品时没有想到的。

 优秀APP的三个标准

设计APP产品必须学会放弃,大而全地绑定用户始终是一种诱惑,但当你想要的东西特别多的时候,得到的就会特别少。

一个优秀APP产品往往要具备三方面的特点:一是性能好,通俗讲就是加载速度快;二是用户第一眼就能够找到自己想要的东西,快速有效地解决问题;三是设计有人情味儿,也就是现在很多人常说的“有爱”。

首先,在当前的网络环境下,APP产品的性能好,用户无需等待与忍耐,这是判断一个APP好不好用的重要标准。微信的性能就相当突出,在网络环境很差、很多APP都无法打开的情况下,它还能够使用。但性能并不是一个纯技术层面的问题,也包括策略层面的考虑,开发者需要对速度与效果进行平衡。比如在点击查看微信的消息时,它总是会进入到消息列表,而不是只显示单个消息,此举虽然会牺牲一些速度,却可以使消息的到达率更高。“快捷酒店管家”同样如此,原本打开地图就显示方圆50公里内的酒店,加载速度很慢,后来考虑到用户很少会跑到那么远的地方去住,选择也无需提供那么多,便将搜索直径缩小到10公里,只有再次拖动地图时才会加载其他酒店,速度明显提高。

第二,必须学会放弃。大而全地绑定用户始终是一种诱惑,但当你想要的东西特别多的时候,得到的就会特别少。作为在手机等移动终端上使用的APP来说,简洁是很重要,因为设备屏幕空间有限,用户完成的任务也有限。但如何理解“简洁”?它其实是一种合理的整理。飞机驾驶舱里有无数仪表,你能说它不简洁吗?它必须那么复杂。所以并不是说少和简单就是简洁。APP的简洁应该指核心功能非常突出,不核心的功能可以找到,不需要的功能没有。

在产品设计时要在“用户想要什么”与“你想给什么”之间博弈。用户使用APP就像鱼在池塘中游弋,产品开发者需要通过搭建障碍来引导用户。某些通道的口会留得很宽,那是希望用户经常用的功能;某些口很窄,想通过要困难一些,适用于用户使用较少的功能;有的地方就是雷区,不能让他们过去。比如“快捷酒店管家”打开后的地图主界面默认为定位用户附近的酒店,这正是多数用户需要的;也有用户要找其他城市的酒店,主页面的某个位置会提供搜索按钮,可以切换到相应界面;在预订下单等关键点,就会要求用户必须输入姓名与手机号才能继续,以此保证订单的真实性。

第三,“有爱”是一个好APP的重要特质。APP总要跟用户交互,交互过程应当尽量让人感到愉悦。要做到令人愉悦,就必须认清自己的用户群体,根据他们的特征喜好不断增加细节元素。过去打开“快捷酒店管家”的地图,附近的酒店会一下子显示出来,缺乏特色又十分生硬。后来考虑到我们的核心用户群体是20岁左右的年轻人,他们的QQ皮肤会很花哨,微博模板也个性十足,也就是说,他们追求的是张扬、好玩儿、酷,于是我们将酒店的显示方式改成了从天上哗啦哗啦掉下来的有趣方式。 

 让用户感觉APP是活的

并非所有的用户流失都是不良的,相反,进行用户管理有时候还要故意“逼走”一些用户,“净化”用户队伍。

对于一个APP来说,用户的下载只是万里长征的第一步,下载后的用户流失是必须面对的问题。有研究说,APP产品在下载后三个月内平均会失去76%的用户,维系用户确实是个难题。

用户流失的原因各不相同。一种是3分钟效应,甚至有人说是60秒效应,就是说如果在3分钟之内用户无法找到你的亮点,或者说他急需解决的问题你无法解决,就可能会直接把你删掉,或者无限期打入“冷宫”。这是产品自身的问题,需要做出根本改变。第二种是用户确实在某个特定时段没有需求,比如订酒店就不是日常需求,如果APP因为这种原因被搁置,那就需要通过不断的运营让用户在需要的时候想起你。

APP的运营对于维系用户来说非常重要,业内常说的打榜虽然可能一时有效,但如果后续没有运营也没有意义。如何理解运营?我认为它包括产品运营与市场运营两部分,其本质是建立起产品与用户的关系,而不能仅仅理解为做活动。产品运营的方式很多,信息推送最为常用。在产品中增添好玩的细节、功能也是一种自我运营,比如我们会时常更换有趣的开机界面,圣诞节时将酒店图标变成举小牌子的圣诞老人,目的是让用户感觉你的产品一直有人在用心去做,你的APP是活的而不只是冷冰冰的工具。

维系用户固然重要,但并非所有的用户流失都是不良的,相反,进行用户管理有时候还要故意“逼走”一些用户,“净化”用户队伍。我们的团队有一个原则,即如果一个用户从来不进行搜索、预订等任何活动,他就被视为需要清除的“毒瘤”, 因为他不仅会让用户活跃度等数据变得难看,还会因其无视各类升级要求而增加不同版本的维护成本。“强制升级”是剔除“毒瘤”的方式之一,强制升级时用户打开APP,只有一个“升级”按钮,不升级就进不去。此举自然会因“激怒”用户带来流失,但这种流失是对无形负担的减轻。

此外,恰当管理用户预期也是客户运营的智慧所在。我们拒绝一个人连续给5个人订5间房的用户,尽管这并不违背行业规则,但对于APP产品来说,这种情况会让预订的验证程序变得更加复杂,从而影响其他用户的体验。为了让产品做得更简洁,宁愿牺牲这类用户。面对此类需求,我们会实话说自己做不到,或者请用户多等一段时间,而不是随便答应改变。为用户设置一个合理的期望值,在合理限度内为用户提供尽可能好的使用体验,这也是打造良好用户体验的重要方面。

——

这是跟中欧商业评论的记者聊天的整理,原文发在《中欧商业评论》2013年1月号上,题目是“一个产品经理的用户洞察法则”。感谢罗真美女的耐心整理。

产品的信任感

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

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

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

早前的时候,快捷酒店管家的名字其实是“酒店管家”,但是,快捷酒店管家又是一家只能提供快捷酒店预订的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。

为了设计而设计

我有个习惯,每天晚上睡前会搜罗一遍最新的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、原型设计的过程中,酷炫的原型交互需要适可而止。

移动产品设计之ios系统的导航

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

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

(图片来源:Tapworthy

平铺列表

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

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

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

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

标签页

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

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

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

树状结构

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

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

3类导航模式的比较

导航模式

优点

缺点

代表应用

平铺列表

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

标签页

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

树状结构

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

Mail

Facebook

导航模式的组合应用

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

模态视图

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

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

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

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

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