我有一个好想法……为什么落地困难重重？

　

不能落地的 idea 不是好 idea。

相信大家在工作中除了完成业务需求之外，多多少少也会萌生一些本身的创新想法。

然而，在产生想法时电光火石般的喜悦过后，我们却会发现，真正鞭策想法落地、完成一个「设计驱动」的项目远没有想象中那么简单：说服不了业务方，没有开发资源，一拖再拖然后杳无音讯，半路被迫拥抱变革，好不容易上线了却数据欠安被各种质疑……

笔者本身也经历过这样的挫折，一度产生过怀疑甚至安于现状的情绪。如今回头再看，还是本身多多少少在对想法自己的业务价值认知、时间节奏办理、实际效果判断等方面存在问题，才造成了各种落地不畅的结局。

业务价值认知：想法是否契合核心业务目标？还是认知偏差下的一厢情愿？

作为一个还处于「创业阶段」业务线的设计师，我有时会羡慕成熟业务线的设计师可以花大量时间思考和打磨诸如引导页、特殊场景、动效、点赞互动等细节的设计。当本身想在负责的业务里鞭策类似事件时，却要么被业务需求压得根本没有思考时间只能给一个无功无过的「基础版方案」，要么辛辛苦苦发散创新做出了 Demo 却在开发阶段因为优先级等问题无奈被砍。

这种情况相信不少人都遇到过，用老板之前的话就是「还没到阿谁阶段」，而我的理解阐述则是：因为我们设计师的身份，过分放大了对于一些细节、创新想法的价值评估（产生认知偏差）；但它们并不是业务目标导向的，对业务方当前阶段最关心的几个数据指标贡献极微甚至可能起到反作用，在资源有余的时候也许可以落地，其他时候就更可能沦为我们的一厢情愿。对于非成熟业务线的产品，后者的情况更加常见。

更合适的做法也许是花更多时间去和业务方对焦和理解产品的核心业务目标、当前所处阶段、未来的长远规划等，多方面收集分析他们和用户遇到的问题和困惑（我称之为「360°调研法」），从核心目标出发去提本身的想法，反复碰撞、校验，达成共识后再细化具体方案；而不是先入为主预设好问题和结论，基于此寻找能够支撑不雅观点的论据，选择性过滤其他信息，直接用一通不明觉厉的方法推导得出完整方案，才想到要去和业务方碰撞，结果被挑战得遍体鳞伤。

比来我们鞭策的一个改版项目用了前者的做法，业务方体现了认同和支持，并在方案产出后积极争取资源排期落地；而就在大半年前，我们也用后者的做法鞭策过一次，最终结果却是遭到无穷无尽地挑战，最终被 Hold。

追求设计创新固然重要，但是如果处在一个资源有限的业务线里，，请必然思考清楚这两个问题：创新点子自己没有足够清晰的业务价值？是否能对当前业务的核心数据指标产生贡献？

时间节奏办理：拆分优先级，最小可行性方案兜底，「见缝插针」正常迭代

上面说的是在资源有限的场景下鞭策点子，需要思考清楚点子自己是否有足够清晰可量化的价值；而如果开发资源没有那么紧张，前端愿意做，一些价值量化相对困难的细节思考创意，还是有必然落地机会的，而落地过程中时间节奏的办理会变得比较重要。

我们在做设计的时候讲究全链路，讲究多角度思考给出完整方案。但在实际开发节奏中，往往做不到一蹴而就，需要拆分成多步进行。这就需要我们在给出方案的同时，也对具体内容功能点的优先级有一个判断，兜底给出一个对基础体验影响小、能快速上线验证的最小可行性方案，然后在正常业务需求迭代中「见缝插针」（好比这个业务需求涉及到某某页面，就把某某页面相关的体验优化或创新点子整合进来一起考虑），陆续完善到比较抱负的状态。

实际效果判断：技术实现是否能达到用户预期？真实数据下表示如何？

作为设计师对技术趋势有必然认知是应该的，我们有时也会尝试将个性化保举、人工智能、AR 等整合到本身的设计方案中来，但如果对技术最终能实现的效果没有大致预判感知，就酿成了「抱负很丰满，现实很骨感」。

之前我尝试鞭策过一个将「个性化」作为核心策略的项目，但是忽略了很重要的一点：我们做的是一个基础用户量级很小的 B 端产品，能获取的用户个性数据非常有限，之前产品里有过「保举」模块存在，但实际效果也是要划上问号的。基于「个性化」设计出来的产品方案看上去很美好，但实际上线后可能只会给用户保举一大堆噪音，更好一点的做法也许不是系统保举而是让用户手动自定义选择。最终这个项目在开发阶段 Delay 很久最终不了了之，直到后来调整了核心策略，「个性化」被弱化成了重要性比较低的一小块，才顺利重启。

标签：盐城 东营 林芝 乌鲁木齐 九江