不能落地的 idea 不是好 idea。

相信大家在工作中除了完成業務需求之外，多多少少也會萌生一些本身的創新想法。

然而，在產生想法時電光火石般的喜悅過后，我們卻會發現，真正鞭策想法落地、完成一個「設計驅動」的項目遠沒有想象中那么簡單：說服不了業務方，沒有開發資源，一拖再拖然后杳無音訊，半路被迫擁抱變革，好不容易上線了卻數據欠安被各種質疑……

筆者本身也經歷過這樣的挫折，一度產生過懷疑甚至安于現狀的情緒。如今回頭再看，還是本身多多少少在對想法自己的業務價值認知、時間節奏辦理、實際效果判斷等方面存在問題，才造成了各種落地不暢的結局。

業務價值認知：想法是否契合核心業務目標？還是認知偏差下的一廂情愿？

作為一個還處于「創業階段」業務線的設計師，我有時會羨慕成熟業務線的設計師可以花大量時間思考和打磨諸如引導頁、特殊場景、動效、點贊互動等細節的設計。當本身想在負責的業務里鞭策類似事件時，卻要么被業務需求壓得根本沒有思考時間只能給一個無功無過的「基礎版方案」，要么辛辛苦苦發散創新做出了 Demo 卻在開發階段因為優先級等問題無奈被砍。

這種情況相信不少人都遇到過，用老板之前的話就是「還沒到阿誰階段」，而我的理解闡述則是：因為我們設計師的身份，過分放大了對于一些細節、創新想法的價值評估（產生認知偏差）；但它們并不是業務目標導向的，對業務方當前階段最關心的幾個數據指標貢獻極微甚至可能起到反作用，在資源有余的時候也許可以落地，其他時候就更可能淪為我們的一廂情愿。對于非成熟業務線的產品，后者的情況更加常見。

更合適的做法也許是花更多時間去和業務方對焦和理解產品的核心業務目標、當前所處階段、未來的長遠規劃等，多方面收集分析他們和用戶遇到的問題和困惑（我稱之為「360°調研法」），從核心目標出發去提本身的想法，反復碰撞、校驗，達成共識后再細化具體方案；而不是先入為主預設好問題和結論，基于此尋找能夠支撐不雅觀點的論據，選擇性過濾其他信息，直接用一通不明覺厲的方法推導得出完整方案，才想到要去和業務方碰撞，結果被挑戰得遍體鱗傷。

比來我們鞭策的一個改版項目用了前者的做法，業務方體現了認同和支持，并在方案產出后積極爭取資源排期落地；而就在大半年前，我們也用后者的做法鞭策過一次，最終結果卻是遭到無窮無盡地挑戰，最終被 Hold。

追求設計創新固然重要，但是如果處在一個資源有限的業務線里，，請必然思考清楚這兩個問題：創新點子自己沒有足夠清晰的業務價值？是否能對當前業務的核心數據指標產生貢獻？

時間節奏辦理：拆分優先級，最小可行性方案兜底，「見縫插針」正常迭代

上面說的是在資源有限的場景下鞭策點子，需要思考清楚點子自己是否有足夠清晰可量化的價值；而如果開發資源沒有那么緊張，前端愿意做，一些價值量化相對困難的細節思考創意，還是有必然落地機會的，而落地過程中時間節奏的辦理會變得比較重要。

我們在做設計的時候講究全鏈路，講究多角度思考給出完整方案。但在實際開發節奏中，往往做不到一蹴而就，需要拆分成多步進行。這就需要我們在給出方案的同時，也對具體內容功能點的優先級有一個判斷，兜底給出一個對基礎體驗影響小、能快速上線驗證的最小可行性方案，然后在正常業務需求迭代中「見縫插針」（好比這個業務需求涉及到某某頁面，就把某某頁面相關的體驗優化或創新點子整合進來一起考慮），陸續完善到比較抱負的狀態。

實際效果判斷：技術實現是否能達到用戶預期？真實數據下表示如何？

作為設計師對技術趨勢有必然認知是應該的，我們有時也會嘗試將個性化保舉、人工智能、AR 等整合到本身的設計方案中來，但如果對技術最終能實現的效果沒有大致預判感知，就釀成了「抱負很豐滿，現實很骨感」。

之前我嘗試鞭策過一個將「個性化」作為核心策略的項目，但是忽略了很重要的一點：我們做的是一個基礎用戶量級很小的 B 端產品，能獲取的用戶個性數據非常有限，之前產品里有過「保舉」模塊存在，但實際效果也是要劃上問號的?；凇競€性化」設計出來的產品方案看上去很美好，但實際上線后可能只會給用戶保舉一大堆噪音，更好一點的做法也許不是系統保舉而是讓用戶手動自定義選擇。最終這個項目在開發階段 Delay 很久最終不了了之，直到后來調整了核心策略，「個性化」被弱化成了重要性比較低的一小塊，才順利重啟。

標簽：鹽城 東營 林芝 烏魯木齊 九江