我在上年下半年，作为一名交互有幸进入大厂。
之前在小厂经历也是很好的，业务上手之后产品经理和研发经理都非常认同，所以很多时候的一些体验意见都可以得到重视，虽说是野蛮成长，总算没长歪。
言归正传，什么样规模的大厂呢？大概就是UED团队有几百号人的规模吧。在大厂工作工作模式和小厂肯定是有区别的，入职以来，觉得最大的区别就是你得在规范中，和其他设计师协作中来完成你的设计方案。
为什么我们需要规范？
很多人觉得规范是一个束缚了自己设计方案的阻碍。我一开始也觉得规范很麻烦，导致很多的构思都由于规范无法良好地实现。但是从用户体验出发，一个复杂的系统不可能只由一位设计师去完成全部的设计，这个时候，我们如何协作，才能保证整个系统的操作具有统一性，和相似性，减低用户的认知成本呢？那当然很大的功劳是规范啊。
分析好需求，才有可能在规范内做好设计。
无论任何时候，脱离使用场景、商业目标的设计都是失败的。接到需求后，无论是产品，还是交互，都必须自己去分析需求，在设计方案时也时刻注意不能脱离你需求的体验目标、商业目标。
在规范内拿出你最好的解决方案。
俗话说，条条大路通罗马。能达成需求目标的交互方案肯定不止一种，做需求的时候多想想，不要只止步于你的第一个方案。接着，尽量使用规范化的组件、交互思路去完成你的方案。方案完成后，可以先放下，过一会再以使用者的身份去体验你的设计方案，不断审视，务求方案能在业务需求、规范、体验中找到良好的平衡。从过去的需求经历来看，这确实是一门技术，想要找到平衡点确实不容易，但是一旦找到了，少有成就感外，后面的环节有人质疑你的方案时，你会发现你的方案经得起推敲。
当无法判断哪种方案体验更好时，最符合规范的设计就是好的设计。
俗话接着说，条条大路通罗马。既然我们在设计方案时不止一种路子，那肯定会有各方的意见，觉得自己给出的方案能提升用户体验。这个时候，我们回到开篇时讲到的一个观点，在同一个系统中，我们唯有遵循规范，才能使操作具有统一性、相似性，降低用户认知。我们其实都不是用户，无法判断采用新的交互逻辑是否能让用户识别，或者真的能提升用户的效率，所以在选择方案时，最符合规范的方案往往也是首选。
举个例子，我们经常会对一个表格内的数据进行一些操作。如果你选择了5条数据进行操作（比如删除，为了好理解例子中都将此操作定义为删除），结果发现其中的两条是不能进行删除的，这个时候，有两种交互方案
1. 在删除前提示有两条数据不能进行删除，再进行删除3条数据
2. 直接先执行可以删除的3条数据，再提示用户剩下的两条数据不能删除
不考虑不能删除的两条数据如何处理的情况下，其实这两个方案的结果是一样的，最后都是告知用户有3条数据进行了删除，有两条不能。有人觉得第一种打断了用户操作删除的这个任务目标，而有人觉得先提示不能删除的会更让用户对自己的操作有预知，更有安全感，两方都有理。这个时候我们的规范是第2条，这就表示，系统其它地方的删除操作也是使用第2条的交互，那很明显，我们选择第2条，保持系统的一致性，或许会更符合用户的认知。
规范是可以打破的
当然规范并不是万能的，也并不是所有的时候都是合理的。所有的规范都应该允许有例外的情况。当你在了解业务逻辑和需求的商业目标后，发现在规范中确实无法拿出具有良好体验的交互方案时，就必须考虑打破规范。当然这个过程还是需要比较慎重，因为前面也说到，打破规范也意味这可能需要提高用户认知成本等等的风险，此时可以多与业务方、协作的设计师沟通，一起探讨出最好的方案。
继续举个例子，还是刚刚我们对表格数据的一些操作。这个表格里的数据都是钱，而这个操作就是对这些钱进行选择然后体现，依然是两种交互方案
1. 在提现前提示有两条数据不能进行提现，再询问是否执行提现
2. 直接先执行可以提现的3条数据，再询问用户不能提现的两条数据的处理方法
人类对钱是非常敏感谨慎的，所以很明显第2个方案直接就先执行提现是有点鲁莽了，在执行操作前还是需要打断用户的操作提起用户的注意，所以根据业务场景我们最后选择了第1个方案。
从一开始讨厌规范，不想和规范打交道又偏偏绕不过规范；到后面熟悉规范，使用规范能驾轻就熟完成一些小需求，一路走来我对规范可谓又爱又恨。但我始终相信，无论有无规范，只要保持思考，有用户数据佐证更好，综合考虑的话定能做出好的设计。
