江苏龙网

  1. 首页 > 资讯 > 科技 > >

设计师|参加需求评审，设计师需要注意这几个问题( 二 )


2. 记下你觉得有疑问的地方 ， 但是一时说不清楚
我不知道你有没有碰到过 ， 你觉得这个需求有点怪 ， 有点不符合用户的使用习惯 ， 或者你觉得PM的解决方案让你觉得就是有不妥 ， 但是当下你无法讲清楚 ， 也没有更好的方案
如果是这种情况 ， 我建议先等等 。你可以等会议结束 ， 自己再梳理一遍 ， 不懂再问下PM ， 把需求理清楚 。有时候出现这种问题 ， 不一定是PM的问题 ， 可能是对需求的理解错了 ， 或者你根本不理解他在说什么 。
对于不懂的是要提出来 ， 但是如果你自己也讲不清楚你不清楚的到底是什么问题 ， 那就先不要问 。我想问一个问题前 ， 你要先能清晰的表述这个问题 。
3. 不要轻易打断PM的需求讲解
会议中 ， 可能会比较尴尬的碰到一种情况 ， 就是一听到不懂的 ， 马上反馈要PM解释 ， 但是可能他正要讲或者他稍后会讲清楚 。但是你不恰当的问题则会打断他的思路 ， 也同样打断其他人的思路 。
所以 ， 强烈建议在PM讲完一个需求后 ， 再提出你的疑问 。
4. 需求文档不完整的 ， 要让PM补充清楚
我相信大部分PM都会提供比较完整的需求文档 ， 但是也无法完全避免会有缺胳膊少腿的文档 。比如状态的枚举是不完整的 ， 没有考虑到异常情况 ， 权限问题等等 ， 这都需要PM补充完整 ， 因为这些都会关系到你的交互说明要如何写清楚 ， 也避免开发同学到最后开发时 ， 还要和PM确认有哪些状态 。
需求文档写清楚 ， 是一件很重要的事情 。虽然大部分情况下 ， 我们都相信 ， 我们能记住 ， 但是事实上我们都会忘记 ， 而且这样也方便后期回溯和复盘 。所以 ， 请拒绝PM简单粗暴的需求文档 。如果是需求的内容就应该写在文档里 ， 已经砍掉的功能就不要写在文档里 ， 避免文档过于臃肿 ， 也会造成误解 。
需求文档至少要写清楚需求背景、目标人群、使用场景、要解决的问题是什么以及解决方案 。
既然做需求 ， 就要清清楚楚 ， 明明白白 ， 杜绝糊里糊涂接需求 。
5. 清楚需求计划 ， 需求排期
需求评审的最后 ， 要清楚PM对这个的需求的排期是怎么安排 。而且你要对照你手上其他需求的排期 ， 要做轻重缓急的权衡 。如果是需要调整的需求 ， 则需要与需求的业务方说好 。
时间很重要 ， 要确定你真的可以在这个时间点内完成 。
要确认需求的优先级是什么 ， 是不是在这期的迭代全部完成 。对于比较重工作量的需求 ， 很有可能会分批进行 ， 所以也要清楚第一期是设计哪些页面 。而那些会归纳在第二期、第三期的可以先放放 。后面是否需求有变动 ， 都是不可预知的 ， 要把精力放在这期要做的需求上面 。
03 需求评审后：需要确认的事1. 重新梳理需求
需求评审时 ， 是PM按他的理解在讲解需求 。所以评审结束后 ， 设计师要按自己的理解重新梳理一遍 ， 方法不限 ， 可以是画草图 ， 可以是用思维脑图 ， 主要是让你真的理解需求 ， 而不是一知半懂 。
其实评审时 ， 要完全理解需求 ， 还是有一定难度的 ， 因为你的思路基本上都是跟着PM走 ， 有时候好像当下理解了 ， 但是自己梳理时 ， 又发现新的问题 ， 这其实也是正常的 ， 可以和PM再约下时间 ， 对下需求 。
2. 需求 ， 是否真的需要设计师介入
这个问题是不是很奇怪 。但是在众多的需求中 ， 有一些需求其实在前期不一定要设计师来介入 。比如一个不是很完整的产品 ， 功能大部分都没确定 ， 前期可能就一两个页面 。而这个页面可能就是一个列表 ， 一个详情页 ， 这样的页面 ， 前端完全可以自己搭建起来 。设计师可以等产品功能更加完整了再介入设计 ， 至少是一个产品 ， 而不是一两个页面 。
设计师也需要优化资源 ， 投入到更需要设计的产品当中 。当然如果公司本身也没什么产品 ， 你也很闲 ， 和PM关系也很和谐 ， 也不会占你太多时间 ， 你也可以不考虑这个问题 ， 哈哈 。


推荐阅读


上一篇：|100%真全面屏 全球首款屏下摄像头手机官宣

下一篇：黑科技|厉害的何止5G，OPPO亮出黑科技，比Wi-Fi快100倍