1 个回答
先看下两种设计有什么好处和坏处。
第一种点击支付方式直接支付
- 1. 支付效率更高，不需要二次确认，思考的时间较短
- 2. 减少用户在支付环节的流失率，一般来说，增加一步操作，就会增加用户的流失率
- 3. 大于一种支付方式的情况下，误触和选错的概率较高
第二种单独勾选支付方式，再点击确认
- 1. 增加用户的思考时间，支付效率较低
- 2. 增加用户在支付环节的流失率
- 3. 大于一种支付方式的情况下，误触和选错的概率较低
我们再看下具体的支付场景（只考虑移动端）
1. 支不支持直接调起支付 SDK：不管是App 和 其他应用（H5、小程序等），支付方式是不是都可以直接调起 SDK 。像微信和支付宝我们手机都会安装，也有相应的使用习惯，但涉及到银行卡或其他支付的时候，如果我们手机内没有这个应用，会跳转到 H5 页面，用来绑定银行卡。还有在微信和支付宝内不支持调起其他支付方式的 SDK，需要通过浏览器重新打开支付页面。
如果不支持直接调起支付 SDK 的情况下（非一种支付方式），不太适合做支付方式直接支付的设计，因为用户在选错或者换一种支付方式的情况下需要返回到上一个页面，这个使用成本要大于用户勾选支付方式并点击确认的成本。
2. 支付方式
- 一种支付方式
- 微信和支付宝两种支付方式
- 非微信和支付宝两种支付方式
- 多种支付方式
如果多种支付方式存在时，不太适合做支付方式直接支付的设计，因为用户误触和选错的概率较高，这个使用成本要大于用户勾选支付方式并点击确认的成本。
3. 调起支付的 SDK 未支付返回后是直接生成订单到其他页面还是原来的支付页面：生成订单的情况不太适合做支付方式直接支付的设计，因为这时候用户需要重新找到该订单支付，这个使用成本远远大于用户勾选支付方式并点击确认的成本。
4. 选择支付方式的页面是否只有支付方式的选项还是存在其他的信息选项（如地址选择、人员选择）：如果该页面还存在其他的信息选项不适合用支付方式直接支付的设计，因为其他信息的选择和确认与支付方式同样重要，而支付方式直接支付的设计将其他信息的确认步骤干掉了，使得用户购买流程不完整和增加用户相应使用成本。
总结：不同的设计方式对应着不同的用户使用成本。因为每一个应用的业务背景不同，需要考虑不同的用户使用成本，设计方式自然也不同。所以哪一种设计方式更好要考虑自身业务综合使用成本。