iOS 開發中，設計師和工程師怎樣有效地進行溝通協作，流程如何？

01-18

一般完成的開發流程是怎樣的？交互（UX）設計師進行設計工作時，工程師的主要任務是什麼？工程師會偏好先實現看不見的邏輯層還是先會一些視覺實現？兩個角色之間如何有效地溝通和協作？工程師會在項目的哪些方面、時間點上和交互設計師檢查進度？

我就用在知乎做 iOS 開發時的流程來舉例吧。

分工

======

開發知乎 iPhone 我們的分工有三類：設計，iOS 開發，RESTful API 開發。

流程

======

設計與定義

設計師負責定義產品並進行視覺設計，@向若琿同學的習慣是初期就逐步用 PS 給出高保真的設計，加上必要的備註就就導出圖片再共享到 Dropbox；與此同時，在 iOS 和後端這邊，我們會進行一些必要的準備工作並著手一部分看不見的邏輯的開發工作，比如 iOS 和 server 交換數據的方式以及 iOS 端數據模型抽象。

隨著不斷收到各個視圖的設計圖，亦即產品定義，我和負責 API 的 @IAMSK 同學商討確定每個 API 的 spec 然後放在 Dropbox 里，因為 API 基於 RESTful 原則，API 定義非常有跡可循，可以大幅降低開發間溝通和使用 API 的成本。

此外 iOS 方面還要評估一些交互設計的可行性，然後就各自分頭去開發了。

開發

iOS 開發上，我們會將工作一分為二為視覺和模型兩部分同時進行，除了解耦和復用，更為了方便模型的單元測試。

因為設計和定義是按照一定邏輯單元給出的，比如：問題系列、回答系列，所以幾乎在整個開發過程中總是能保證 App 已經完成的部分是可以 build 及 run 的，哪怕只有查看答案一個功能時。堅持這樣做的這樣的好處是工程師隨時可以把開發的成果拿來給設計師評估，同時不至於因為總開發周期過長一點兒貨不出導致大家絕望。

這個階段，設計師會不斷將開發需要用到的資源從 PS 中切出並加上標註丟到 Dropbox 里。

同時如果 API 開發這個階段落後於 iOS 模型開發了，那麼為了不耽誤 iOS 視覺和模型的聯調，iOS 模型這邊會 switch 到 fake data 以保證順利推進。

這期間的工作，我們早期是通過 trello 來協調的，後來改用 Phabricator 了。

聯調

最後，把 App 的每個部分整合起來進行聯調。為了方便這種流程，我們抽象了一套揉和了 UIStoryboard 與 Ruby router 二者功能的庫，這樣視圖間的跳轉和數據傳遞可以相對輕鬆的在最上層定製。

總結

======

整個流程大概就是這樣的，每個步驟可能循環往複穿插進行… 概括來說，就是：

- 定義與設計

- 開發

- 聯調

定義和設計的時候從儘可能從一個小的核開始，並且按照某種邏輯單元來劃分，會讓後來的工作事半功倍。

無論開發iOS還是Android，設計師和工程師都基本是一樣的互動交流過程。

下面的流程僅適用於快速的產品開發，不適用於研究性質的探索性產品。

基本流程為：用戶研究及需求 -&> 設計 + 框架實現 --&> 細節實現，調整細節設計 --&> 修改bug，直至穩定發布。

關於流程的討論太多，這裡只提一些經驗，或能加快整個流程，或讓設計師和工程師更好的互動。

1、需求討論：這個階段不是產品經理和boss幾個人的事情，大夥一起參與到討論中，所有人，包括測試工程師。

此外，有的時候真的沒必要把需求和設計2個環節分開。放在一起討論，能討論到需求就需求，能把交互設計甚至視覺創意討論出來就繼續討論達成一致，然後再分工去整理各自的文檔。流程裡面浪費時間的地方在於不能達成一致，定不下來，一次又一次的你來我往，所以珍惜每次大夥一起討論的機會，盡量把能定下來的都定下來，定不下來的儘快組織討論，實在不行找個人拍板。基本幾輪討論下來，需求也敲定，交互框架也敲定了。

2、接著就分工去細化了。交互設計師這時需要獨處一陣了，靜下心來思考有沒有不完善的地方，細節的地方；此時，工程師也對軟體基本的架構及難點有所了解，可以開始很多很多工作了，搭框架、搭模型、資料庫建模、解決技術難點，甚至可以把確定的交互先實現。此時，保持每周1、2次的碰頭會，設計師、產品經理和工程師彼此交流進展，討論一些問題等；此外，建議交互定下來主界面以後就可以交給視覺設計師出風格了。

3、經歷了第二階段，這時交互設計師就基本完成設計部分的工作了（僅只是全部工作的20%），一定要親自把設計和工程師以及測試工程師講解一遍，不能只把文檔丟過去。視覺也基本完成了首界面的風格，開始其他界面的詳細設計了。工程師也開始瘋狂編碼。接下來視覺設計師不斷出圖、工程師不斷編碼，軟體慢慢完善。

這時，設計師（交互和視覺）和工程師碰頭次數就要增多了，最好2天見一面，聊一聊，設計師要主動看看實現的如何，確保和設計理解的一致，解決些界面上的bug，不合理之處等；工程師也要主動和交互反饋問題，實現難度等，遇到技術瓶頸，雙方要儘快協商出妥協的辦法。產品經理也別閑著，組織設計師和工程師溝通，看看哪裡缺個什麼圖、缺個什麼交互，趕緊去要，參與解決問題，並大量的開始試用產品，用相對第三方的眼光去檢驗，有條件找幾個用戶用用。

原則就是：有問題早發現、早解決。

這個階段尤為漫長，從開發到最後的交付穩定版本，容易出設計實現的問題，因為時間長，除了開發和測試工程師外，其他各個環節都容易懈怠和鬆懈，特別是設計師。因為基本設計已完成，文稿也已發出，看似主要工作已經完成，剩下的都是別人按設計實現的過程，很可能此時也被領導委派到別的項目組，所以和項目組的溝通次數會減少，關注程度也會減少。這必然是不可取的，設計師自己設計的產品自己都不盯著，出了問題就是設計師的責任。一定要時刻牢記在心：設計師的工作20%是設計，80%是用盡各種辦法讓你的設計盡量完美的落地，如果你的設計落不了地，那只是紙上談兵，價值不大。

項目管理工具太多太多，任何可以協同的工具都可以作為項目管理工具。我們嘗試過：Evernote、Github、trello、QQ群以及Excel等，效果都差不多，關鍵是團隊使用統一的工具，具備每天使用這個工具進行項目管理的習慣，不要讓工具流為形式。但我認為最最有效的，是保持高效持續的溝通。

基本以上這些，希望對你有幫助。

這中間需要產品經理介入。

首先

產品經理在完成整個產品架構之後需要跟設計師和工程師進行初步溝通，向他們講解整個產品的idea，涉及到的功能邏輯等等。

接下來的步驟就是產品經理和設計師之間的協作，產品經理輸出原型，設計師將原型美化成UI。

這中間可能需要涉及到無數次的修改修改再修改，最終定稿。

定稿之後

設計師需要將設計稿輸出給工程師看，並向工程師講解界面之間交互邏輯，此時產品經理也需要在一旁解答疑問。

講道理，這就體現出作為偽美工的程序猿的好處了。