盐料 | 聊聊需求评审，你要做的事
设计师的工作职责不只在最后输出的美观，同样重要的是产出的过程。不要让设计是断层的，它应该是完整的，有开始，有结束。
很多人把设计师的工作单纯的定位为【视觉】层面的输出，好像只要设计稿美美地就大功告成了。但是，我们都知道，其实不是这么简单。
设计师的工作职责不只在最后输出的美观，同样重要的是产出的过程。需求的产生，需求的背景，需求的解决方案等等。不要让设计是断层的，它应该是完整的，有开始，有结束。
设计的前期，PM一般会拉个需求评审会，这时设计师也需要参与到其中，不要等到需求完全确定了，设计才开始介入。有些不合理的需求，应该从一开始就规避。如果PM没有这个习惯，你可以温柔地建议他拉你一起。设计师要在产品的开始和结束都渗透在其中，这样你才能对一个产品整体性更清楚，也更有把握。
需求评审是一件比较费力费时的事情，所以在确定需求评审时间后，可以先请PM给你一份需求文档，可以先简单的了解，对于不理解的概念，可以提前自己弄清楚，这样也可以避免在评审会中提出太过初级的问题。如果是对现有产品的改版，可以先了解产品线上页面是怎么样的，这样也可以更了解需求，也对PM提出的解决方案是否真的解决用户的问题，有进一步的了解。
我想，这样的准备工作是需要的，不要一脸茫然的参加评审会，你不需要完全明白，但是至少你要大概了解评审会要评审什么内容。这样大家在聊需求时，你也快速接上他们的频率，不要让他们觉得你什么都不懂，也给不出什么建议，也不提出任何疑问，你只是角落里那个“安静的美男子”，这样你就变成可有可无的角色了。
我们都在谈“设计师如何掌握话语权”，我想提前了解产品需求会是重要的一步。天下武功唯快不破，设计亦然，当你比别人快一步时，被动转主动时，就是改变的开始。这是一个好的开始，也是与PM、开发们建立关系的开始，当你慢慢用自己的主动和设计能力建立彼此的信任时，他们会愿意来咨询你的意见，而不是只当你是一画图的，而这时就是你发挥你设计影响力的时候了。
还有一点，提前预备你的时间，检查你的行程表，避免会议冲突。
需求评审的初审到确定方案，可能需要2-3轮评审讨论。在这当中，如果你有什么疑问，都要提出来。或许是功能点PM没有写清楚，或许是功能本身的不完整，或许单纯地就是你不明白。需要补充的让PM补充清楚，不要靠自己脑补来理解需求，大部分情况下设计师与PM理解的，都不是同一件事。
不要觉得不好意思，就不说出你的疑惑，很有可能你疑惑的地方，也会造成用户的疑惑。不懂就问，是一件很重要的事，这会关系到后续设计稿的输出方向以及交互说明的补充。如果你自己都不明白，你要如何确保你的设计能让用户明白。
如果当下你觉得PM提出的解决方案是不合理的或者有更好方案，可以直接说出来，不要埋藏在心中。说出来，大家一起讨论，这就是你增加曝光的时刻。不管结果是否被采纳，你都是双赢。为什么这么说？如果被采纳，这无疑是好的，可以让你的团队更加信赖你，如果你刚入职或者是加入一个新的项目组，这都是一个建立关系的好的表现。那如果后来证明，你的方案有问题呢。其实这也是件好事，至少可以发现在对产品理解中是存在你所不知道的gap， 所以你需要加强逻辑的严谨性和对产品的理解。
我不知道你有没有碰到过，你觉得这个需求有点怪，有点不符合用户的使用习惯，或者你觉得PM的解决方案让你觉得就是有不妥，但是当下你无法讲清楚，也没有更好的方案
如果是这种情况，我建议先等等。你可以等会议结束，自己再梳理一遍，不懂再问下PM，把需求理清楚。有时候出现这种问题，不一定是PM的问题，可能是对需求的理解错了，或者你根本不理解他在说什么。
对于不懂的是要提出来，但是如果你自己也讲不清楚你不清楚的到底是什么问题，那就先不要问。我想问一个问题前，你要先能清晰的表述这个问题。
会议中，可能会比较尴尬的碰到一种情况，就是一听到不懂的，马上反馈要PM解释，但是可能他正要讲或者他稍后会讲清楚。但是你不恰当的问题则会打断他的思路，也同样打断其他人的思路。
所以，强烈建议在PM讲完一个需求后，再提出你的疑问。
我相信大部分PM都会提供比较完整的需求文档，但是也无法完全避免会有缺胳膊少腿的文档。比如状态的枚举是不完整的，没有考虑到异常情况，权限问题等等，这都需要PM补充完整，因为这些都会关系到你的交互说明要如何写清楚，也避免开发同学到最后开发时，还要和PM确认有哪些状态。
需求文档写清楚，是一件很重要的事情。虽然大部分情况下，我们都相信，我们能记住，但是事实上我们都会忘记，而且这样也方便后期回溯和复盘。所以，请拒绝PM简单粗暴的需求文档。如果是需求的内容就应该写在文档里，已经砍掉的功能就不要写在文档里，避免文档过于臃肿，也会造成误解。
需求文档至少要写清楚需求背景、目标人群、使用场景、要解决的问题是什么以及解决方案。
既然做需求，就要清清楚楚，明明白白，杜绝糊里糊涂接需求。
需求评审的最后，要清楚PM对这个的需求的排期是怎么安排。而且你要对照你手上其他需求的排期，要做轻重缓急的权衡。如果是需要调整的需求，则需要与需求的业务方说好。
时间很重要，要确定你真的可以在这个时间点内完成。
要确认需求的优先级是什么，是不是在这期的迭代全部完成。对于比较重工作量的需求，很有可能会分批进行，所以也要清楚第一期是设计哪些页面。而那些会归纳在第二期、第三期的可以先放放。后面是否需求有变动，都是不可预知的，要把精力放在这期要做的需求上面。
需求评审时，是PM按他的理解在讲解需求。所以评审结束后，设计师要按自己的理解重新梳理一遍，方法不限，可以是画草图，可以是用思维脑图，主要是让你真的理解需求，而不是一知半懂。
其实评审时，要完全理解需求，还是有一定难度的，因为你的思路基本上都是跟着PM走，有时候好像当下理解了，但是自己梳理时，又发现新的问题，这其实也是正常的，可以和PM再约下时间，对下需求。
这个问题是不是很奇怪。但是在众多的需求中，有一些需求其实在前期不一定要设计师来介入。比如一个不是很完整的产品，功能大部分都没确定，前期可能就一两个页面。而这个页面可能就是一个列表，一个详情页，这样的页面，前端完全可以自己搭建起来。设计师可以等产品功能更加完整了再介入设计，至少是一个产品，而不是一两个页面。
设计师也需要优化资源，投入到更需要设计的产品当中。当然如果公司本身也没什么产品，你也很闲，和PM关系也很和谐，也不会占你太多时间，你也可以不考虑这个问题，哈哈。
对于需求评审，有些设计师总是有莫名的抗拒，不是很愿意参与前期的评审，觉得PM和开发在讨论的事情，自己也听不懂，在会议里面就是从头坐到尾，挺无聊的。还不如讨论完，直接告诉她要改的是什么。如果你是初级设计师，这属于可以理解的范围，但是如果你想往上发展，你就要往前走。
其实不懂，说明你不够理解产品，所以这不是他们的问题。
设计师要参加评审会其中一个原因是，你可以在设计前就干掉那些不需要做的需求。有时候有些需求，不一定要靠设计解决，也可以完全靠技术手段解决。
比如因为某些不可说明的技术原因，在页面上要放一个很突兀的刷新按钮，让用户手动刷新页面，但其实对用户来说，是多做一步。那为什么会产生这个的需求的原因可能是，这个数据不是当前平台的，是从第三方平台获取过来的，而第三方平台因为某些原因无法与当前平台做到数据实时互通。而类似这种问题，其实就要考虑开发同学用技术去解决，而不是把问题留给用户。
需求评审，其实不可怕，真的。
