参加需求评审,设计师需要注意这几个问题

0 评论 3558 浏览 3 收藏 13 分钟

编辑导读:需求评审会,虽然是产品经理的演讲会,但是与会人员却不是只有产品经理。本文作者从设计师的解读,对设计师参加需求评审需要注意的问题进行了梳理总结,供大家一同参考和学习。

很多人把设计师的工作单纯的定位为【视觉】层面的输出,好像只要设计稿美美地就大功告成了。但是,我们都知道,其实不是这么简单。

设计师的工作职责不只在最后输出的美观,同样重要的是产出的过程。需求的产生,需求的背景,需求的解决方案等等。不要让设计是断层的,它应该是完整的,有开始,有结束。

01 需求评审前,你不可遗漏的准备工作

设计的前期,PM一般会拉个需求评审会,这时设计师也需要参与到其中,不要等到需求完全确定了,设计才开始介入。有些不合理的需求,应该从一开始就规避。如果PM没有这个习惯,你可以温柔地建议他拉你一起。设计师要在产品的开始和结束都渗透在其中,这样你才能对一个产品整体性更清楚,也更有把握。

需求评审是一件比较费力费时的事情,所以在确定需求评审时间后,可以先请PM给你一份需求文档,可以先简单的了解,对于不理解的概念,可以提前自己弄清楚,这样也可以避免在评审会中提出太过初级的问题。如果是对现有产品的改版,可以先了解产品线上页面是怎么样的,这样也可以更了解需求,也对PM提出的解决方案是否真的解决用户的问题,有进一步的了解。

我想,这样的准备工作是需要的,不要一脸茫然的参加评审会,你不需要完全明白,但是至少你要大概了解评审会要评审什么内容。这样大家在聊需求时,你也快速接上他们的频率,不要让他们觉得你什么都不懂,也给不出什么建议,也不提出任何疑问,你只是角落里那个“安静的美男子”,这样你就变成可有可无的角色了。

我们都在谈“设计师如何掌握话语权”,我想提前了解产品需求会是重要的一步。天下武功唯快不破,设计亦然,当你比别人快一步时,被动转主动时,就是改变的开始。这是一个好的开始,也是与PM、开发们建立关系的开始,当你慢慢用自己的主动和设计能力建立彼此的信任时,他们会愿意来咨询你的意见,而不是只当你是一画图的,而这时就是你发挥你设计影响力的时候了。

还有一点,提前预备你的时间,检查你的行程表,避免会议冲突。

02 需求评审中:你要做的事

1. 勇敢提出你的问题

需求评审的初审到确定方案,可能需要2-3轮评审讨论。在这当中,如果你有什么疑问,都要提出来。或许是功能点PM没有写清楚,或许是功能本身的不完整,或许单纯地就是你不明白。需要补充的让PM补充清楚,不要靠自己脑补来理解需求,大部分情况下设计师与PM理解的,都不是同一件事。

不要觉得不好意思,就不说出你的疑惑,很有可能你疑惑的地方,也会造成用户的疑惑。不懂就问,是一件很重要的事,这会关系到后续设计稿的输出方向以及交互说明的补充。如果你自己都不明白,你要如何确保你的设计能让用户明白。

如果当下你觉得PM提出的解决方案是不合理的或者有更好方案,可以直接说出来,不要埋藏在心中。说出来,大家一起讨论,这就是你增加曝光的时刻。不管结果是否被采纳,你都是双赢。为什么这么说?如果被采纳,这无疑是好的,可以让你的团队更加信赖你,如果你刚入职或者是加入一个新的项目组,这都是一个建立关系的好的表现。那如果后来证明,你的方案有问题呢。其实这也是件好事,至少可以发现在对产品理解中是存在你所不知道的gap, 所以你需要加强逻辑的严谨性和对产品的理解。

2. 记下你觉得有疑问的地方,但是一时说不清楚

我不知道你有没有碰到过,你觉得这个需求有点怪,有点不符合用户的使用习惯,或者你觉得PM的解决方案让你觉得就是有不妥,但是当下你无法讲清楚,也没有更好的方案

如果是这种情况,我建议先等等。你可以等会议结束,自己再梳理一遍,不懂再问下PM,把需求理清楚。有时候出现这种问题,不一定是PM的问题,可能是对需求的理解错了,或者你根本不理解他在说什么。

对于不懂的是要提出来,但是如果你自己也讲不清楚你不清楚的到底是什么问题,那就先不要问。我想问一个问题前,你要先能清晰的表述这个问题。

3. 不要轻易打断PM的需求讲解

会议中,可能会比较尴尬的碰到一种情况,就是一听到不懂的,马上反馈要PM解释,但是可能他正要讲或者他稍后会讲清楚。但是你不恰当的问题则会打断他的思路,也同样打断其他人的思路。

所以,强烈建议在PM讲完一个需求后,再提出你的疑问。

4. 需求文档不完整的,要让PM补充清楚

我相信大部分PM都会提供比较完整的需求文档,但是也无法完全避免会有缺胳膊少腿的文档。比如状态的枚举是不完整的,没有考虑到异常情况,权限问题等等,这都需要PM补充完整,因为这些都会关系到你的交互说明要如何写清楚,也避免开发同学到最后开发时,还要和PM确认有哪些状态。

需求文档写清楚,是一件很重要的事情。虽然大部分情况下,我们都相信,我们能记住,但是事实上我们都会忘记,而且这样也方便后期回溯和复盘。所以,请拒绝PM简单粗暴的需求文档。如果是需求的内容就应该写在文档里,已经砍掉的功能就不要写在文档里,避免文档过于臃肿,也会造成误解。

需求文档至少要写清楚需求背景、目标人群、使用场景、要解决的问题是什么以及解决方案。

既然做需求,就要清清楚楚,明明白白,杜绝糊里糊涂接需求。

5. 清楚需求计划,需求排期

需求评审的最后,要清楚PM对这个的需求的排期是怎么安排。而且你要对照你手上其他需求的排期,要做轻重缓急的权衡。如果是需要调整的需求,则需要与需求的业务方说好。

时间很重要,要确定你真的可以在这个时间点内完成。

要确认需求的优先级是什么,是不是在这期的迭代全部完成。对于比较重工作量的需求,很有可能会分批进行,所以也要清楚第一期是设计哪些页面。而那些会归纳在第二期、第三期的可以先放放。后面是否需求有变动,都是不可预知的,要把精力放在这期要做的需求上面。

03 需求评审后:需要确认的事

1. 重新梳理需求

需求评审时,是PM按他的理解在讲解需求。所以评审结束后,设计师要按自己的理解重新梳理一遍,方法不限,可以是画草图,可以是用思维脑图,主要是让你真的理解需求,而不是一知半懂。

其实评审时,要完全理解需求,还是有一定难度的,因为你的思路基本上都是跟着PM走,有时候好像当下理解了,但是自己梳理时,又发现新的问题,这其实也是正常的,可以和PM再约下时间,对下需求。

2. 需求,是否真的需要设计师介入

这个问题是不是很奇怪。但是在众多的需求中,有一些需求其实在前期不一定要设计师来介入。比如一个不是很完整的产品,功能大部分都没确定,前期可能就一两个页面。而这个页面可能就是一个列表,一个详情页,这样的页面,前端完全可以自己搭建起来。设计师可以等产品功能更加完整了再介入设计,至少是一个产品,而不是一两个页面。

设计师也需要优化资源,投入到更需要设计的产品当中。当然如果公司本身也没什么产品,你也很闲,和PM关系也很和谐,也不会占你太多时间,你也可以不考虑这个问题,哈哈。

最后的话

对于需求评审,有些设计师总是有莫名的抗拒,不是很愿意参与前期的评审,觉得PM和开发在讨论的事情,自己也听不懂,在会议里面就是从头坐到尾,挺无聊的。还不如讨论完,直接告诉她要改的是什么。如果你是初级设计师,这属于可以理解的范围,但是如果你想往上发展,你就要往前走。

其实不懂,说明你不够理解产品,所以这不是他们的问题。

设计师要参加评审会其中一个原因是,你可以在设计前就干掉那些不需要做的需求。有时候有些需求,不一定要靠设计解决,也可以完全靠技术手段解决。

比如因为某些不可说明的技术原因,在页面上要放一个很突兀的刷新按钮,让用户手动刷新页面,但其实对用户来说,是多做一步。那为什么会产生这个的需求的原因可能是,这个数据不是当前平台的,是从第三方平台获取过来的,而第三方平台因为某些原因无法与当前平台做到数据实时互通。而类似这种问题,其实就要考虑开发同学用技术去解决,而不是把问题留给用户。

需求评审,其实不可怕,真的。

 

本文由@箴盐设计  原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!