第一点：确认你所理解的需求是否正确

一千个人的眼中，就有一千个哈姆雷特。对于需求的理解也是一样，我们拿到需求以后，要和产品经理进行沟通，将自己对需求的理解与简单的页面构思，阐述给产品经理，以确定自己的理解与设计方向是否准确。切忌，拿到需求就开工去做，以为可以节省时间，却不知错误的理解和方向，让你付出更多。

不要认为，产品经理给的需求就像数学定理一样可以深入理解，详细解读，没有那么多的产品经理有这个功夫和能力去做这个事情。因此，沟通才是保证你对需求的理解，对设计方向正确把握的基石。

那么，在需求交流之前你要准备好什么呢？第一，认真研究需求，理解需求；第二，是你在研究需求时，发现的问题，最好整理出来，以便在讨论时提出，让产品经理为你解答，而不是自己”以为“；第三，如果时间充足，最好整理出界面的框架，或者用草图来展示你的设计思路，看产品经理是否认可你的设计。

对于讨论中形成的共识，最好以邮件的形式发出，一方面可以作为会议纪要，便于随时解答疑惑，另一方面，是立字为证，防止需求的随意变更。

第二点：需求不清楚的要重写或者沟通彻底

在需求文档中，如果存在模糊不清，或者容易引起歧义的地方，要让产品经理重写需求，或者对所提需求进行详细、确定的说明，切忌陷入“自以为是”的陷阱。目的是什么，大家都清楚，就不多说了。

第三点：争取更多的设计时间

设计不是一蹴而就的事情，也不是一直进行的事情。在拿到需求，正确评估设计时间的前提下，争取更多的时间，给自己留出处理突发事件的时间，使得你在整个产品设计过程中保持一种适度的工作强度，不致于手忙脚乱。切忌随意评估设计时间，不仅耽误开发，影响产品后续的规划，而且让自己陷入被动的局面。任务提前完成，总比拖延完成要好。

第四点：交互稿的初次评审

对于初稿的评审，过程是痛苦的，因为，你总会听到来自四面八方的批评之声。但鲁迅先生有言：真的猛士，敢于直面惨淡的人生，敢于正视淋漓的鲜血。交互设计稿出来以后，就要进行交互稿的确认以及交互原型的评审。不管怎样，交互原型总是要确认其是否满足产品经理的需求。

在大型公司中，由于人员较多，任务分工较细，一个产品的开发过程会牵涉到不同地方、不同部门的员工，因此面对面的沟通成本较高。一般只会在需求确认、交互稿的评审等关键节点，才以开会的形式进行沟通交流。

评审过程要注意三点：其一，要准确、清晰、大胆的表达自己的设计思路，评审的主题就是来评审你的交互稿，要注意自己的表达；其二，切忌陷入开发讨论。会议是用来评审界面和交互的，如果陷入开发讨论，那你作用又是什么呢？其三，避免过度发散，如果我们总是在会上来提出新想法，然后去讨论其合理性，那就不用等到交互评审的会上来进行了。有什么想法可以在评审结束后，统一表达收集，也可会后邮件发出。这样，交互评审才能顺利进行。

评审中最重要的一点：以邮件形式发出会议纪要及修改意见。若为其他方式沟通修改意见，修改意见也最好以邮件汇总的方式反馈过来。避免扯皮！

第五点：交互稿修改过程中的沟通

交互稿的修改不是一次能完成的。中间会有很多的沟通，沟通最好要保留记录，聊天或者邮件，理由同上！

第六点：邮件发出你的设计终稿

最终的交互设计稿，最好以邮件的方式发出，并根据需求评审和期间的沟通结果，整理出修改目录以及所对应的需求，便于产品经理与开发人员迅速找到交互稿中的变更点，节约时间。同时，也能够避免一定的设计稿的修改。

总之一句话，目标明确的情况下，再开展设计！

本文来源于广州网站建设公司与广州网站设计制作公司-广帆互动广州公司！