产品分析报告：云闪付的乘车码功能

　　本文是关于云闪付乘车码功能的产品分析，主要的思路是关注核心、拓展场景、优化体验。
　　01环境说明
　　02分析方向
　　2。1乘车码的使用
　　云闪付APP是一种非现金收付款移动交易结算工具，通过收付款、享优惠、卡管理三大核心功能，为持卡人提供各项优惠的金融、生活及购物服务，安全保障用户合法权益。
　　其中推出的乘车码，可以让用户在不用携带公交卡、零钱的情况下乘坐公共交通，还能特享随机立减的优惠。
　　2。2乘车码界面的UI
　　云闪付APP整体采用红白相间的UI风格，符合当代中国大众的审美，与百元大钞相近的配色给用户以喜庆红火的暗示。
　　乘车码界面的UI简化为类似“出票机”的样式，button设置大方清晰，用户可以很快根据自己的需要进行相应的操作。
　　03功能体验
　　3。1产品结构图
　　3。1。1部分一级页面截图
　　产品的四个一级页面分别为“首页”、“发现”、“财富”和“我的”，这是目前市面上的C端产品比较常用的界面分类，就目前来看也是比较合理的。
　　首页用于放置用户较为常用、或是应用想让用户优先点击的功能；发现则便于用户查看并使用相关的优惠；财富界面直接管理用户的存储卡、信用卡，并对开支进行一个简要的统计；我的则是用于放置与用户相关的包括个人信息、订单、设置等常用功能。
　　分类思路比较清晰，但UI界面的某些设置还有待优化。
　　3。1。2APP产品结构图
　　通过上图可以看出，云闪付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建议和总结
　　4。1建议
　　根据乘车码使用场景中遇到的问题，本文主要提出了以下建议：
　　（1）调出界面
　　考虑实现“多码合一，一码通用”；
　　在右上角的空白位置显示“您今日可享2次随机立减”，完成立减扣费便减1；
　　修改提示语“先乘车后付款”为“网络未连接时也可使用”或是“断网时可先乘车，后付款”这样易于理解的。
　　（2）扫码
　　完成扫码后，App页面应弹出付款成功的界面，并告知付款多少。
　　使用了随机立减，可以在UI上强调这一点；断网的情况下使用，则可以说明情况
　　（3）查询
　　“支持线路”的页面设置搜索框和分类tab，方便用户查询；
　　“乘车记录”强调优惠信息，支持查询统计自己在公共出行上的费用。
　　（4）设置
　　在应用内预设《乘车码申请须知》，如果可以，在初次使用该城市的乘车码可弹窗显示《乘车码申请须知》的内容，最下方提供确认按钮。
　　关于更多下拉弹窗中内置按钮的放置优化。
　　（5）其他可能的建议
　　1）与掌上公交等应用进行联动，在掌上公交内可以对应到云闪付的乘车码，或是云闪付可对应到掌上公交的路线查询功能，形成场景应用的连贯，减少用户麻烦。
　　这样用户在使用公共交通出行时，就不用思考要先去用掌上公交查线路，再去打开云闪付的乘车码。
　　2）拓展乘车码的无感应用。如在一些比较寒冷的区域，使用公交卡是比使用电子乘车码还要方便的，只要拔出卡，碰一下就可以把手伸回口袋里取暖。
　　云闪付可以考虑进行该功能的拓展，类似小米和华为都有在做的手机公交卡，只要提前设置好，打开App便能使用手机自带的NFC功能当作公交卡来刷，这也有效解决了用户公交卡容易忘带，容易丢的痛点。甚至于在确定乘坐地铁的出行方案时，可以进行提前支付。
　　4。2总结
　　云闪付作为非现金收付款移动交易结算工具，无疑是成功的。它利用产品自身的收付款、享优惠、卡管理等功能，结合其得天独厚的地位，完美地搭建起了交通、购物、营销、支付、信用等领域的交易结算服务。
　　其推出的功能（包括乘车码）不仅方便了用户，也通过各种补贴行为让用户享受到了实惠，在前有支付宝和微信支付，后有其他支付工具的环境下站稳脚跟。
　　而要想赢得支付工具的竞争战，思前想后，还是需要做到以下三点：
　　（1）扩大用户基础
　　除了通过各种补贴、信用卡免手续费、拉新奖励等吸引新用户之外，产品自身的体验也要持续优化。这意味着要让产品设计时基础功能要更符合大多数人群的使用习惯，而非基础功能也要兼顾满足其他人群的个性化需求。
　　（2）拓展接入场景
　　尽可能满于用户更多的支付需求，这需要与更多的商家对接，目前云闪付能支持使用的商家还是比较有限的；开拓出云闪付更多可能的支付场景，如景区旅游时的门票便可用云闪付临时购买，无须出票便能直接使用。
　　（3）重视用户运营
　　拉新的同时也要存活，如将签到的奖励多样化，将支付的使用次数积分化，以游戏化的场景吸引用户坚持使用。
　　如支付宝每次使用时会增加蚂蚁森林的能量，能量就可以用来种真的树；也能增加蚂蚁农场的鸡饲料，鸡产的蛋最终都用于公益事业。那可否将银联本来要做的公益事业与这些进行游戏化的连接和推广呢？
　　期待未来的云闪付能为用户带来更多的惊喜。