邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
33999 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
邱岳的产品手记
15
15
1.0x
00:00/00:00
登录|注册

01 | 验证码是个好设计吗?

伟大的变革时代
新方法解决老问题
革命性用户体验进化
机器学习应用
滑动验证码
reCAPTCHA
用户利益 vs.产品利益
有效设计 vs.好设计
替代验证码机制
不推卸责任的设计
服务提供方责任
用户承担成本
增加门槛
区分人和机器
Completely Automated Public Turing test to tell Computers and Humans Apart
验证码的进化
方案选择的平衡
不推卸责任
技术演化改变用户体验
验证码的进化
方案选择的平衡
用户体验改进
责任推卸
设计初衷
CAPTCHA
思考
验证码设计
参考文章

该思维导图由 AI 生成,仅供参考

当你注册或者登录某个应用的时候,经常会用到验证码。它们大部分是由一串歪歪扭扭的字符组成的,看起来并不容易辨别。
验证码的英文名是 CAPTCHA,这不是一个正规的单词,而是个缩写,它的全称是:Completely Automated Public Turing test to tell Computers and Humans Apart,翻译过来是:用来区分人类和电脑的全自动图灵测试。不知道为什么,我就是觉得它听起来像一个不大正经的恶作剧。
据维基百科的描述,验证码出现于十年前,是为了防止机器(程序)假扮成人,去占用原本为用户准备的资源。比如,利用脚本程序不断地模拟尝试登录以便破解账号密码,或者利用恶意代码在 BBS 中发布大量广告或诈骗内容。
可以看到,它的设计初衷是为了区分人和机器,实现方式是在正常流程中增加了一道门槛,人可以翻过去,而机器会被挡住。
从某种意义上说,它可能是个有效设计,但我不认为它是个好设计。因为挡住机器这件事本应该是服务提供方的责任,而服务方却将其成本转嫁给了用户。
这件事引发了我的思考。
第一个思考:不要将责任推卸给用户
不知道你有没有想过,让用户辨别和输入扭曲的验证码,其实是因为服务提供方的能力欠缺,无法静默区分人和机器,而输入验证码本身,这一操作对用户来说其实并无价值。
有一次我接到用户打来电话,抱怨自己搞不定验证码。我向他解释我们正在被攻击,所以临时调高了验证码的级别。电话的最后,我习惯性地向他道歉,用户却很体贴地安慰我说没必要道歉,毕竟被攻击不是我们的错。
当时我心头一热,脸上一红。他说的没错,被攻击确实不是我们的错,但更不是用户的错,让他们付出成本,花费时间,去辨别图片里的那个圆圈究竟是 O 还是 0 还是 6,其实就是让他们承担我们本应该承担的责任。
举一反三,如果再激进一点考虑,我们的软件服务中还有不少推卸责任的设计,比如让用户在成千上万的商品中筛选和比价,比如各种复杂的界面参数设置和兴趣选择。要是想得再发散一点,所有的银行账户密码似乎也没有必要,超市排队也是一样。
如果用户不需要付出筛选和比价的成本,或不需要花费精力记住账户密码,却可以享受到同样高质量的服务,是不是更好呢?
基于这样的思考,我们是不是应该马上去掉这些推卸责任的设计,比如想出更复杂的方案,替代现有的验证码机制呢?这是关于验证码的第二个思考。
第二个思考:方案选择的平衡
有效的设计确实未必是好设计,比如我自己曾经参与设计的产品中也用到验证码,而且在某些特殊阶段(像刚才提到的被定向攻击),我们还会升级验证码机制,让验证码出现的频率更高,而且更加难以辨认,从而在某些关键入口抵抗一些有针对性的攻击。
这一策略是有效的,但对用户的伤害也很大,升级验证码机制后,用户登录过程中耗费的时间会显著增加,通过率也会下降,还有大量的用户抱怨一股脑地涌进来。
然而从服务提供方的角度来看,它却用最低的成本快速地解决了当时面临的问题。这是产品设计方案选择过程中不得不做出的“平衡”,很多时候我们没有办法第一时间实施对用户的完美方案,这就需要在产品利益和用户利益之间,找到微妙的动态平衡点。
所以让一个产品经理讲用户价值其实不难,天花乱坠说完美方案也不难,难的是在实际工程里做出合适的决定。做工程大部分时候都满身污垢,能在其中保持镇定,保持平衡并不容易。
我们当时在扛过了几轮攻击之后,投入了一些技术资源,引入了更多静默监测的策略。比如记录用户密码、记录用户上次登录的位置 / 设备,或通过一些页面动作来做出判断,保证大部分老用户和一部分新用户不会受到验证码的打扰。
我们并没有做到完美,因为资源永远有限,我们需要把它更多投入到我们的竞争优势上,所以还是保留了验证码机制。在某些情况下还是用这种原始、粗暴,但有效的手段来解决问题——这就是我们选择的平衡。
第三个思考:验证码的进化
Google 在两三年前发布了一个叫作 reCAPTCHA 的解决方案,本着“对人类友好,对机器难搞”的原则,用户只需要简单点击一个“我不是机器人”的复选框就可以,不再需要分辨歪歪扭扭的验证码。reCAPTCHA 通过收集用户环境和行为数据,综合分析、智能区分人和机器。
除此之外,阿里也发布了自己的滑动验证码,还有国内一些第三方的验证码服务也在快速迭代进化。毕竟 Google 的服务不太稳定,他们还是获得了自己的生长空间。
这些更高级的验证码服务,大部分都在标榜自己的“人工智能”属性,不管真假,这确实是个非常典型的机器学习应用场景,提供各种行为特征,训练算法去分辨人和机器。
我们把这个思路放大来看,如果可以把过去看似理所应当,其实是由于服务提供方的成本考虑,而把责任推卸给用户的那些功能或流程拿出来重新思考设计,再搭配成熟的机器学习算法,或许就可以带来一系列革命性的用户体验进化。
比如免密支付,让用户不必再耗费精力记录密码,比如无人超市,让用户无需排队付款,无人驾驶,让用户在通勤的过程中不需要费神开车,等等等等。
这个伟大的变革时代提供了新的方法和工具,让我们有机会重新去审视过去由于技术和工具的限制而不得不做出的妥协。
用新方法解决老问题,或许不需要什么翻天覆地的变化,只是撬松一两块被惯性封印的砖,就已经算得上强有力的推动了。这是验证码给我最后,也是最重要的启发。
所以说,一个简单的验证码,背后却并不简单,我们能从中看到设计原则、设计哲学,甚至技术演化改变用户体验的过程。
在你熟悉的产品中,是否也有像验证码这样,虽然用户习以为常,却并不合逻辑,而且暗含机会的产品形态呢?不妨在留言中讲出来,我们一起讨论。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

验证码是一个常见的设计,用于区分人类和机器。然而,文章提出了对验证码设计的质疑,认为将责任推卸给用户并不合理。作者认为,服务提供方应该承担区分人和机器的责任,而不应该让用户付出成本和时间去辨别验证码。同时,文章也探讨了设计方案选择的平衡,指出有效的设计未必是好设计,需要在产品利益和用户利益之间找到动态平衡点。此外,文章还介绍了验证码的进化,提到了一些更高级的验证码服务,如Google的reCAPTCHA和阿里的滑动验证码,以及机器学习在验证码领域的应用。最后,文章呼吁利用新方法解决老问题,重新审视由于技术和工具限制而做出的妥协,以带来革命性的用户体验进化。整体而言,文章对验证码设计进行了深入思考,提出了对设计原则、设计哲学和技术演化的见解。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《邱岳的产品手记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(96)

  • 最新
  • 精选
  • 二爷
    置顶
    @Atom:是的,苹果在Touch ID识别率还不是很高的情况下(不能识别潮湿的手指)就采取“三次识别失败才允许用户输入密码”的策略,不是很奇怪吗?// 很可能是苹果大爷原来xx了,但也有一种可能,我们从非要给它找出一点道理的角度来猜。 可能是过去的「召回率低」,也就是 false negative 高,也就是说指头是对的,但算法有点弱,没查出来,因为动动手指成本低,所以索性就让用户再试几次。 后来算法进步了,false negative 低了,摁一次,算法发现指纹不对就肯定不对,不用再试了,直接摁密码就好了。 有点强词夺理,但是另种思路,希望能给你启发。
    2017-11-22
    4
  • 二爷
    置顶
    @刘祯 我记得苹果有个应用就是戴着 Apple Watch 走近 Mac 就可以自动解锁,跟你说的思路很像
    2017-11-21
    6
  • 二爷
    置顶
    @cos 可以做用户调研,也可以用验证码做营销,比如输一遍品牌名什么的,这是一个用户绕不过去的路障
    2017-11-21
    1
    19
  • 二爷
    置顶
    @Atom 我觉得应该跟 Touch ID 的识别效率有关系
    2017-11-21
    3
  • 二爷
    置顶
    @Dom Google 会利用验证码帮图书馆项目做 OCR 辅助,也挺有意义的,我之前在丁香园的时候一直想利用验证码做一些专业性的事情(因为登录的都是专业医生),但没来得及实施,如果用户量大而且有什么特别的专业属性其实可以考虑考虑的。
    2017-11-21
    15
  • 二爷
    置顶
    三方验证登录验证以后,马上要求验证手机号,接着还有输入密码和确认密码。觉得更好的做法可不可以之后必须绑定时再绑定手机呢?经常听见用户抱怨这种“假”的三方登录// 对,特别假,大部分人都担心没有手机号会拽不住用户,我觉得其实问题不大。
    2017-11-21
    5
    68
  • 二爷
    置顶
    @ 圆圆 Annika// 其实主要也是因为平台迁移,过程转向手机了,现在输注册密码也倾向于明文,或者提供明文选项啦
    2017-11-21
    1
    7
  • 二爷
    置顶
    @ 孤独的老米//手机号验证有两个风险,一是黑产有大量能接收短信的黑手机,二是可能会被「呼死你」之类的应用利用发短信的接口盗发,所以还是需要加上一些策略,有时最直接的就是验证码; 小米的应用有时是可以识别手机号的,在注册的时候(iOS),应该是运营商提供的信息,运营商在这件事情上其实是大有可为的,可惜…
    2017-11-21
    2
    11
  • 破晓
    第三方登录后需要手机号验证还有一个原因是为了避免一个用户产生多个账号。几年前做的一个产品,支持微博、微信、QQ、手机验证码注册,但登录设计欠缺,许多用户用不同方式登录之后,产生了多个账号,甚至有部分用户经常反馈自己的帖子、订单没有了,其实是在她的另一个账号里面。 后面想考虑给用户合并账号发现太难了,真是一个大坑。所以设计的时候一定要考虑这个场景,处理好。 在用户产生重要数据的缓解必须绑定手机号,避免此类情况?

    作者回复: 👍

    2018-04-17
    3
    41
  • 风信子姑娘
    饿了么的登录很顺畅 通过输入手机号 获取验证码后 系统自动辨别验证码 自动登录 如果涉及到登录的过程 用户只需要填写手机号就可以

    作者回复: 这是在 Android 中,iOS App 获取不到短信内容

    2017-12-17
    2
    6
收起评论
显示
设置
留言
96
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部