<b>本文講的是以開發人員方式傳遞設計，</b>
<b></b>
長标題：像在開發環境中搭建 UI 一樣在 Sketch 中設計
首先，這将是本文中唯一一次提到 Photoshop。現在是 2017 年了，為自己好，去下載下傳 Sketch（或者 Figma — 隻要不是 Photoshop 就行） 用吧。
UI 設計已經有了長足的發展，圖像處理程式也是如此（如果你現在還這麼稱呼它們的話）。仍記得在 GIMP 中建立我們的第一套 UI 時的場景，現在，有了 MacBook，我們可以用 Sketch 完成幾乎所有與 UI 相關的所有工作啦。
事情是這樣的，盡管，Sketch 是為設計人員打造的。其使命是幫助設計人員建立使用者界面 — 你可以用它建立相當驚豔的東西。但不要忘了，你是在打造一個産品，在設計被傳遞時，你的工作才算完成，而不是當你“定稿” Sketch 檔案時。
你的設計必須經由開發人員在開發環境中建構。這就是問題所在：如果你比較 Sketch 和開發環境中的 UI 建構工具（或者 IDE，比如 Xcode、Android Studio)，就會發現兩者相似之處并不多。
開發人員建構你的設計的方式，與你作為一個設計師在 Sketch 中建立的方式完全不同。如果這麼想，聽起來有些蠢，不是嗎？
Xcode、Sketch 和 Android Studio（和一些閃電符号）
沒關系，這篇文章就是介紹一種設計方法，它更接近開發人員建構你的設計時的方式（好拗口）。
你知道 Sketch 中的 Symbol 功能，是吧？當開始用 Sketch 時，我們對這個功能非常着迷，因為這如此接近開發人員建構 UI 的方式。多數情況下，當你觀察例如清單項或者操作欄時，它們都可以看作一個獨立的源視圖不斷被複用。
像開發人員一樣設計，最重要的指導原則就是根據視圖來思考你的設計。将 View 視為獨立的一組元素，它們已定義了邊界，并按照層次排好順序了。
例如，在我們的 Nimber 安卓應用中，将搜尋結果頁分成兩個主要視圖：由操作欄和包含了使用者位置輸入及篩選卡片組成的頂部視圖，傳回搜尋結果的清單視圖。
在上面的線框圖和結構圖中，你可以看到視圖的邊界是如何在設計中被清晰定義的。Sketch 檔案中有一些不可見的圖層（透明度為0%），這在交給開發人員時非常有用。
看下面操作欄是如何被分解成更小的視圖的。
視圖層級的最頂層
操作欄視圖
100% 透明度時的操作視圖元素
確定不要随機把圖層分類。以清晰的方式定義它們的尺寸和間距（避免奇數），并按層級順序排序。
同樣的原則也适用于圖層的樣式，當你需要統一的邊框、圓角、陰影時，也可以這樣做。
當你傳遞設計後，開發人員可以在 Zeplin 中提取某個元素的尺寸、邊距、留白等資訊，再在 IDE 中建立相應的視圖。
為什麼會在這裡。。。
按 1x 設計指的是，首先你不需要計算其他螢幕的比例大小，重要的是，你和開發人員最終都用相同的參數。這樣可以防止傳遞你的設計時出現計算錯誤，保持一組統一的值。
這是适用于視圖尺寸、文本尺寸、行高等絕大部分與數字相關的設計。
一次建立，多次重用。嘗試使用盡可能少的顔色。
開發人員最常用的命名是 Primary, Secondary, Accent, Enabled, Disabled 等。你可以按同樣規則命名。Primary 和 Secondary 可以是你的文本顔色，Accent 可以是你的品牌主色調，你懂的。
在 Sketch 裡，你可以用顔色拾取器來儲存這些顔色，但就我所知，沒有什麼可以在 Sketch 檔案之外共享它們的好辦法。然而你可以用你的調色闆的顔色、它們的名字和 hex 碼建立一個畫闆。這樣當開發人員用 Zeplin 打開你的設計時，就能快速提取出這些顔色，在應用的代碼中使用它們。
Nimber 應用中我們用到的顔色。
牢記開發人員不是在建立完美的 UI，而是在建立接近理想 UI 的東西。他們不得不處理無網絡連結、或伺服器響應錯誤、或者沒有内容顯示的等很多情況。
我們生活在一個多螢幕尺寸的時代，是以不得不相應地進行設計。當為 Android 系統設計時，這個尤為重要，因為它的裝置有各種各樣的尺寸。
“正确”的方式是為手機螢幕（7 英寸以下）、7 英寸的平闆、10 英寸的平闆電腦各設計一套 UI。Master-Detail Flow 是一種将清單和詳情面闆組合在一起複雜的布局，如下圖所示：
并非所有使用者都是在英語環境中使用應用。時刻想着，在其他的語言中，文字的長度可能較長（或者較短），在設計布局時，必須要考慮到這個因素。
不要過于挑剔 — 你不可能控制每一個像素。由于不可預知的資料，應用程式的某些部分設計不可避免地不完美。
嘗試使用平台内置的互動方式、手勢、過場及動畫特效，開發人員會感謝你的。
多與開發人員溝通！讓他們指導你。雖然 Zeplin 和 Flinto 這類工具是與開發人員共享設計的好方法，但是它們不能解釋應用每個部分的行為。分享知識，努力實作最好的産品。
<b>原文釋出時間為：2017年3月03日</b>
<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>