設計專案的整理演變史與優缺點比較:Zeplin,Notion,Figma

在擔任 UIUX 設計師的過程中,對於設計專案在整理與交付的流程也做了一些調整,不同的工具有其各自的優缺點,整理一下自己在這些過程中參考的內容作為紀錄,並提供給有需要的設計師參考。

Yuki,lin
8 min readJan 21, 2021

初期:Zeplin

在剛開始學習 UIUX 的過程中,只知道 Zeplin是個開發時的好工具,卻不知道他好在哪裡?協助了工程師什麼功能?解決了開發中的哪些問題?以為只要從 Sketch 上傳一張設計圖稿,工程師就可以完美的實現設計。

但即使你在 Sketch 中設定好了 Style Guide,定義一些元件的規則,上傳到 Zeplin 後都會變成單純的代碼,缺少檔案樣式與元件的關聯性,也會讓每個經手的工程師都採用不同的方式進行實作,導致日後維護的困難度提升。

你可能會說:「那我在 zeplin 額外上傳一張 style guide 的圖稿就好啦~」

但分開在不同圖稿的style,對工程師在開發時卻不能能流暢的閱讀,右側的Inspect 選單並沒有很好的連結 Style Guide 的對應關係。

圖1 截圖來源自 zeplin 官方影片

也是因為這個原因,發現了 Zeplin 的 Global Style Guide 功能,透過在 Sketch 檔案中上傳 Style Guide 到 Zeplin,就能夠連動的讓設計稿頁面都連結到對應的樣式關係,以及所屬元件的共用資料庫。

可以設定的樣式分成:Color、Text、Spacing & Layout、Component。在顯示上對應連結的視覺強度也很高,可以參考底下畫面:

  1. 字體會直接顯示對應的字體樣式
  2. 顏色也會直接顯示對應的顏色樣式
  3. 滑鼠在該區塊時可以查看到對照 Component 名稱
  4. 物件與物件中定義好的距離
圖2,圖3 截圖來源自 zeplin 官方影片

設計師可以依照各個 component 元件撰寫備註,也可以在 component 頁面中查看該 component 出現在哪些頁面,藉以確認有沒有缺漏的部分。

圖4 截圖來源自 zeplin 官方影片

然而這樣還是有它的缺點,例如樣式設定時他會參照所有的屬性,所以同樣的字型樣式,如果有置左置中置右的差別,就得獨立成不同類型的 Text style,顏色也是一樣,需要獨立出來各自設定。即使對於工程師來說:顏色、字型與對齊位置是三種不同的屬性,卻需要設定成獨立的樣式,但這就是 Sketch 的硬限制了。

而對設計師來說,Sketch 跟 Zeplin 兩邊的檔案並不同步,所以在維護上,也要特別注意樣式更新上傳後,有哪些頁面也需要連動重新上傳,否則容易出現 Zeplin 元件庫更新但設計稿上的元件漏掉更新的問題;並且,不論是Component 的備註或是分組,在 Sketch 跟 Zeplin 也都要各做一次。

中期:Notion

在 Zeplin 中上傳設計稿件後,發現除了畫面,還有其他內容需要統整在專案中:畫面流程、各種情境的文案對照、加入動態動畫的變化數值…等等,如果全部都用 comment 功能會顯得太過瑣碎,右側的備註區塊也越來越長,難以查找跟檢閱,所以希望可以將跟專案相關的資訊整理起來,方便自己以及團隊成員搜尋記錄跟連結觀看詳情。

有鑒於團隊當時,主要使用的專案排程工具以及文件資料庫就是 Notion,自然而然也將它變成設計時重要的檔案整理工具的首選。

每次有新增的專案(User Story)加入,我會開啟一個新的 Notion Template,包含:專案名稱、目的、目前進度、解決方式、流程圖、Prototype 示意等相關檔案連結。於是每個專案的資料都整理在同一份 Notion 文件,如果想要查找前期脈絡或使用者訪談的內容,也只需要從內容當中去連結到對應的資訊即可,也方便自己管理自己的設計進度。

後期:Figma

考慮到後續跟不同 Stackholder 確認畫面所需要的輸出的時間成本,以及製作 prototype 測試的設定需要在不同工具中轉換費工,我先在一個小專案試行後,就決定將所有的檔案搬移到 Figma。

雖然搬移過程滿痛苦,但現在看來的確是正確的決定。

從 Wireframe、Component 元件庫同步、檔案交付、Prototype 製作、設計畫面討論、文件整理,統統可以一步到位😇,省去很多煩雜的流程,解放工作時間。

專案的呈現方式延續過去在 Notion 的形式,也參考了其他公司的檔案分類方法,讓不同人進入到檔案後都能清楚知道各個 Page 代表的意思,並且查找到需要的內容。

圖5 Figma Project 的 Page 分類方式

結語

因為目前團隊仍算新創,只有我一個設計師,這樣的工具轉換對我而言相對單純方便,團隊成員也願意一起嘗試新工具。如果團隊擴編或是產品歷史悠久,相對之下要考慮的轉移的成本也會不同,也許可以試著在閒暇時間自主嘗試新工具,使用過後對於新的工具操作有信心的話,要引入組織可能也會更有自信。

簡單做了各個比較工具的差異(主觀心得):

圖6 三種工具的比較表格

回頭整理這樣的轉變過程,發現自己使用的工具,也隨著工作內容涉入前期研究的深度與廣度而有所改變,在不同的階段有了各自對應的需求,需要交付、紀錄的內容也有所不同,也因此接觸越來越多協助 UX 研究與溝通的工具。

感謝越來越多的工具,協助設計師在繁瑣的工作中優化流程速度,幫助設計師與其他團隊成員更快速溝通,專注時間在解決問題上。如果你有其他推薦好用的工具,非常歡迎推薦分享!

謝謝你花時間閱讀,如果我的文章對你有幫助,歡迎你拍手或是留言給我建議,你的行動可以讓我更有動力。

如果你喜歡這篇文章,請幫我拍手 1-20 下
如果你喜歡工作記錄這系列的文章,請幫我拍手 20-40 下
拍手到 50下?歡迎留言或 FB私訊給我你對文章內容的想法吧!

參考資源:

--

--

Yuki,lin

我是Yuki,喜歡閱讀、繪畫,記錄生活 現任方格子 vocus PM,之後讀書心得等最新內容,主要更新發佈在 方格子 vocus ,歡迎註冊追蹤最新文章!