标签：有用 概率 不容易 一段 事件 设计 查询 需求 判断
做产品，要经常使用自家的产品，要站在用户的角度思考，是不是理所当然？看似简单，要做好，并不容易。
作为骑车上班族的一员，自认为算是滴滴青桔的典型客户，对于滴滴青桔“车损”的流程，有槽要吐。
先看一下，滴滴青桔，车损流程：
（1）用户：扫码开锁（线上操作）；
（2）用户：尝试骑行，发现车损（线下）；
（3）用户：关锁，准备换一辆（线下）；
别扭的地方来了：
（4）系统提醒：扣费；
画外音：不爽，车还没骑，就扣费了。
捣鼓了一下，不支付，还不能扫下一辆：
（5）用户：被迫支付（线上操作）；
画外音：不爽。罢了罢了，确实开锁关锁了，一块五，也不贵，当吃个闷亏。
做个好事，帮平台报修吧：
（6）用户：车辆报修（线上操作）；
画外音：希望下一位朋友，不要再受这个气。
按钮是灰色的，好像不能提交，看到提示“请输入您想反馈的问题”：
（7）用户：被迫输入一段文字（线上操作）；
画外音：额，是为了阻止用户报修，减少工单，才这么设计的吗？
还是不能提交，看到提示“请拍摄损坏位置，便于我们更快审核”：
（8）用户：被迫拍摄一张照片（线上操作）；
画外音：C，这是平台审核的需求，不是用户的需求，为啥要把麻烦转嫁到用户身上。
（9）用户：确认提交；
画外音：提交后，好像找不到报修进度查询的地儿，是没有这个产品功能，还是我没找到？
接下来，看下美团摩拜的“车损”流程：
（1）用户：扫码开锁（线上操作）；
（2）用户：尝试骑行，发现车损（线下）；
（3）用户：关锁，准备换一辆（线下）；
惊艳的地方来了：
（4）系统提醒：是不是车损呀？本次行程免单；
不扣费，也不用帮平台报修。
是不是酷爆了？
画外音：系统上判断“开锁关锁时间差”，“车辆移动距离”都很容易。
如果你是用户，未来会骑滴滴青桔，还是美团摩拜？
车骑得比较多，各种小概率事件，都碰上了。
建议滴滴的产品同学，多骑骑车，多体验自己的产品；多站在用户的角度思考，而不是只站在平台的角度思考。
画外音：把槽吐出来，是还抱有期望。
一个用户，一点心声，轻喷。
标签：有用 概率 不容易 一段 事件 设计 查询 需求 判断
原文地址：https://blog.51cto.com/jyjstack/2547661
