起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識項目不同階段，設計師如何推進高效協作？
設計師在不同的項目階段會扮演不同的角色，各階段的工作內容和職責也不盡相同。本文作者結合自己工作經歷，對設計師在項目不同階段的任務進行了梳理總結，與大家分享。
產品設計的迭代過程中，難免會遇到需求量大、上線時間周期短、人力緊缺、研發技術實現等問題，通常這種情況，無論是互聯網大廠還是中小型公司，都會采用項目組的形式統一協調管理。
設計師作為其中重要一環，在項目啟動之前、項目推進過程中、以及項目收尾階段，主要的工作內容和職責是什么？在不同階段有哪些需要注意的事項？近期參與了公司的一個此類大型項目，嘗試著將以上問題做個梳理，希望對你有幫助。
一、項目啟動階段
1. 評估需求內容、工作量和人力
前期通常是業務方、產品、設計、研發和測試各方向負責人，大概圈定出各產品線的需求內容與需求量，并且確定全部需求上線的時間節點。
依據這份需求清單和限定時間，各職能方向的負責人需要對照本部門現有人力，大概評估可能存在的風險點。對于設計負責人主要關注的點包括：留給設計交付的時間是否足夠？限定時間內現有人力是否滿足？是否缺少完成特定需求的設計師？
存在以上問題需要及時反饋給項目負責人，接下來自然是挨個解決問題。設計交付時間如果可以適當延長更好，如果節點已卡死只能是現有人力加大工作效率和產出、或者增加人力支援、或者緊急招人。
一般來說緊急招人肯定是來不及的，另外新人的業務沉淀不夠、并且沒有經過實習期對工作流程和內部設計內容的積累，很難適應高強度高要求的設計工作。這次我參與的項目，人力方面調集了公司其他事業部的設計師前來支援。
2. 了解支援設計師的專業能力/過往項目經歷/擅長方向
如果時間上來得及，可以提前與前來支援的設計師、或者他們的主管進行簡要溝通，了解他們當前專業能力所處的階段、過往大型項目的經歷，以及擅長的方向等。以此為依據，結合本次項目中不同需求的特點：比如需求復雜度、涉及多終端、視覺表現力等，分配任務。
3. 設計部各方向負責人開會，明確需求內容并分配設計工作
設計交付時間已明確、人力問題已解決，那就開干吧。設計部主管會先召集設計內部各方向負責人開會，包括交互、視覺和運營方向的設計負責人。首先設計部各方向協調人要明確需求內容、統一話術表達、理清整體和局部的業務流程。
接著根據劃定的內容、結合設計師的專業水平和擅長特點，分配設計工作內容。注意這里的分配也是大概圈定，后期項目推進中可能會有一些不確定因素，需要隨時根據變動情況靈活調整人力。
4. 規劃工位，項目相關人集中坐在一起
由于有支援的小伙伴，為了便于設計內部和上下游不同職能同事之間及時溝通，項目組相關成員最好集中位置辦公，這樣可以提升溝通效率、節約溝通成本。
二、項目推進階段
1. 提前匯總并公布設計工作注意事項
多人協作的設計項目，需要特別注意以下問題：
- 支援的設計師對業務了解程度不夠，有必要組織介紹項目背景。
- 向參與的設計師講解項目的業務流程，便于設計師明確自己負責的需求所處的環節和目標。
- 設計稿產出需要遵守本部門各端的設計規范。
- 設計師需要明確自己在項目不同階段的任務和產出、以及上下游跟進人…
因此需要提前針對這些問題，匯總并公布相關文檔、鏈接和說明，幫助設計師增強對業務的了解，讓支援的小伙伴明確協作流程和上下游對接人、以及各自負責的需求在不同時間節點的進度。
2. 分配具體任務，設計各方向負責人做好協調工作
設計工作處于需求落地推進的第一階段，研發同事需要結合設計稿才能進入前臺界面功能開發階段，所以前期設計師工作壓力會比較大。
尤其是面對時間周期比較緊張的項目，往往上下游采用同步推進的方式：比如設計稿不必全部產出且評審調整后才交付開發，而是設計初稿階段，下游同事已開始介入。
在需求設計階段，很有可能暴露出以下幾個重要問題：
- 需求功能或流程調整的信息沒有同步，導致負責不同終端的設計師，針對相同功能的設計方案不同。
- 需求調整或者信息沒有及時通知相關人，導致設計交付時間可能延后。
- 由于產品可能按照不同業務線或者不同終端劃分負責的需求，某個設計師的設計方案中可能使用到其他設計方案的設置：需要設計師之間配合，結合各自業務綜合考慮調整方案…
因此設計各方向負責人，需要及時協調解決出現的信息不同步問題，把控設計稿評審和交付進度，對不同設計方案，從業務角度進行全局質量和細節把控。
3. 組織設計稿評審
設計稿評審是需求推進過程中的重要一環，因為交互設計師承擔著將產品需求、業務邏輯、任務流程，以及易用性相結合，轉化為界面的職責，所以交互稿的評審非常重要。
交互稿評審目的是讓上下游同事更加直觀的了解需求，研發可以據此判斷頁面邏輯復雜度與工作量，視覺設計師可以提前構思頁面排版與風格。交互設計師會針對評審會提出的功能點技術實現問題、現有設置是否合理等問題，在評審會后統一調整定稿。
即便是非常緊急的項目，仍然建議組織交互評審?？紤]到緊急項目中上下游同事時間寶貴，可以集中某個時間段，依次安排不同需求的交互方案評審。
4. 配合研發跟進解決問題
當需求設計階段結束之后，接下來就該研發小哥們擼起袖子加油干了。在需求研發階段，經常會出現以下問題：
- 部分功能設置因為技術實現問題，不得不尋找替代方案，可能需要對現有設計方案做調整。
- 由于多人協作，可能針對相同操作場景，會出現不一樣的設置，需要做全局性的規則說明。
- 研發對于設計稿中的細節有困惑，需要得到設計師的及時反饋…
基于以上各種可能出現的問題，設計師需要及時跟進處理，不然嚴重的話會影響開發進度。
三、項目收尾階段
1. 設計驗收與問題跟進
面對上線周期比較短的項目，當測試人員完成第一輪“跑通業務功能流程”的測試之后，設計師便需要介入，開始設計還原度驗收。驗收階段需要解決以下問題：
- 設計師匯總的驗收問題、解決進度和結果、以及無法解決的原因等，需要建立一份驗收清單，便于項目組相關成員及時查閱和跟進。
- 按照項目中不同需求內容模塊，在驗收清單中建立不同的驗收匯總表。另外強調一個細節：設計驗收往往需要上傳示例圖，推薦使用石墨文檔（石墨文檔支持上傳單元格圖片，這個功能真的是很棒）。
- 驗收表中明確寫清楚問題的來源終端、解決結果、備注說明、提出人、解決人等。
另外項目中的部分需求可能按照不同時間節點發布，優先驗收發布時間點早的需求。設計協調人需要及時跟進開發和測試，提前通知相關設計師留意設計驗收的優先級。
2. 收集設計師記錄的問題和優化建議
設計驗收完成之后，驗收清單中的問題大致分為這幾類：已解決、未解決待優化、無法解決。我們需要重點將“未解決待優化”的問題按照某些維度分類匯總、并給出設計部建議的優先級，便于后續版本迭代。
此外可以向參與項目的每一位設計師收集他們的建議和想法，包括業務邏輯、操作流程和體驗、易用性、視覺呈現等不同方面。一些好的建議和觀點，同樣可以為后續版本迭代提供參考。
3. 提前與產品溝通，在后續版本逐步解決待優化問題。
上面已經提到了，對于驗收清單中未解決待優化的問題、以及設計師基于自身對業務思考得出的想法建議，設計部各方向負責人需要按照某些維度，比如功能模塊、終端、頁面功能點等維度分類匯總。然后與相關產品同事提前溝通，按照待解決問題的優先級排期。
總結
以上是我經歷整個項目之后的一些經驗總結，不同公司不同類型的項目，協調管理流程肯定存在差異，但是對于項目啟動階段的準備工作、過程中的問題把控，以及收尾階段的歸納梳理，本質上是一致的。
#專欄作家#
Viksea，微信公眾號：Viksea的設計思考（ID：viksea-ux），人人都是產品經理專欄作家。關注電商領域產品業務和用戶體驗，擅長邏輯分析。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
學到了
抓緊點贊收藏 ??