來學學交互設計的優(yōu)先級判斷與排期協(xié)同

在被密集需求轟炸（需求本身都具備一定合理性，不包括那種應該拒掉不接的需求），同時自己還有一堆想自發(fā)驅(qū)動去做的事情時，交互設計師該如何進行合理的設計優(yōu)先級判斷，分解需求排期推進呢？來看今天的實戰(zhàn)經(jīng)驗！ 在以往的項目中，我通常是完成一個設計需求的評審交付后，再去跟進下一個需求，而在需求相對空閑的時間段里則做做系統(tǒng)的產(chǎn)品體驗分析、構思想優(yōu)化點的產(chǎn)品設計草案，整理設計組件和規(guī)范等，并行應對 > 3個需求（不包括日常迭代的小需求）的情況很少。 但在幾周以前，項目組的 PD 們在兩天內(nèi)拉上設計和開發(fā)，一口氣評審了 5 個 Prd ，在評審快結(jié)束的時候，我已經(jīng)沒有任何專心聽下去的心情，而是陷入了深深的苦惱和煩悶中去：一方面是感覺在密集需求轟炸面前分身乏力、精力難以集中（我是那種喜歡專注地做完一件事情再管其他的性格），另一方面則是因為之前干勁十足自發(fā)驅(qū)動的網(wǎng)站信息架構整體重構計劃因此被延期，感覺自己又變回了那個「接需求的」。 不過在師兄和 PD 們的幫助下，我逐漸對這一大波密集需求有了清晰的優(yōu)先級判斷和排期規(guī)劃，在沒怎么加班的情況下較為有條不紊地按期產(chǎn)出了其中 3 個需求具體的設計解決方案，甚至在 PD 需求的基礎上還完成了更多相關產(chǎn)品環(huán)節(jié)的設計，將單一頁面改進推進成了相關完整場景下工作流的整體優(yōu)化。優(yōu)先級與排期看似是 PD 們主導的事情，但交互設計師同樣應該重視這一環(huán)節(jié)，而不是讓自己陷入被動加班應對不合理需求節(jié)奏、或是自己隨心所欲但卻拖累一群項目組小伙伴加班的境地。 在被密集需求轟炸（需求本身都具備一定合理性，不包括那種應該拒掉不接的需求），同時自己還有一堆想自發(fā)驅(qū)動去做的事情時，交互設計師該如何進行合理的設計優(yōu)先級判斷，分解需求排期推進呢？
交叉并行，配合項目組成員進度 在我們產(chǎn)品 2.0 計劃的這波需求（有 PD 提出的，也有設計師想自發(fā)改進的）中，有重視覺輕交互的運營設計，有界面簡單但牽涉業(yè)務邏輯復雜、開發(fā)成本高的流程設計，有視覺需求弱、交互甚至產(chǎn)品直接 Cover 的后臺設計，有重情感化互動、需要設計師主動思考探索的跨 PC、移動平臺創(chuàng)新設計，還有影響面最廣泛的全網(wǎng)整體重構…… 在這些對于各職能來說工作量不一的需求面前，如果按照傳統(tǒng)的瀑布式「Prd/用戶研究 – 交互設計 – 視覺設計 – 前后端開發(fā)」流程逐一完成需求交付的話，當前面的職能花上較多時間來考慮解決方案時，后面的職能就會在這段時間內(nèi)變得無所事事，而之后又可能變得疲于奔命。（舉例子來說，如果我先做需要較長思考和設計時間的某創(chuàng)新設計，花掉一周半的時間，這段時間我后面的視覺和開發(fā)資源都會空閑；而等我交付掉了這個頁面，再用兩天不到的時間做完了某流程設計，對開發(fā)來說之前的需求才剛啟動， 又來了一個開發(fā)成本更高的，壓力就會變大不少） 根據(jù)師兄和 PD 們的建議安排、以及開發(fā)們給出的排期估計，在整體 Deadline 已定，部分需求業(yè)務優(yōu)先級相近的前提下，我選擇優(yōu)先投入幾個重開發(fā)/重視覺，而交互產(chǎn)出周期相對較短的需求，這樣視覺/開發(fā)們可以在更早的時候就介入，而不是等到接近 Deadline 時分身乏力；與此同時，用研也啟動對于整體重構這類計劃的前期用戶調(diào)研驗證，而我在這個相對較長的周期里先完成那些明顯能幫助達成業(yè)務目標、滿足用戶訴求的設計，等用研結(jié)果出來之后，再跟進那些有較大影響面、風險和不確定性（可能激發(fā)強烈反彈）的設計。這種職能交叉并行的推進方式，可以將大家的壓力更合理均勻地分解，而不是在某一處發(fā)生「集中堵塞」。
優(yōu)先快速打包完結(jié)低成本、短排期的需求 在明確各需求的業(yè)務優(yōu)先級時，PD 將 A 需求劃為 P0，而 BCD 需求是 P1，業(yè)務優(yōu)先級都比較靠前，但實際執(zhí)行過程中，我最先啟動的卻是 BCD 的設計，而它們成本相對較低、設計和部分開發(fā)排期相對較短。 對于項目組來說，就如上一節(jié)里所說，快速完結(jié)部分需求的設計，可以讓整個項目組資源在更早的時候就有投入，更好地分散壓力。對于交互設計師來說，多個短周期需求先并行，在一個需求進入初稿產(chǎn)出-多方確認完成（在大公司里，多方反復溝通和確認修改花費的時間成本有時會比設計本身大不少，出現(xiàn)一段時間內(nèi)找不到人確認不了方案又不方便繼續(xù)做設計的情況）的空白期內(nèi)，正好可以把另一個需求也完成得差不多，最終差不多同時評審打包交付；而快速完結(jié)掉這些業(yè)務優(yōu)先級不低的短周期需求后，就可以集中精力投入到設計思考成本更高、周期更長、自主驅(qū)動力更足的事情中去了，而不是在執(zhí)行后者時被反復分心干擾（對于我這種討厭分心的人來說，能集中精力做事情還是很重要的）。 謹慎對待全局重構，充分驗證再執(zhí)行 剛被 Prd 轟炸完時，我一度為自己醞釀已久的全局信息架構、一級頁面整體重構優(yōu)化的大計劃被暫時擱淺而不爽，也考慮過將新的業(yè)務產(chǎn)品需求納入進這個大計劃里整體考慮。 但這在產(chǎn)品周期里不太現(xiàn)實，這個大計劃從用戶體驗設計師的視角來看可能是一次治本的體驗提升，讓信息架構和功能流程得到充分的精簡優(yōu)化，但激進的變革也容易讓用戶在固有認知操作習慣下無所適從，引發(fā)強烈的用戶反彈。而我們的產(chǎn)品又缺失合理的數(shù)據(jù)埋點，無法通過直觀的某幾個數(shù)據(jù)指標升降情況來判斷改版的成敗，如果有幾個聲音很大的反對用戶跳出來，也拿不出合理的數(shù)據(jù)論證來支撐自己的觀點。 正是基于這樣的風險預判，師兄建議我謹慎對待全局信息重構的事情，等用研有了專業(yè)的調(diào)研輸出、充分驗證想法后再正式介入考慮方案，而不是自己隨便總結(jié)出一些體驗不好（從專業(yè)視角來看這些痛點也許都客觀存在，但缺乏充足的用戶研究反饋作為論據(jù)）的地方就開始大動干戈；而另一個建議延后跟進整體重構的理由則是「先有菜再擺盤」，2.0 中新增了很多需求模塊，先把這些模塊涉及到的獨立頁面都分解設計完成，再統(tǒng)一考慮整合入口的信息架構，如果一開始就想統(tǒng)籌兼顧，則容易陷入很長一段時間都沒有結(jié)果產(chǎn)出的境地，萬一中途發(fā)生方向等不可控變更也會波及到更廣的范圍，需要復出更高的代價來修正。