- 从一个日历的确认按钮引发的讨论和思考
飞猪的日历界面
booking的日历界面
从飞猪的日历界面看到，选择入住时间和退房时间后，界面自动跳转至上一操作页，而booking的日历界面的底部有个确认按钮，功能比飞猪的选择退房操作多了一步，都是操作完成后返回上一操作页。咋的一看好像很多余，是不是多余呢，因为在携程IBU酒店进行app5.1设计界面的时候碰巧遇到这个问题。开发也说在结果上看来好像很多余。
我自己作为一个界面设计人员，对于其后面说隐藏更深层的原因其实了解并不多，在和朋友的沟通和思考过程中，给出了自己的答案。
发现问题
我先前觉得可能这只是一个习惯性的用法。见图。
选择19号入住日期后，点击21号离店的效果跟上面的确定按钮确实没啥区别。
再三思考，回到场景分析，其实本意还是有所不同的，上面的选择退房日期跳转是对退房时间的操作确认，booking的选择退房时间后需要点击确认按钮是对整个界面操作的确认。 只是从体验上讲，点击确认按钮的同时也没有执行操作。
虽然飞猪点击退房时间的跳转和booking点击确认的结果一样，但是用户的需求和心理体验是不同的。
我们再进一步进行分析：
飞猪的查询页“入离日期”选择只有一个操作入口，但是booking是两个，即可以选择入住时间，也可以选择退房时间。
我们建立一个场景：用户选择入住时间，退房时间都会清空；飞猪是必须操作完入住时间才能操作退房时间的，而booking，如果用户选择退房时间，只要选择大于入住时间的日期就可选，从操作步骤上，飞猪用了两步：选择入住，选择退房。booking同样用了两步：选择退房，选择确认。
我们通过用户体验地图分析：飞猪的查询页入离时间只有一个入口，决定了只有一个路径：修改入离时间-选择入住时间-选择退房时间。booking的查询页入离时间两个入口，决定了有两个路径：修改入住时间-选择入住时间-选择退房时间-确定；修改退房时间-选择退房时间-确定；这个确定按钮就是对两个路径做同样指令的操作，同时，确定按钮还起到了取消按钮的作用，所以booking的日历界面没有取消或返回按钮，这就是它的意义，它是对这个日历修改行为的终止。
继续探索
我觉得估计是之前酒店预订的新用户在进行日期选择时，对这种选择两个日期的误操作率很高（失败），很多人会经常跳转回去不断调整，所以就在当前页面尽可能的让用户确认正确，即使输入有误也可以即时修正，因为一旦进入下一页，回退修改的成本会提高太多，得不偿失，所以之前因为是都有这个确认过程的。
后续之所以逐步取消，应该是现在这个操作形成了行业基准，大家都有基础认知，输入的成功率显著提升了，所以回退的很少了。自然而然就取消了确认这个过程。
两种操作的用户动机是不同的，期望不同。可能有些用户选择入离时间后，然后点击确认，完成整个修改操作，因为她犹豫不决自己预定酒店的时间。也有可能有些用户选择入离时间后，认为应该完成了整个操作，因为他很肯定自己预定酒店的时间。
不过回头看支付宝和微信的支付密码是否需要确认按钮的问题，其实也差不多，随着用户习惯的养成，没有确认按钮似乎也不影响整个体验过程。
