手机短信验证码交互概念

概念没弄清之前，不敢冒用“XX设计”、“XX结/架构”字眼。

手机发送验证码，是个最简单的例子。从用户角度讲，流程如下：

输入手机号（输入）->获取验证码（点击）->输入验证码（输入）->确认（点击）

这四个步骤中所有操作都是非选择性的，也就是说输入手机号和验证码，获取验证码和确认，都是有且仅有此一项操作需要用户完成的，不会引起用户歧义的，所以光标默认都可以在完成步骤后下一输入框/按钮上聚焦。

这单单是从用户使用计算机的角度讲的，如果涵盖用户的所有操作流程，应该为：

用户点击申请/设置进入“获取验证码”页面->输入手机号(1)->获取验证码(2)->接收手机短信(3)->手机按键查看短信内容(4)->记住验证码内容(5)->在计算机上输入验证码(6)->点击确认，完成验证过程(7)

其中的所有环节注意细则：

(1) 中国大陆的手机号为固定11位，所以文本框限长11位。

考虑到用户容易出错的状态和行为，可以设计仅提供阿拉伯数字输入，同时如果用户输入全角数字则自动将其转换为半角数字，出错提示可以在用户焦点离开文本框时激发判断条件。

如果再考虑细节，可以将文本框的默认值设置为1，或者+861，这是手机号码的规律数字。不过考虑到用户的使用习惯，所有人记手机号都是11位11位的，这个1要不要加还有待商榷。

(2) 在用户输入了第11个数字后，光标应该默认移动到“获取认证码”按钮上（按白鸦图），对于经常输入用户名/密码的用户，快捷的方式都是输完用户名之后按键输密码然后按这样登录的。

 

(3)由于地域等原因，短信有时候需要等待好一会儿才能收到，这期间有的用户会因为不耐心，或者觉得短信没到，重新申请验证码。

Google这点做的不是很好，我就因为一直没收到其短信而不停重发验证码，等验证码到了的时候一下来了一大堆，都分不清哪个才是最后的那个。我觉得一个可行的方案是用户点击“获取验证码”后，给一个提示：“您的验证码已经在路上了，重新获取需要耐心等待XX秒”，这个XX以

秒倒数（比如30秒），等计时到0才变成再次获取验证码。既降低了服务器资源浪费，又能给用户明确的提示。

(4)在接受短信上Nokia的比较人性化，当有短信或者电话进来时，中间的功能键就是查看新短信或者接听电话，而不用再一层一层打开菜单查看。其他的反正我看到同事一款索爱的就非常麻烦，需要打开菜单的。不过在收到信短信时，同事的效率也很高，习惯成自然，就不觉得被虐待了。

(5)现在的验证码一般都是数字的（瞎猜腾讯要出汉字的验证码）。最好的用户体验应该是用户一眼就能记住的内容，不必重复翻看或者校对的。但是出于安全性考虑又不能设计的太短，一般市面上最短见过极个别3位的，一般都是4位，Google的如果没记错好像是6位。不知道有没有什么科学依据。

不过，我个人觉得5位的验证码更适合中国人，并且有两位数字一样或者发音的平仄相同。为什么呢？因为从记忆和朗读的规律看，这样的数字更容易被瞬间记住，比如10086这种的。另外一个角度，从古诗看，什么“平平仄平仄”这种的容易被瞬间记忆（没有科学根据，老祖宗传下来结合自己瞎猜的）。不服？举个例子：74188好记还是32906好记？（说实话，对我来说都差不多-_-）

(6) 一般验证码都是固定位数的，无论是4位还是6位，完成输入后，光标应该自动移到“确定”按

钮上，这样按空格就能提交了。

最后通用的一点：鼠标定位慢，键盘定位快；鼠标需要看屏幕确认，键盘闭眼睛就能输入完成。为啥用空格不用回车？因为我的小姆指没大姆指那么发达。

本文来自：http://ucdchina.com/post/1098

补充：

注册时验证码:用户注册时需要填写手机号或者邮箱,点击获取验证码,此时你使用java的random生成一个随机数或者就使用时间拼出来一个随机数,然后将这个随机数存储在此用户的session中,使用java发送邮件,使用短信猫或者短信网管发送短信把验证码发过去,用户收到后在网站上输入收到的验证码,用户点击注册,java后台验证用户输入的与session中的验证码是否一致,不一致拒绝注册

注册完成后激活码:与上面不同的是先允许用户注册,只不过用户属于未激活状态,然后把生成的激活马存在用户表的一个字段上,并给用户发过去,用户收到后登录自己的账户把激活码输入正确后,用户状态修改为正常