我一向不喜歡做只被動接受業務、PD 需求然後執行的設計師，在分析需求、思考方案的過程中總會有些自己的想法冒出，但將想法整合進設計方案容易，說服利益相關方和推動落地卻不是那麼簡單，在專案排期緊張開發資源衝突等情況下，設計師的創新想法相比業務的剛需也更容易被延後上線（一旦週期長了可能就被慢慢遺忘）、甚至無情砍掉。「體驗設計驅動業務創新」是一句喊起來容易做起來卻挑戰重重的口號，今天這篇文章就想反思下自己最近在推動創新設計提案過程中踩到的一些坑。
簡單功能與複雜邏輯
最近在做一個有著大量資料列表、榜單的移動端頁面互動設計，Prd 中的需求描述為純粹的列表展示，為了補上從使用者瀏覽發現問題到推動問題解決過程中的閉環缺失，提升使用者參與感來緩解純粹瀏覽的枯燥，結合目標使用者很忙碌的特徵，我為榜單包裝了幾個低操作成本、有一定趣味性的互動入口（性質類似於DING一下、點贊、鮮花、雞蛋等），並設計了點選入口後的完整互動反饋描述。
但在和專案組評審的過程中，卻發現後端的入口顯示判定邏輯遠比前端的介面展示覆雜得多。我考慮的初版判定邏輯方案是從比較理想化的普通使用者角度出發，認為資料（負面型）增長超過 X% 則給出負面互動入口，反之降低超過 X% 則為正面互動，不給使用者增加額外的思考和選擇成本。但和業務方溝通卻發現真實業務場景中的邏輯沒有這麼簡單，比如雖然現在的已有榜單都是負面資料排行，但未來可能也會引入正面資料模組；比如不是資料降低就值得鼓勵，如果沒有達到預期目標同樣需要批評……而我們緊張的開發資源不足以在一期支撐起這麼多複雜的業務邏輯判斷。所以最終決定的方案還是同時外化兩個入口，讓使用者根據真實情況選擇性互動。
互動設計在介面上的整合呈現相對簡單，也適合設計師在此開腦洞，但我們正式向業務、PD 提案的時候，絕不能僅僅思考完介面之上的互動流程就了事，對於介面之下的後端判定邏輯也要結合業務場景和開發資源充分考慮，給出清晰可執行的方案，能夠落地的想法才值錢。
共創藍圖與合作變革
可能有很多設計師小夥伴都遇到過和我相似的困擾：被大量的業務需求連續轟炸，又難以找到足夠有氣場的合理理由選擇性執行，明明自己直覺對產品使用者價值不大、甚至引發不良體驗，最後還是不得不做；想跳出區域性需求從更系統的角度思考統籌，提出一個顛覆性的整合設計改版方案，但對產品現有形態和利益衝擊較大、結果好壞難料，即使說服業務方達成一致，也會被一些看上去更容易短期出結果的補丁性質需求一再插隊……
這些問題不是設計師單槍匹馬就能解決的，而是涉及到驅動和業務、PD 方的合作機制變革，來幫助提升設計師在戰略層的視野和決策能力。最近包括我在內團隊裡不少設計師都在嘗試驅動和用研、業務方共創體驗藍圖，雙方共同梳理完整的業務、產品鏈路地圖，已有的使用者痛點、未來新增的業務需求、設計師自己的創新想法等都需要整合進藍圖裡，系統判斷價值和優先順序再思考執行解決方案；而不是現在這樣被動接受業務方拍腦袋過來的一個又一個彼此割裂、關聯不清、有時感覺不靠譜卻因為缺少論據（如系統整理過的相關使用者痛點反饋）而辯駁無力的需求，導致最後出來的產品整體有一種隨意拼湊、思考不繫統不深入的感覺。
其實我之前已經做過一些痛點梳理和體驗地圖的繪製工作，但核心問題在於共創的程度不夠，缺乏專業的用研訪談與焦點小組輸入支撐（更多是設計師和 PD們自己腦補出來的痛點，雖然和後來用研主持焦點小組的結果有所重合），各鏈路環節也是憑著自己的理解繪製，和業務方反覆溝通確認的頻率不高，導致不夠完整全面。這樣出來的地圖更容易被視為設計師 YY 的產物，在說服利益相關方時也容易底氣不足。
熟悉排期與及時溝通
再就是排期了，設計師除了對自己的產品設計進度要有一個清晰的排期計劃之外，也要對專案組整體的排期情況有一定了解，知道具體的開發上線時間。當希望在 PD 需求的基礎上加入創新設計內容的時候，要及時去和專案組溝通清楚（如做一個簡單版的 Demo 演示等，不用畫很完整的設計方案），被認可就儘早推動其加入開發排期的計劃。而如果磨磨蹭蹭到畫完全部設計方案做正式評審時才提出，很可能這時候開發已經基於 Prd 完成了技術評估與排期、甚至部分動工，這樣想再中途插一個創新設計的功能點進去，就會變得相對困難，受到各種挑戰、被砍也是正常結果。