最近又一次遇到在眼见可以将辛苦设计和评审修改完毕的交互文档交付视觉的时候，突然发生了需求变动，方案面临重设计的状况。「改需求」一直是设计和 开发们容易深恶痛绝的事情，虽然有时候这确实是需求方没想清楚的锅，但作为用户体验设计师的我们，也许还可以多做一些事情，来更好地预防和减少这类情况的 发生。

培养战略思维

对于一些用户体验设计师来说，能够在和业务方沟通确认后说清楚当前需求对应的产品业务目标、还原用户场景、推导出设计目标再思考方案是前期基本功， 做到并不困难；但如果涉及到产品的长期方向、核心差异化竞争力等非纯粹用户体验层面的思考，他们就会变得支支吾吾，或只会转述上游 PD 们给出的答案，而缺乏自己的主见。

战略层的思考意识缺乏会让我们只能看到和应对短期的需求，而难以从更长远、全局的角度思考产品设计。当 PD 们判断出现失误、方向偏差越来越大时，我们却在浑然不觉地继续执行他们的需求，当失误中途被某个大 Boss 发现叫停时，设计方案已经基本完成，最后不得不推倒重来。

当我们接到需求设计产品的时候，除了从用户体验的角度思考和给出建议，也要有从业务/商业角度思考和追问的意识：这个产品在未来 1-3 年内会是怎样的形态？核心竞争力和差异化亮点是什么？这个短期需求是否能和长远业务目标契合？这个需求的设计投入/产出比是否合理？在整体的业务产品链路 地图中处于怎样的位置？在和业务方沟通确认需求的过程中，也要敢于连续追问几个「为什么」，而不是得到一个表层的答案就满足。

虽然这次我在完成交互设计后被大 Boss 将需求喊停，但对于对方给出的理由还是服气的，比如投入/产出比过高，耗费很大的设计开发成本但实际场景中用到的频率太低；可以结合长期一点的产品整体信 息架构优化综合考虑入口设计，而不是生硬地在隐蔽的二级菜单里添加一个模块等。为什么这些问题我发现不了，或者萌生过相似想法但没底气去说服业务方？大概 是对产品战略层的思考理解还不够透彻吧。

不过早陷入细节

诚然，对体验细节的关注和极致追求是设计师的重要素质，细节说明清晰完整的标注文档也是帮助设计师更好赢得开发信任的重要助力。但设计师同样需要判断准介入细节设计的合适时机，过早陷入细节会有更大的被全盘推翻的风险，造成更强的挫败感。

作为一个完美主义者，我有时会习惯性画出高精度设计文档后，再去和业务方沟通确认一些自己的疑问和创想，在这个过程中会发现一些之前没意识到的非普 通文案、设计细节的问题，造成整个模块都需要推翻重来，而与此对应的一些细节设计考虑和表达也化为乌有，耗费了多余的设计成本。

回想起来，我和业务方的沟通确认过程应该是缺失了一个中间环节，我的模式是 Prd 评审前后一次（纯语言、文本式交流）、高精度交互文档完成前后一次（基于设计稿甚至高保真可交互 Demo 演示），前者会因为图形化表达缺乏导致一些环节的理解表达不到位、事后才发现不对劲，而后者会有更大的修改成本、不得不修改时自己的抵触情绪也更强。如果 中途能多借助白板、便签纸、手绘线框等低精度的图形化表达工具来辅助思考、发现疑问、沟通确认，把疑问争议都确认得差不多了再投入高精度细节设计（当然， 在实际中可能会面临设计 – 正式评审周期紧张，业务方除了评审很难抽出时间之类的情况，未必能如此理想地进行），也许就不用频繁陷入「抠完细节最后发现全部白抠了」的尴尬境地。

必要的强势

有些时候，业务方对于设计的具体完成周期会缺乏清晰的认知，觉得设计师只需要花费很少的时间就能解决，需求改了也不会增加太多的时间成本，但真实情况未必如此。这时候，必要的解释说明和强势坚守时间底限（包括向上级求助争取）就更加重要。

之前绩效访谈时也和老大聊到过这样的事情，当时的情况是业务方的需求很紧急，三天内必须确定方案，而我的应对方案是尽量提升自己的设计效率，压缩内审时间，适当加班等，然后被挑战：下一次给的期限变成两天了怎么办？

这一点我觉得开发同学普遍做得比我要好，他们能很明确地告知业务方需求变更的时间成本，让对方清楚意识到这不是随便改一改就能应对的事情。面对不合 理需求不敢主动争取，而是随意压榨自己的设计时间，不仅会让自己疲于奔命，设计质量也会变得更难以保障，最终影响到的还是我们自己的信用。

原文来自：优设

作者：鸿影