如何有效的避免自己陷入思维僵局

　　设计是一个在不断尝试和纠结中前进的职业，设计师就是一个个纠结综合体。工作中时常被自己的思想围城弄得不可自拔，既听不进其他人的意见，也无法为自身找到突破。不是任何时候都能有人帮你拍醒自己，所以如何有效的避免自己陷入思维僵局才是问题的关键。
　　我也曾掉过不少坑，每次都是愁得头发掉一把；刚开始总是得过且过觉得事情解决了就行了呗，结果就是下次依然掉坑。按老人家的话来说＂不能记吃不记打呀＂，所以今天就行来跟大家聊聊我是怎样避免走入思维僵局的，不敢说办法一定有效，不过也能一定范围内为你当过那些飞来的＂横祸＂。
　　明确目标
　　明确目标当然是第一要务，没有目标就像无头苍蝇撞来撞去，即使最终把事情顺利完成了也是糊糊涂涂。目标不明确很容易做着做着就偏了，或者是到最后也没弄清楚是为了解决什么问题。
　　在接到需求后一定要分析功能诉求，有疑问的地方多跟产品经理交流，互动本身就是一个相互补充的过程。就如同设计永远没有最优解，交互稿永远没有最终版，所以你也不能指望产品经理就能一次性写出完美的PRD。将心比心，如果一个开发能帮你看出逻辑上的漏洞你将会以拥有这样的伙伴而开心，产品经理也希望能有一个互进互助的下游来共同完善需求。
　　只会话线框图的交互不是好设计，并不是说交互做多了就该转岗去做产品，而是时刻有一颗探讨最底层需求的心，才能不当一只没有方向的无头鸟。
　　平台、场景
　　任何产品都是基于不同场景下而做出的设计，同一产品也会因为所处平台的不同而使得功能差异化。因此搞清楚平台、理清楚场景很重要。
　　不同平台本身就是不同场景下的产物。场景分析可以让产品经理和设计师理清最底层的设计思路，明白该功能是为了帮助一群什么样的用户在什么样的状态下解决什么样的问题。有了这些清晰的大前提后，就可按照＂纲领＂做＂方针政策＂了，不至于为一些不靠谱的需求而浪费时间和人力。
　　多于开发沟通、了解开发实现
　　＂我是设计为啥要去管开发＂如果你有这样的想法就已经失败了一半。开发小哥并不像你想象的只是会敲代码，同样作为互联网氛围下的一份子，他们中的很多都比我们先入行，对于用户体验这种东西或许没有设计师理解的深入；但对于什么是好的设计他们也不乏有独到的见解。
　　对于我们来说，只是游荡在设计圈子中虽然时常可以有灵感的碰撞，但宽度难免有限。每当我思路混乱的时候就喜欢找开发小哥聊聊，听听他们对问题的理解，不过前提是他们有时间跟你聊。往复过程中我发现，虽不是问题每次都能得到很好的解决，但大多都会给我带来新的思路。他们在考量问题时会站在性能和实现成本的角度，在某种程度上来讲比我们只会高呼＂用户体验＂要来的更加实在。
　　其次，就是在可能的情况下多了解一点开发问题。在实际的工作中尤其是实现环节中，我们和工程师之间要有频繁的沟通，因为你不可能指望某个人只对着交互稿就能搞定一切，过程中开发时常也会发现一些交互上的疏漏。交流过程中他们会经常说一些控件名称，就会让我感到困惑。就像我们经常说什么标签栏、工具栏、占位符之类的，了解一些他们的语言和名称会大大的提高工作效率。如果能明白功能的实现原理就再好不过了。带着这样的思路做交互稿本身就是一箭双雕，既满足体验又兼具开发实现。要知道在成本效率当道的氛围下，如果你的设计能兼具＂物美价廉＂分分钟甩那些只会执拗的高呼维护体验的设计几条街。
　　不被某一案例所牵制
　　做设计前先找资源，这习惯在本科时期就已养成；认为这样才能知己知彼，不至于辛辛苦做完后才发现早有先例。想法其实没错，因为本科学习产品设计，对产品的创新性和外观的独具性要求的很高，所以做前都会先看资料再做发挥。
　　而互联网产品则不然，软件的好坏讲究的是能否自洽。我发现之前养成的习惯很容易让我被某一案例所牵制，就拿这次来说，我一会觉得花瓣的形式好，一会儿又觉得LOFTER也很有道理，最后又感觉微博才是想的最清晰的方案。翻来覆去过程中我已经忘了去考虑各个方案之间为何存在差异性，他们都是为了解决自身怎样的特殊性，我这次又是为了解决什么问题。多看好的设计案例是为了让你学习别人对问题的思考方式，而不是为某个＂好＂设计就不可自拔的养成惯性思维。
　　没有所谓的最好
　　没有几个优秀的设计能做到一步到位，过程中遇到反复或他人的否定都是常有之事。每次做了很多方案从中挑出最好的以后，就觉得这已经是可行范围内的最优解了，如果这时候突然有人质疑就会觉得他是未加思考的＂信口开河＂，甚至对此感到恼怒。其实应该感谢向你质疑的人，是他们及早帮你发现了问题，如果都不能让身边人都信服的方案，又如何能做到让用户信服。