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