不要讓工程師問問題

首先必須先說明，我知道設計的過程，溝通是很重要的一環，尤其是跟工程師溝通時，更是有助於釐清很多設計的盲點，雖然比較多時候會摩擦生熱，但是大部分的溝通是有趣的。但是，當你必須跟工程師們「遠距離溝通」時，這個過程就變得不是這麼有趣了。

我們總共有 6 個 RD，但是只有 1 個常駐在辦公室，因此我的工作必須要跟 RD 遠端連線。
因此，要如何增加溝通的效率就是我亟需解決的問題了。
增加溝通的效率目的是為了要減少彼此來回溝通的次數。

為什麼要避免互相來回確認呢？

• 會時不時打斷手邊正在進行的任務。對設計師跟工程師而言都一樣干擾。
• 來回確認次數一多，誤解的機率自然多。
• 透過電話溝通沒有記錄，用 IM 溝通沒有組織，用 Email 溝通沒有速度。
• 一直來回確認的時間日積月累下來是很可觀的。

要減少確認，就必須要讓工程師問不出問題。
對此，我認為解決的方法在於製作清楚的流程圖、原型、以及完整的說明文件。
其實工程師需要的東西是一個像 IKEA 說明書的東西。除非真的看不懂，才需要打客服 / 設計師專線。
這邊分享一些我目前認為還不錯的應用。

流程圖的部份

流程圖的繪製我使用 Draw io 這個服務搭配 Pancake 使用。
這兩個服務產生的 Combo 技讓流程圖可以在線上瀏覽，還可以即時更新。
用 Draw io 繪製流程圖很快速。在加上可以匯入截圖，所以可以從一開始只有文字的流程，改成手繪稿，最後改成 Mockup。全部使用一個網址就可以搞定。
另外因為 Draw io 產生的圖是 SVG 格式，因此觀看者可以自由的縮放大小。
這個組合真的可說是天衣無縫。

原型的部份

原型的工具有數十種，但是每一種的特性都不一樣。
我目前的選擇是 Pixate 跟 Marvel ，而這兩個運用的點也不同。
Pixate 的優點是可以很快速的做出很細緻的動態效果，我用來表達在單一頁面的動態效果。
但是缺點是分享的檔案不能原網址同步更新，必須要重新上傳一個原型並產生新的網址。

Marvel 的優點是快速的將每個頁面串在一起，適合用來表達多頁面間的關係、切換方式跟效果。
另外 Marvel 的原型是可以原網址更新的，不需要重新換一個分享網址。但 Marvel 的動畫效果僅能表達頁面的切換效果，細部的動畫像是捲動、點擊、拖曳則沒辦法製作。
這兩種原型基本上不需要為了文件特別製作，而是在設計的流程中很自然就會產出。

文件的部份

如果從一開始確認需求、繪製流程、手繪畫面草稿、Mockup、Prototype 的這個流程順利，最後一步才是製作文件。
因此文件是建立在先前討論的共識上，因此文件的功能是統整所有的結論的依據。
但這只是設計端的結論。
文件還是必須讓 RD 去評估可行性，不過大致的方向並不會改變太多。
一旦文件讓雙方達到共識，事情就變得簡單多了。
文件我分成 GUI 與 Flow。

GUI 詳細描述每個頁面以及元件的外觀，定義出一套完整的開發 Guideline。

Flow 詳細說明每個頁面應該會有的操作機制，因為有些功能的定義是無法用 Prototype 表達的。
有任何問題只需查看文件即可，不需要透過溝通來解決。
但是有時候只有文件是不夠的。還是必須要搭配原型的使用。

未來可以調正的方向

目前的方式我認為還是有很多進步空間，像是製作文件太花時間，或是必須依照需求切換不同的 Prototype 工具。
我希望可以將文件做成網頁的方式，就像 iOS 跟 Android 的方式。
這樣就不會有版本更新的問題。只是前置作業上需要花一點時間製作。
目前找到的原型工具因為需要依照特性分開使用，所以還是不夠有效率。
傳說 Adobe 正要發佈一套新的 UI 開發工具：Comet。

這套似乎要把所有 UI 設計會用到的功能包含進去：流程圖、Mockup、Prototype。
如果真的有這麼好用，我一定會馬上把原本一大堆雜七雜八的工具扔一邊，改用 Comet。

最後，面對這樣的問題，最重要的應該就是心態了。
你必須要把工程師也當作是使用者。把工程師當成是使用者，盡量將所有開發時可能需要的資料都為他們設想好。
把 User Friendly 的精神也套用到工程師身上，可以在開發時省下不少麻煩。