用户中心账号体系重构背景分析
用户中心是我负责的主要业务线之一，包含用户帐户管理，用户安全管理，用户资料管理和用户资产业务支撑，巨大的用户量和数据在系统中基于用户中心而运作，作为基础服务平台的一部分，安全和稳定是重中之重，产品模块也遍布各个其它业务线，常常是牵一发而动全身，产品更新适合渐进式的微调优化，产品形态也需要不断将复杂的逻辑尽量抽象为简单的用户操作流程。
作为一个saas服务系统，我们的用户来自各个平台，各种形式，在帐号体系不够健康完善的情况下，不同业务为了满足自己需求所创造的用户身份又会加剧本来就复杂的帐号体系，拿我经验的例子来说，平台上共有10种大类的用户身份，一部分完全由不同的用户ID代表，另一部分基于某种ID再添加上次生ID，底层系统架构没有理清，不够健壮的时候，上游业务很容易出问题，用户在特定业务如订单的查找上就会遇到很多困惑。当我接手用户中心业务线时，是经过了一番曲折的，首先因为我本身是要做scrm的积分商城和会员业务，但发现业务的基础，用户帐号体系没有打通，同一个用户在业务层面的底层系统里是可能分成多个身份的，系统本身也是不知道的，而且不同身份基础上支持的同一个业务实现方式也是不同的，因此无法做到scrm的目标。为了做scrm的业务，我主动接下了用户中心的混乱局面，然后推动并主导了帐号体系的重构，期间与各方人员合作，了解系统架构现状，讨论解决方案，最终经过2个月的时间，最终确定了一个基本的“主ID”，并其它ID都向其靠拢，业务建立在此之上，使不同的可识别为同一个身份的帐号进行绑定和资产（订单）的合并迁移，至此走出了帐号体系重构的第一步。
帐号体系重构一期
后来，又将注册登录时的绑定环节进行了优化，使这一动作尽量既符合用户预期，又满足业务需求，方案最初将绑定从默认绑定变为了用户可感知的主动选择，以减少用户的不同账号身份进行绑定后订单资产看似可能“丢失”一样的误解。上线一个月后，“订单丢失‘的误解少了，但又出现了新的问题，绑定的出现让他们多了一种选择，但选择与之前默认的不同的时候，用户却还习惯性的认为结果应该是另一个样子，这就带来了新的误解，究其原因是用户无法很好的将自己的选择与结果之间产生认识，即使这一动作的意义已经在流程中显得很明显和强烈，但我们发现这类用户总无法避免。虽然人数远少于没问题的人，但我开始重新思考是否有更好的办法，起初为了带来”更好“的用户体验而增加了更多的选择，为了让用户意识到自己在业务A里的动作是如何影响到业务B的， 但这就是有一道墙在，产品似乎很难做到完美的避免所有看不到墙的人存在，这根本上是一个系统性的体验问题，意识到这一点，我知道最初的方案并不一定就是体验的提升，至少多出来的墙就是给了用户更多的选择负担。
后来我和技术团队一起，又围绕这个问题寻找了很久继续优化的方案，最终多亏我们的死磕，也依靠工程师们的智慧，从技术上找到了一个点，虽然也不完美，我们发现解决了这个问题，总会出现新的问题，但至少可以避免用户在原始方案下的误解。于是，我又重新设计了方案，把流程变得更加柔和，不过分突出绑定，从根本上说，依然延续在微信环境下登录yz手机帐号即绑定的设计，如下图：
帐号管理
另外，我开开放了新的帐号管理模块，解决了买家在去中心化的购买平台上难以管理自己的帐号的问题，这是从0到1的迈进，甚至在整个yz产品体系中，这是唯一个可以让用户进行手机号更换并不影响资产的入口，算得上一个标志性事件。如下图：
