使用Figma做交付時你需要注意這些！

今天繼續給大家分享一篇來自我們小姐姐翻譯的文章，有關figma如何給開發人員做交付的過程，figma在今年可謂是風頭十足，那麼他在正式工作協作中會有什麼出色表現呢，我們來看看吧！

作為一名產品設計師，我曾與許多產品團隊一起合作。我的職責是確保原型圖的簡潔和細節的完美，然後再進行產品設計交付。為了改進原型圖的質量，我歸納總結了一份質量評估清單。通常，我能夠用它來幫助我考量我的設計稿是否在交付前足夠完善，保證我可以產出最佳的交付方案。本文討論了我如何為開發夥伴提供一套完美的原型圖，同時能夠呈現所有必要的交付信息，並為設計師和工程師提供無縫的交付體驗。

1.為工程師創建標注

我非常注重像素的完美度。特別是在寫標注時，我往往會有細節上的強迫症，但這也保證了給工程師所準備的原型質量。這裏指的標注不僅僅是一係列的設計參數，它們是設計師與工程師之間的交流基礎，我希望能通過這份文檔，確保我設計中所需要傳達的信息和功能都是正確的。

“標注文檔”表示最終的設計交付品，並能夠向負責開發的同事發出可以開始搭建產品的信號。

過去我都用Zeplin來編寫產品開發交付的標注文檔，但因為我現在的工作流程都以Figma為中心，所以我在設計文檔中創建了一個名為“工程頁麵”的新頁麵來進一步優化這個環節。

設計文件中的工程頁麵

‍身為設計師，我們必須承認我們已經住在Figma裏麵了；然而我們做開發的小夥伴並沒有那麼多Figma的實踐經驗。所以單獨創建一個頁麵，可以讓工程師們以開發為中心去使用，而不需要他們看到設計師的各種設計迭代和框架（同理Sketch中的“Artboards”也是如此）。

‍設計師混亂的Figma文檔示例

如今促進協作已經成為了Figma基因的一部分。為開發的同事創建獨立的頁麵之後，利用Figma的評論功能，能夠讓設計師和工程師就視覺元素進行提問和討論。

用評論標注特定UI組件的截圖

‍這一個文檔保存了設計過程的所有部分（從概念到交付），為項目提供了單一信息源（SSOT），也為未來的迭代提供了寶貴的參考資源。

2.標注規範

添加標注在大部分人看來很枯燥，但我總會在這件事上投入額外的時間和精力，並相信它會幫助我的同事更有效率地進行產品開發。我會用大部分的標注集中解釋設計的結構和基礎參數，例如：間距、字體排版和顏色。但我也喜歡增加一些額外的參數來幫助工程師簡化搭建流程。

在Lyft產品語言（LPL）中，空格、字體和顏色都是一些既定的屬性。我們推薦設計師參考使用這些屬性，因為它們是用一係列別稱來標記的代碼。我們將這些別稱用於設計和開發，從而成為了設計和開發在同一個頁麵裏進行交流溝通的暗號。你可以跟你開發的同事說：“當你在Figma中打開“檢查/Inspect”麵板，你就可以看到顯示這些信息的別稱（見下圖）。”

把重要的組件信息附在“檢查/Inspect”麵板，用於支持開發流程

當我創建標注時，我通常會先在設計中重新鏈接屬性。在每個文本層中，我都會在將它們重新鏈接到LPL裏的字體排版屬性，接著我會重新鏈接LPL的顏色屬性。

在Lyft，我和一位非常有天賦的安卓工程師Alex Lockwood合作開發一些Figma插件。他創建了一個設計掃描器（Linter）給我們用來檢查未鏈接的字體和顏色。這有助於我和其他設計師更快地完成這個流程。有了他的插件，我們就可以快速地重新鏈接到這些新的屬性。

這個掃描器，也叫Lint或Linter，是一種靜態代碼分析工具，用來標記編程錯誤、 bug、風格錯誤和可疑結構。這一術語來自Unix工具，用於檢查C語言源代碼。-維基百科

‍Lyft創建並使用了Figma的設計掃描插件

我們標注清單上的下一個信息是間距的細節。雖然工程師可以通過點擊圖層來查找UI元素之間的間距，但如果我能直觀地給他們顯示這些間距，事情會變得更簡單。為了傳達這一信息，我需要把標記間距的圖層覆蓋在原型圖層的上方。

用於傳達間距信息的圖層截圖

通常，我的標注文件包含了以上的信息之後，工程師就可以順利地開始構建了。但是我想要更進一步細分化，加入一些關於其他設備平台的參數標注。盡管大多數設計都是基於iOS手機的尺寸和Apple的人機界麵指南（HIG），但是由於我希望自己的設計能夠被所有用戶真正地接納，並考慮到要兼顧我做安卓開發的同事——我必須要精通全平台的規範。在編寫標注和深入研究這些通用規範的應用實例和UI模式時，我參考了Apple的人機界麵指南、穀歌的Material Design和微軟的Fluent設計係統等設計規範原則。

給iOS工程師的交付標注

‍給安卓工程師的交付標注

3.額外要注意的

像前麵提到的，我（過分）專注細節。在與很多產品團隊一起工作後，我發現過去的交付文檔仍然缺少了一條可以進一步簡化開發工作的信息。以前開發的同事最常問我的問題是：這個組件是否是新增的，或是定製過的？這促使我找到一種能更簡單地傳遞這些信息的方法。這裏可以通過兩種方式來實現：使用組件來覆蓋，或者利用組件自帶的描述。

方法一：

組件覆蓋的方法能夠幫助工程師區分組件是否是設計係統當中一部分。如果設計原型裏使用的是屬於設計係統的某個組件，我會在上麵放置一個透明的圖層，然後用已有組件的名字標記。這個方法可以幫助我與開發同事溝通，讓他們能夠輕鬆地在源代碼中找到這個組件。

特定組件的透明覆蓋層

方法二：

在Figma中，添加組件覆蓋是一個手工過程。對於任何發布過的組件，都可以在描述裏包含以關鍵詞和表情形式表示的信息。因此，我們可以利用組件描述來做標注。在組件的“檢查/Inspect”麵板中，我們可以通過添加諸如“[LPL]核心UI—[平台][組件名]”之類的特定短語來添加組件描述。

‍

帶有特定關鍵字的Android / iOS按鈕組件

在確定完成了以上的標注之後，我認為這份交付文檔已“準備就緒”。從我的經驗來看，以下這些是交付後耽誤工程師進行開發的常見障礙：

未鏈接的字體和顏色

元素之間的間距值不統一

有哪些組件是在設計係統裏的，哪些是定製過的，指示不明確

雖然這是一個枯燥的工作環節，但這方法不僅幫助你提交了一份完美的原型圖，也幫助你簡化了很多交付和開發上的流程。

4.設計交付清單

幫助你確保與開發團隊進行高質量交付的清單：

①在Figma中創建一個單獨的頁麵，並將其命名為“工程頁麵（?For Engineering）”

②檢查是否已經把設計內的元素（字體和顏色）鏈接到設計係統屬性中

③用不同顏色在設計上標記關於間距的細節

④基本間距是8px的因數（即，兩倍間距為16px：2 x 8 = 16），具體原理和方法可以參考往期文章：原創 | 8點柵格係統總結歸納和用法

⑤對應其他係統尺寸大小（iOS和Android，桌麵端和移動端）進行標注

⑥檢查原型圖裏是否使用了設計係統裏的組件，並在這些組件上放置文字名稱覆蓋（或檢查這些組件是否包含了相關的描述信息）

5.總結

不同的公司從設計到工程的交付流程似乎大有不同，即使在一家公司，我也看到過完全不同的流程被應用到各個團隊當中。在我看來，沒有絕對正確的方法，隻要你一直記得要試圖去回答“我做的工作是否能幫助到我的開發同事？”，那麼從一個項目到另一個項目的交付就會變得越來越有效率。

（本文來源於微信公眾號@應謀鬼計，譯者：大魚海棠Rena，頭圖作者：Mariah Barnaby-Norris）