不想做测试的产品不是好UE

96
作者 詹仕波
2016.07.05 23:48* 字数 1158

产品经理在做某个功能或者需求点的时候,一般都能想到正常的功能点或流程,但是对于异常情况能想到多少,是需要考验产品经理功力的。这需要产品经理有很好的逻辑思维、发散思维,最好还懂点技术思维,如果有测试思维或者UE思维那就更好了。

举个例子:更换手机号是大多数网站或者APP都会有的功能,大部分产品更换手机号的主要界面如下图所示,是不是看上去很简单?


更换手机号主界面

互联网从业2年+的从业者大部分都能给出如上的界面,你能直接拿着这个页面给开发提需求么?显然是不行的。很多页面交互、产品细节、业务逻辑和业务异常等情况没有能够体现出来。

再举个例子,上图右侧的手机号输入框,默认状态需要有默认提示文字么?输入框激活和失焦后的显示样式、手机号除了位数做校验外还要不要做其它校验(手机号段或者首个数字必须是1开头)?校验的范围是怎样的?各种异常情况下提示信息怎么显示,怎么反馈给用户?输入内容后同步校验还是最终点“提交”时校验?回退后再进入页面时之前填写的信息清空还是保留(部分还是全部)?短信验证码的获取按钮哪种情况下灰化,哪种情况下可以点击?

如果考虑的层次更深一点,那么你需要考虑:iOS和安卓端手机号校验是调用同一套接口还是单独来做?可否和WEB端通过WebService来共用同一套微服务接口?手机号校验号段还是只校验首个数字为1即可?两者的利弊都有哪些?该界面需要输入的内容全是数字,是否可以默认全部呼出数字键盘?短信验证码输入错误后立即等待60秒重新获取还是设定一个临界值(比如连续输错5次)?数字验证码和短信验证码依次正确输入后再返回修改数字验证码,最后提交时是否需要再次校验数字验证码?解绑后不绑定新手机号算作解绑完成还是未完成?

以上的这些细节如果产品经理在功能设计阶段或PRD撰写中没有考虑完整,需求澄清的时候开发或测试没有提到,那么开发的阶段程序需要反复的跟产品经理确认这些细节的地方如何来处理,小则影响交付项目延期,重则前功尽弃全部推翻。如果开发在交付验收的时候没有覆盖这些细节,那么问题有可能直接呈现在用户面前,用户体验会极差。

那么问题来了,怎么才能保证产品经理在做产品(需求/功能)设计的时候不会有细节遗漏呢?答案很简单,产品经理试着写测试功能点,换位思考,假定自己是位很刁钻很极品不走寻常路的用户,枚举各个环节可能会遇到的问题,然后形成测试点。

下图使用XMind绘制,产品经理可以用其来理清自己的思路,然后据此来反复检查PRD中是否涵盖了这些功能测试点。测试人员可以据此来编写详细的测试用例。


更换手机号(功能)测试点

初入门的产品经理可以使用此方式来锻炼提升自己的产品设计能力,中高阶的产品经理在做复杂功能/需求时也可以用Xmind或脑图的方式来进行角色场景分析。

个人觉得初级产品经理和中高级产品经理的一个显著区别就是:中高级产品经理考虑问题会更深入更全面一些、会从多视角多维度来来看待问题。

产品设计