01-产品策划-用户登录注册

系统总结了关于用户登录注册的一些知识,供大家参考。

在互联网世界,用户是一切,如果用户都只是匆匆过客那么很难在产品中形成固定的用户群,在用户行为统计上也很难形成有价值的数据,如今就算是工具类的应用也都在建立用户系统,更不要说社区或社交类的产品。

一、为什么要注册登录

首先我们来分析注册、登录功能的价值在哪里,我们从三个层面来分析:

1.用户层面

①用户需要在产品中获得一个独立的ID,以体现其个性化的存在。

②用户需要产品为其记录使用进度、状态、收藏的内容。

③用户希望获得其它用户的真实信息或更详尽的信息。

④用户希望产品通过对自己更详尽的了解提供更好的服务。比如大姨吗。

2.功能层面

①便于跨设备同步数据,也便于在同一设备中切换不同的账户并保留账户之前的状态。

②有社交功能的产品必须注册账号以编写自己的UGC的内容,同时便于其它用户辨识。

③有交易功能的产品,为个人账户记录订单等交易信息,同时提高交易的安全性。

④有应用内付费、VIP会员增值功能的产品,注册登录可以确保用户权益。

3.业务层面

①需要采集对于核心业务非常重要的用户信息,比如手机号、真实姓名等信息。

②注册登录后便于采集推进运营的数据,以指导产品运营方向。

③用户激励:通过注册得到手机号、邮箱账户后,一些产品通过给用户发短信或优惠券(送优惠券、活动推荐)吸引用户,提高活跃度。

④消费转化:某些产品得到手机号后,会利用电话营销的方式向客户推介其付费服务。

综上,在设计功能之前,产品经理应该弄清楚你的产品目标属于以上哪些,注册账户功能的重要性怎样,哪些核心功能与其相关联。

二、注册登录的方式和优劣势

1.用户登陆注册系统分为两大类

①自建用户系统:邮箱、手机号、用户名(单一用户名+密码的方式正在被淘汰)

②第三方账号授权用户系统:微信、微博、QQ

这其中,自建用户系统是自己控制和维护用户的一套登陆信息,对于日后找回密码或发送消息都有一定的方便性。第三方账号授权依托于第三方社交平台来登陆,属于一种绑定行为,忧点是用户注册方便,但缺乏控制性。

2.在选择注册登录方式之前,先总结一下注册登录设计时要考虑的因素

①普遍性:这种注册方式是否绝大部分用户群体都满足注册条件?是否有门槛?

②便捷性:注册流程是否方便,易理解,易操作,易记忆?

③安全性:这种注册方式是否存在安全性问题?

基于以上评价因素,针对三种不同的注册登录方式进行下比较:


3.具体分析几种注册方式

①用户名

在自建用户系统中,单一用户名+ 密码的这种登陆方式已经很少见了,至多出现在一些内部系统中。对于云端的产品,一旦用户忘记用户名或密码,那么这个账户也就再也无法登陆了,除非找管理员证明身份来人工取回,这在如此大用户量的互联网产品中是不可行的。

所以用户名+密码的体系正在被淘汰,还比较常见的方式是用户名密码和邮箱或手机号码等一起使用,例如一些论坛都采用这种体系,注册是同时提供用户名密码和邮箱,在登陆时可以用用户名+密码快速登陆。

②邮箱注册

相对于手机号注册,邮箱注册的好处在于邮箱地址可以永久留存,不会有手机换号造成的那种困扰。但是其缺点也比较多:

首先,对于国内用户来说,邮箱的使用频率没有老外那么高,邮箱的重要性远低于QQ、微信、手机,很多用户没有个人邮箱,他们也不会为了注册你的账户去申请个邮箱,所以邮箱注册的需求相对来说较弱。

其次,在移动端利用邮箱注册的体验也较差,因为验证邮箱的话需要跳出APP去接收邮件,无论是登录邮件客户端还是打开浏览器进入邮箱网页,这个操作都提高了流程的复杂度,降低了用户体验。

那么,邮箱注册是否还有存在的价值?为什么还有一些应用保留了邮箱注册功能(或只提供了邮箱注册功能)呢?个人分析有四点原因:

a.APP的用户群体不只国内用户,考虑到外国人的使用习惯,保留了邮箱注册。

b.一些商务类的APP,用户群体锁定为职场人士,这些人是有邮箱的使用习惯的。

c.一些学习类的APP,考虑到学生群体换号的可能性比较大(或出国)。

d.考虑到一些不希望暴露自己手机号,不愿意用手机号注册的用户群体。

我们先来看下以下四种注册流程:

方式1的效率最高,但是没有邮箱验证的话保证不了账户的安全性,若邮箱录入错误则无法找回密码。另外这种方式容易被注册无效账户或恶意注册邮箱,浪费服务器资源。

方式2的验证码(或链接)需要在注册流程中强制输入,这种方式会阻断用户的操作流程,有在注册过程中损失用户的可能。如果邮箱信息对业务逻辑及其重要的话,可以参考这种方式。

方式3和4都是快速注册成功,之后再让用户通过邮箱验证的方式验证邮箱的有效性。这种方式的好处是既保证了注册信息的有效性和安全性,也不会降低太多的用户体验。其中方式4是在APP中完成邮箱的验证,这样可以避免方式3中用户注册后忘记去验证的问题。

如果邮箱信息有一定重要性的话,建议选择第4种方式,以Facebook为例:先注册,后通过发送到邮箱的验证码进行验证,在注册后的首页中,会有验证邮箱的提示。

如果考虑到降低开发成本,或邮箱信息没那么重要的话,可以第3种方式。

③手机号注册

手机号注册多见于移动端产品中,注册时使用手机号当做用户名,此时需要手机接收验证码来确认配对,配对可以为了确认注册的手机号是用户本人的,可以防止输入手误或他人恶意注册带来的风险。手机配对之后再输入密码和一些产品需要的相关信息,如昵称、性别、兴趣等,这些就与主要注册流程无关了。以下为手机注册的流程图:


手机注册的优势在于:

a.对于移动端产品,验证方便,在注册时可以比较方便地让用户完成验证操作,而且在一个连贯的流程中完成(很多时候阅读验证码不需要打开短息,只是在上弹提示中就可以获取)

b.手机号记忆方便,对用户名的记忆和密码找回都非常方便

c.手机号码是用户最稳定的一个身份id,掌握其手机号码可以展开更多的服务,例如通过访问通讯录构建关系

d.实时的消息推送

手机注册的问题在于:

a.手机号虽然是全球唯一的,但是是复用的,也就是当你不用一个手机号之后,运营商会把这个号重复利用卖给下一个人

b.手机作为现代人的一大器官,手机号码的泄露会引起非常多的麻烦,比如垃圾短信、骚扰电话之类的,所以用户多会比较谨慎地选择

补充一个效率更高的登录注册方式:

即将登录和注册功能集成到一个页面相同的控件中。操作方法是:当用户输入手机号后,移出焦点时系统判断该手机号是否已经在数据库中进行了注册。如果已经注册,则让用户继续输入密码;如果未注册,则系统界面立即变化成注册界面,在下方加入验证码输入框,以便用户完成注册。


④第三方帐号注册登录

第三方账户登录,国内常见的有微信、微博、QQ三个社交平台的授权登录,国外常见的还有Facebook、Twitter、Google。下面分析一下利用第三方账户登录的优缺点:

优点1:为用户节省注册时间,简单点击两下就可以直接登陆。体验最佳。(不包括微博认证总出错的问题)

优点2:利用第三方平台注册过的用户,都是经过手机或邮箱验证过的用户,安全可靠。同时引入第三方账户的方式也将账户安全性的问题抛给了第三方平台。

优点3:利用第三方账户登录,可以在条件允许下获取第三方平台的信息,比如好友信息、基础资料等信息。

缺点:只利用第三方账户登录的话,无法获得任何有价值的用户注册信息,同时也构建不成自己的用户体系。这是第三方账户登录的最大问题。

如何利用好第三方登录的同时,也能逐步构建起自己的用户体系呢?

一般的做法是在第三方账户登录后,立即弹出“绑定手机”或“完善信息”的页面,这样的做法会给用户带来很差的体验,用户使用第三方账户登录的本意就是跳过注册的流程快速登录,但登录后发现还要进行跟注册相同的短信验证等操作,会感觉被玩了一样。所以,设计时应尽量避免这种情况的发生。更加合理的解决办法是:①在绑定手机画面中加入“Skip”按钮,让用户自行选择是否录入。②不在第三方账户登录后立即显示绑定手机画面,而是在使用某些必要的功能时弹出绑定画面。

三、注册登录的设计思路

以上分析了三种不同的注册登录方式,那么在产品设计过程中,如何设计注册登录的流程,如何选择注册登录的方式呢?由于不同产品所处的阶段不同、产品目标不同、人群定位不同,所以想要得出一个标准答案是不切实际的。下面给出一个整体的分析思路:


1.分析产品让用户注册登录的必要性

分析有没有必要为APP设计注册功能?如果用户注册登录对于用户、产品功能、商业模式本身带不来任何价值的话,就没必要设计这样的功能。比如一些实用工具类的产品:计算器、手电筒、天气预报、安卓清理大师、语音助手等等。

2.分析产品让用户注册登录的目的

可以从用户、功能、业务三个层面分析这个问题。针对本产品,每个层面的需求都需要认真的进行思考:

①用户需求

从用户角度,分析用户希望注册产品的迫切程度。用户第一次安装使用一个APP时,可以分成三种不同的心理:

a.用户有强烈愿望使用产品。一种情况是产品功能对于用户来说非常有价值,用户愿意花费时间注册使用,比如说一些手游、一些有美女主播的直播类软件。另一种情况是产品功能新奇特用户很像试试,比如FaceU,当女性用户看到了朋友圈里出现了有趣新奇的FaceU靓照时,自己去体验的意愿很强烈。用户有强烈意愿使用的产品,完全可以先注册再让用户去使用。

b.用户希望先用一用看看,好用了再注册。这就跟体验式消费、先尝后买的思路是一样的。由于大部分用户第一次使用肯定是抱着试试看的态度来的,为了给用户留下最好的第一印象,先使用再注册的流程是必要的。目前大多数的产品都是提供这样的方式,如果你的APP不能让用户有强烈的使用愿望,最好的选择是先让用户去使用,用好了再注册。

c.用户觉得没必要注册,但产品的功能偶尔会用到。一些使用频度较低的APP,比如铃声、壁纸类软件,以及一些工具+社交类的软件,对于用户来说注册功能对用户带来不了任何价值, 这类APP建议使用先使用后注册的方式。

②功能需求

从功能角度思考,一种情况是产品的核心功能对用户体系依赖程度非常大时,可以先注册再使用。比如QQ、微信、陌陌这样的社交软件,不登录无法正常使用功能。另一种情况是产品某些功能需要用户登录,但对其它功能没影响时,可以使用到该功能时再登录。比如电商APP可以先浏览,在加入购物车或下单时再登录。

③业务需求

从业务角度来判断,注册信息如果对产品核心业务非常重要的话,可以考虑先注册的模式,或者常用的做法是进入APP的第一屏是注册页面,但在角落里留下“游客入口”的按钮。当然,如果只是为了获取用户的手机号等信息,也不一定非要通过注册这一种途径。可以在产品功能页面中引导用户录入信息或注册。比如驾考宝典的“帮你选车”的小测试功能,再比如设计君的“咨询规划师”功能。

3.分析每个注册登录需求的场景

根据场景的分析得出最适合本APP的注册登录方式的问题,还是从用户、功能、业务三个层面思考:

①功能需求

从功能角度,对注册登录有需求的功能要的是一个合理的账户体系,至于选择那种注册手段其实不重要。所以可以忽略功能需求对注册登录方式选择的影响。

②用户需求

对于用户来说,三种注册登录手段的优缺点都很明显,不同的用户的性格特点、生活习惯会影响其选择:比如有的用户讨厌泄露手机号、有的用户没有个人邮箱、有的用户没有安装微博等等。另外,相同用户在不同的情况下也会有不同的选择:比如在挤公交地铁时使用、在吃饭时使用、在看电视剧时使用、闲得无聊时使用、朋友在身旁推荐时使用等等。以这种多样化场景需求来考虑,最合理的做法应该是为用户提供多种注册登录方式,最好是手机号、邮箱、第三方登录都有,让用户自己去选择使用哪种。

进一步分析,如果能锁定APP的目标用户群体,能够细化出突出其特点的用户场景,可以根据其用户特点添加或减少注册登录方式。比如我的APP不考虑海外用户群体,用户基本也没有使用邮箱的习惯,那么就可以考虑不选择邮箱注册的方式。比如我的用户大多数是大学生群体,会经常换手机号,或者一部分还有出国的可能,那么邮箱注册就是必要的。

③业务需求

分析具体业务需求的场景会得到不同的选择。对于一些业务模式来说用户的手机号信息非常重要,会考虑只保留手机注册一种方式不给用户更多的选择。有的产品考虑到开发成本和日程进度的因素,会选择最常用的手机号注册方式。对于一些产品来说手机号不是必要的信息,可以选择直接利用第三方账户登录。

四、注册登录功能的设计细节

确定了设计思路之后,我们来看看设计登录注册功能中,在细节上要考虑哪些点。以WPS客户端为例,我们分析一下登录注册功能的整个页面流程。其中,邮件验证成功、邮件重置密码、邮件重置密码成功三个页面为利用邮件客户端打开的Web端页面。整个流程逻辑清晰,引导流程的按钮突出醒目突出,需要用户配合的操作都以文字形式进行提示,用户使用起来没有障碍。


1.在流程设计中需要注意的细节

①注意页面跳转后是否应该有回退按钮,以及点击安卓的back键应该退回到哪个页面。不应该退回到已经提交完数据信息的页面。

②重置密码成功后,一般应该返回登录页,让用户输入新密码以便加深记忆。

③注册成功后,一般来说会直接登录成功进入APP首页。但一些金融类对账户安全度要求较高的APP会在注册成功后返回登录页,让用户重新输入一遍密码,以加深记忆。

④在某些可能会产生异常的点(比如提交数据时服务器异常、邮件或短信未发送、响应超时等),一定做好准备,一旦发生异常给用户合适的提示。

⑤考虑到是否会存在短信验证码,或验证邮件收不到的情况,这种情况能不能提供备选方案。

2.功能设计时要注意的细节

①用户体验方面

a.将邮箱和手机号输入框整合成一个,节省了空间提升了美观性,还减少了用户的操作步骤。

b.用户名密码这些必填项未输入时,登录按钮为不可用状态,避免误操作带来的麻烦。

c.输入框中显示提示信息的方式进一步释放了画面空间,让整个画面更加简洁。但是注意输入框和提示文字的灰度要把握好,太浅了灰难以察看。

d.画面中核心流程按钮突出显示,其它按钮最小化显示,根据重要程度可以将颜色加以区别。

e.输入框的获得焦点时突出显示,以便在多个输入框时辨别焦点所处的位置。

f.错误提示直接显示在画面中,不以弹出对话框的形式或toast的形式实现。弹出对话框体验差,toast显示时间过短的话用户可能没看清。

g.画面中的输入框、按钮等重要控件尽可能在弹出软键盘时都显示在屏幕上半部分,以便用户切换、确认等操作。

h.注册/登录失败的情况,提示信息应尽可能详尽,是账户名出错还是密码出错,或者是手机号已经被注册过了,越详细越好。

i.输入邮箱地址时,建议弹出自动补全功能,自动加入常见的邮箱后缀。

j.发送验证邮件后,应该给用户详尽的说明和操作提示,也可以加入一个按钮跳转到相应的邮箱地址。

②功能逻辑方面

a.发送短信前可以弹出对话框提示确认一下手机号,这种做法可以让用户自行确认一下手机号是否输入正确,节省了用户发错一条短信的成本。当然这种做法用户体验稍差。

b.注册页面考虑是否有必要加入服务条款链接。个人觉得没有必要同时加入一个单选框让用户去选择,因为点击注册按钮就代表了同意服务条款。

c.为避免反复点击发送多次验证码,点击一次发送验证码按钮后会倒计时恢复功能,一般为60秒。

③安全性方面

a.密码输入框加入显示/隐藏按钮,默认为明文显示状态。防止用户输入错误。

b.一般情况下不需要设计“确认密码”输入框,考虑到移动设备空间有限、操作不便。但一些对密码安全要求严格的应用还是会设计“确认密码”功能。

c.密码输入错误过多时,考虑要不要加入验证码机制,以防止恶意破解密码。

d.短信验证环节,连续验证次数超过5次时,考虑加入验证码机制,以确保安全性,同时避免无谓的损失。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,847评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,208评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,587评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,942评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,332评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,587评论 1 218
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,853评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,568评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,273评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,373评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,031评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2 269

推荐阅读更多精彩内容