最近做事情的时候，在密码找回及更换邮箱账号这一个功能上出现了一些相左的意见，可能站在各自不同的角度，所以会有去讨论一下到底哪一种方案更适用于当前的产品。首先产品是一款统计工具，需要用户通过邮箱注册账号来管理他的统计数据。在注册账号的时候是不是要对他注册邮箱的真实性进行验证呢？

那么从我的观点出发是：工具型产品，统计信息私有不公开，那么邮箱账号需要一定的安全性，一个真实的邮箱可以提供产品与用户一个有效的连接渠道，在找回密码的时候也能够准确的将密码返回到用户手中。建议在邮箱激活之前是一个账号的试用状态，即操作产生的内容不做永久保存，一周或者三十日内会清除。

产品的观点是：不做激活操作，注册即可使用，不对账号真实性做验证，产品初期需要用户积累，多出来的验证操作是在给产品建墙，阻挡用户来使用产品，，进行注册的用户并不愿意花费时间来进行更多的验证操作，目标明确“快速体验产品的特性”。所以让入口变得越简单越好。如果验证邮件反复尝试扔无法收到，那么该邮箱即使是真实的也不能成为一个有效账号。

不进行验证的话可能会带来很多繁复的问题，例如：如果注册当时我的注册邮箱输入错了怎么办？我没有得到验证反馈没有发现这个问题，在这个账号下进行了很多操作，下一次登录的时候并不记得错误的账号是什么，那么我无法登录了，找回账号的方式，只能联系客服来解决；掌握了用户真实的邮箱，可以在统计一定时间后发送提示邮件，提醒一些可能忘记了查看统计的用户返回查看数据统计，提高用户的留存率；通过发送版本更新信息来努力召回一些长时间未使用产品的用户回流，对产品之后的运营是有一定帮助的。虽然可能会损失一部分随意注册的用户，但是对验证后的用户提供更好的纽带。并且在对相关的同类产品的对比当中也有发现，类似于站长之家、诸葛IO这样的统计工具也都有邮箱验证这一步骤。

产品的态度是：我们是否真的需要一个验证过的真实用户，假使是一个用户没有邮箱，或者就是喜欢用虚拟的邮箱注册账号，不验证的操作在他不忘记密码的情况下仍然能够正常的使用产品；大多数的用户都是正常且正确的注册账号，并没必要为了少部分用户可能会出现的错误而给所有注册的用户设置障碍。我依然认为这样没有验证的注册会让很多账号存在隐患。

最后达成的妥协是取消了邮箱验证的过程，在注册成功后的感谢提示当中再显示一遍注册账号，虽然觉得注册后的用户并不会有心思去检查一遍账号，大多数会快速的跳过进入到后面的引导过程。

第二个有异议的地方是在个人设置当中添加了一个可以更改注册邮箱的功能，当时设想的用户场景是需要更换到一个更加常用的邮箱，并不是作为一个很主要的功能，所以也放在了邮箱账号下拉列表的个人设置当中。当时设想的的是，通过对原邮箱发送确认邮件，来验证新旧邮箱的变更。

产品的变更意见是邮箱跳转会比较麻烦，而且通过输入密码来更换账号更加安全，如果不对密码进行验证的话，从位置上走开一会儿，其他人就可能变更了账号（我觉得这个逻辑可能不够严谨，因为其他人可能还要知道用户的原邮箱的密码才能通过邮箱去更改密码，但如果浏览器中有记录那就还是很可能被更换的）；或者原来的邮箱丢失了，想要更换到一个新的邮箱账号当中，因为进入不了原邮箱，所以根据原邮箱来确定新邮箱的方式是实现不了这样变更的。出于原邮箱丢失的而去使用这一项功能的场景会比单纯为了更换邮箱账号的场景更加频繁。而且在原邮箱并没有验证的情况下，原邮箱是否真实存在也是一个问题，那么多一个并不一定存在的邮箱进行邮件确认是无效的；极端情况，验证邮件繁复无法接受到，就无法完成更改的目的。

这里稍微想了一下，确实是在原邮箱失效的情况下无法更改注册邮箱了，而这又是真实的使用场景，但是这样一种可以通过账号找回密码，又可以通过密码更换账号的方式觉得有有一些怪怪的。最后还是采用了密码验证修改邮箱账号这样一种方式。

对于以上这两个问题我觉得矛盾还是更多的集中在安全性和易用性的讨论上，安全的环境并不是非得要有足够多的验证信息和密码，易用的产品也并不是简单到任何操作都触手可及，而在于有条理和清晰的思路，明确的行动目标，以及对当前行为的可控，在之后关于一些功能逻辑的讨论上身边人还是给了很多的指导，在不断的提问与应答，和各样的使用场景的切换下，还是得到了很多的启发。