设计需求评审制度

引入需求评级能提升优秀需求的涌现，减少低品质的资源浪费，还能提升专业能力判断的准确性，是一个多方共赢的制度。

背景

过去工作中我们经常遇到

平台设计在用户侧，同事侧，老板侧都会时常听到对体验设计的坚持不够，红线标准不明。而很多做出阻拦不合理方案，给出合理建议的需求，事后的复盘也无法量化坚持力度。
因为平台设计base业务线的工作方式导致设计师十分同理又努力的去给一些kpi导向的需求进行兜底和妥协，而最终的上线的项目却没有带来实际收益，同时又严重伤害了产品用户体验。
因为需求建议详细，细节要求高，导致有些设计师不愿主动思考，需要几个方案出几个方案；或者因为过去的表达总被无视，争论容易产生其他麻烦，就也主动放弃表达，不做推荐，事后又说当时口头建议了，我们无从查证。
很多优秀的，大家都很认可的需求，我们只在内审、周会等内部进行了称赞，而对接上下游的时候除了默默支持的需求外，更多声音是提出质疑和否定。久而久之，其他职能容易产生的“对抗情绪”，而没有理解到设计职能也是在努力帮助业务到达目标的共创心理。

5. 因为交互资源的稀缺，而业务有时有出现比较大型，复杂逻辑的需求，base在业务线的单兵设计有些时候无法解决，又不得不硬着头皮解决，就会造成沟通反复，产出逻辑漏洞多的事故。

要求

故而，引入一套设计需求评级的制度，对于以上遇到的情况能有很大幅度的改善。

￮ 需求文档。在需求文档的评论中，给出设计师的评级判断（例：该需求设计评级A，支持。这个需求对于社区氛围教育良好，缩短流程体验佳）

￮ 项目排期表。在自己的项目排期表中添加一列“需求评级”。对B以下的需求在没有做调整的情况下，排期无限延长。（需要提醒和说明）

a. 先检查需求文档的完整性。

i. 如需求不完善，建议需求方做补充。

ii. 如需求完善，但不合理or体验侧有问题进入下一步。

b. 根据规范和过往设计经验判断体验的一致性和合理性。

i. 如需求交互不合理，执行设计给出合理建议 or 请求交互助力小组协助。

ii. 如需求交互合理自洽，但存在明显伤害用户体验，需要主动提出问题进入下一步。

c. 与业务需求方讨论，，尝试平衡用户体验和业务目标，达成一致后，给出设计方案。

d. 给出建议方案。举出各自优劣。

e. 可根据最终解法修改需求评级，留档说明。

等级	程度	处理	备注
S	强烈支持	全力支持，加注支持	改善用户体验，交互闭环，逻辑自洽。产品策略鼓舞人心，战略意图明显。
A	支持	全力支持	对体验没有负向影响，功能逻辑清晰 or 目标达成路径清晰
B	中性	正常支持	对体验没有负向影响但功能逻辑存在问题，目标达成路径模糊 or 对体验有一些影响，但目标路径清晰
C	反对	建议优化需求请求协助优化	对体验有负向影响，功能逻辑存在问题，目标路径模糊 or 虽然目标达成路径清晰，对用户体验有严重伤害
D	强烈反对	拦阻，请示产委帮助	对用户体验有严重伤害，且目标达成路径模糊

对评级的判断流程

i.根据原型设计自查表检查需求的完整性。

ii.根据交互设计规范判断体验的一致性和合理性。

附：

原型设计基本原则自查表

针对过去时有碰到的背景情况：

因为交互资源的稀缺，而业务有时有出现比较大型，复杂逻辑的需求，base在业务线的单兵设计有些时候无法解决，又不得不硬着头皮解决，就会造成沟通反复，产出逻辑漏洞多的事故。

在某些业务线设计师无法独自解决复杂逻辑的需求情况下，可以请求平台设计交互助力小组加入项目。

交互助力小队：由 TL 和2名交互和2名ui组成的混编组成体验小组。旨在帮助没有交互参与，但逻辑复杂，亟需改善体验的大中型项目。

目前试运营阶段已经帮助在解决/解决了一些项目：

好友profile 发消息/手机号入口优化 2021.11

中间页-产品规划