設計師在不同的項目階段會扮演不同的角色，各階段的工作內容和職責也不盡相同。本文作者結合自己工作經歷，對設計師在項目不同階段的任務進行了梳理總結，與大家分享。

產品設計的迭代過程中，難免會遇到需求量大、上線時間周期短、人力緊缺、研發技術實現等問題，通常這種情況，無論是互聯網大廠還是中小型公司，都會采用項目組的形式統一協調管理。

設計師作為其中重要一環，在項目啟動之前、項目推進過程中、以及項目收尾階段，主要的工作內容和職責是什么？在不同階段有哪些需要注意的事項？近期參與了公司的一個此類大型項目，嘗試著將以上問題做個梳理，希望對你有幫助。

一、項目啟動階段

1. 評估需求內容、工作量和人力

前期通常是業務方、產品、設計、研發和測試各方向負責人，大概圈定出各產品線的需求內容與需求量，并且確定全部需求上線的時間節點。

依據這份需求清單和限定時間，各職能方向的負責人需要對照本部門現有人力，大概評估可能存在的風險點。對于設計負責人主要關注的點包括：留給設計交付的時間是否足夠？限定時間內現有人力是否滿足？是否缺少完成特定需求的設計師？

存在以上問題需要及時反饋給項目負責人，接下來自然是挨個解決問題。設計交付時間如果可以適當延長更好，如果節點已卡死只能是現有人力加大工作效率和產出、或者增加人力支援、或者緊急招人。

一般來說緊急招人肯定是來不及的，另外新人的業務沉淀不夠、并且沒有經過實習期對工作流程和內部設計內容的積累，很難適應高強度高要求的設計工作。這次我參與的項目，人力方面調集了公司其他事業部的設計師前來支援。

2. 了解支援設計師的專業能力/過往項目經歷/擅長方向

如果時間上來得及，可以提前與前來支援的設計師、或者他們的主管進行簡要溝通，了解他們當前專業能力所處的階段、過往大型項目的經歷，以及擅長的方向等。以此為依據，結合本次項目中不同需求的特點：比如需求復雜度、涉及多終端、視覺表現力等，分配任務。

3. 設計部各方向負責人開會，明確需求內容并分配設計工作

設計交付時間已明確、人力問題已解決，那就開干吧。設計部主管會先召集設計內部各方向負責人開會，包括交互、視覺和運營方向的設計負責人。首先設計部各方向協調人要明確需求內容、統一話術表達、理清整體和局部的業務流程。

接著根據劃定的內容、結合設計師的專業水平和擅長特點，分配設計工作內容。注意這里的分配也是大概圈定，后期項目推進中可能會有一些不確定因素，需要隨時根據變動情況靈活調整人力。

4. 規劃工位，項目相關人集中坐在一起

由于有支援的小伙伴，為了便于設計內部和上下游不同職能同事之間及時溝通，項目組相關成員最好集中位置辦公，這樣可以提升溝通效率、節約溝通成本。

二、項目推進階段

1. 提前匯總并公布設計工作注意事項

多人協作的設計項目，需要特別注意以下問題：

• 支援的設計師對業務了解程度不夠，有必要組織介紹項目背景。
• 向參與的設計師講解項目的業務流程，便于設計師明確自己負責的需求所處的環節和目標。
• 設計稿產出需要遵守本部門各端的設計規范。
• 設計師需要明確自己在項目不同階段的任務和產出、以及上下游跟進人…

因此需要提前針對這些問題，匯總并公布相關文檔、鏈接和說明，幫助設計師增強對業務的了解，讓支援的小伙伴明確協作流程和上下游對接人、以及各自負責的需求在不同時間節點的進度。

2. 分配具體任務，設計各方向負責人做好協調工作

設計工作處于需求落地推進的第一階段，研發同事需要結合設計稿才能進入前臺界面功能開發階段，所以前期設計師工作壓力會比較大。

尤其是面對時間周期比較緊張的項目，往往上下游采用同步推進的方式：比如設計稿不必全部產出且評審調整后才交付開發，而是設計初稿階段，下游同事已開始介入。

在需求設計階段，很有可能暴露出以下幾個重要問題：

• 需求功能或流程調整的信息沒有同步，導致負責不同終端的設計師，針對相同功能的設計方案不同。
• 需求調整或者信息沒有及時通知相關人，導致設計交付時間可能延后。
• 由于產品可能按照不同業務線或者不同終端劃分負責的需求，某個設計師的設計方案中可能使用到其他設計方案的設置：需要設計師之間配合，結合各自業務綜合考慮調整方案…

因此設計各方向負責人，需要及時協調解決出現的信息不同步問題，把控設計稿評審和交付進度，對不同設計方案，從業務角度進行全局質量和細節把控。

3. 組織設計稿評審

設計稿評審是需求推進過程中的重要一環，因為交互設計師承擔著將產品需求、業務邏輯、任務流程，以及易用性相結合，轉化為界面的職責，所以交互稿的評審非常重要。

交互稿評審目的是讓上下游同事更加直觀的了解需求，研發可以據此判斷頁面邏輯復雜度與工作量，視覺設計師可以提前構思頁面排版與風格。交互設計師會針對評審會提出的功能點技術實現問題、現有設置是否合理等問題，在評審會后統一調整定稿。

即便是非常緊急的項目，仍然建議組織交互評審?？紤]到緊急項目中上下游同事時間寶貴，可以集中某個時間段，依次安排不同需求的交互方案評審。

4. 配合研發跟進解決問題

當需求設計階段結束之后，接下來就該研發小哥們擼起袖子加油干了。在需求研發階段，經常會出現以下問題：

• 部分功能設置因為技術實現問題，不得不尋找替代方案，可能需要對現有設計方案做調整。
• 由于多人協作，可能針對相同操作場景，會出現不一樣的設置，需要做全局性的規則說明。
• 研發對于設計稿中的細節有困惑，需要得到設計師的及時反饋…

基于以上各種可能出現的問題，設計師需要及時跟進處理，不然嚴重的話會影響開發進度。

三、項目收尾階段

1. 設計驗收與問題跟進

面對上線周期比較短的項目，當測試人員完成第一輪“跑通業務功能流程”的測試之后，設計師便需要介入，開始設計還原度驗收。驗收階段需要解決以下問題：

• 設計師匯總的驗收問題、解決進度和結果、以及無法解決的原因等，需要建立一份驗收清單，便于項目組相關成員及時查閱和跟進。
• 按照項目中不同需求內容模塊，在驗收清單中建立不同的驗收匯總表。另外強調一個細節：設計驗收往往需要上傳示例圖，推薦使用石墨文檔（石墨文檔支持上傳單元格圖片，這個功能真的是很棒）。
• 驗收表中明確寫清楚問題的來源終端、解決結果、備注說明、提出人、解決人等。

另外項目中的部分需求可能按照不同時間節點發布，優先驗收發布時間點早的需求。設計協調人需要及時跟進開發和測試，提前通知相關設計師留意設計驗收的優先級。

2. 收集設計師記錄的問題和優化建議

設計驗收完成之后，驗收清單中的問題大致分為這幾類：已解決、未解決待優化、無法解決。我們需要重點將“未解決待優化”的問題按照某些維度分類匯總、并給出設計部建議的優先級，便于后續版本迭代。

此外可以向參與項目的每一位設計師收集他們的建議和想法，包括業務邏輯、操作流程和體驗、易用性、視覺呈現等不同方面。一些好的建議和觀點，同樣可以為后續版本迭代提供參考。

3. 提前與產品溝通，在后續版本逐步解決待優化問題。

上面已經提到了，對于驗收清單中未解決待優化的問題、以及設計師基于自身對業務思考得出的想法建議，設計部各方向負責人需要按照某些維度，比如功能模塊、終端、頁面功能點等維度分類匯總。然后與相關產品同事提前溝通，按照待解決問題的優先級排期。

總結

以上是我經歷整個項目之后的一些經驗總結，不同公司不同類型的項目，協調管理流程肯定存在差異，但是對于項目啟動階段的準備工作、過程中的問題把控，以及收尾階段的歸納梳理，本質上是一致的。

#專欄作家#

Viksea，微信公眾號：Viksea的設計思考（ID：viksea-ux），人人都是產品經理專欄作家。關注電商領域產品業務和用戶體驗，擅長邏輯分析。

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。