设计需求又被改?这3个方法可帮你预防它的发生
来源:优设网 浏览数:
责任编辑:CHH 时间:2016-08-24 08:31
责任编辑:CHH 时间:2016-08-24 08:31
[导读]改需求」一直是设计和开发们容易深恶痛绝的事情,虽然有时候这确实是需求方没想清楚的锅,但作为用户体验设计师的我们,也许还可以多做一些事情,来更好地预防和减少这类情况
最近又一次遇到在眼见可以将辛苦设计和评审修改完毕的交互文档交付视觉的时候,突然发生了需求变动,方案面临重设计的状况。「改需求」一直是设计和开发们容易深恶痛绝的事情,虽然有时候这确实是需求方没想清楚的锅,但作为用户体验设计师的我们,也许还可以多做一些事情,来更好地预防和减少这类情况的发生。
培养战略思维
对于一些用户体验设计师来说,能够在和业务方沟通确认后说清楚当前需求对应的产品业务目标、还原用户场景、推导出设计目标再思考方案是前期基本功,做到并不困难;但如果涉及到产品的长期方向、核心差异化竞争力等非纯粹用户体验层面的思考,他们就会变得支支吾吾,或只会转述上游 PD 们给出的答案,而缺乏自己的主见。
战略层的思考意识缺乏会让我们只能看到和应对短期的需求,而难以从更长远、全局的角度思考产品设计。当 PD 们判断出现失误、方向偏差越来越大时,我们却在浑然不觉地继续执行他们的需求,当失误中途被某个大 Boss 发现叫停时,设计方案已经基本完成,最后不得不推倒重来。
当我们接到需求设计产品的时候,除了从用户体验的角度思考和给出建议,也要有从业务/商业角度思考和追问的意识:这个产品在未来 1-3 年内会是怎样的形态?核心竞争力和差异化亮点是什么?这个短期需求是否能和长远业务目标契合?这个需求的设计投入/产出比是否合理?在整体的业务产品链路地图中处于怎样的位置?在和业务方沟通确认需求的过程中,也要敢于连续追问几个「为什么」,而不是得到一个表层的答案就满足。
不过早陷入细节
诚然,对体验细节的关注和极致追求是设计师的重要素质,细节说明清晰完整的标注文档也是帮助设计师更好赢得开发信任的重要助力。但设计师同样需要判断准介入细节设计的合适时机,过早陷入细节会有更大的被全盘推翻的风险,造成更强的挫败感。
作为一个完美主义者,我有时会习惯性画出高精度设计文档后,再去和业务方沟通确认一些自己的疑问和创想,在这个过程中会发现一些之前没意识到的非普通文案、设计细节的问题,造成整个模块都需要推翻重来,而与此对应的一些细节设计考虑和表达也化为乌有,耗费了多余的设计成本。
回想起来,我和业务方的沟通确认过程应该是缺失了一个中间环节,我的模式是 Prd 评审前后一次(纯语言、文本式交流)、高精度交互文档完成前后一次(基于设计稿甚至高保真可交互 Demo 演示),前者会因为图形化表达缺乏导致一些环节的理解表达不到位、事后才发现不对劲,而后者会有更大的修改成本、不得不修改时自己的抵触情绪也更强。如果中途能多借助白板、便签纸、手绘线框等低精度的图形化表达工具来辅助思考、发现疑问、沟通确认,把疑问争议都确认得差不多了再投入高精度细节设计(当然,在实际中可能会面临设计 – 正式评审周期紧张,业务方除了评审很难抽出时间之类的情况,未必能如此理想地进行),也许就不用频繁陷入「抠完细节最后发现全部白抠了」的尴尬境地。
必要的强势
有些时候,业务方对于设计的具体完成周期会缺乏清晰的认知,觉得设计师只需要花费很少的时间就能解决,需求改了也不会增加太多的时间成本,但真实情况未必如此。这时候,必要的解释说明和强势坚守时间底限(包括向上级求助争取)就更加重要。
之前绩效访谈时也和老大聊到过这样的事情,当时的情况是业务方的需求很紧急,三天内必须确定方案,而我的应对方案是尽量提升自己的设计效率,压缩内审时间,适当加班等,然后被挑战:下一次给的期限变成两天了怎么办?
这一点我觉得开发同学普遍做得比我要好,他们能很明确地告知业务方需求变更的时间成本,让对方清楚意识到这不是随便改一改就能应对的事情。面对不合理需求不敢主动争取,而是随意压榨自己的设计时间,不仅会让自己疲于奔命,设计质量也会变得更难以保障,最终影响到的还是我们自己的信用。
作者:@窒息红Leon
TAGS:设计
培养战略思维
对于一些用户体验设计师来说,能够在和业务方沟通确认后说清楚当前需求对应的产品业务目标、还原用户场景、推导出设计目标再思考方案是前期基本功,做到并不困难;但如果涉及到产品的长期方向、核心差异化竞争力等非纯粹用户体验层面的思考,他们就会变得支支吾吾,或只会转述上游 PD 们给出的答案,而缺乏自己的主见。
战略层的思考意识缺乏会让我们只能看到和应对短期的需求,而难以从更长远、全局的角度思考产品设计。当 PD 们判断出现失误、方向偏差越来越大时,我们却在浑然不觉地继续执行他们的需求,当失误中途被某个大 Boss 发现叫停时,设计方案已经基本完成,最后不得不推倒重来。
当我们接到需求设计产品的时候,除了从用户体验的角度思考和给出建议,也要有从业务/商业角度思考和追问的意识:这个产品在未来 1-3 年内会是怎样的形态?核心竞争力和差异化亮点是什么?这个短期需求是否能和长远业务目标契合?这个需求的设计投入/产出比是否合理?在整体的业务产品链路地图中处于怎样的位置?在和业务方沟通确认需求的过程中,也要敢于连续追问几个「为什么」,而不是得到一个表层的答案就满足。

诚然,对体验细节的关注和极致追求是设计师的重要素质,细节说明清晰完整的标注文档也是帮助设计师更好赢得开发信任的重要助力。但设计师同样需要判断准介入细节设计的合适时机,过早陷入细节会有更大的被全盘推翻的风险,造成更强的挫败感。
作为一个完美主义者,我有时会习惯性画出高精度设计文档后,再去和业务方沟通确认一些自己的疑问和创想,在这个过程中会发现一些之前没意识到的非普通文案、设计细节的问题,造成整个模块都需要推翻重来,而与此对应的一些细节设计考虑和表达也化为乌有,耗费了多余的设计成本。
回想起来,我和业务方的沟通确认过程应该是缺失了一个中间环节,我的模式是 Prd 评审前后一次(纯语言、文本式交流)、高精度交互文档完成前后一次(基于设计稿甚至高保真可交互 Demo 演示),前者会因为图形化表达缺乏导致一些环节的理解表达不到位、事后才发现不对劲,而后者会有更大的修改成本、不得不修改时自己的抵触情绪也更强。如果中途能多借助白板、便签纸、手绘线框等低精度的图形化表达工具来辅助思考、发现疑问、沟通确认,把疑问争议都确认得差不多了再投入高精度细节设计(当然,在实际中可能会面临设计 – 正式评审周期紧张,业务方除了评审很难抽出时间之类的情况,未必能如此理想地进行),也许就不用频繁陷入「抠完细节最后发现全部白抠了」的尴尬境地。
必要的强势
有些时候,业务方对于设计的具体完成周期会缺乏清晰的认知,觉得设计师只需要花费很少的时间就能解决,需求改了也不会增加太多的时间成本,但真实情况未必如此。这时候,必要的解释说明和强势坚守时间底限(包括向上级求助争取)就更加重要。

之前绩效访谈时也和老大聊到过这样的事情,当时的情况是业务方的需求很紧急,三天内必须确定方案,而我的应对方案是尽量提升自己的设计效率,压缩内审时间,适当加班等,然后被挑战:下一次给的期限变成两天了怎么办?
这一点我觉得开发同学普遍做得比我要好,他们能很明确地告知业务方需求变更的时间成本,让对方清楚意识到这不是随便改一改就能应对的事情。面对不合理需求不敢主动争取,而是随意压榨自己的设计时间,不仅会让自己疲于奔命,设计质量也会变得更难以保障,最终影响到的还是我们自己的信用。
作者:@窒息红Leon
免责声明:本文仅代表作者个人观点,与纳金网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
相关阅读
- 人工智能快讯:微软2024年10月23日
- 阿里云开源AI应用开发2024年10月23日
- 如何将阿里云服务器2024年10月23日
- 衡阳师范获省计算机2024年10月16日
- 杭州文三3D打印创意设2024年10月10日
- 苏州点铁工业设计申2024年10月10日
- 2024年度中国皮革行业2024年10月10日
- 2024年世界:人工智能2024年10月10日
- 2024年湖南省“工业设2024年10月10日
- 快讯:福建旅游产品2024年10月10日
精采专题
热门文章
最新文章