（3）架构平级切换：在路由推荐认证方式中，应支持用户自主切换至其它认证方式，尊重用户的选择

考虑到用户习惯的原因，若后台智能推荐给用户的认证方式并非用户想要使用的方式，应支持用户平级切换到其它认证方式中去。在设计中应注意其它认证方式与当前智能路由方式在信息架构上的平级关系。因为虽然通过智能路由为客户推荐支付方式，但是并不代表不尊重用户，依然把最终的决定权交给用户。

例如工行e支付在转账汇款场景支持多种认证方式，在智能路由推荐规则下，推荐了U盾认证方式，若用户此时不想采用U盾认证，可直接选择其它认证方式进行验证。

如招商银行，在某个话费充值场景，推荐客户使用指纹认证方式开通并支付，若用户不想采用这个方式，可切换至支付密码方式进行支付操作。同时可以在后台系统里记录下用户的选择，在下次同类型的支付场景中便可为用户推荐相同的认证方式。

如在当下疫情防护期间，用户在日常出行中必然是带着口罩，而在这种特殊时期的支付场景中用户显然是不方便进行刷脸认证的，但是在日常消费支付中，仍然有不少支付产品依然给用户推荐刷脸认证方式，那么用户则需要每次手动将刷脸认证切换为密码认证，增加了非必要的操作动作。这不仅在用户习惯上没有去尊重用户，也不符合疫情期间所推行防护理念。

如果可以结合用户的定位地点（如在室外）以及用户在室外进行的支付操作行为（如切换成密码操作），那么下次再为用户进行推荐认证方式时，则应要为用户推荐上次所选择的认证方式，而不再是一昧推荐刷脸认证方式。

（4）流程模块通用：应做好认证流程中的通用模块设计且保证流程一致从而提高操作体验的一致性和流畅性

虽然不同认证方式的任务流程各不相同，但为了保证操作体验的一致性，应尽量提炼流程中的通用模块或调整某些认证方式的任务流程以求最终达成一致的任务路径模式，最终使得用户在使用各种认证方式时任务流程是一致的，降低学习成本从而提高操作效率。

在认证流程中，关键认证通常包含“准入密钥”获取和“重要信息”验证两个步骤。二者是属于递进关系，必须先获得“准入密钥”，才可以进行“重要信息”的验证。

如短信验证码认证流程中，“准入密钥”是有效手机号（当前正在使用的），“重要信息”则是发送到手机号上的短信验证码。如在密码器认证流程中，用户需要先持有“准入密钥”（密码器），才可以进一步将密码器上的动态码（重要信息）输入到支付界面中去进行验证。如在支付密码认证方式中，“准入密钥”实际上是后台自动获取到当前支付所使用的设备（如手机）是否为原先开通支付密码时所绑定的设备，只有通过获取到设备号（IMEI）即“准入密钥”，才可以进行6位支付密码的验证步骤。

因此对于体验设计来说，应做好“准入密钥”获取和“重要信息”验证的衔接环节，让两个步骤不中断从而保证流畅的认证体验。为了能提高操作效率，最好是能将两个步骤无缝链接。

例如短信认证方式中，通过向用户前期开通时预留的手机号发短信，无需用户手动输入手机号并点击获取。例如支付密码认证方式中，后台将自动发起对当前支付设备进行设备信息检索，若获取到所绑定的设备信息，则直接进入支付密码验证步骤。

在两个步骤的衔接当中，可通过文案提示、可视化形式等多种形式进行有效引导，尽可能保证流程不中断。如在短信验证码认证中，可提示用户是向哪个手机号发送了短信，以便用于去查询。如U盾认证需要先将U盾物理介质插入手机中，可通过可视化方式进行提示，有效进行了“准入密钥”和“重要信息”的衔接。