设计的过程是需要积累的，我们都要学会沉淀，尽可能的将这些设计流程转换成一道工序，也许这是不完善的，但一定是最适合自己的。
随着手头项目的增多，对接的需求方也总是五花八门，各有秋千。有的跟你谈需求能细致到让你毫无发挥的余地，似乎你就只能做个画图的了。有的简单到只有一句话，例如“你帮我把这个页面优化一下”
但是不管是哪类需求方，他们大都容易站在他们的思考方式上去给你讲解这个需求，往往说出来的内容，不一定就是你想要的内容，而且有时候会把你带偏。更离谱的就是，有的需求方甚至自己都还没有对需求进行的一定的分析，只是听到领导提了，就跟着提了。通常碰到这一系列的需求方，你一定要有个清晰的讨论思路，在这个数据爆棚的时代，往往我们需要的是对信息做减法和分类，而不是成为收纳盒，要明确自己是想在需求方获取些什么信息，哪类信息能帮助你快速理解需求？
通常我都会从以下几点来提问（个人见解）：
用户使用场景（让需求以新手用户的场景来说明）
用户使用平台（手机、电脑、ipad、电视等等）
最终要达到的目的
用户使用场景
其实梳理用户使用场景，是了解需求最快捷也是最直接的方式，其实就是相当于用户旅程图。为什么这么说呢？因为只有成为一个真正的用户，去实际操作，才能明白真正的痛点。而且在这过程中，你会发现真正造成这个痛点的地方可能不仅仅是只有需求方提到的那一个，还有更多的潜在原因。
不知道各位有没有发现，往往需求方来找我们的时候，其实有的不仅将需求提出，还顺带附赠了解决方案，这种解决方案往往就是抄袭业界竞品。通常这种“指导性”需求，导致的结果就是，我们又变成了“线框小子”。所以我们要跳出这个框架，不要过多的被需求方限制住，上来就直接问需求具体场景怎么跑，自己去把问题找出来并想出解决方案。
在上述提到需要让需求方以新手用户的身份来对我们进行场景说明，是为了让自己的交互设计更具有可用性和易学性。毕竟一些需求的提出，就很可能意味着交互形式或者是功能上有新增，这样一来，用户是需要一定的学习成本的。在梳理场景的时候就能把这些一起考虑进去的话，对后续画稿具有一定的引导性。
用户使用平台
在跑完用户旅程图以后，你应该要明确下你所设计的界面将会在哪些平台上展现，这个在后续做交互设计的时候，你能很明确的知道应该用多大的画布来设计，设计上应该遵循哪类平台的交互方式。因为不同平台之间的交互方式是存在一定差异的，如mac电脑的弹窗是左边取消，右边确定。而windows的弹窗则是左边确定，右边取消。
其实在梳理用户使用场景的过程中，你大概就能知道自己所需设计的界面是在哪个平台上展现，但是之所以后面还需要再次确认的原因有两点，一是为了保证两边信息是一致的，二是在了解各个平台的过程中，你可以跟需求发掘一些潜在的平台，也就是可能当下不会在这个平台下做设计，但后续很有可能会在新平台下使用，那么我在做设计的时候也会同步考虑一下可拓展性。
最终要达到的目的
这个目的指的就是结果，你需求最终要获得的结果。举个例子，以前在做视频会议的时候，曾经有用户反馈,视频会议界面的“静音”和“扬声器”这两个图标让我感觉不出来当前状态 ，于是需求方跑来跟我说希望优化一下图标，用户期望的是希望能感知当前“静音”和“扬声器”的状态是什么。
那么你会不会就理解为“优化图标，让用户能感受到当前状态就是最终的目的呢？然而并不完全如此，其实这个视频会议优化图标的最终目的是为了让用户能愉快的使用视频会议这个功能。当时我奔着这个目的去优化时才发现，让用户无法感知当前状态的真正原因在于点击扬声器的过程中视频性能上没有给予相应的反馈,使得用户不得不通过图标去获得信息。 当时“静音”和“扬声器”这两个功能的视觉是参照业界微信和QQ的样式去设计，并没有用户在使用微信或者QQ的视频会议时反馈这个问题。
我们时常会抱怨需求方的不专业，但是否有从自己身上去寻找问题。到底是什么原因导致双方花了那么多的时间在讨论需求上，出来的结果却总是不尽人意。假设从一开始我就清楚自己需要什么的话，那在沟通的时候是否就能直奔主题，做出一份让双方都满意的设计稿。我们每天都在做设计，但如果别人问起，你都是如何做设计的，那你是否又能答得上来呢。说到底，设计的过程是需要积累的，我们都要学会沉淀，尽可能的将这些设计流程转换成一道工序，也许这是不完善的，但一定是最适合自己的。
