作為一枚去年畢業(yè)的交互設計新人躬络，我過去的設計工作流絕大部分是「等Prd評審 - 確認Prd疑問 - 提煉目標梳理架構 - 出交互方案 - 評審 - 跟進上線」這種痴柔，雖然從0到1做了不少大大小小的項目荐吉，也會去主動思考完善PD需求中的不少細節(jié)，但基本都是被動模式而缺少主動提案：被動接受來自PD或運營的完整需求描述冕茅，然后在對方給定的具體框架內進行交互設計榕订。

后來隨著對業(yè)務熟悉程度加深店茶，我開始有意識嘗試去主動做一些事情、進行一些改變劫恒，比如整理已有用戶反饋贩幻、制作體驗地圖、搜集競品两嘴、撰寫體驗分析報告等丛楚，這一部分起初因為經驗不足等原因踩過一些坑（參見《回歸本質：我的平臺型產品設計分析缺了什么》），修改后給PD看后得到的反饋還算積極憔辫；而在開始嘗試將「體驗問題分析」轉化為「具體解決方案」的過程中趣些，也深感設計提案的不易之處，直到這周才真正把第一批具體的產品設計方案初稿交付PD贰您、提上評審開發(fā)的議程坏平。這次產品設計提案的正式評審修改、排期實現锦亦、數據反饋驗證環(huán)節(jié)尚未進行舶替，本文就先總結一下自己前半部分工作中從公司前輩處學到的經驗與自己的心得吧（對于未上線或非對外公開項目不會有具體的項目細節(jié)配圖描述，所以可能會寫得比較虛孽亲，還請大家理解）坎穿。

核心目標的認知統一

設計師們多多少少有一些強迫癥展父，看到某個細節(jié)有瑕疵就會吐槽「體驗不好」返劲，但要想拿一些所謂的「完美像素」、「遵循規(guī)范」栖茉、「可用性好」等去說服需求方與項目組篮绿，對設計細節(jié)本身不是那么敏感的他們卻可能不那么在意，或者換句話說吕漂，相比「更好的用戶體驗」本身亲配，大多數人更在意的是「更好的用戶體驗能否為當前的核心業(yè)務目標帶來貢獻」，和核心業(yè)務目標關聯不大的設計優(yōu)化提案，也更容易被劃入「優(yōu)先級低」的范圍然后一再拖延吼虎。

如果想讓自己的設計提案更好更快地得到大家的認同與推進落地犬钢，就要在設計方案所促成的問題解決上保持與項目組的核心業(yè)務目標同步，而忌自己悶頭搜集思考思灰、不主動和項目組溝通確認清楚各階段業(yè)務目標玷犹，導致解決方案雖然有利于小環(huán)節(jié)用戶體驗提升，卻對業(yè)務全局無關痛癢洒疚、甚至產生負面影響歹颓，而難以得到重視推進。

1. 不只關注Prd油湖，主動了解更多業(yè)務相關資料信息

雖然最直接的資料Prd可以給我們提供很多業(yè)務目標與方向上的信息描述參考巍扛，但想要對此有更深入全面的理解的話，則需在平時更主動積極去關注更多相關資料信息乏德，而不是等到Prd評審時才開始一切撤奸。

只要稍微留心一下項目組的郵件，不難得到來自運營喊括、PD的各種Mrd寂呛、階段總結報告、上線數據反饋等資料瘾晃，這些都可以幫我們了解更完整的項目需求贷痪、項目現狀、發(fā)展方向等的來龍去脈蹦误，知道最初的問題和用戶痛點所在劫拢、業(yè)務現狀不足與未來改進方向等，對Prd中加工后傳達的概念有更接近本質的準確理解强胰，減少只看Prd造成的信息傳達損耗舱沧、引發(fā)的設計方向偏差。在更早的階段（早于Prd評審）就參與到項目組的需求討論會議（頭腦風暴偶洋、故事會熟吏、Mrd評審等）也是同理，雖然在不是很了解業(yè)務時可能沒多少發(fā)言的空間玄窝，但可以傾聽獲取來自不同業(yè)務方的更多信息反饋（他們本身就是核心用戶或者對用戶的接觸了解程度非常深入牵寺，對B端產品來說這點尤其明顯），幫助在頭腦中建立起對業(yè)務更完整的印象恩脂。

2. 關注項目動態(tài)帽氓，多次溝通確認，減少信息滯后

因為戰(zhàn)略調整俩块、市場變化之類的因素黎休，項目的業(yè)務目標不會是一成不變的浓领，所以這就需要我們更多關注項目動態(tài)，反復多次和需求方溝通確認清楚各時間段項目的核心目標所在势腮，并根據變化及時調整設計提案联贩，減少信息獲取滯后導致的無效設計工作增多。

孤立解決到整合延伸

在搜集分析了一些項目業(yè)務背景信息捎拯、市場競品資料撑蒜、用戶調研數據反饋之后，我通過產品設計分析報告（涉及環(huán)節(jié)有多角色任務流程梳理玄渗、用戶體驗地圖座菠、用戶診斷、用戶目標分析藤树、設計目標提煉浴滴、競品分析等）的形式匯總提煉出了一批體驗改進點，并撰寫了初步的解決方案思路岁钓。

這樣的好處是我可以對已有的體驗問題有一個更完整全局的印象升略，將部分同一場景下的體驗問題統一考慮整合到一個解決方案中去（碎片式解決視角有限，而且分次開發(fā)可能帶來更多限制和復雜度提升）屡限，也可以在某個體驗優(yōu)化需求的基礎上延伸出更多場景（比如用戶反饋某個問題描述不清需要退回品嚣，我可以基于之前了解的其他信息迅速聯想到除了描述不清，還可能有選錯分類钧大、選錯人等情況出現翰撑，也同樣適用于需要退回的場景），讓解決方案覆蓋到更大的范圍中去啊央。

雖然體驗問題的分布本身很碎片化眶诈，但最終的解決方案卻相對整體、考慮角度相對全面瓜饥，用一套交互設計稿同時解決多個體驗問題逝撬，而不是每個碎片的體驗問題都單獨出一遍交互，這樣在交付和評審時也更加方便乓土。

優(yōu)先級與排期的劃分

雖然經過了整合處理宪潮，但具體的解決方案點仍然有不少，一次性全完成交付顯然不現實趣苏，這時就需要進行優(yōu)先級與排期的劃分了狡相。

我目前的劃分中主要考慮以下幾個因素：和核心目標的相關程度、牽涉的待確認點多少拦键、開發(fā)成本等谣光。如果和當前階段的核心目標關聯不大檩淋、不是純產品設計能解決的體驗問題（如涉及業(yè)務邏輯變更）芬为、實現成本大但收益比不高等萄金，優(yōu)先級就往后放，反之則前置媚朦。然后分批制定具體的設計氧敢、評審、交付上線時間等询张，這一塊也需要多和項目組確認孙乖，減少和其他需求的沖突。

對于優(yōu)先級與排期份氧，我還沒有多少實踐經驗唯袄，相信有很多產品經理和用戶體驗設計同學都要比我熟悉、專業(yè)得多蜗帜，所以這塊不談太多恋拷，僅供參考，也歡迎經驗更豐富的同學指教厅缺。