一人多線也能玩得轉？ UXer 的產品開發協作心法（上）
本文適合（1）進入工作領域 1–5 年的 UX Designer/Product Designer/Product Manager（2）試圖導入 UX 工作流程或團隊協作的 Anybody
嗨，身為一個 UXer 在工作當中，多多少少會遇到不同項目同時進行的時刻，甚至這些項目可能還有屬於不同開發階段、甚至屬於不同產品線的需求。
當項目的時程壓力壓著團隊與你持續往前走，產品經理、項目經理、研發工程師和各方老闆都來催時，總感覺自己人生已經萬念俱灰，恨不得喊個「太上老君急急如律令，給我退散！」
以上的場景，或許你工作到目前沒還遇過，但在不少新創公司或者互聯網公司中的中型設計團隊，可能每天都是這麼樣的上演。
尤其當組織或公司有著變現壓力，或著有著爭取項目上線時間的目標時， 身為產品開發迭代過程中的一員，UX Designer 大多時候會對接到複數的需求方與執行方，當協同溝通與設計執行的時間沒有調配好時，往往就是整個項目組的災難。
因此 Nathan 本週想與大家聊聊，當類似這樣有不同需求同時發生時，如何先自趨後趨人，調好自己的節奏，再慢慢的推動團隊與項目的協同更加順暢，用 Uxer 的智慧來解決問題。
01 心中有三條線，同步多工不再是夢
時間絕對是產品開發過程中最寶貴的資源，沒有之一。
上面那句話可能不是危言聳聽。乍聽起來可能會有點不太認同，但其實對於互聯網公司或是營利組織來說，所有的產品開發行為，其實都是面向市場的商業行為。不管是開發、成本、行銷等資源的再多再少，其實都有資源多與資源少的做法（這又是可以另外開一篇文章的內容啦：Ｐ
所以對於互聯網型，或者需要搶佔市場的產品開發來說，對於會影響項目時程的事情都算是高風險。因此如何確認自身參與的產品開發線中的需求狀況，並按項目組協調好的時程推進，是優先級非常高的事情。
畢竟因為自己的工作導致項目延期，這個鍋誰都扛不起的阿！
為了保持高敏捷的面向市場節奏，目前的組織大多導入了 Agile 或 Sprint 這種敏捷開發模式。但是這更多是對項目與組織推進的描述。不管在哪種模式下，當多人協作或同時有複數需求線進行來臨時，都容易有個人時間資源分配不均，導致顧此失彼的情況。
傳統產品開發過程中，每個需求都能大致分為有「定義、設計、開發」三個大階段。每個大階段中當然有許多工作的細項，暫且不展開，但可以發現 UX Deisgner 是少數跟這三個大階段都會參與的角色。
因此，即便團隊採用了不同的敏捷開發方式，UX Designer 心中仍然可以保持 Waterfall 型的工作方式。每個需求進到自己的 Backlog 時，可以依據當前的需求現況，判斷需要投入的時間與工作方式。
舉例來說：
01 如果目前接入的需求，沒有明確的 Product Requirement Document 時，可以僅輸出關鍵稿來彙整關係人的想法。這些關鍵稿甚至用框架原型都行。
02 當需求已經有較明確的產品 Spect 時，時間能更多投入在發想與創新設計方案中。可以針對同一需求，輸出多種方案拓展可能性。對於開發實現的設計文檔，尚不是高優先級。
03 但當高保真設計輸出，讓技術團隊進入評審對接時，應該避免掉設計方案的變動，更多時間投入在推進需求與效果實現上。
另外，每個需求除了在不同階段有不同的工作模式外，個人的不同投入資源比，也能讓工作的進行更加順利，並讓自己朝某個方向穩定成長。
對於創意型的 UXer，可以將時間更多放在「幻想線」與「對焦線」上，但對於產品型的 UXer，「對焦線」與「推進線」可能是更多能在工作中產生價值的區段。
如果對於是像 UI Design 的角色來說，可以把大部分時間放到開發端，更著重在效果實現的部分。
當然，這些時間調配，主要還是依照個人與團隊對於自己的定位來調整。
對 Nathan 個人來說，即便是不同的產品線同時在進行過程，這三個階段的需求，調控的時間佔比大概再 2:5:3。主要是對於個人的定位來說，是偏創意探索與孵化型的 UX Designer，會花較多的時間將洞見轉化為設計價值。
心中有了三條線後，產品迭代過程中，可以建立以 需求項為單位 的追蹤表，除了讓自己明確當前的工作事項外，也同步與協作人員讓關係人了解你目前的工作進度與狀況。
同時，建立 設計輸出的版本控制 與 變更節點，也是建立良好的需求管理方式。避免因為在快節奏中導致的需求變動，影響到自己的其他需求推進時程。
基於不少人團隊目前主要使用的開發工具為 Sketch，結合 gitlab/github 方式是種不錯的版控選擇，當然也會有人使用 Zeplin 或其他公司中的版控工具。
即便是因為公司規定讓使用這些工具有疑慮的話，其實簡單的做好檔案命名，也是個簡易的版本管理方式。協同者或中下游的同事，能一看就能掌握目前的需求現況。
簡易命名規則 [項目名稱_需求名稱_年/月/日（時）_關鍵描述]
ex. UX四神湯_用戶互動計畫_201812111200_設計1.0完成02 求快也不能落下品質，讓團隊成為助力
設計評審這個詞，可能對於小型團隊與單人 UX Designer 組織來說，會有點陌生。但其實這在大型互聯網中，早已是一種行之有年的工作模式。
一般來說，設計評審有兩種模式，一種是由設計師主動發起的 Design Challenge，希望透過與不同設計師的想法碰撞，來彌補設計的多面性問題。
另外一種則是偏向 Design Review 的方式，中大型需求通常涉及多人協同，當準備輸出進入開發階段時，大多會透過設計評審的方式，來確保框架上的一致性，以及確認各自設計者是否有設計盲區。
當然兩個類型的評審過程中，肯定會有主管方的參與，進行設計思路與方案的 Review。
設計評審中，Design Review，與較為人熟知的專家評審較為雷同，更多聚焦在可用性與易用性問題上。而由設計師主動發起的 Design Challenge 關注的更多是在補全多面性問題。
雖然都跟設計品質有關，但前者更多的是確保多人協作的品質。
另外依據不同的目的，還可在分為內審（主要由設計師參與）和外審（由需求方和技術方、相關關係人參與）。
Design Challenge 設計評審
一般來說，Design Challenge 型的設計評審，由於參與的其他設計師，大多不再同一需求脈絡中，很難短時間在有限的信息下給出完美的設計細節。因此大多會圍繞在設計策略上進行討論。
這類型評審，大多會是以參與人提問的方式來幫助發起的設計師，並聚焦在幾個問題上：
01 幫助釐清目標 — 這個設計方案想解決什麼問題？
02 明確需要建議 — 這次 Challenge 需要從其他人這獲得的幫助？
03 介紹方案思路— 確保參與者對於發起者的設計方案處在同一頻道上
04 個別提問討論 — 與會者對於各自關注的信息進行提問
05 關注解決問題 — Challenge 應聚焦在解決什麼問題，而不是解決方案上
對於 Design Challenge 型的評審，最好的反饋就是開放型的建議，而不是針對性的解決方案。因為對於發起評審的設計師來說，可能是因為已經處在相同的需求脈絡中过久，導致方案進入局部最佳解。
但這未必是因為個人的能力問題，導致方案思考不夠周全。
但對於其他的設計師來說，正是因為「當局者迷，旁觀者清」，有時候能從另外的角度思考問題。往往能看到一些原有的盲點。
設計方案沒有對錯，只有是否適合當下的環境
如果 Design Challenge 型的設計評審，這種開放型的反饋風氣沒有把控好，很容易會變成能力上的評比。也間接導致後續發起者的意願降低。因此組織者或管理者，對於風氣把控工作也是非常重要的。
Design Review 設計評審
Design Review 型的設計評審，相比則較為嚴肅些。也是最令人頭疼的設計師工作中一大恐懼，如果參與評審的人員都是同一背景，那可能問題還小，最怕的就是有其他需求相關者參與的評審會議。
那就真的像是菜市場喊價一樣，似乎不提點意見給設計師，不彰顯一下自己的想法獨樹一格不罷休。
甚至原本設計思考周全的方案，因為某些重要參與者中的個人偏好，而被改的面目全非。還有的時候，設計評審變成了集體決策時間，少許改動也要全員同意，嚴重影響了項目的節奏。
最後還是得設計師自己加班收拾殘局阿。
針對這類 Design Review 評審的實務上建議：
01 控制關鍵參與人
人越多越不受控，不要妄想發起一場大而全的設計評審，來周知所有樣目關係人。如果有非設計角色參與的 Deisgn Review，盡量控制在 5~7 人範圍的評審人數。
一般參與的角色，會視項目重要程度包含「產品需求直接關係人」、「UI 協做直接關係人」、「開發協作直接關係人」。如果涉及的技術過多時，通常會找到關鍵的接口人或框架師來做為設計評審參與人。
02 準備周全了在上
非設計專業的人，很難透過一些關鍵信息的入在腦海中形成畫面，並進而達成共識。對於這類非專業的人來說，是所見為憑，即便你說明了你是提供高保真設計原形，參與人們還是會以視覺稿來評。
搭配文章前面所提的 三線工作法，如果是需求對焦的評審，切記不要提供過於完整的設計稿，以免來回對焦討論導致自己的資源浪費。適時對外同步自己的三線工作法時間節點，也能讓需求方了解他應該什麼時間點，準備好需求內容。
另外，設計評審前最好讓需求在 對焦線 探索了可能的方案，否則不如推遲評審時間，避免參與者 透過完整的設計稿件來討論需求。
03 建立以建設性建議取代批評的評審模式
與 Design Challenge 相同，Design Review 設計方案前要把設計要解決的問題，要帶給用戶什麼樣的體驗（需要和產品經理和整個團隊達成一致），和支撐設計的數據和經驗判斷先明確出來。
對於非相同背景的參與者，這樣的方式比較能快速了解目前設計方案的背景與現況。許多參與者的批評，到最後發現是因為根本不了解目前設計進行現狀。因此避免舉行 Design Review 時，一上來就直接進入設計方案本身
另外，在進行 Design Review 時，設計師來掌控整個評審過程的節奏，是
非常重要！非常重要！非常重要！
因為準備周全的設計師，應該是要最了解自己的方案哪邊是亮點，哪邊可能是有風險的。
並且當非專業參與者，在針對設計方案表達意見時，把控討論風向，轉向我覺得「怎麼做可能會更好」的方向。對於設計評審的結果可能會更有價值。
下次遇到批評時，可以嘗試以下幾種方式：
A 讓參與者先聽後說，拒絕重複的挑戰方案討論
B 明確參與者是否是表達個人喜好
C 重點問題優先討論，細部的問題是等待重點問題結束後在進行討論
即便設計方案參與者都十分認同，並且也找不到更優的設計思路時，在這種情況下，設計師應該把討論轉向現有方案在拓展性上是否有潛在問題。在後期實現和運營中是否存在風險的討論上。這樣來自不同專業背景的人員，能提供一些更專業的意見，來幫助豐滿現有的方案。
04 線下提早達成共識
雖然脫離了公開舉行設計評審的本意，但也很現實，有人在的地方就有江湖，有時候設計評審被批評，並不代表你的設計方案不夠好。而是重要關係人覺得她的影響力是否有發揮。
因此在設計方案完成至 80% 到舉行設計評審的過程中，可以提前找到重要關係人，甚至自己與對接團隊的老闆，提前對焦設計方案與想法。
好的設計評審跟舉行有效率的會議是一樣的。方案應該被提前了解，會議上只是討論 Action 與後續 Schedule。
而對於管理者而言，其實還有許多建立高品質設計的團隊協作方式，比如在
A 項目初期建立 Design Patter Library (Visual / Interaction)
B 建立接口人與執行者的機制
多人協作過程，最怕的就是所有人都像前各自對接需求與拆解需求，在設計團隊中設立 UX PM 的角色來把控協作，UX PM 關注在設計框架上，Designer 則更關注在設計執行與需求拆解上。
C 竟稿未必是不好的
在大型項目中，引入複數的設計執行者進行同一需求設計，未必是不好的手段，在挑選設計執行者時，最好能從設計師本身具備的 不同屬性 來考量。這樣能確保重點需求在不同面向上都有解決方案。
而對於參與竟稿的設計師而言，對執行得過程中必定會有碰撞成長，但要注意的是，避免讓竟稿的結果變成優缺比較。因為本身挑選的設計師既然是不同的屬性，那也就只有當前的方案符不符合現狀而已。
當然，這種情況在現實中，很難最終這麼和平收場，但在獎評過程中，注意竟稿所帶來的勝出，不應過於凸顯就行。
當然還有許多由設計管理上處理協同問題的方法，礙於篇幅就不展開說明，只要記得目標與方法不該混為一談，優線的組織應該是要不遺餘力的優化與改進工作方式，但這並非是設計為本的目標。
UXer 的目標應該是打造出優秀的產品，透過提昇用戶體驗的方式幫助企業獲利。
最後，既然入了 UX 這一行，多少跑不了遇到混亂需求與產品時程重疊的問題，希望能透過小小的文章幫助大家都在成為多多多面手的路上～
上篇的內容主要集中在 UXer 在團隊協作中，可能遇到的盲點或問題。下篇則預計會來討論，如何在自己的工作過程中，建立起良好的協作習慣，讓團隊溝通與項目迭代能事半功倍。
如果對於本篇的文章有其他建議，也歡迎底下留言討論喔～
謝謝大家看完，如果你喜歡這篇文章的話，也請記得點贊一下喔！如果覺得寫道你的心坎裡，也請不要吝嗇用力點個 5 次贊！我們下次見囉 See ya~
-Nathan
