1、背景和目标

1.1、背景说明

目标市场上几乎所有产品都会涉及金钱交易，毕竟公司开发一个产品还是为了赚钱。

如社交产品发红包，社区产品打赏，教育产品知识付费，电商产品购物支付，游戏产品充值支付，互金理财产品、借贷产品等更是围绕资金交易，还有各种产品的各种付费会员，方方面面离不开资金交易。

只针对支付功能，对资金交易没有强需求的产品，如社区产品打赏、教育产品知识付费，大多会接入微信支付与支付宝，不会开发太多附加功能；

而涉及到充值、提现的产品，对资金交易有强场景和强需求，如互金理财、借贷产品等，简单的支付宝和微信支付没有办法满足全部场景，而且涉及资金交易量大，用户也不会把所有钱都放到微信和支付宝中，这时候，就需要开发绑卡功能，以满足用户大资金交易的需求。当然对于充值（支付），也是可以直接走微信和支付宝的，这种方式对于大多人来说，也是十分方便快捷的，但是就金融产品的属性来说，银行卡还是必须的，身份验证角度也好，风险与安全角度也好，银行卡的绑定和管理都是必不可少的功能。

1.2、目标

• 完成绑卡逻辑、交互、细节梳理

• 对常见的绑卡方式做示例

2、绑卡状态

image

针对前两种状态，需要引导用户进行绑卡，针对第三种已绑卡状态，直接展示银行卡列表即可。

3、实例展示

针对实名和绑卡可分开进行的场景，有两种情况：

• 明确引导添加银行卡的场景：该种情况，绑卡的流程交互与实名绑卡需一步完成的一致即可

• 非引导添加银行卡的场景：该种情况，可先引导用户完成实名，在需要用户绑卡的时候再进行引导绑卡

下面主要针对引导添加银行卡的场景展示绑卡流程与交互，其中以京东金融、微信、支付宝、小米金融、人人贷、唯品金融做简单说明。

3.1、京东金融

image

分析：

• 该展示为已实名未绑卡的状态

• 展示采用拟实物的卡片样式，并将切换光标的动作融合为下一步的button，并将button下移，使用户编辑时所有操作都集中在键盘部分，避免来回跳跃

• 卡类型自动识别，若未识别出来，提供手动选择，但因为提示不明显，很容易被忽略而无法继续进行

• 由于卡片有背景色，所以很吸引眼球，导致在刚进入的一段时间内无法注意到键盘上方的编辑框

• 编辑内容前端校验通过即可进入下一步，直到手机号等全部编辑完成提交才进入后台验证，验证通过则绑卡成功，验证不通过则在当前页（手机号）提示错误信息

3.2、微信和支付宝

微信：

image

支付宝

image

分析：

• 微信和支付宝的绑卡基本是一样的，所以放在一起讨论

• 因为是绑卡引导，所以两者都在第一个页面引导用户编辑银行卡号，编辑完成再补充其他需要的相关信息

• 全部编辑完成提交后台验证，验证未通过微信会直接回到银行卡编辑页，支付宝留在其他相关信息编辑页；对于容易编辑错误的用户并不友好，但显然微信和支付宝并不对此种情况做更多的处理，编辑错误大概是经过了验证，不因20%的用户去影响80%的用户

• 样式采用的是最简单最传统的列表式，对用户习惯没有任何影响

3.3、小米金融

image

分析：

• 同样，小米金融也使用同样的方式，进入直接引导用户编辑银行卡信息，然后在下一个页面判断用户是否已实名，若已实名，则只需编辑手机号码即可

3.4、人人贷

image

分析：

• 人人贷为三要素鉴权，内容相对较少，所以在一个页面内展示，也不会有更多的心里负担。

3.5、唯品金融

image

分析：

• 唯品金融采用最传统的方式，若用户未实名认证，则直接引导用户编辑身份信息，编辑完成满足前端检验规则，则直接进入绑卡页，编辑完银行卡信息后满足前端校验规则“立即绑卡”button变为可点状态

• 点击“立即绑卡”button后台校验信息是否正确，若正确则绑卡成功，不正确则在当前页提示错误信息

• 该种提示方式如果在身份证号编辑错误的情况下，不容易定位问题，且基本全部信息都需要重新编辑

4、细节与交互

4.1、整体流程

• 进入页面，光标自动对焦到第一个可编辑且需要编辑的编辑框

• 用户点击编辑框后调用相应键盘

• 编辑框编辑信息后，在编辑框后面出现“x”，点击则清空编辑框

• 一项编辑完成后对该项进行必要的前端校验

• 前端全部校验通过，引导用户提交（button变为可点状态）后台

• 后台校验后实时反馈校验结果

• 根据校验结果进行相应提示和交互

4.2、输入键盘

点击编辑框后调起键盘，不同的编辑框需要不同的键盘，键盘可以用系统的，也可以自开发，调起相对应的键盘类型及相应键说明如下：

4.3、编辑框

当未编辑内容时，编辑框有相应的编辑提示，编辑后编辑框后出现删除的“x”，点击删除的“x”直接清空编辑框，编辑框为空提示说明如下：

• 为空提示注意：手机号要说明是银行预留手机号，因为现在一人多个手机号十分常见，注册手机号不一定是银行预留手机号，所以对此要进行具体说明

• 银行卡类型一般会在编辑银行卡号识别出开户行时自动展示，若编辑到相应位数依然不能识别，则需要给用户展示编辑框，引导用户自己选择

• 有的编辑框在特定情境下为了减少用户编辑工作量，会自动带入一些信息，如手机号，在该场景下，可能需要给用户展示一种安全的状态，做成加密的样式，此时编辑框交互：

• 如果该编辑框为加密状态，则点击选中该编辑框且点击键盘删除则清空编辑框

• 如果该编辑框不为加密状态，则点击选中该编辑框且点击键盘删除则只删除最近的一个字符

4.4、前端校验规则

姓名和验证码不做校验，身份证、银行卡、手机号做位数限制和校验，下表举例以实时提示前端校验结果为例（错误则进行提示，正确则可进行下一步）：

4.5、前端校验错误信息提示

前端校验方式有多种：

• 编辑框只要不为空即可点击button：点击button后进行前端校验并提示，该种方法对于开发和逻辑都是极为简单的，但错误提示不是实时的，若前端校验有误但修改正确并提交后台后，如果后台不通过会反复提示错误；但如果用户输错率较低，也可以简单处理

• 编辑框只要编辑完成即进行前端校验并提示，全部校验通过button才可点：这种方式对用户的反馈比较及时，但开发逻辑会增加

• 无论哪一种方式，适合自己用户的才是最好的

下面仅针对实时提示错误信息进行说明：

• 校验节点

• 编辑中判断

• 失去焦点判断

• （判断说明中提示错误信息的情况均为不为空的情况，编辑框为空不提示错误信息）

• 当前编辑框编辑完成后，无论对错，只要进行了重新编辑，即不提示错误信息

• 当前编辑框只要不合规则，无论有没有错误提示，button都为不可点状态

• 错误提示文案：

• 若只有一个编辑框有误，则提示：{编辑框名称}格式有误，如身份证格式有误

• 若多个编辑框同时有误，则提示最近编辑的编辑框错误信息

4.6、后端校验错误信息提示

用户全部编辑且前端校验全部通过后提交后台验证：

• 验证通过则绑卡成功

• 验证不通过则提示错误信息

4.7、绑卡结果

此处只针对绑卡结果实时返回的情况进行分析，此种情况下，绑卡结果有以下三种：

提示方式针对需要特别让用户注意的做成toast会太弱，所以对四要素编辑有误的做成页面提示，其他只需了解，所以做成toast提示。

到此，基本所有细节以赘述完毕，希望对你的绑卡设计有所帮助。