APP案例分析-摩拜单车app
第二次作业-App案例分析
本次案例分析选用的是 摩拜单车IOS５.７.５版本
测试环境为 IPhone 6s (IOS11.0.1，含有3DTOUCH功能).本次案例分析仅针对APP 而言，并不涉及到整个MOBike共享单车的其他服务体系。
第一部分 调研， 评测
1.1上手
上手体验：简单明了，打开APP 的第一眼就能够配合MObike的其他其他服务使用起来，用户的使用学习成本极低。界面UI设计以红色为主，符合现在主流的简约化设计风格。总体UI还是没得挑剔的。
1.2.找BUG
使用过程中发现了如下两个问题：
1.2.1 3DTouch快捷操作选择扫一扫偶然出现闪退现象，直接上动图。
预期效果：能够正常打开扫一扫的操作界面。直接扫描单车上的二维码
BUG现象：
1.2.2 3DTouch快捷操作选择扫一扫进入操作界面后，并没有直接打开二维码扫描界面。而是进入了APP的主界面
预期效果：能够正常打开扫一扫的操作界面。直接扫描单车上的二维码
BUG现象：
1.3其他用户体验
用户背景：非计算机专业本科在校生。
用户需求：使用APP作为工具打开MOBike。
使用机型：IOS10，（没有3DTouch功能）。
使用体验：上手容易，可以支持多种方式支付押金。除了自行车的其他故障，APP上来说基本没有什么弊端。还能够记录每一次的行踪，这个是其他同类服务可能不具备的。
用户改进建议：能够记录每一次的行踪，但是却不能手动删除，这可真是一个麻烦的问题。emmmm,这可能会对某些不想让手机记录下行动轨迹的用户放弃选择MOBike。
关于UI设计还是比较符合大众审美的，说不上非常炫酷华丽的UI设计，但是起码让人用起来不别扭
结论：一般，对比同类没有什么很突出的表现。
第二部分 分析
2.1功能分析
①：【地图寻车->】【预约车辆->】扫码开锁->结束付款
②：查看历史行踪
③：应用内的商城服务
④：自行车报修
注：【】为可选项
2.2产品对比
| 品牌 | MOBike | OFO | HALLO BIKE |
| 界面UI | 三款软件中个人人为最优界面 ９分 | 中规中矩 ８分 | 中规中矩 ８分 |
| 扫码速度 | 对于二维码图形的识别速度，同类软件中速度最慢的一个 ７分 | 不支持快捷开锁，还要手动输入密码是比较麻烦的 ５分 | 识别速度快，是三个软件中开锁最方便的一个 ９分 |
| 其他附加功能 | 附加功能繁多，总是会有点绕，但好在菜单层次分明，容易使用 ７分 | 无法取消你所不关心的通知消息，总是有个小红点很烦人 ５分 | 基本无太多附加功能，是个人最喜欢的一个 ７分 |
第三部分 建议和规划
1 如果你是项目经理，如何提高从而在竞争中胜出？
①优化开锁速度，从二维码的内容识别开始。
②简化商城内容，内容越多新客户使用的几率就更小了，因为入手难度高，学习成本高
③采用奖惩制度，鼓励用户报修，对问题分等级处理，简单的报修问题可以先不对自行车进行锁定处理（设置成无法开锁），对于会影响骑行的问题要将自行车锁定起来。以免影响了用户的体验感。
2 市面上同款的APP 众多，厦门地区主要有 OFO 、 Hallo Bike 、
3 我觉得新增一个导航是不错的选择
N：
目前的APP没有导航的功能，但实际上已经是使用了高德地图的地图接口了。在用户不知道路的前提下可以通过APP一站式服务，不需要再手动切换到其他导航软件进行导航。这样可以优化停车点的服务
A：
从新开发一个导航系统对于这种创业公司是远不可能的，我们只能够通过与高德地图携手。通过各种商业手段去获取到高德的地图导航接口，并嵌入到系统中。另外应用本身就有记录行踪，可以通过记录下的行踪数据对常用的路线进行优化反馈，让骑行路线从用户中来到用户中去，还可以填补高德地图不存在的路线。
B：
解决用户取到车以后的可能存在的不知道往哪走的问题。另外采用商业合作去获取别人现成的导航功能是可行性比较高的方案。
C:
本身APP存在的初衷是作为开锁，租车的管理工具。很大一部分还是应该在整个服务体系中去优化产品。作为APP而言应该追求高效，功能性，实用性强。少一些花里胡哨的东西，多一个实际我们很可能用到的功能，竞争力自然就大了。就比如我16G的手机，我装不下那么多软件，那我一个MOBike既可以租车，又可以给我简单的导航，那我不就可以少用导航的APP；
D：
谁用谁知道，用过一次以后需要导航的用户自然会选择该类产品
4.如果让我来领导技术团队：
MOBike的整个服务侧重点应该是在其他的运营服务上，如果我是负责技术的，如同上面的优化APP是一方面，另外我会注重小程序等这一方面的开发，或者是嵌入到支付宝，QQ等其他的常用平台。
5.
这个可是一个凭空意淫的大难题。首先，美工和后端的开发是可以分离的，而且要考虑多端支持到底支持多少，比如我们要同时兼容IOS和安卓两大阵营，还要同时兼容小程序和手机端大小的web页面。
后端的话应该是通用的。但是后端的难点是建立在我要用谁的地图引擎，我的后端要搭建一个支持多大规模的服务器，这个也是很难拍脑袋就想出来了。
五个人的团队应该是不足以支持这么多方向的开发的，但是如果勉强要这么做，我会选择两个人做服务端提供服务，（后端后期可能工作就比较少了，那他不妨最后以一个小白的身份去做测试）。
一个写IOS，一个写安卓。（实际上两个人应该要互相共享整个APP的操作逻辑）。然后一个人负责测试（可能一个人也是不够的，但是总要有人主要负责测试一整块）。
时间轴方面
①：前一周，每个人都需要参与到设计这个app中来，确定要初期的基调。服务端的人开始考虑各种需要大的技术问题，如地图怎么来，如何结合硬件去开锁。前端的人开始进行原型设计。（IOS和安卓可以公用一份设计原型的，暂且先不考虑小程序等复杂的）
②：２－４周。服务端开始搭建服务器平台。前端开始做UI的实现，期间要对方向进行微调，比如某方面的功能受制于某项法律规定，或者其他的资源无法开发等。
③：５－９周 主要代码的编写
④：９－１２对原型进行内测修改。服务端可以考虑优化，而美工由于功能的叠加可能需要对界面进行简单的重构。
⑤：１３－１４ 两周时间做第一次的测试，此时的主要内容在测试方面。
⑥：１４－１５ 对测试的问题进行修改
⑦：１６－１７ 进行回归测试
注：测试应该是贯穿整个开发过程的，故在这里就不一一例举出来了
