在被密集需求轟炸（需求本身都具備一定合理性，不包括那種應該拒掉不接的需求），同時自己還有一堆想自發驅動去做的事情時，交互設計師該如何進行合理的設計優先級判斷，分解需求排期推進呢？來看今天的實戰經驗！

在以往的項目中，我通常是完成一個設計需求的評審交付后，再去跟進下一個需求，而在需求相對空閑的時間段里則做做系統的產品體驗分析、構思想優化點的產品設計草案，整理設計組件和規范等，并行應對 > 3個需求（不包括日常迭代的小需求）的情況很少。

但在幾周以前，項目組的 PD 們在兩天內拉上設計和開發，一口氣評審了 5 個 Prd ，在評審快結束的時候，我已經沒有任何專心聽下去的心情，而是陷入了深深的苦惱和煩悶中去：一方面是感覺在密集需求轟炸面前分身乏力、精力難以集中（我是那種喜歡專注地做完一件事情再管其他的性格），另一方面則是因為之前干勁十足自發驅動的網站信息架構整體重構計劃因此被延期，感覺自己又變回了那個「接需求的」。

不過在師兄和 PD 們的幫助下，我逐漸對這一大波密集需求有了清晰的優先級判斷和排期規劃，在沒怎么加班的情況下較為有條不紊地按期產出了其中 3 個需求具體的設計解決方案，甚至在 PD 需求的基礎上還完成了更多相關產品環節的設計，將單一頁面改進推進成了相關完整場景下工作流的整體優化。優先級與排期看似是 PD 們主導的事情，但交互設計師同樣應該重視這一環節，而不是讓自己陷入被動加班應對不合理需求節奏、或是自己隨心所欲但卻拖累一群項目組小伙伴加班的境地。

在被密集需求轟炸（需求本身都具備一定合理性，不包括那種應該拒掉不接的需求），同時自己還有一堆想自發驅動去做的事情時，交互設計師該如何進行合理的設計優先級判斷，分解需求排期推進呢？

交叉并行，配合項目組成員進度

在我們產品 2.0 計劃的這波需求（有 PD 提出的，也有設計師想自發改進的）中，有重視覺輕交互的運營設計，有界面簡單但牽涉業務邏輯復雜、開發成本高的流程設計，有視覺需求弱、交互甚至產品直接 Cover 的后臺設計，有重情感化互動、需要設計師主動思考探索的跨 PC、移動平臺創新設計，還有影響面最廣泛的全網整體重構……

在這些對于各職能來說工作量不一的需求面前，如果按照傳統的瀑布式「Prd/用戶研究 – 交互設計 – 視覺設計 – 前后端開發」流程逐一完成需求交付的話，當前面的職能花上較多時間來考慮解決方案時，后面的職能就會在這段時間內變得無所事事，而之后又可能變得疲于奔命。（舉例子來說，如果我先做需要較長思考和設計時間的某創新設計，花掉一周半的時間，這段時間我后面的視覺和開發資源都會空閑；而等我交付掉了這個頁面，再用兩天不到的時間做完了某流程設計，對開發來說之前的需求才剛啟動， 又來了一個開發成本更高的，壓力就會變大不少）

根據師兄和 PD 們的建議安排、以及開發們給出的排期估計，在整體 Deadline 已定，部分需求業務優先級相近的前提下，我選擇優先投入幾個重開發/重視覺，而交互產出周期相對較短的需求，這樣視覺/開發們可以在更早的時候就介入，而不是等到接近 Deadline 時分身乏力；與此同時，用研也啟動對于整體重構這類計劃的前期用戶調研驗證，而我在這個相對較長的周期里先完成那些明顯能幫助達成業務目標、滿足用戶訴求的設計，等用研結果出來之后，再跟進那些有較大影響面、風險和不確定性（可能激發強烈反彈）的設計。這種職能交叉并行的推進方式，可以將大家的壓力更合理均勻地分解，而不是在某一處發生「集中堵塞」。

優先快速打包完結低成本、短排期的需求

在明確各需求的業務優先級時，PD 將 A 需求劃為 P0，而 BCD 需求是 P1，業務優先級都比較靠前，但實際執行過程中，我最先啟動的卻是 BCD 的設計，而它們成本相對較低、設計和部分開發排期相對較短。

對于項目組來說，就如上一節里所說，快速完結部分需求的設計，可以讓整個項目組資源在更早的時候就有投入，更好地分散壓力。對于交互設計師來說，多個短周期需求先并行，在一個需求進入初稿產出-多方確認完成（在大公司里，多方反復溝通和確認修改花費的時間成本有時會比設計本身大不少，出現一段時間內找不到人確認不了方案又不方便繼續做設計的情況）的空白期內，正好可以把另一個需求也完成得差不多，最終差不多同時評審打包交付；而快速完結掉這些業務優先級不低的短周期需求后，就可以集中精力投入到設計思考成本更高、周期更長、自主驅動力更足的事情中去了，而不是在執行后者時被反復分心干擾（對于我這種討厭分心的人來說，能集中精力做事情還是很重要的）。

謹慎對待全局重構，充分驗證再執行

剛被 Prd 轟炸完時，我一度為自己醞釀已久的全局信息架構、一級頁面整體重構優化的大計劃被暫時擱淺而不爽，也考慮過將新的業務產品需求納入進這個大計劃里整體考慮。

但這在產品周期里不太現實，這個大計劃從用戶體驗設計師的視角來看可能是一次治本的體驗提升，讓信息架構和功能流程得到充分的精簡優化，但激進的變革也容易讓用戶在固有認知操作習慣下無所適從，引發強烈的用戶反彈。而我們的產品又缺失合理的數據埋點，無法通過直觀的某幾個數據指標升降情況來判斷改版的成敗，如果有幾個聲音很大的反對用戶跳出來，也拿不出合理的數據論證來支撐自己的觀點。

正是基于這樣的風險預判，師兄建議我謹慎對待全局信息重構的事情，等用研有了專業的調研輸出、充分驗證想法后再正式介入考慮方案，而不是自己隨便總結出一些體驗不好（從專業視角來看這些痛點也許都客觀存在，但缺乏充足的用戶研究反饋作為論據）的地方就開始大動干戈；而另一個建議延后跟進整體重構的理由則是「先有菜再擺盤」，2.0 中新增了很多需求模塊，先把這些模塊涉及到的獨立頁面都分解設計完成，再統一考慮整合入口的信息架構，如果一開始就想統籌兼顧，則容易陷入很長一段時間都沒有結果產出的境地，萬一中途發生方向等不可控變更也會波及到更廣的范圍，需要復出更高的代價來修正。

本文由人人都是產品經理專欄作家 @鴻影?原創發布于人人都是產品經理?。未經許可,禁止轉載。