我们把帐号系统重构了,顺便Get了这6个经验
账号重构是我做PM之后,经手的第一个项目。
最初的需求,应该是原始简陋的账号体系无法实现更换手机号,更换微信等需求,也没法把用户的微信和手机号分别创立的账号统一起来。
于是,为了解决这个问题,我决定优化表结构和逻辑,将手机号,三方登录的UID都降级,统一在一个固定的账号主ID上。
- 顺便……再解决一下登录页面UI太丑交互太过时的问题?
- 顺便……再增加一下强制第三方绑定手机号来杜绝脏数据?
- 顺便……把个人中心页面优化一下?
- 顺便……(╯‵□′)╯︵┻━┻ 产品要控制欲望……再顺便开发要砍人了……
这是第0条经验。
【Tip 0】控制欲望,版本封闭
不成熟的小产品可以让老大帮忙规划需求,然后再旁边记小本本,学习一下如何管理需求,安排优先级。(比如要考虑前端后台的工作量啦~拆分功能会受到多大影响啦~用户体验和商业价值孰轻孰重啦~)
下面……是自己这一个多月来的血泪教训……适用于一切【常规功能的重构需求】。
【Tip 1】一定要先调研清楚后台逻辑
API的开发哥哥在需求评审的时候,非要我跟前端一起,把页面的接口都整理一遍,再跟着后台一起爬代码看逻辑。
在被一行行天书摧残了一下午后,我发现PRD基本不用改(= =)……但是,如果在写PRD之前先受过摧残,那么写起来至少可以快一倍。所以,还是要谢谢开发哥哥的傲娇要求的。
对于一个刚刚创业的小公司,很多功能都是早期应急做出来的,又经过线上时不时优化的小补丁,可能会给现在的需求开发带来一个又一个的坑。
如果在最开始,没有把线上的逻辑搞清楚,在开发阶段再填坑,会付出惨痛的代价(比如熬夜加班补逻辑的同时还要被开发哥哥嫌弃……)
【Tip 2】关于逻辑
1. 该抄就抄。2. 最核心的逻辑牢牢攥在手心。
该抄就抄
账号体系这种只要是一个有用户的产品就会有的常规功能,在互联网普及这么久后,已经有了成熟的体系。
那么如果我们想要做这个功能或者优化这个功能,最应该做的,就是……抄啊!
大公司几亿用户多少年验证出来解决问题的最优方案,也是中国网民多年来的操作习惯……不复用是傻子么!
咳咳,但是借鉴也是有技巧的。
比如我们是不是希望用户以手机号为主要注册用的账号,该怎么样淡化/强调第三方的入口;各种密码验证码的格式和校验;页面跳转中注册和忘记密码的入口放哪儿;置灰和文案的小细节……历尽千帆,取百家之长,选择最符合自己产品的……原型图画好了耶~
ps. 不要忘记加入符合自己公司特色的小创新~(如果有且适合加进来的话……没必要盲目追求新意)
pps. 也不要忘记兼容产品以前的坑哦~
最核心的逻辑牢牢攥在手心——死也不改
在PRD已经定稿以后,开发过程中,需求是可以小幅度变更的。毕竟PM不是神肯定会有考虑不周的地方。
但是核心逻辑,是一定要明确好,并且保证每一个参与项目的人都了解清楚的。
如果开发中发现核心逻辑错了,宁可暂停整个项目不做,也不能朝令夕改,产品如果对于自己的逻辑都搞不清楚,那连最后的话语权也没有了。
【Tip 3】关于交互
站在用户的角度出发,但别把自己当成用户。
PM是用户的代言人。
这里的用户,是所有的用户,包括各种会进行奇怪操作或是有特殊需求的非主流用户。
怎么样能更好更全面地写好PRD避免遗漏,我想到比较好的方法是:
设计页面和流程图要分三遍
- 第一遍,保证核心的常规流程是走得通的(比如用户一步一步登录或注册的过程),或者通过账号中心绑定手机号至成功的操作。
- 第二遍,保证其他分支流程不存在死循环或者死胡同(比如进行到某一步突然忘记密码,或者突然断网或手机收不到验证码等),不管什么情况,一定要给用户反馈。
- 第三遍,优化核心流程的用户体验。比如可以把一些元素放在一个页面展现不用分多个页面,比如一些按钮的特效和交互。
多看多琢磨其他产品这块儿的功能
比如连续输入多次错误的手机号,会出现图片验证码,防止爬库。
比如有些页面涉及表单提交和状态更新,点击返回或者右滑后的页面展示和跳转逻辑。
这些细节只能说多研究,多经历……如果没有项目经验可以积累,那么多多观摩其他成功产品也总是有帮助的。
【Tip 4】关于PRD
流程图比文字更好用。
这次账号重构我最大的坑就是……写了一万多字的PRD,结果开发基本照着流程图来的……(然后我的流程图还漏了很多元素)
后来在宣讲的时候,重新画了一遍流程图,把一些对应的页面跳转和提示都加上去了。感觉开发同学理解,和自己说明都快了很多。
以后写PRD,图文并茂,少说废话。该枚举的地方用表格,且一定记得加目录索引。
PRD是PM的脸,别让他变成下图所示。
【Tip 5】关于沟通
当面>私聊>群聊
如果每天都随身带着手机,那我的微信步数肯定要double。
PM请安心当一只召唤兽~虽然跑来跑去很麻烦,但是当面沟通比起打字甚至拉群里说,提高的效率不是一点半点的。
【Tip 6】关于职责
保证可用100%,易用50%
衡量一个产品的好坏和能否上线,有很多因素,比如:
- 可用性——是否满足业务需求
- 易用性——是否有好的用户体验
- 美观性——是否传递了公司品牌形象
- 安全性——是否会影响线上其他功能,是否存在安全隐患
其中我觉得,产品最主要的是保证100%的可用性,即PRD明确的功能性需求要都实现。
其次是50%的易用性,可能我们设计的时候考虑到了80%甚至100%的易用性,但是由于时间或者其他原因,开发没有做。这部分涉及用户体验的需求是可以后续版本优化,或者为功能性和安全性需求让道的。
美观性和安全性,在设计的时候要考虑,但是决定权交给UI和RD。让专业的人,做专业的事。可以提出建议甚至异议,但是不要盲目乱做决定。
以上是这次版本迭代整理的几条心得。感谢包容我这只小菜鸟的产品、UI、开发、测试同学~
希望以后再读到,会觉得说的都是废话。
作者:徐家小翼,公众号:poemmanager,PM圈萌新一只,求带飞求指导~~
本文由 @徐家小翼 原创发布于人人都是产品经理。未经许可,禁止转载。
内容和标题”我们把帐号系统重构了”严重不符,没有描述业务逻辑,扯太多方法论岂不是误导新人
弱弱的想问一下,方便分享一下小小的流程图么?
把抄这种词拿到台面上,这样真的好吗
受教了
只是自己的一点小分享~如果觉得有道理那就太好啦
我们这边的产品经理是设计出身,对设计极度苛刻。
原谅设计吧 都是为了产品
设计出身的产品感觉做出来的不管功能好不好用,肯定会逼格高高的样子
文章不错,但是有个图片挂了,作者大人。估计是直接复制粘贴微信的图片的吧。微信图片是不支持第三方直接复制粘贴的。 😮
啊啊谢谢提醒…以后会注意哒~