极客时间已完结课程限时免费阅读

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

01 | 验证码是个好设计吗？-极客时间

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

2017-11-21 邱岳 来自北京
《邱岳的产品手记》
课程介绍

讲述：邱岳

时长07:41大小3.51M

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

赞 30

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
开篇词 | 产品经理的世界没有对错
下一篇
02 | 产品经理工具指南
unpreview
 写留言

精选留言(94)

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

    作者回复: 👍

    共 3 条评论
    39
  • 求渔
    2018-04-26
    智能音箱的唤醒词就是这样的一个例子，如果不加，实现算法复杂，但是加了，用户使用繁琐。在技术不成熟时，可能会采用将复杂度转加给用户的方式。
    20
  • Geek_29c987
    2018-02-12
    超市水果上粘的标签 为了方便收银人员按个计费 但是回家之后要弄掉很麻烦
    共 3 条评论
    18
  • Dom
    2017-11-21
    验证码千奇百怪，唯独豆瓣的最让人舒服，不会歪歪扭扭难辨认，而且一直都是一个英文单词，从来没有输错过。
    17
  • 弗兰
    2017-11-21
    三方验证登录验证以后，马上要求验证手机号，接着还有输入密码和确认密码。觉得更好的做法可不可以之后必须绑定时再绑定手机呢？经常听见用户抱怨这种“假”的三方登录
    16
  • cos
    2017-11-21
    运营人想，输入验证码的地方是个很好的推广位，如果验证码能和产品的运营推广结合，是不是也是很好的创新。有明确的收益，有变革的动力。
    共 1 条评论
    15
  • 零
    2019-01-23
    我在用且慢app的时候，每次隔几天打开就让再重新登陆一次。软件也没更新啥的。 还有在第三方页面打开百度网盘，进行保存资源的时候，也是会让重新登陆。 我是极客时间的新用户，阅读的时候发现，二爷前几条回复了几个用户的留言，但是看不到那些用户的问题。就看的有点懵。
    15
  • 小姬不会飞
    2018-07-10
    不是很理解三方登录以后还要验证手机号并输入验证码和密码的目的，仅仅是为了留住用户吗？ 但是按我的习惯来说，我选择第三方登录仅仅是为了方便。当我刚开始使用一款软件时，并不了解它，只是抱着试用的心态，这一点我觉得"随便看看"这个就设计的很好。而当这个软件真的吸引我，我才会选择注册。 所以我觉得产品经理更多的关注点应该在如何设计产品吸引用户，而不是一开始就想着怎样留存用户。
    展开
    7
  • 杨惠姣
    2017-11-22
    提到验证码的输入对用户其实并无价值，就想到豆瓣的验证码，一个验证码就是一个单词。让整个生硬的过程优雅了很多～
    共 1 条评论
    6
  • 孺子牛
    2018-12-04
    刚开始做pm的时候，在理解商城登录功能的时候，当时专业性比较弱。想法比较飘。想的都是如何最简化这个流程， 比如手机获取验证码根本没必要，手机卡都插在手机里，难道手机不能识别吗？只需要点个“手机号码识别按钮即可”。关于验证码，当时我的上级给我讲了区别人和机器人这个原因。我就在想，要这么麻烦还输字母数字的啊，手机难道不能感受到是什么东西触摸了它么？而且手触碰按钮的时候都是有指纹的呀。直接“指纹验证”即可，多方便。 当时的想法我表达出来，告诉了一些资深产品经理。他们说等我懂得更多之后就能明白这个问题了。 后来看了无数竞品之后，在懂得了一些技术实现原理之后，我竟然觉得，验证码和手机验证已经是相对极简的方案了。 知识反而局限了想象力，做登录功能时候的初心变成了后来约定俗成的法则。 二爷关于验证码的思考谈不上多深邃，而是在从事多年之后还能保持初心，不局限于眼前，不放弃每一个细节的深度思考。这种产品品质是值得我去思考和学习的！ 感谢二爷的分享！
    展开
    5
  • 大伟真伟大
    2018-10-30
    好多停车都自己贴了支付宝或者微信，但是坑爹的是有的没有贴。恰恰又没带现金，只能堵着去后面的人微信转账取现。遇到几次了。 为啥没人做车牌自动划账呢？感觉要是能和政府部门合作，好大一块蛋糕可以切呢？？
    共 1 条评论
    5
  • 风信子姑娘
    2017-12-17
    饿了么的登录很顺畅 通过输入手机号 获取验证码后 系统自动辨别验证码 自动登录 如果涉及到登录的过程 用户只需要填写手机号就可以

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

    共 2 条评论
    5