其实每个设计师自己都有一套成熟的工作流程了，随意说说，点到为止。

准备其实是一个反复问自己问题的过程，当时的项目背景如何、有什么资源、希望做什么事情。做事情的原因也即项目目的分两方面：一是解决现有的问题，对已有的东西或过去自己挖下的坑做补救，进行更进一步的优化；二是去探索、发现、满足用户的新需求，这种时候就需要更多的了解。项目背景牵扯的范围会广一点，要做的需求在产品的项目安排内是否属于较高的优先级，方案是否会让开发苦不堪言增加大量的工作量甚至影响架构的改动，是否牵扯到一些合作方的事宜需要沟通协助，这些其实都是设计师要考虑的。

并非能做出一个酷炫、一定会让用户耳目一新或者你觉得最合适最完美的设计方案就是好的设计师了，我觉得做交互设计师的日子学到最多的其实是平衡二字。

你真的了解你的用户嘛？！交互设计师最擅长处理和考虑最多的就是情境。

设计方案针对的是否是产品受众的用户画像？设计师需要通过访谈调查及自己的预判断去了解用户的需求是什么，甚至猜测方案出去后每一步的转化率及达到的效果，让结果可量化。

了解的方式无非就是：访谈、观察、记录、分析这些。问问自己，用户的主要需求是什么（不是他抱怨的或期望的东西），现有产品的主要问题还有哪些，使用的情境是怎么样的，用户是怎么理解这个设计方案的（心智模型）

如果产品是处于红海领域，理所当然的就会有很多竞争对手。我一般会拿2、3款竞品，找找他们是如何解决这个问题的，同时也会找一些虽然不是直接对上、但是另辟蹊径解决同样问题的产品做分析和对比，以期发现一些值得借鉴或引以为鉴的点。有时候会发现对手真的做的挺好，或甚至因为项目赶期研发工作量等各种各样的原因，产品经理会说“抄嘛~先抄后超”，那就抄吧少年，这行业就是这样的，只要你能抄出预期抄出风采。

功能的定位、需求、目标、合作的方式、研发可行性、项目时间点与优先级、是否影响其他模块、技术上是否能创新、解决多少现有问题——看起来与设计方案无关却需要时时考虑并直接影响方案最终能否实施的问题。

我有多少时间来完成这个方案、谁来最终决策、其他设计师有没类似的案例、完成后达到的目标和判断标准如何设定——与设计师自身相关也需要时时考虑的问题。

如何产出一份深受研发&测试同事喜爱的设计方案，试试MECE原则

MECE，是Mutually Exclusive Collectively Exhaustive，中文意思是“相互独立，完全穷尽”。 也就是对于一个重大的议题，能够做到不重叠、不遗漏的分类，而且能够借此有效把握问题的核心，并解决问题的方法。

——来自 百度百科

具体大家自己看吧，有时候测试妹子都会欣慰的说可以直接拿我的目录来做测试用例纲要了（才不是为了讨好妹子呢！虽然我在男人很多的IT公司！╭(╯^╰)╮）

另外如果是一个庞大的功能模块设计，也要考虑 80/20原则。

入口是否可以合理、对用户来说是可预见的，是否有可控的出口。如果牵扯到一些运营的需求会产生激烈的讨论，一边设计师会认为“这个功能不是强需求，要弱化，要不打扰，不能影响用户”，另一边产品运营人员会认为“广告不做大点流量（qian）怎么来！！你养我？！！）

设计师总是要在用户感受与商业需求中做“痛苦的抉择”，但这已经是常态，毕竟我也得吃饭泡妞不是 ：P。如果做出值得称赞的平衡（看我又说到平衡了），就是设计师的功力所在了。

流程是否顺畅、完整、有主次，样式是否统一清晰有认知度，反馈是否合情合理，意外情况处理是否完善都是工作中反复考虑的点。

能在完成一个合理方案基础上，做出给用户超出预期的感受就更好了，有时间的话（不只是你的时间，还包括研发GG的时间），可以尝试一些进阶的情感化的尝试。这个社会，大家都讲“走心”，只有直接命中人们内心情感的G点，才能获得喜爱（与转发），就跟一本枯燥的文言文字典一样，即使它再全面再沉淀着多少知识，都不如一本有错字的小黄书受大众喜爱（警察叔叔就是他！）。

作者：Ruxth；via：简书