设计师进阶，从需求开始

很多人认为，设计师的工作只是视觉层面的输出，照着原型出设计稿，就算大功告成。其实不然，他们所说的只是最最最最最基础的表面内容，实则并没有那么简单。

除结果以外，更重要的是在工作中的产出过程。需求的开始和结束，包括需求的背景、解决方案等。这不仅仅只有PM才完成的工作，设计师也占其中一部分。如果缺少了这样一个过程，设计出来的只是一个没有情感、没有体验，甚至不人性化的工具而已。

-

•   需求评审前，不可缺少的准备 
  

在需求评审前，设计师也需要参与到其中，不要等到需求完全确定了，设计才开始介入。一些不合理的需求，应该从一开始就规避，时间成本也不会太大，并且对一个产品的整体性更清楚，也更有把握。

可以先找PM要一份需求文档，从头到尾梳理一遍，作为简单了解。对于不理解的内容，自己可以先记下来。如果是改版需求，就要先了解线上的整体逻辑。这样才能够真正的了解需求，解决用户问题。

至少整体逻辑和思路要清晰，这样在会议上才能够跟的上大家的节奏，甚至可以提出有建设性的建议，不至于在坐在那里成为一个可有可无的角色。

-

•   需求评审中，需要做的事  

敢于提出自己的问题

在需求会过程中，把自己前期记录的问题，或者会议上功能点不清楚、功能本身逻辑不完整等，都要提出来，不要用自己脑补的方式来理解需求。一般情况下，设计师与PM的理解往往不是一回事。

不要觉得不好意思，如果有问题不搞清楚，后期就有可能出现问题，甚至造成用户流失。如果自己有更好的解决方案就要大胆提出来，大家一起讨论，此刻就是增加自己曝光时刻。当然解决方案是通过深思熟虑过，而不是心血来潮。

如果遇到自己觉得需求有问题，但又不知道具体问题出在哪，无法讲清楚的，也没有更好的方案。这种情况，可以等到会议结束，自己重新梳理一遍，或者询问PM，有时不一定是PM的问题，可能是自己对需求理解不深。

不轻易打断别人的讲解

会议中可能会遇到一些突发情况，有些人听到不明白的，会马上打断其讲话，并问清楚。但很有可能他正要讲，就被打断了。这种不恰当的时机不仅打断了他的思路，也会打断其他人的思路。 

所以，可以耐心听完一个需求后，再提出自己的疑问。

-

•   需求评审后，确认的事  

再次梳理需求

评审过后，设计师需要按照自己的理解重新把需求梳理一遍，可以用思维脑图、草图等，方法因人而异，确保自己真正理解需求。如果遇到新的问题，可以约PM时间，再过一遍。

需求排期

最后，要清楚这个需求后续是怎么安排，包括开发所预估时间、上线时间等。而且要对照自己目前手里正在进行中的工作内容。如果需求着急上线，需要调整时间的，具体可以与PM和开发沟通。

尽量确定在可控范围内完成设计，清楚需求的优先级很重要，是否需要分批进行。时间紧迫的时候，可协商有的需求内容移到下一期迭代。当然，还是需要把精力全部放在确定好的当前需求上面。

-

•   最后  

设计师一直都是相对被动的一方，提前了解产品需求是重要的其中一步，那么被动转主动时，就是改变的开始。

当慢慢用自己的主动和设计能力与PM、开发建立彼此信任时，就是发挥自己设计影响力的时候了。