今天是自上周入职以来第一次参加团队会议，讨论新来的PM提出的几个需求。
第一感觉，需求很细。但是就算是这么小的需求，也会让整个小UED团队六七个人讨论很久。
一些需求由于技术限制就Pass，一些需求讨论下来优先级不是很高Pass，挑一下印象最深，同时也没有结论的几个问题：
1.购物车是否要常驻导航栏，旅游产品app的购物场景是否需要频繁切换至购物车？
2.由于产品是由网页端起家的，考虑旅游使用场景，外出换票登录web端并不方便，所以邮箱作为一大重要的入口来获取使用凭证（QR code）。邮箱注册的用户没有问题，order的时候会自动录入邮箱。但是针对微信和FB第三方入口登录的用户，邮箱地址空白，在order的时候则需要手动输入邮箱。
那么，验证邮箱的正确性成为一大问题：
现有产品逻辑为填写完邮箱之后，需要用户手动勾选确认协议，类似这样👇
如果没有勾选往下填写信息，点击预订之后会报错，体验很不友好；但是关键问题在于，就算用户勾选了这一项，用户也许不会check，并不能很好的保证邮箱的正确性。
在小小的表单区域内，如何优雅地拿到正确的用户邮箱，便成为一个小纠结的问题。交互是一门细致活，但是有时候，我们得跳出来，才有更好地解决方法。
首先，从使用场景上来看，微信通常在移动端，FB有移动端和网页端。移动端场景换票需求使用app查找凭证的频率肯定高于邮箱，并且klook移动端一大特色功能为离线查看凭证，那么在移动端上邮件信息到底是不是优先级最高且必要就要挂上一个问号了❓
接着，也许会说到全平台统一规范的问题，这下似乎刚刚那段话就成了烟消云散。如果在移动端一定要发送邮件凭证，一定要验证邮箱正确性，我们可以想到几个解决方法：
1.高亮文本提示用户
2.用户输入两次邮箱，保证一致
3.发送验证邮件至邮箱，直接激活
4.发送验证邮件至邮箱，邮件中登录
5.本文中直接☑️
6.在接入第三方账号的时候，验证邮箱，但这样有损体验度
个人而言，125几乎上伪解决方案，邮箱依然可能上错误的；34在表单中验证会显得功能很重，但是从一个角度来看，验证邮件这个操作只会进入一次，且在产品方如此看重这个凭证的前提下，一切看起来会很合理。重要的功能，一次验证，安全保证，让用户参与到账号财产的自我保护队伍中来～
除了防止用户犯错，也可以从挽救的角度来看，支付后是否收到凭证，没有收到凭证如何修改邮箱，重新发生凭证，等等等等
－
今天不早了，先睡。明天继续。
