您的位置:首页 > 其它

我们是如何设计支付表单的

2015-07-21 14:49 246 查看
原文:THE
ANATOMY OF A CREDIT CARD PAYMENT FORM


译者:杰微刊-张帆

杰微刊编注:

本文是Wave(已有上百万用户的在线账务管理系统)工程师讲述的信用卡表单设计过程。

从实际场景出发,讲述了表单中的图标摆放、文案设计、用户交互、错误处理等各方面设计的思考和权衡,内容绝不仅涉及信用卡和表单。

希望本文对产品设计师、UIUE、开发工程师都有所帮助。

使用信用卡在线支付看起来很简单对吧?肯定和否定的答案各占一半。回答“是”,是因为自从互联网伊始我们便一直在这样做(比如亚马逊);回答“否”,是因为没有两张信用卡的类型是相同的。

在过去的20年,我们建立了一种在线支付的心理模型:在自己的钱包中抽出一张信用卡,将信用卡的详细信息填到网页的表单中,然后点击提交按钮。但整个过程充满了用户难以理解的各种问题。显然,也没有人愿意在此过程中查看使用手册。



各大受欢迎网站和APP中的信用卡表单

目前,在线支付仍然比直接当面支付要笨重2到3倍。没有什么方式比在支付终端上刷卡或者插卡更便捷。零输入的操作,你甚至不用关心卡片上打印的信息。我们假想这样一个神奇的世界,你在显示器上刷一下卡,就可以在你最爱的乐队那里买一件屌炸天的全新体恤。或者我们完全放弃物理卡片,这样你就不需要在钱包中取出它再进行支付。通过Apple
Pay,我们已经在现实世界中取得了支付方面的里程碑式的发展。

我们与互联网越来越紧密。在线支付也变的更快捷方便。最新的HTML标准中包括了对信用卡输入的说明,同时浏览器还在不断的推动这其中的界限。Chrome浏览器42以上版本支持自动完成。Safari支持信用卡信息自动填充。但是每一笔交易你都不得不需要一张实际的卡片来输入安全码。

在信用卡表单还未被历史淘汰时,我们今天的任务仍然是要在其中添加清晰、简单、安全的验证逻辑。

Wave上,我们的发票清单系统可以使商家开发票清单并将这些发票清单送达他们的客户,而这些发票都是通过信用卡支付的。我的工作是在给定的业务需求上设计一套信用卡表单。这篇文章就是关于我们团队在最终形成产品之前对设计方面的思考和探索。



我们的目标是使用户的输入和疑问变的有意义,其中包括:

1. 接受哪些支付卡?

2. 支付金额

3. 卡片上的签名

4. 卡号

5. 所使用的卡片类型

6. 有效期

7. 安全码

8. 为什么需要邮编

9. 表单是否安全

10. 当我点击提交按钮会发生什么

11. 处理卡片错误

12. 针对不同屏幕的适配

1. 我们接受哪些支付卡?

当信用卡表单呈现在用户面前时,用户第一个问题便是“支持我的信用卡吗?”。这个行为其实等同于现实社会中的场景。当你在收银台准备付款时,你可能会寻找一些告示,上面说明了哪些卡片是可以进行支付的。所以,通常的解决方案时使用信用卡图标作展示。

但是,在网页的表单中,你将图标置于何处呢?起初,我们尝试把这些图标放置在卡号这一栏上面。这个位置减少了表单的高度,但是图标看起来小且拥挤。另一个选择时将卡片的图标放在卡号的输入框中,而这样做又使得卡片占据了输入框过多的空间。我们后来决定将信用卡图标放置在表单的最上面。这样,这些图标可以在视觉上被用户直接看到。用户不需要一一搜索来确定支持怎样的卡片,同时,这些图标还能及时的引起用户的注意,传递了这样的信息——“这就是你要进行支付的地方”。我们觉得单纯的图标足够了,所以我们并没有添加标签,比如“Cards
accepted”或者“Pay with”。详见下图所示:



2. 支付金额

另一个我们需要满足的要求是允许用户决定要支付的金额。对于金额较大的发票,用户可能需要部分支付(比如定金),或者在工作完成之前分阶段支付。默认情况下,支付金额等于全部未支付的发票金额。换句话说,如果用户决定部分支付,则支付金额等于所欠金额。

对于网页表单而言,我们知道,越多的输入导致越低的完成率和更高的拒绝率。为了减少输入项目的数量,我们将支付金额以只读方式展现,点击编辑按钮可以进行修改,而不是直接默认展示输入文本框。在编辑模式下,我们考虑需要有一个“保存”或“完成”按钮,点击之后将会使输入框回到只读状态。但是我们后来发觉这样并没有必要,因为金额已经在输入框中可见。此外,如果用户希望在此编辑金额,他们可能只需要简单的更改输入金额即可,不需要处理任何Edit/Done按钮。

我们还想要在用户准备提交表单之前确认金额。一个确认可以消除用户对他们信用卡即将支付多少金额的顾虑。我们在“Pay”按钮中展示了需要支付的金额。这个数量随着“支付金额”输入框的变更同步更新。



3. 卡片签名

另一项我们需要用户提供的是卡主的签名。对于标签文字,我们考虑了一些选项,如下所示:

* Name of card holder

* Card holder name

* Name on card

* Name(和卡片上一致)

* Full name on card

我们觉得Name on card是提示用户输入的最短和最清晰的方式。它请求用户在输入框中输入和卡片上所展示的一模一样的签名,而不是使用户考虑卡主的全名或者缩写。

4. 卡号

碰到卡号输入框时,用户一个常见的问题是“我的卡号之间有空格,我是否需要输入空格呢?”为了解决这个问题,我们规定了输入的值只能是0-9。所以如果用户输入了空格,该空格不会被显示,也不会对数字格式产生任何影响。

起初,我们想在用户离开卡号输入框时遮挡卡号。这样做是为了提供给用户安全感,类似密码输入框被遮挡一样。但是我们后来意识到,信用卡卡号并不是一个“秘密”。仅有一个卡号,你也做不了任何事情。此外,当用户准备提交表单时,他们可能希望重新检查一下输入是否准确。一个遮盖的字段可能会打断用户的检查,因为用户可能不得不把焦点重置在输入框来确保它的内容。

5. 所使用的卡片类型

我们在其他的支付表单中学到的一个有用的模式是在视觉上暗示所使用的卡片类型。它们可以使用户确保输入的卡片类型和他们手中的卡片类型是一致的。我们可以通过卡号的第一个数字来判断卡片类型,如下所示:

* 3 -
Travel/entertainment cards(如美国运通卡和大来卡)

* 4 - Visa

* 5
- MasterCard

* 6
- Discover Card

当用户输入前两位卡号后,我们立刻在输入框的右侧显示卡片logo,如下图所示:



当然,和问题1类似,我们也做过不同的尝试:

* 将表单上面的卡片logo去掉,因为这些logo距离卡号输入框实在有些远,相关性并不明显。

* 默认将所有的信用卡logo放置在卡号输入框,当用户输入前两位卡号,仅保留输入卡号对应的卡片logo,其他logo全部隐藏。

6. 有效期

大部分信用卡以MM/YY(月份/年)的形式来展示他们的有效期。有些会以完整年份展示,如YYYY格式。在设计有效期输入时,我们希望能够给用户提供一个高效的输入模式。用户不需要使用鼠标在选择菜单中选取日期和年份,或者通过上下肩头进行选项的导航。用户只需要简单的输入信用卡上的日期即可。这样可以避免用户去考虑实际的月份,如08表示8月,这样一来,思考最小化。

由于输入需要有特定日期格式,所以我们在输入框中放入一个默认显示的文字。值得注意的是,默认显示的文字包含一个“/”,但是在输入时却不要求用户输入这个符号。我们通过控制输入只能是数字,所以如果用户输入/,将不会被显示。当输入月份后,斜线自动加在其后面。



7. 安全码

信用卡的安全码是为了减少信用卡诈骗而被开发的。换句话说,有了安全码,卡片更安全。但问题是,这个代码在不同卡片上的命名并没有统一标准,我们应当怎么称呼这个码呢?每种卡片都有其独特的命名:

* MasterCard
- 卡片许可码(CVC2)

* Visa - 卡片认证码(CVV2)

* Discover
- 卡片身份码(CID)

* American Express
- CID或者唯一卡片码

* Debit Card
- CSC或卡片安全码

此外还有一些其他的排列:

* Card verification data

* Card verification number

* Card verification code

* Card code verification

有些疯狂,不是吗?卡片的首字母缩写更会产生混乱和疑惑。我们希望避免这种疑惑,但同时能够暗示用户这个输入关乎安全。所以我们将这个输入命名为“安全码(Security Code)”。

接下来,一个安全码可以有4位数字(美国运通卡正面)或者3位数字(其他品牌的卡片的背面)。为了帮助用户决定在哪里找到要输入的代码,我们包含一个图片提示,这个图片提示有三种状态:

1. 双重代码: 如果用户未输入任何卡号,图片提示则会显示两种可能的选项;

2. 4位代码: 如果用户的卡片是美国运通卡,则图片提示则会显示为卡片正面的4位数字

3. 3位代码: 如果用户使用了其他卡片,则图片提示展示位卡片背面的3位数字

如下图所示:



8. 邮政编码

出于额外的安全度量,我们不得不询问和用户卡片相关的邮编。这里有所权衡:添加额外的输入会增加用户的抵触,但是添加了这项输入,我们的业务会更安全,有更小的被诈骗的倾向。

我们意识到用户输入的邮政编码可能与他们的个人地址有关,而不是与其卡片相关的代码有关。为了使用户明确,我们添加了一段提示框,提示用户输入信用卡账单地址的邮编。

美国的邮编仅包含数字,最多10位(ZIP+4FTW)。在加拿大,邮编包含一个字母和一个空格。我们旅输入框中仅可最多输入10个字符。

为了同时满足美国和加拿大的客户,输入框标签文字为“ZIP/Postal code”。



9. 该表单是否安全

当用户第一次粗略的扫视了一眼信用卡表单,他们通常会问自己“这个表单安全吗?我如何信任这个网站?他们是不是在骗取我的信用卡信息?”其实,通过设计来强化安全感有很多种实现方式。我们考虑过的选项如下所示:

* 在表单的头部,紧挨着“Pay Invoice”,放置一个锁的图标,但是这种方式让人感觉很无力,并且和表单的输入并无关联;

* 在卡号输入框中放置一个锁的图标,但是问题是“仅仅这个输入是安全的,还是整个表单是安全的呢?”

* 在“支付”按钮上展示文字“Pay
$1.00 securely”,但是当金额过大时,文字会被挤出按钮。

* 在表单下面添加安全徽章,但是我们觉得这些徽章会影响我们简单干净的审美,进而影响整个页面。此外,用户并不能区别这两个徽章,所以我们放弃了这个想法。

鉴于已有的在线支付模型,我们觉得锁的图标足够了。最终的设计方案时将这个图标放置在“Pay”按钮中。图标的这个位置很关键,因为它在关键点上强化了安全:当你点击Pay按钮时。



10. 当我点击支付按钮时发生了什么?

一旦用户准备好支付,他们点击支付按钮。此时按钮的状态变更为pending/loading,显示的文字为“Sending...”。我们提交了一个服务器请求,假设没有错误出现,我们则会返回一个成功信息。



11. 处理卡片错误

在网页表单设计中,其中一个比较重要,但通常不招人喜欢的部分便是错误处理。是的,有些时候是非常单调乏味的。有无穷无尽的方式来设计错误。但只要处理得当,错误处理便会变为一个简洁的交互。

在互联网软件中,有两种错误验证:1)客户端;2)服务器端。

客户端校验

客户端的错误会在请求发至服务前捕获。引起这些错误的典型原因是数据格式错误或者丢失数据。

为了增添点乐趣,你可以用不同的方式来验证客户端输入。幸运的是,Luke Wroblewski写过一篇非常棒的文章解释了各种情况的校验方法——“After,
While, and Before and While
”。基于Luke的研究和直觉,我们选择了After方式。After方法将会在用户当前输入结束,移到下一项输入时展示错误信息。换句话说,这是一种模糊验证。另外值得注意的是,当遇到输入错误时,用户不会被“锁定“到当前输入框。他们可以通过键盘上的tab键直接移动到下一项输入,之后再处理出现的任何错误。

下面是我们客户端错误的校验标准:

* 卡片签名和邮编除外的所有输入,仅包含数字(即没有字母或者特殊符号)

* 支付金额最小为$1

* 卡号:长度必须是16位(对美国运通卡则是15位),且必须以已知的4个卡片代码之一开头

* 有效期:月份长度为2个数字,年份长度为2个数字(即,MMYY)。月份仅可为1-12,年份必须小于当前年份(如15年)

* 安全码:如果是美国运通卡,则长度必须为4位,其他类型的卡片长度为3位

* 邮编:长度至少为5个字符,最多位10个字符

为了直观的展示错误,我们使用红色的背景和红色的边框来展示输入框,但是我们不会将输入的文本置为红色。至于错误提示,我们将其以红色文本展示在出现错误的输入框下面。



服务器端校验

服务器端的校验通畅在表单发送至服务器后进行捕获。它们可以针对系统的,或者是针对校验对象的。在我们的表单中,我们不得不处理三种类型的服务器端错误:

1. 无效数据,包括了卡号、有效期、安全码和邮编(如过期的卡片、无效的邮编)

2. 系统错误,在服务器出现问题时校验(如超时,断开连接等)

3. 卡片错误,在使用卡片进行支付但是被拒绝或者其他原因时进行校验(实际上可能有上百个原因)

为了处理系统错误,我们将当前输入框占据,这样用户可以重试支付。当卡片被拒绝时(即卡片错误),通常这里有可能存在诈骗等,所以我们清空用户的当前输入。



12. 为不同的屏幕设计

从一开始,我们便希望能设计一个适配不同屏幕尺寸(即响应式的)和不同屏幕(即iPhone中的Wave应用)的表单。通过使用一个表单对象,我们只需要在一个地方修改表单。我们不需要操作多段代码。

在iPhone应用Wave中,Invoice功能初始化为一个原始的信用卡表单,该表单基于单行输入设计模式。输入框虽然满足功能,但是有轻微的bug。重要的是,我们察觉到这样进行输入框展示标签,用户体验十分差,如果输入出现错误,用户不得不在输出之间进行导航。

现在,通过使用HTML iFrame,我们将全新的信用卡表单注入到应用中。这样一来,使用应用填写信用卡信息和在PC桌面中使用浏览器填写信用卡信息用户体验是一致的。在将来,我们还会在在应用内不使用CSS来控制表单元素,以使得这些样式和应用中的其他表单保持一致。



好了,以上就是信用卡表单的详解。我们回顾了从手稿、表单输入设计、错误处理和移动端展现几乎所有的内容。我们的信用卡表单一定会随着时间的推移不断的发展,所以保持更新。支付空间并不是完美的,但是通过学习和理解移动支付背后的用户交互绝对是有趣的。

现在,是时候展示一发DEMO了!

最后,十分感谢Nick Presta,他用React讲整个表单进行了实现,此外还要感谢其他Wave中支付相关的同事。

--------------------------------------

相信爱阅读的您,最近已经注意到了我们。

我们将陆续推出一系列关于业务设计和技术架构方面的好内容。

也欢迎您提出意见、推荐文章,为让别人更了解这个世界,作出自己的贡献。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: