1、将注册与信息补全分离。
注册的目标是:用户拥有与设备无关的唯一识别的ID。
信息补全的目标:补充基本信息,做内容/用户推荐等。
信息补全的部分,可以放置在必要的时刻进行引导,如发布内容、关注好友进行引导或者强制填写。这样避免了冗长的注册流程。
注册,要尽可能的简单,取决于产品设计中User模型的基本属性都有哪些。
邮箱、手机号、密码、昵称......
要搞清楚哪些内容是你的产品模型中必不可缺的部分。
可以使用手机号/邮箱等先对昵称进行填充等手段,减少用户注册时填写的内容量。
通过第三方账号登录,一般可以获取比较多的个人信息,关系链甚至邮箱。
不过鉴于新浪微博API不断收紧,还是不要太过依赖这些。
第三方登录也不要做太多,微博、微信、QQ足矣。
======
话说注册做的再简单,也就只能跟登录一样。
之前尝试了将手机号登录与注册合并在一起的做法,貌似也没什么问题。
2、“先试用后购买”ying'can方式
案例一:索狐视频 ![](http://www.mtedu.com/data/php/upload/image/20150724/1437727490966336.png)
案例二:果壳网APP ![](http://www.mtedu.com/data/php/upload/image/20150724/1437727453932995.png)
同样,登录注册也隐藏的很深,不注册的情况下,收藏、使用一点儿也不影响。我刚开始看的时候甚至有点惊 讶,app的注册放到这里,会不会影响用户注册的热情呢。后来发现担心完全多余,当你想注册的时候,自然会 去找。 上面两个例子随便找的,现在很多app都是这样设计的,我叫做“先尝后买”。这里就又要回去看我们之前的两 个条件了,条件1,必须是app。为什么呢,因为app是安装在用户手机上的,是有本地存储的,可以少使用,甚 至在离线状态下让用户使用,这里和“web”是有本质区别的。所以在app的模式里,是完全有可能使用“先尝后 买”方式“粘住”用户的。 我们倒着说,下面再看看那些app适合这样使用,这就涉及的app的分类了。 UGC现在已经不能用火来形容了。100个app里,得有90个都要引入UGC的,就算开始不用,改版只有也肯定要规划的。所以说起app就不能回避ugc。按说只要涉及到社区,论坛,评论,历史记录等等都需要用户注册,但是其实我们看看是否都需要用户立即注册呢。 我粗略的想了一下,只要不是纯社交类的,或者说主要是社交类的都可以先不注册。 工具类的,影视类的,公知类等等吧,比如图片处理(各种美图什么的),视频观看(各种网络视频),知乎日报,果壳等等吧,这些app用户安装之后,要么当个工具用,要不就是公司已经提供了资源(比如电影电视剧)。就算知乎,果壳这样强UGC的,也可以允许用户查看别人的问题和回答,就好像百度,google一样,不注册你照样使用。这点很重要,这极大的延伸了不需要注册就能使用的app的范围。很多很有实力的web服务,都可以移植到app里,因为他们在web版本里已经有很丰富的内容了,app就是一个展现的渠道。比如很多很有名的论坛网站。 注册确实很麻烦,而且容易引起用户反感,如果注册本身只是阻碍而不是目的的话,我们是否可以考虑绕过或弱化它,基于上述思想。我考虑把注册从使用流程中拿出来,作为一个功能单独实现。这样可以极大的减小它对用户使用的影响。
3、先注册后设置密码
案例一:美丽说APP
![](http://www.mtedu.com/data/php/upload/image/20150724/1437727440245154.jpg)
如此便捷的流程十分适合像电商这种类型的app,对于那些冲动购物的孩纸们简直是噩梦啊。
这一功能主要针对于初次使用者,吸引更多用户方便使用,后续的账号管理就是待用户用爽了产品以后,再进行 诸如修改密码,换头像等操作。
关键点就是不要在不恰当的阶段走过多的流程,这是设计注册流程主要考虑的。
|