我一向不喜欢做只被动接受业务、PD 需求然后执行的设计师，在分析需求、思考方案的过程中总会有些自己的想法冒出，但将想法整合进设计方案容易，说服利益相关方和推动落地却不是那么简单，在项目排期紧张开发资源冲突等情况下，设计师的创新想法相比业务的刚需也更容易被延后上线（一旦周期长了可能就被慢慢遗忘）、甚至无情砍掉。「体验设计驱动业务创新」是一句喊起来容易做起来却挑战重重的口号，今天这篇文章就想反思下自己最近在推动创新设计提案过程中踩到的一些坑。

简单功能与复杂逻辑

最近在做一个有着大量数据列表、榜单的移动端页面交互设计，Prd 中的需求描述为纯粹的列表展示，为了补上从用户浏览发现问题到推动问题解决过程中的闭环缺失，提升用户参与感来缓解纯粹浏览的枯燥，结合目标用户很忙碌的特征，我为榜单包装了几个低操作成本、有一定趣味性的互动入口（性质类似于DING一下、点赞、鲜花、鸡蛋等），并设计了点击入口后的完整交互反馈描述。

但在和项目组评审的过程中，却发现后端的入口显示判定逻辑远比前端的界面展示复杂得多。我考虑的初版判定逻辑方案是从比较理想化的普通用户角度出发，认为数据（负面型）增长超过 X% 则给出负面互动入口，反之降低超过 X% 则为正面互动，不给用户增加额外的思考和选择成本。但和业务方沟通却发现真实业务场景中的逻辑没有这么简单，比如虽然现在的已有榜单都是负面数据排行，但未来可能也会引入正面数据模块；比如不是数据降低就值得鼓励，如果没有达到预期目标同样需要批评……而我们紧张的开发资源不足以在一期支撑起这么多复杂的业务逻辑判断。所以最终决定的方案还是同时外化两个入口，让用户根据真实情况选择性互动。

互动设计在界面上的整合呈现相对简单，也适合设计师在此开脑洞，但我们正式向业务、PD 提案的时候，绝不能仅仅思考完界面之上的互动流程就了事，对于界面之下的后端判定逻辑也要结合业务场景和开发资源充分考虑，给出清晰可执行的方案，能够落地的想法才值钱。

共创蓝图与合作变革

可能有很多设计师小伙伴都遇到过和我相似的困扰：被大量的业务需求连续轰炸，又难以找到足够有气场的合理理由选择性执行，明明自己直觉对产品用户价值不大、甚至引发不良体验，最后还是不得不做；想跳出局部需求从更系统的角度思考统筹，提出一个颠覆性的整合设计改版方案，但对产品现有形态和利益冲击较大、结果好坏难料，即使说服业务方达成一致，也会被一些看上去更容易短期出结果的补丁性质需求一再插队……

这些问题不是设计师单枪匹马就能解决的，而是涉及到驱动和业务、PD 方的合作机制变革，来帮助提升设计师在战略层的视野和决策能力。最近包括我在内团队里不少设计师都在尝试驱动和用研、业务方共创体验蓝图，双方共同梳理完整的业务、产品链路地图，已有的用户痛点、未来新增的业务需求、设计师自己的创新想法等都需要整合进蓝图里，系统判断价值和优先级再思考执行解决方案；而不是现在这样被动接受业务方拍脑袋过来的一个又一个彼此割裂、关联不清、有时感觉不靠谱却因为缺少论据（如系统整理过的相关用户痛点反馈）而辩驳无力的需求，导致最后出来的产品整体有一种随意拼凑、思考不系统不深入的感觉。

其实我之前已经做过一些痛点梳理和体验地图的绘制工作，但核心问题在于共创的程度不够，缺乏专业的用研访谈与焦点小组输入支撑（更多是设计师和 PD们自己脑补出来的痛点，虽然和后来用研主持焦点小组的结果有所重合），各链路环节也是凭着自己的理解绘制，和业务方反复沟通确认的频率不高，导致不够完整全面。这样出来的地图更容易被视为设计师 YY 的产物，在说服利益相关方时也容易底气不足。

熟悉排期与及时沟通

再就是排期了，设计师除了对自己的产品设计进度要有一个清晰的排期计划之外，也要对项目组整体的排期情况有一定了解，知道具体的开发上线时间。当希望在 PD 需求的基础上加入创新设计内容的时候，要及时去和项目组沟通清楚（如做一个简单版的 Demo 演示等，不用画很完整的设计方案），被认可就尽早推动其加入开发排期的计划。而如果磨磨蹭蹭到画完全部设计方案做正式评审时才提出，很可能这时候开发已经基于 Prd 完成了技术评估与排期、甚至部分动工，这样想再中途插一个创新设计的功能点进去，就会变得相对困难，受到各种挑战、被砍也是正常结果。

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