想避免产品设计陷入误区？本文以哈啰单车为例，深度剖析其在手机号换绑、账号找回等功能上的不足，从场景定义、用户群体判断到产品引导设计等方面，为产品经理提供改进思路，助你打造贴合用户需求、提升用户体验的优质产品。

事情是这样的，前阵子我用支付宝扫了辆哈啰共享单车，但是系统提示我当前手机号和哈啰绑定的手机号不一致，需要验证原 1096 的手机号或者将 9335 当前手机号进行换绑。

我当时选择了换绑，9335 的手机号收到验证码后，让我非常困惑的事情发生了，系统提示我 9335 的手机号已经绑定至其他哈啰账户无法继续操作。

这样一来就彻底陷入了死循环，当时我也不知道该怎么操作，无奈只能放弃扫码骑车了。

后面回到家后，我大概梳理了下整个流程，感觉哈啰的这个设计确实很不对劲—

为方便大家理解，我先简单讲述下个人使用哈啰单车的经历。

尾号 1096 的手机号是我在上大学时候使用的，因为骑单车的频率并不高，通过手机里现有的支付宝软件扫码骑车对于我来说是最便捷的。

毕业后我更换了手机号，尾号为 9335 ，又因为顺风车的业务下载了哈啰 APP，同期也使用过共享单车功能。

再后来我换了新手机，因为顺风车需求的低频性就一直没再下载哈啰 APP，于是再当我使用支付宝扫共享单车就出现了开头这种情况。

便于大家直观理解，我专门做了张图，如下—

将功能集成上架于主流软件的开发平台，确实有利于降低使用门槛，但不能忽视用户的情境性特点，否则就没办法定义全用户的需求场景，很容易就会出现我遇到过的这种情况，陷入死循环。

单纯的手机号换绑功能已经覆盖不了用户在多渠道入口、不同现状下的业务场景需求，我们做一些场景假设，相信大家就能很轻易地感知到我所说的意思：

• 新账户只有数据没有权益；
• 老账户不仅有数据还有权益，新账户只有数据；
• 老账户只有数据没有权益，新账户不仅有数据也有权益；
• 新老账户都有数据和权益；

这里用户需要的不仅仅是换绑手机号同时也存在切换账户体系的需求，而哈啰的换绑场景更像是加了诸多限制的完美场景，为了做功能而做功能。

如果是常规的账号换绑功能，这样设计确实没有问题，但结合哈啰单车现有的业务上就不合理，用户的真实需求更应该是在保留数据/权益的前提下，用新手机号完成产品使用。

到这里为止，我觉得哈啰的产品经理没有完全理清业务发展轨迹中用户的真实场景有哪些。

其次，这里的设计问题也误判了用户群体，加大了运营策略在业务运行中的效果误差。

我不清楚和我有类似经历的用户群体有多少，但当我在老账户体系上完成新手机号换绑后，我也成功地被哈啰认定为【回归用户】。

当我这样的个体达到一个数量级时，我们被定量出的那个数据，对于哈啰来说才是更具有迷惑性和毁灭性的。

每一个策略都存在误差时，最后汇总的数据也就不再贴近真实场景。

除此之外，我认为哈啰的产品引导设计做的也不够好，用户对哈啰自身的账号体系感知是很弱的，反而会更关注我在什么场景下使用过。

下图是哈啰换绑手机号页面，先不说没有将权益/数据等信息进行展示，辅佐用户决策，防止用户换绑后权益数据丢失的情况，单纯的账号信息展示对用户来说就不够友好。

如果是我，会侧重展示用户的使用场景可能会更好理解，比如“通过哈啰APP注册”“通过支付宝注册”等。

除了账号换绑以外，我顺便还体验了下其他功能，结果真的一言难尽。

因为换绑后，我最新的骑行数据丢失了，于是试着找回新手机号原先绑定的账号，整个过程系统提供了实名认证、支付宝订单号后4位认证、微信订单号后4位认证三种认证方式。

先说实名认证，过程中摄像头一直卡顿，同时认证完成后无提示且摄像头区域黑屏，我试了好几次都是这样，后面我看到实名信息已认证，我也不清楚是怎么回事。

再说订单号后4位认证方式，更是不合理，我的账号已经解绑无法登陆，我怎么找回订单号呢？而且订单号本身20多位，我要核对后找出再来认证后4位，这种方式用户真的能接受吗。

不仅于此，我还能用相同手机号做换绑，且到最后一步系统才提示我，而且提示文案也很容易让人误解。

这一轮体验下来，哈啰给我的感觉非常掉价，正所谓产品无小事，但如果整个产品全是这样的断头路流程、纯逻辑性校验，怎么能相信他还能提供好的服务呢？

价值观和基本功如果落了，就很难再找回来，希望哈啰关注业务的同时也能兼顾好服务。