「摩拜单车」取消预约功能优化

问题产生：

范范某日使用摩拜单车时发现取消预约功能文本存在歧义。

---

该功能目的：

对用户取消预约车的操作进行二次确认，确保用户操作是基于自身操作意愿的，避免了用户误操作而取消预约的情况发生。

可能的用户：想要取消预约单车的用户。

1、预约了车，但是改变了出行计划（步行或者乘坐公交地铁等其他交通工具）的用户。

2、预约了车，在路上看到其他摩拜单车，想要就近骑行的用户。

3、预约时间到，无法赶到预约车旁（可能是找不到）的用户，可能会选择重新预约。

4、到达指定地点，发现没有车/车坏了的用户。

5、误操作预约了单车的用户。

该功能的用户期望：

1、想要预约车的用户，不会使用该功能。

2、熟悉此功能的用户，已踩过坑，并不会在意这个小瑕疵功能的存在。

3、想取消预约车的新用户，想简单便捷的取消预约，不会期望此功能占据太多的思考选择时间，用户时间越赶，对此功能的敏感度会越高。

流程：

现象及原因：

“取消”按钮字样存在歧义，忽视提示的用户可能会理解为“取消”是取消订单，多次操作尝试之后才能取消订单。

影响面：

取消预约功能在庞大的用户群里面出现的频率可能不算太低，覆盖的人数应该也不会太少。

但此功能的影响面较小，影响的都是初次使用取消预约车功能的用户，体验较差。用户在二次使用此功能时，会有意识的选择相应的按钮。

解决方案：

1、解决方案一：

将按钮文本“确定”改为“是”

将按钮文本“取消”改为“否”

解决方案一

2、解决方案二：

修改原有按钮的背景色，使得两个功能区分开来。

解决方案二（画的有点丑）

3、解决方案三：

修改提示框样式，只为用户提供一个选择，用户可以选择×或点击提示框外内容来放弃取消预约。

「注」这样的界面设计可能更倾向于引导用户点击确定，而不是引导用户进行选择。

解决方案三

4、解决方案四：

取消提示框提示，采用手势操作来取消预约。

解决方案四

方案优先级及合理性：

针对上面4个方案，选择方案一为最右方案。

理由：方案一提示框采用iOS自带提示框，仅改变按钮本身文本，开发难度低；不改变已有用户的使用习惯。

方案二缺点：开发难度较大，由颜色来引导用户操作，也可能使不想取消误触发此功能的用户取消预约。与功能的目的相违背。

方案三缺点：开发难度较大，需要构建一个新的UI控件。

方案四缺点：改变原有用户的操作习惯，已经习惯了原有功能的用户反而会受到影响。开发难度太高，迭代成本太大。

考核指标：

1、统计用户在此功能上的平均停留时间（Duration），预计迭代后，平均停留时间变短。

2、统计迭代前后相同周期内，取消预约成功率的比例（迭代前，用户要成功取消，可能会多操作1~2次，导致成功率偏低）。预计迭代后，成功率升高。