本文主要从电商小程序产品切入，从产品设计层面更细粒度解构登录注册模块的产品设计思路。
小程序给众人的第1印象——高流量、易获客，冲击了1大波企业的肾上腺素，因而风风火火投入小程序生态的建设中，近乎没法自拔。腾讯微信坐拥10亿左右用户，不管小程序终究能不能成，单论这1点，撸点羊毛肯定是不成问题的。
如何将海量微信公域流量转化成自家产品的私域流量？
这是每个决心跟进小程序的公司的产品战略核心，而行将接手小程序的产品经理（PM）：接受不完全清晰的产品定位，实现产品与用户之间更好的连接。
登录注册模块是产品账户体系的核心模块，是用户接触产品的关键性第1步，是产品与用户建立真正意义连接的纽带。这么讲，其实就是想强调登录注册的重要性，由于触达用户的功能路径不简洁、复杂冗余将直接影响产品的用户转化，乃至下降盈利业务的成功率。
2016年10月份写过1篇关于账户的文章《账户体系设计：账户体系的核心要素及商业模式》，详细论述了账户价值层面的意义。
此次想借助此前负责的电商小程序产品，从产品设计层面更细粒度解构登录注册模块的产品设计思路。严格意义上，我是第3次接触账户方面的产品架构设计，第1次在刚毕业实习那会，而前后两次的对同1件事情的思考角度、心态可谓大相径庭。下面1起来看我是如何搭建小程序的登录注册产品机制：
01-产品设计的背景
相比APP、WAP产品形态而言，小程序是1个比较新的物种（老酒换新瓶）。那末，之于现有产品线而言，是1个补充，（未来）可能会演化成1种冲击。换句话说，除诱人的流量红利，部份公司跟进小程序完全是出于对微信生态的畏敬，乃至有有些直接是奉命行事——老板1句话，总之都是是源于内心的产品认知焦虑。以下从两个维度拆解：
维度1：产品层面（Product）
- 小程序作为新的产品线，产品特性需要重新计划迭代
- 小程序作为老产品线的延伸，需要兼容已有用户体系
- 小程序基于微信开发建模，需要统筹3方平台的特性
维度2：运营层面（Operation）
- 小程序基于微信，产品特性上要融会社交传播
- 小程序生于微信，大量微信流量红利需要惠泽
- 小程序依赖微信，触达用户需要更加精准、有效
1方面是新鲜产品特性的引入，另外一方面是运营策略层面的试错，因此很有必要平衡二者之间的价值本钱，且保持产品的延续有效迭代。固然，要求我们保持产品的灵活性，也由于小程序平台本身也处于延续开放的状态，二者处于1个共同成长的循环状态。
除上述两个维度的顾及，针对目标用户和使用处景需要予以不1样的适用范畴的斟酌。以下从这两个维度思考：
维度3：用户画像
- 新用户，泛指纯新用户（剔除伪新用户），这类用户是产品运营推行最需要获得的，也是花钱营销推行的目的所在；
- 老用户，特指老用户，这类用户是已有产品形态多终真个存量用户，是产品得以生存的基础血液，直接体现了产品的粘性；
- 访问者，专指未注册用户，前两类用户基本都是从这类用户转化而来，是用户相对1款产品的第1重身份，吸引转化很关键；
维度4：使用处景
- 辅助补充，拓宽用户使用处景，健全既有产品线，跟得上产品流行趋势；
- 社交分享，小程序天然具有微信赋予的社交属性，有趣的玩法很多；
- 第3方营销平台的付费推行，算是强推，花钱买用户，灌溉式获客；
其实，用户画像和使用处景决定了后续产品迭代进程中，功能的取舍、优先级，或说迭代的进度次序。1个理想的做法是小步快跑、增量迭代，既经济又现实，符合产品的迭代演进路径。最关键的是，给产品经理预留了充足时间，给产品提供了足够的选择。可问题是：既没给产品（Product）留时间，又没给产品经理（PM）留时间！
02-产品设计进程
基于以上的几点分析及公司的产品定位，终究得出两个观点，作为初期小程序产品线的产品原则：
- 快速获客，缩短产品与用户的路径
- 账户唯1，兼容新老用户账户信息
秉持这两点基本原则，为了到达产品早期运营目标，最大化发挥小程序开放的产品能力，对小程序的账户体系进行了<3段式设计>，以匹配不同阶段、不同产品目标。以登录注册模块为例：
阶段1：手动手机号
借助用户手机号快速验证注册，为用户生成唯1UID，1个手机号被认为是1个独立用户。通过手机号注册是目前产品最主流的手段，得益于手机的唯1性、真实性，1举解决了利用用户实名认证的困难。同时，减轻了用户记忆的负担，毕竟APP太多，记住1个号码远胜于多个账号密码。
市面上很多小程序直接手动输入手机验证码动态登录，完全避开第3方开放账户的关联，试图下降不同体系产品之间的耦合程度，特别是小程序外包系。某种程度而言，是值得赞美的，单1产品线（唯一小程序）采取这类方式是值得可取的，毕竟用户获得本钱其实不大且比较简洁、方便。
产品1期MVP版本，这便是我采取的方案，由于推行较弱、用户较少的情况下，这1产品设计方案可以支持，能到达快速上线的要求，易于后期的增量迭代。
阶段2：自动手机号
除产品经理自定义的小程序产品特性，小程序开放平台本身提供了丰富的集成能力，包括登录/注册的组件。平台自行开放的产品能力是为了开发更高效，产品更方便触达用户。小程序开放了几组登录、授权、用户信息方面的接口：
- 静默登录（wx.login）：启动微信时，直接后台自消息默登录，用户毫无发觉，体验很好。条件是能通过某种渠道，定位到该用户的账户身份。
- 基础授权（wx.getUserInfo）：获得用户微信基础信息，完善用户信息库，健全基础画像。
- 微信手机号授权（getPhoneNumber）：获得微信誉户绑定的手机号，不必手机验证码动态验证。（短信费用都省了…）
- UnionID机制说明：同1个微信开放平台下的相同主体的App、公众号、小程序，如果用户已关注公众号，或曾登录过App或公众号，则用户打开小程序时，开发者可以直接通过wx.login获得到该用户UnionID，不必用户再次授权。
使用【微信手机号授权】的开放产品能力，可以有效缩短用户注册路径，提高获客效力。因此优先给用户登录/注册提供<微信手机号授权>的选择，其次为用户提供手动输入手机号入口，极大改良了用户体验，最大程度留住用户，哪怕有1点歹意的感觉。
产品设计阶段2，便升级了1期的设计方案，市面上有很多小程序采取了这类登录注册机制，而我们仅将其作为过渡方案实现，并没有直接实现落地，再度升级了2代设计方案，尝试1劳永逸解决系统性的问题。因而，便有了第3阶段的思考——Passport融会。
阶段3：Passport融会
阶段2只简单使用了微信小程序的产品开放能力的1个点，而小程序平台共提供了4个方面的产品能力。经过两次的迭代，我将负责的小程序的账户体系日趋完善，构成最符合产品线要求、满足商业需求、满足用户诉求的广场景流程。
- 1组矛盾：微信开放账户（OpenID&UnionID&微信手机号）、自由账户体系（自有账户）
- 目标用户：新用户（伪新用户）、老用户
- 使用处景：快捷登录、静默登录、常规登录、活动推行（助力、拼团等）
将用户类型与使用处景交叉分析得到以下的典型故事（User story）：复合的场景均以图文的情势显现，如果图中有毛病，欢迎指正。
图文解字01-小程序登录注册全场景
图文解字02-小程序登录注册全流程
（上图已去掉了我司的任何图标名称，以避免有软文嫌疑。图文仅供参考，且未全覆盖小程序登录注册完全生命周期，是1个动态变化的流程，尽请甑别辨别理解。）
终究的登录注册产品设计方案，全面引入微信小程序开放的接口（API），极大提升产品的多场景处理能力，同时统筹了新老用户的使用感受。这里不能不说1句：微信太强大！第3段设计核心升级了以下两个要点：
- 静默登录（wx.login）、UnionID：用户不必反复手动登录，微信账户体系与自持账户买通，对减少1人多账户冗余的情况功不可没，而用户体验均属于上层之作。
- 基础授权（wx.getUserInfo）：用户微信昵称、头像等基础信息，是营销推行活动参与角色信息的重要利用场景，为活动提供了可信的身份信息的支持。
触及账户登录注册模块的几个微信开放能力共同解决了1个问题——用户身份的定位，对账户体系的设计账号（Account）的唯1性被认为是根本。从1开始，我就给自己负责的小程序的【登录】1个定义——必须具有自持账户才认为是登录状态。各种账号（Username）对应到1个账户(Account)！最大程度减少1个用户多个账户的情况，第1时间做账户合并，多账户之间的多级映照。我深知：1人对应多账户是1件痛苦的事，由于我曾历过。
记得之前好几篇文章提到了账户体系的产品设计，都只限于意识层面的输出，这1次应产品经理朋友之邀，也算是对自己的交代，由于此前很早就想复盘1遍小程序的账户-登录注册模块的产品进程。固然，有很多朋友留言说，见你写的文章大多都是偏理论的，能不能输出1些偏实战的干货。虽然我1直深信：理论经验的输出要比实践更高级，由于势必投入更多深入的思考的时间，不单是简单叙事流水账。
这1次小程序登录注册体系的产品设计进程，结合了运营、技术、产品、第3方平台的多方规则，让小程序具有了登录注册的系统级能力。正是鉴于实践的需要，让我更加意想到认知的价值，如果说你都不清楚的知道先决规则，那末所做之事又该从何下手呢？固然，这1次产品经历是我个人产品能力的实践（技术开发被折磨的够戗…），场景实在是太多了，着实不容易。
有时候，被产品同行问道：你们公司产品经理都做些甚么工作啊？但凡提到产品设计，便被质疑：设计不是交互设计师做的事情吗？哪有那末多交互设计师？产品经理（我）是制定规则的，只是顺便画了个图（原型图）。
我认为：产品设计能力是1个系统能力，着眼的是全流程、全生命周期的描绘，而不只是某个单点的锱铢必较。
作者：小王
