问题产生：
范范某日使用摩拜单车时发现取消预约功能文本存在歧义。
该功能目的：
对用户取消预约车的操作进行二次确认，确保用户操作是基于自身操作意愿的，避免了用户误操作而取消预约的情况发生。
可能的用户：想要取消预约单车的用户。
1、预约了车，但是改变了出行计划（步行或者乘坐公交地铁等其他交通工具）的用户。
2、预约了车，在路上看到其他摩拜单车，想要就近骑行的用户。
3、预约时间到，无法赶到预约车旁（可能是找不到）的用户，可能会选择重新预约。
4、到达指定地点，发现没有车/车坏了的用户。
5、误操作预约了单车的用户。
该功能的用户期望：
1、想要预约车的用户，不会使用该功能。
2、熟悉此功能的用户，已踩过坑，并不会在意这个小瑕疵功能的存在。
3、想取消预约车的新用户，想简单便捷的取消预约，不会期望此功能占据太多的思考选择时间，用户时间越赶，对此功能的敏感度会越高。
流程：
现象及原因：
“取消”按钮字样存在歧义，忽视提示的用户可能会理解为“取消”是取消订单，多次操作尝试之后才能取消订单。
影响面：
取消预约功能在庞大的用户群里面出现的频率可能不算太低，覆盖的人数应该也不会太少。
但此功能的影响面较小，影响的都是初次使用取消预约车功能的用户，体验较差。用户在二次使用此功能时，会有意识的选择相应的按钮。
解决方案：
1、解决方案一：
将按钮文本“确定”改为“是”
将按钮文本“取消”改为“否”
2、解决方案二：
修改原有按钮的背景色，使得两个功能区分开来。
3、解决方案三：
修改提示框样式，只为用户提供一个选择，用户可以选择×或点击提示框外内容来放弃取消预约。
「注」这样的界面设计可能更倾向于引导用户点击确定，而不是引导用户进行选择。
4、解决方案四：
取消提示框提示，采用手势操作来取消预约。
方案优先级及合理性：
针对上面4个方案，选择方案一为最右方案。
理由：方案一提示框采用iOS自带提示框，仅改变按钮本身文本，开发难度低；不改变已有用户的使用习惯。
方案二缺点：开发难度较大，由颜色来引导用户操作，也可能使不想取消误触发此功能的用户取消预约。与功能的目的相违背。
方案三缺点：开发难度较大，需要构建一个新的UI控件。
方案四缺点：改变原有用户的操作习惯，已经习惯了原有功能的用户反而会受到影响。开发难度太高，迭代成本太大。
考核指标：
1、统计用户在此功能上的平均停留时间（Duration），预计迭代后，平均停留时间变短。
2、统计迭代前后相同周期内，取消预约成功率的比例（迭代前，用户要成功取消，可能会多操作1~2次，导致成功率偏低）。预计迭代后，成功率升高。
