【2005】移动端启动的“黄金七秒”

导语

一个移动端应用,在系统层点击ICON到真正进入应用第一个可操作页面,这几秒十分重要。心理学中有个“七秒钟理论”,就是说人与人见面的时候,产生好恶决定于见面的头七秒,对一件商品的认识,可以在七秒钟之内以色彩的形态留在人们的印象里。

根据国外相关机构的研究表明:能被消费者瞬间进入视野并留下印象的产品,其时间是0.67秒,第一印象占决定购买过程的60%,而这60%是色彩带来的。

启动过程中有可能出现什么页面?

  • 启动页
  • 过场页
  • 登录页
  • 注册页
  • 应用首页
  • 信息采集页

启动页

进入应用第一个看到的页面,一般是应用LOGO加应用名称,或许还有公司相关信息。主要是突出品牌/应用的色系色调,没有太多的内容,核心目的是品牌认知。

过场页

  1. 走马灯图片:一般出现于初次进入(如:新安装,更新版本进入),一般用于对应用的核心功能进行介绍;
  2. 几秒钟广告:有可能是视频,有可能是几秒钟广告图,一般用于活动宣传。

登录页/注册页

这个可以一起说,部分应用强制登录后进入,主要出现于未登录或登录状态失效。

应用首页/信息采集页

这个和上面相反,非强制登录的应用在启动后出现,展示第一个希望给用户看到的内容或希望收集的信息。

启动过程怎么设计最好?

没有最好的设计,只有最合适的设计。可能在甲产品中设计A会显得很傻,但有可能在乙产品中,设计A又显得非常合理了,这是要根据产品特性决定的。

来看一个近年流行的启动流程(非强制登录类应用,例如新闻类产品):

常规套路.jpg

非常常见的一个启动流程,固定位置的品宣,5秒左右的广告,进入首页。完成整个启动过程。看似简单,整个流程是经过多番考虑的。

有何巧妙?

  • “净色底+品宣”的固定显示,哪怕广告加载不出来,也不违和;
  • 广告不挡“品宣”,感觉整个启动就在一个页面进行,相对缓和;
  • “跳过”按钮带倒数,就等于有“进度条”概念,让用户清晰知道等待时长,选择是否跳过显示。
  • 广告的加载方法,这个是看团队功力的地方。例如:打开时检测最新广告进行加载;检测是否有广告更新列队,提前下载在本地,到日期直接显示;发现新广告,下次显示等方法,这里就不详细说了。

好在哪里?

说说过去,还是“品宣”和“广告”,但不同在于以前的“广告”是满屏的,有可以跳过的,也有不可以跳过的。“跳过”按钮是个感受加分项,但不是加分最多的,关键还是页面切换。

以前的启动过程:

老流程.png

上述介绍的启动流程:

新流程.png

我解释下,同样的时间内,老流程跳了几下,让人感觉距离很远。新流程的视觉感受一直保留在一个页面内,让人觉得下个页面就到终点了。这个细小感受上的差异,极有可能决定了用户对产品的印象。当然了,我上文所说的内容并不是绝对的,只是一个举例,任何事情抛开了前提条件讨论都是耍流氓。

在这里,说的只是原理,哪怕同一个应用的不同时期阶段,启动过程要考虑的事情可能也不相同,会导致设计理念和效果对后续造成的影响也会不同,所以一切要按实际出发就好。

启动过程的设计技巧

  • 清晰,直接明了的品牌宣传,让用户一想做这个事情就想起你;
  • 使用整齐,简洁,干净的界面,舒缓用户的急躁心情;
  • 使用场景化,情怀化的氛围,让用户身同感受;
  • 使用触动情感的语句或画面,让用户产生共鸣。

启动过程设计好坏的蝴蝶效应

  • 新用户的登录转化率
  • 用户留存率
  • 活动宣传效果
  • 同类型产品的印象值

……

小结

本文只是很浅的说了一下启动过程需要注意的点,并未深入去分析各行各业启动过程的侧重点和他们迭代过程碰到的问题及解决想法。

总的来说,启动就是应用的门面,里面包含非常多的处理逻辑及设计思路。肉眼上看家家应用都差不多,但实际背后的逻辑才是见真军的地方。例如首选项配置,用户数据采集,加载逻辑等。日后有时间,再逐个分析分享。

【2001】关于“验证码”的下发机制

今天在使用招商银行的【掌上生活】app时,碰到这样一个情况,某个业务场景,需要输入手机号,填写下发的验证码。或许是网络原因,验证码几分钟没到,作为用户,肯定会多按几次,这是非常正常的操作行为。然而,坑爹的事情发生了,试了两三次,几分钟过去了,在某次请求后,验证码来了,但输入后是错的,大概过了30秒,又来了一条,我再次输入,还是错的。使用返回再进入,又重新获取了一次,来信息了,但还是错的,瞬间心好累。

为什么会出现这个情况?因为他们的验证码下发机制没有考虑到一些特殊场景,例如网络延误,短时间内多次下发的输入等。他们的机制很简单,就是请求一次,生成一个不一样的验证码,需要输入最新的,或许有最大下发次数保护机制,这个是另外的话题,这里不发散说。然而,不知道是哪边服务器的原因,延误的验证码不是连续来,而是隔十几秒来一个,还要让人在当前页面等到最新的验证码进行输入才是正确的,想到就心好累。

这里就引出了一个问题:验证码的下发是否应该使用相同的验证码?

在一定时间内(10-30分钟),向同一个手机号下发相同的验证码会比较好,超过一定时间,下发不同的验证码。这样在短时间内,用户看到多个相同的验证码,不会出现疑虑,对需要输入的验证码非常明确,若短时间内的验证码不同,就会产生“哪个才是我需要输入的?”这个疑问烦恼,可能产生多次输入的试错成本。

那么,如果在迭代需求中,需要描述这个功能,怎么说比较好呢?

用户发起一个验证码请求时,去库里查该账号/ID最近一次下发验证码和下发时间,若在30分钟内,则把该验证码再下发一次,并进行记录(30分钟是否需要重新计时,根据各个业务的情况自行调整,没有标准答案),若是超过30分钟,则重新生成新的验证码进行下发。

小结

虽然只是一个触发验证码的动作,里面也涉及到很多小细节,这里主要是讲述的是验证码多次下发的使用场景。在整个流程当中,其实还涉及什么时候触发下发请求的相关问题,倒计时控制连续下发验证码的时间问题,每个功能都需要多思考,尽可能的严谨和人性化,这些细节不一定能让产品带来飞跃性的成功,但肯定能提高产品的下限。