在工作中除了完成业务方的需求之外，我们也时不时会发起一些设计驱动的项目，但并不是每一次设计提案都能顺利得到落地。仅仅有想法是没有价值的，如何将想法包装推销出去、说服别人接受、不断收集有效建议进行完善，也是非常重要的一环。

保持阶段目标一致

有些同学可能会遇到这样的烦恼：感觉产品的用户体验这里不好那里不好，可拿着自己改进后的概念稿去找业务方时，却经常碰一鼻子灰，被无限拖延甚至直接否掉。其实很多时候，问题确实客观存在，但是和业务的阶段目标不匹配，需要调用的开发资源却又不低，优先级被降低也情有可原。而建立在阶段目标一致基础上的设计提案，通过的难度相对就要低很多，有时候甚至根本不需要你花费口舌解释一大通缘由，业务方就直接表示了认同。

首先，我们需要主动关注业务动态，在每个季度开始前从业务方处了解清楚接下来几个月要做的主要事情，和事情背后指向的阶段目标，再基于这些阶段目标去寻找设计机会点，而不是盲目进行优化；其次，业务方当初制定的阶段目标并不一定完全合理，如果我们通过用研报告和接触用户等，发现真实用户痛点诉求和阶段目标存在较大出入的话，大可把信息进行同步，协商调整目标；最后，要以良好的心态去看待和接受目标的中途调整和增加，只要它符合产品定位、有利于业务长期发展，但要注意有限时间内目标优先级的分配，不要同时向多个大目标出击最后却顾此失彼。

展现完整推导过程

和设计稿本身相比，前期的各种调研、分析、发散、推导过程同等甚至更加重要，而把这个思考过程完整、有逻辑性地展现给业务方，和直接展示飞机稿相比，可以更有效地获取他们的认可。

以我最近在做的项目为例，过程中的产出物包括但不限于：焦点小组和问卷调研报告（主要是用研同学提供）、全链路用户行为路径地图、用户画像梳理（用户特征、访问场景、用户目标、关键词、痛点等）、故事板（情境化描述用户使用场景和过程中遇到的痛点）、问题分析（用户分布、业务问题及其背后的用户感受、设计机会点挖掘）、设计策略（整体信息组织原则、设计方向洞察、能带来的业务价值、技术辅助实现手段、衡量验证指标等）、全景图、脑暴 & 卡片分类现场照片、思维导图、白板线框等。

这些产出物可以更好地体现我们的思考过程和专业性，但在组织呈现给业务方时需要注意逻辑串联和可读性，推导过程论据充分、环环相扣，描述不过多使用 UX 专业术语，而是大家都能理解的用户语言（简单来讲就是说人话）。

注意商业技术平衡

我们通常习惯从用户视角去思考和提案，但仅仅站在用户视角是远远不够的，也需要在前期的时候就充分考虑和沟通诠释清楚设计方案的商业价值和技术可行性。

设计提案仅仅只是解决已有的用户痛点、满足已有的用户诉求是不够的，虽然这么做肯定是「对」的，但我们还应该思考和回答一些更深层次的问题，比如：它是否符合产品独特的价值主张？相比竞品是否能形成足够的差异化竞争优势？（参考 UCD 画布，我犯过的一个错误就是在我有人也有的地方过分纠结，而对最独特、差异化的点缺乏深入思考意识）能否促进业务长期的良性运营发展，还是仅仅在短期止血？我们当然希望在某一点用户体验上做到极致，但仅仅做好这一点就够了吗？市场上有没有做到了这一点却不够好的反例？如果有反例又是因为它们缺少了什么？（这些是我上周和 PD 讨论时被反问到的几点）要做正确而有足够价值的事情。

了解技术可行性也同等重要，过于天马行空的概念最终难免沦为一纸空文，但需要指出的是，这并不意味着提案的技术实现手段越简单越好，有时一些更有技术挑战性的事情反而更能赢得开发同学的认可与支持（换位思考一下，作为设计师的我们也不希望每天都是做些简单的拼控件、写标注工作，不是吗？）。不要把开发当成实现你想法的工具，他们同样也会有很多有价值的想法和建议，帮助我们把设计做得更好。

不要一味单打独斗

在发起设计提案的过程中，用户体验设计师将不再是传统的产品开发过程中普通一环，而是需要全程跟踪参与，接触传统意义上由其他职能承担的职责。但是全程参与不等于全程负责，把事情适当交由更专业的人去完成效果会更好，共创式的思维碰撞带来的灵感启发远多于一个人闷头执行。

邀请利益相关方和组内其他设计师共同脑暴、共同绘制草图、共同进行设计比稿……让大家的想法在 Demo 未完全成型的早期阶段得到充分的考虑与参与，再基于此去打磨细化完整的设计方案，与一个人闷头画完交互稿甚至高保真，再拿去一一说服众人接受，通过的难度孰优孰劣，想必大家了然在胸吧？

总结

我觉得做设计提案的过程本质是以不同的侧重角度向不同角色（老板、PD、业务方、开发、用户）讲好同一个故事，就像某位设计前辈之前和我说的那样：「第一阶段和PD等合作伙伴，用完美的逻辑讲通产品闭环；第二阶段和老板、客户，表达核心价值和实现方案；第三阶段和用户，简单易理解的用户场景为先。」祝大家工作中的奇思妙想都能顺利转化为设计提案并成功落地！

本文由人人都是产品经理专栏作家 @鸿影 原创发布于人人都是产品经理 。未经许可,禁止转载。