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