相信大家在工作中除了完成业务需求之外，多多少少也会萌生一些自己的创新设计想法。然而，在产生想法时电光火石般的喜悦过后，我们却会发现，真正推动想法落地、完成一个「设计驱动」的项目远没有想象中那么简单：说服不了业务方，没有开发资源，一拖再拖然后杳无音讯，半路被迫拥抱变化，好不容易上线了却数据不佳被各种质疑……笔者自己也经历过这样的挫折，一度产生过怀疑甚至自暴自弃的情绪，如今回头再看，还是自己多多少少在对想法本身的业务价值认知、时间节奏管理、实际效果判断等方面存在问题，才造成了各种落地不畅的结局。
业务价值认知：想法是否契合核心业务目标？还是认知偏差下的一厢情愿？
作为一个还处于「创业阶段」业务线的设计师，我有时会羡慕成熟业务线的设计师可以花大量时间思考和打磨诸如引导页、特殊场景、动效、点赞互动等细节的设计。当自己想在负责的业务里推动类似事件时，却要么被业务需求压得根本没有思考时间只能给一个无功无过的「基础版方案」，要么辛辛苦苦发散创新做出了 Demo 却在开发阶段因为优先级等问题无奈被砍。
这种情况相信不少人都遇到过，用老板之前的话就是「还没到那个阶段」，而我的理解阐述则是：因为我们设计师的身份，过分放大了对于一些细节、创新想法的价值评估（产生认知偏差），但它们并不是业务目标导向的，对业务方当前阶段最关心的几个数据指标贡献极微甚至可能起到反作用，在资源有余的时候也许可以落地，其他时候就更可能沦为我们的一厢情愿。对于非成熟业务线的产品，后者的情况更加常见。
更合适的做法也许是花更多时间去和业务方对焦和理解产品的核心业务目标、当前所处阶段、未来的长远规划等，多方面收集分析他们和用户遇到的问题和困惑（我称之为「360°调研法」），从核心目标出发去提自己的想法，反复碰撞、校验，达成共识后再细化具体方案；而不是先入为主预设好问题和结论，基于此寻找能够支撑观点的论据，选择性过滤其他信息，直接用一通不明觉厉的方法推导得出完整方案，才想到要去和业务方碰撞，结果被挑战得体无完肤。最近我们推动的一个改版项目用了前者的做法，业务方表示了认同和支持，并在方案产出后积极争取资源排期落地；而就在大半年前，我们也用后者的做法推动过一次，最终结果却是遭到无穷无尽地挑战，最终被 Hold。
追求设计创新固然重要，但是如果处在一个资源有限的业务线里，请一定思考清楚这两个问题：创新点子本身没有足够清晰的业务价值？是否能对当前业务的核心数据指标产生贡献？
时间节奏管理：拆分优先级，最小可行性方案兜底，「见缝插针」正常迭代
上面说的是在资源有限的场景下推动点子，需要思考清楚点子本身是否有足够清晰可量化的价值；而如果开发资源没有那么紧张，前端愿意做，一些价值量化相对困难的细节思考创意，还是有一定落地机会的，而落地过程中时间节奏的管理会变得比较重要。
我们在做设计的时候讲究全链路，讲究多角度思考给出完整方案。但在实际开发节奏中，往往做不到一蹴而就，需要拆分成多步进行。这就需要我们在给出方案的同时，也对具体内容功能点的优先级有一个判断，兜底给出一个对基础体验影响小、能快速上线验证的最小可行性方案，然后在正常业务需求迭代中「见缝插针」（比如这个业务需求涉及到某某页面，就把某某页面相关的体验优化或创新点子整合进来一起考虑），陆续完善到比较理想的状态。
实际效果判断：技术实现是否能达到用户预期？真实数据下表现如何？
作为设计师对技术趋势有一定认知是应该的，我们有时也会尝试将个性化推荐、人工智能、AR 等整合到自己的设计方案中来，但如果对技术最终能实现的效果没有大致预判感知，就变成了「理想很丰满，现实很骨感」。
之前我尝试推动过一个将「个性化」作为核心策略的项目，但是忽略了很重要的一点：我们做的是一个基础用户量级很小的 B 端产品，能获取的用户个性数据非常有限，之前产品里有过「推荐」模块存在，但实际效果也是要划上问号的。基于「个性化」设计出来的产品方案看上去很美好，但实际上线后可能只会给用户推荐一大堆噪音，更好一点的做法也许不是系统推荐而是让用户手动自定义选择。最终这个项目在开发阶段 Delay 很久最终不了了之，直到后来调整了核心策略，「个性化」被弱化成了重要性比较低的一小块，才顺利重启。
如果只管提出想法，不管想法背后的商业价值思考、技术可行性判断、项目管理推动等，那我们和我们口中经常吐槽的那些「管生不管养」的不靠谱产品经理，其实并没有多大区别。不能落地的 idea 不是好 idea，跳出设计师的局限去思考和推动，才能更好地证明我们自身的价值，大家共勉
网友评论