前段时间发了一篇文章：两个真实产品案例所引发的思考。主要对两个切身经历的产品案例，进行了一些分析和思考。有读者评论说可以多分享一些案例形式的人讲解，正好最近又遇到一个比较“有意思”的案例，可以拿出来说道说道。
背景说明
作为一个电商平台，前不久我们上线了申请开发票功能，用户可以选择“普通发票-个人”、“普通发票-单位”、“专用发票”三种类型，其中“专用发票”类型需要填写的信息比较多，在该功能上线一期，出于精简考虑，系统没有保存专票信息。
在后边的版本迭代中，我们紧接着把专用发票的模块功能提上了日程，在做具体设计的时候，身为产品同学我和交互同学产生了比较大的分歧，主要的问题点有如下三个：
一、专用发票的模板数量提供一个还是多个？
交互同学的想法是可维护多个，给用户提供更多的自主性。我坚持的是初期只维护一套模板即可，我又有哪些考虑呢？
首先，多套专票模板的用户需求量到底能有多少？根据以往数据统计，开票的用户本身就是一小部分，并且开专票的比例也很少，其中又同时需要多个专票模板的用户肯定更是少之又少。并且单纯的从主观性上考虑，开具的专票内容相对是固定的，而不像网购的收货地址，可能有家庭地址、公司地址、女朋友的地址等等。所以，多套模板的需求是否存在，或者说需求量有多少目前还是存疑的。
然后，在看一下多套模板带来的成本有哪些？最显而易见的就是开发成本，因为需要支持多套模板，用户任意添加，其开发维护成本势必会增加。还有隐性的用户使用成本，尤其是那些基本上都是使用一套专用发票的用户，无论是在申请开发票填写信息时，还是维护过程中，交互的逻辑相对也会更复杂一些，后边的第二点也会具体说明到这块内容。
综上两点，多套专用发票模板的需求量还是存疑的，并且也会带来额外的成本，所以我倾向选择一期仅提供一套专票信息模板即可。当然，后面的版本迭代中，完全可以再根据实际情况进行调整。这也算是在践行着MVP的设计思路。
前面说明了，发票的类型一共有三种供选择：“普通发票-个人”、“普通发票-单位”、“专用发票”，具体的交互逻辑如下，选择好类型之后则需要填写对应的信息，其中前两种类型信息很少，只需考虑给专票信息提供模板即可。
假定确定只维护一套专票信息模板，申请开票的过程中用户若选择了“专用发票”，此时专票模板中的信息该如何体现出来呢？
常见的一种处理方式，就是当用户选中“专票类型”后，直接把专票信息模板中的信息显示出来供用户查看，确定无误的话则直接提交，如果有问题的话可以点击编辑按钮，进入二级页面进行修改。同时交互上也要考虑，用户第一次申请开专票，没有维护模板的情况下的处理方式。
这种处理方式有一个问题，如果选择“普通发票-个人”、“普通发票-单位”类型，则是表单项需要填写，而选择“公司专用发票”后却是展示专票模板，并可以进入修改的二级页面，这使得在同一个路径中，分成了不同的交互逻辑，本身会有点怪异；并且这种专票模板的处理方式，在已上线的一期方案基础上，无论是交互逻辑和技术实现上都会变得更加复杂，实际的用户体验也是个未知数。
以上是交互提出的方案，而在我最脑海中最初设想的另外一种处理方式：当用户选中“专用发票”类型后，页面下方仍然是需要填写的表单项，此时系统做判断，分为两种情况：
如果是第一次申请专票，没有记录任何专票信息，则为正常的空表单需用户填写；
如果系统已经记录了专票信息，则表单把模板信息做默认填充，用户检查无误的话，直接提交；如果发现有信息需要修改，直接在默认填充的信息上进行修改后提交，并且此时系统会更新专票模板的信息。
这种处理方式在只维护一套专票模板的基础上，只是做了表单项的默认填充，无论是交互逻辑，还是技术实现上都更加简洁清晰。并且这种处理方式很好的包含了第一次无专票模板的场景和有专票模板的场景，另外用户如果在开票过程中需要修改信息，也更加直观自然。所以最终我还是坚定选择了这种处理方式。
然后，针对这个点再谈一下问题一遗留的那个问题，如果要支持多套模板，那在申请开发票的流程中，其处理方式必定会更加复杂；不仅要能够从多套模板中选择一个，也要能够修改某个模板信息，并且还要能在开票过程中直接新增模板。这不仅仅会加大技术实现的成本，并且在需求不明确的情况下也会增加现有用户的使用成本。
三、是否在个人中心增加专票信息维护入口
除了在申请开发票的过程中，可以填写/修改专票的信息，那在个人中心页面是否要增加的专票信息维护的入口呢？
交互设计师最初的设计方案是不需要，他给出的原因主要有两点：
以上已经分析过，需要维护专票信息的用户是一小部分，所以不应该为了少部分用户的需求而在个人中心页面增加独立的入口；
专票信息应该出现在被需要的地方就够了，就是申请开票过程中。
针对第1点，我觉得应该要有一个限定的场景，就是在任务的主流程中，要足够简化，不能因为个别用户的特殊需求而损害了大部分正常用户利益。可是“个人中心”的定位本身就是个人相关信息的展现，而发票信息很自然的应该被归为其中的一部分，并且在这里放置发票信息，并没有对其他正常用户造成额外的干扰。所以这个观点根本无法套用在这个场景中。
针对第2点，如果只考虑大部分的正常使用场景确实如此，可是如果当用户在非开票时想要修改专票信息该怎么办呢？可能有人也会质疑说：这是一种非常低频的使用场景。的确如此，可同时我们也可以继续思考，为了满足这部分低频场景下的需求，在个人中心增加了发票信息的维护入口后，又会带来什么损害吗？如果答案是否定的，并且我们也认可“专票信息”同属于“个人信息”中的一类，为何不增加入口维护呢？
其实，对于这个问题，“专票信息”在某种程度上跟“收获地址”是类似的，而电商平台通用的做法就是，除了在下单时可以填写/修改收货地址，在个人中心也会提供相应的维护入口。
总结
以上，是针对专票信息维护这个产品案例，我在设计过程中的一些思考，其中主要的思路可以总结为以下几点：
当需求不明确时，尽量简化功能，甚至暂时不做，即学会MVP的设计思路；
除了考虑功能带来的收益，也要考虑实现成本，当成本过大而收益有限时一定要慎重；
尽量保证前台交互方式的一致性和简洁性，不要让用户有过多的思考；
在保障前台用户体验的前提下，也要考虑系统实现的复杂性和难易程度，尤其针对迭代功能，设计方案尽可能在原有基础上简化处理；
除了要支持主流的使用场景，也要考虑是否可以满足某些特殊的使用场景；
当犹豫是否要支持某些低频的使用场景时，也可以反向思考如果要支持，需要付出多大的成本，又会带来哪些损害，当收益比足够大时，就可以考虑；
虽然在讨论中，我比较强势地否定了很多交互设计师的观点，但也要坦诚我的设计思路中也会存在局限，存在有所欠缺的地方，所以也欢迎大家来拍砖，一起讨论。做产品设计往往就是这样，很多时候不存在完美无瑕的方案，但是通过反复的思考和讨论，能够不断得出更好的方案。
