产品分析报告：云闪付的乘车码功能（我的蚂蚁农场）

本文是关于云闪付乘车码功能的产品分析，主要的思路是关注核心、拓展场景、优化体验。

01 环境说明

02 分析方向

2.1 乘车码的使用

云闪付APP是一种非现金收付款移动交易结算工具，通过收付款、享优惠、卡管理三大核心功能，为持卡人提供各项优惠的金融、生活及购物服务，安全保障用户合法权益。

其中推出的乘车码，可以让用户在不用携带公交卡、零钱的情况下乘坐公共交通，还能特享随机立减的优惠。

2.2 乘车码界面的UI

云闪付APP整体采用红白相间的UI风格，符合当代中国大众的审美，与百元大钞相近的配色给用户以喜庆红火的暗示。

乘车码界面的UI简化为类似“出票机”的样式，button设置大方清晰，用户可以很快根据自己的需要进行相应的操作。

03 功能体验

3.1 产品结构图

3.1.1 部分一级页面截图

产品的四个一级页面分别为“首页”、“发现”、“财富”和“我的”，这是目前市面上的C端产品比较常用的界面分类，就目前来看也是比较合理的。

首页用于放置用户较为常用、或是应用想让用户优先点击的功能；发现则便于用户查看并使用相关的优惠；财富界面直接管理用户的存储卡、信用卡，并对开支进行一个简要的统计；我的则是用于放置与用户相关的包括个人信息、订单、设置等常用功能。

分类思路比较清晰，但UI界面的某些设置还有待优化。

3.1.2 APP产品结构图

通过上图可以看出，云闪付APP的产品框架相对趋近复杂。各项功能也比较完善，具体的功能分布是否合理，持续优化的空间在哪，还有待笔者详细体验才能再作判断。

3.2 乘车码核心使用流程

上图是乘车码功能的核心使用场景流程图。用户在界面里操作调出二维码，让公交车的扫码器扫描，完成一次乘车支付。

该也行流程涉及以下几个用户使用路径：

用户点击调出乘车码界面；
用户将二维码置于扫描口扫码；
用户进行相关查询；
用户进行相关设置。

3.3 功能体验分析

3.3.1 调出界面

描述：

1）打开首页，用户在副功能区一眼就能看到排列第一的乘车码，点击便能进入乘车码界面，调出速度较快，完全没有卡顿。相比于支付宝和微信支付的调用流程来说，简化了不少，非常照顾用户体验。

出现这种差异最根本原因还是在于产品定位的不同，导致它们在功能的调出流程上各有差异，云闪付更像是把乘车码的功能内置进去，而其他两款应用做得更像是外置的一个插件。

2）同时在乘车码的图标下也写明了随机立减，实际使用过程中，每次都能达到40%到60%，非常能吸引用户点击享受优惠。

可以看出云闪付对于自身目前所处的阶段是定义为前期推广阶段，需要通过烧钱补贴来争取新用户。

3）在乘车码界面，点击二维码区域便能刷新乘车码，根据测试，在断网的情况下也能调出乘车二维码，体验十分良好。

在讲究用户体验的当下，这样的功能设置已经成为标配，在网络异常的情况下允许用户先享后付，是非常人性化的处理。

建议：

1）考虑实现“多码合一，一码通用”。用户在公交车或地铁上扫码付费，本质上就是花钱享受一次出行服务，和在商家那出示二维码扫描没有任何区别。

但在使用时，却需要用户先想一下对方是商家还是公共交通，该向对方出示哪款二维码，显然这对一些中老年用户是不友好的，而且图标和文字较小，他们使用时也会比较吃力。

另外这种“多码合一，一码通用”的做法将能记录用户所有的消费记录，有利于形成一整套交易结算的生态体系闭环。这就像一个大学生既可以拿着校园卡去食堂打饭，也可以去图书馆看书，还可以扫寝室的门禁，在这些场景下TA只需要拿出卡，不用做其他思考。

2）考虑到随机立减的优惠每人每日只有两次，那么可以在右上角的空白位置显示“您今日可享2次随机立减”，完成立减扣费便减1，有效减少了后期运营人员需要再向用户解释的情况。

3）乘车码下方的提示语“先乘车后付款”初看时不知其意，等到发现断网的情况下也能调出乘车码时才稍微理解这句话的含义，但还不能确定是否可行。

建议修改成“网络未连接时也可使用”或是“断网时可先乘车，后付款”这样易于理解的提示语。

3.3.2 扫码

描述：

完成扫码后，整个界面没有发生变化，但会收到一条短信告知已完成扣费。这样处理可能是因为完成扣费后用户会收到其他各种渠道的通知，并且车上的扫码器也会语音提醒“扫码成功”，所以云闪付认为没有必要再做反馈页面。
经过测试，厦门的BRT（快速公交）无法使用。不同的公共交通工具隶属于不同的公司，在使用上也有不同的规则，乘车码最初设计时应该就是针对公交车，至于厦门的快速公交、甚至是地铁都需要设计不同的处理方案。

建议：

1）完成扫码后，App页面应弹出付款成功的界面，并告知付款多少。像支付宝的乘车码使用后，就会在界面上告知用户花了多少钱。

一个功能的使用，尤其是针对C端用户，最好是能有反馈页面，这不仅能给用户一个直观的使用感受，还能顺带在页面下的空白处植入其他广告，一举多得。

如果出现扫码器无法发声或是使用者听力有障碍的特殊情况，就有可能出现重复多扫的情况。因此建议添加该页面。

2）如果使用了随机立减，可以在UI上强调这一点，培养用户的使用黏性；如果是断网的情况下使用，则可以说明费用将在之后扣除，请确保卡里有足够的余额，否则无法享受，这便可以减少运营人员需要再向用户解释的情况。

3）打通各地其他的公共交通，支持在BRT、地铁（重庆叫轻轨）等场景的使用。不仅方便了用户，也能顺带释放掉一部分在购票机前排队的人流量。

而且这里如果能做到“多码合一，一码通用”，那必然会比微信和支付宝（二者目前是把乘车码和地铁卡分开处理）的更加好用。

3.3.3 查询

描述：

1）在乘车前，用户可以点击“支持线路”查询乘车码的功能在那些线路是可用的。这块区域应该是想向用户展示自己支持哪些公交线路，同时通过第二行的“公交”二字也可以表达出乘车码目前是不支持BRT和地铁使用的，只是这样处理过于简单。

2）用户也可点击“乘车记录”查询自己的使用情况。每一行记录左边的图标显示公共交通的类型，同时显示车辆线路、使用时间、金额及使用结果，点击之后能进入详情页面看到具体的付费情况及其他参数。

这个页面在设计时应该没有考虑太多，毕竟从常理上来讲，用户很少会去点击。

建议：

1）“支持线路”的页面设置太过简单，不利于用户查询。用户在乘车时只会关注自己要乘坐的那趟车是否可行。因此，最好在页面最上方设置一个搜索框，根据关键字查询，如输入98，就根据用户所在定位跳出经过的98路，981路，987路等。

更进一步地，还可以在搜索框下方设置分类tab，如厦门地区就可以设置公交车、BRT和地铁，这样不仅易于用户查看，而且在未搜索时，用户便能知道云闪付的乘车码，不像支付宝的乘车码还分为公交卡和地铁卡，是同时支持在公交车、BRT和地铁使用的，这能很好地培养用户忠诚度，一举多得。

2）“乘车记录”的设置比较简单。建议在使用过随机立减的记录强调优惠信息，刺激用户下一步接着使用云闪付的乘车码。

可以的话，支持用户按一定是时间段查询统计自己在公共出行上的费用，给用户一种持家感，也能让用户感觉到产品的用心。

3.3.4 设置

描述：

1）使用乘车码时，用户可以点击“切换城市”来切换所用的乘车码，如果初次使用便直接弹出开通页面。经过测试，在断网的情况下不能开通新城市的乘车码。每个城市都有各自的公交公司，在使用乘车码时需要再次进行确认。

2）点击右上角的更多，可以调出其他操作，包括”扣款顺序设置”、”在线客服”、”暂停使用”、”使用帮助”和”取消”。这有点类似早期苹果手机的界面设置，应该是考虑到这些按钮用户并不常用，所以多设置了一个步骤。

建议：

在应用内预设《乘车码申请须知》，如果用户刚好没网的情况在使用新的乘车码时，也能开通并使用。更进一步地，在初次使用该城市的乘车码可弹窗显示《乘车码申请须知》的内容，最下方是确认按钮，用户点击后便开通该城市的乘车码。
“扣款顺序设置”其实就是设置默认使用的银行卡，建议参考支付宝的付款码界面，直接在乘车码下方设置一个银行卡选择横条，用户点击便可按照自己的需求切换扣费的银行卡。
对”暂停使用”和”取消”两个按钮的点击情况作数据埋点，如果点击率低于百分之五，就可以考虑不设置这两个按钮；一般用户很少会暂停使用乘车码的功能，而取消的按钮在屏幕最下方，用户更容易直接点击空白处，关闭更多的下拉弹窗。
”暂停使用”和”使用帮助”可以分别放在“乘车记录”和“支持线路”按钮的旁边。这样处理便于用户直接点击操作。
这样以后，右上角的更多图标就可以更改成“在线客服”的图标，点击便进入客服界面。这样处理便于用户直接点击操作。

04 建议和总结