在移动产品设计过程中，要保证产品从进入规划->设计->前端开发->后台开发->UAT->到发布全部链路流程都有质量保证，任何一个环节产生问题，可能都会导致用户体验方面的很大的问题。
而有些小的BUG，甚至在有些人眼里都算不上是BUG的一些小的疏漏，可能都会造成产品用户体验方面的大问题。这就是“魔鬼存在于细节中”，不找到那个细节里的潜藏的魔鬼，产品始终就会被困扰，直到最终被失望的用户放弃。
而产品所有环节的参与者，可能从始至终都没有意识到问题的存在，甚或是搞错了方向，金融家查理芒格曾说过：“如果我知道我最终会死在哪儿，那我永远也不会去那个地方”，但产品参与者可能完全不知道“自己会死在哪个地方”，所以也就一次次地在同一个地方摔倒。
举个例子：
某款产品信息流列表页的体验一直被用户投诉不好用，从用户的反馈里也很难看出到底是哪里不好用，甚至引发了用户对整个产品的吐槽和不满，为此产品部门和用户体验部门联合对该产品进行了多次更新和迭代，但始终没有平息用户的抱怨的声音，为此产品参与者也感觉很迷惑，问题到底出在哪儿？
最后经过很长时间的摸排，最终发现是一个非常小的前端问题，甚至可能，都不能称其为问题：
列表页对滚动动作的判断。
当时的情况是这样的，用户在慢速地，缓缓地滚动列表页内容时，在手指抬起的一瞬间，用户本意是要看一下当前滚动到的位置的内容，但系统自动判断用户做了一个点击（Click）动作，然后...系统自动帮用户点击进入了列表内容详情页。
列表页
那么这种事情是怎么发生的呢？
谁应该最终为这个小小的BUG导致的长期的用户体验困扰负责？
我们来探寻一下根本原因：
一般来说，列表页对滚动动作的后续反馈判断，是通过用户手指从初次接触屏幕，到手指抬起之间的距离和时长来进行计算的。
这种滚动动作又根据用户的滑动（swipe）动作，分为两种情况：
1. 用户对当前内容不感兴趣，想快速划过当前区域内容查看其他内容。
伴随着这种用户目标的动作，一般都是手指快速接触屏幕，滑动较长距离，然后手指在目标终点快速离开屏幕。
用户快速滑动内容
这时候系统通过用户交互行为判断后给出的反馈就是通过用户手指接触屏幕到离开屏幕的位置之间的纵向Y坐标差和滑动时长判断出缓动效果（Tween）效果的内容滑动高度，缓动效果的衰减则一般是按照某个固定值来计算的，那么用户要么快速滑动，要么滑动步程非常长，最终结果都是列表内容被快速翻过以满足用户预期。
2. 用户对当前展示的列表项产生了兴趣，想要在当前以及后续列表项之间仔细阅读。
伴随着这种用户目标的动作，一般是手指接触屏幕后，根据用户视线焦点扫描（Scan）的需要来在纵向Y坐标上划过相应长度距离，然后在用户最终感兴趣的内容出现时，用户止住手指在屏幕纵向Y坐标上的移动并停留一段时间后，手指离开屏幕。
这个动作我们可以把它定义为平移(Pan)动作，因为用户在结束滚动动作时的驻留动作，明确告知了系统，我只想慢慢浏览。这时候系统不需要计算之前的用户滑动的步程和滑动时间，只需要把这个动作作为平移动作，如果做得再细致些，可以在用户手指离开屏幕时，根据用户最后离开时滑动速度，给予少许缓动反馈。
问题就出在这里了，在那个让用户非常痛苦的案例里，前端把用户最后的停留->抬起手指的动作，判断为点击（Click）动作了。
产生的后果是不是非常严重？
我认为非常的严重。
这应该来说，是一个非常小的前端失误，毕竟，事后在复盘的时候，有人还信誓旦旦地指出：‘用户被错误地引导进入了详情页也不一定是坏事，还给我们增加了内容阅读量呢’，说这话的人，应该把TA的头按在屏幕列表页上摩擦。
因为这导致了用户在浏览这个信息流页面时，不断地犯错，不断地进入详情页，但用户在非常沮丧的同时，又找不到原因，只能凭借大概的印象给出这个产品一个综合评价：“这个不好用”，最后这个评价甚至可能会影响用户对整个平台的印象，产生了难以量化的灾难性后果。甚至从头至尾，很少有人发现或认识到这个问题和后果。
我举的这个例子，只是我们在产品上犯过的所有的错里很不起眼的一个小错，不是要diss前端，因为在产品设计全流程里，我们都可能会犯类似的错误。
我们应该学到的道理是：千万不要轻视用户，否则用户就会离开你。这应该是一个比较深刻的教训，也时刻警醒着我们，用户体验是一个覆盖产品所有流程，所有部门的综合体，不要放过任何一个细节，因为：细节里面有魔鬼。
网友评论