優化草圖文件：創建 Reduce 應用程序的經驗教訓（案例研究）

Sketch 為文件大小帶來了全新的標準。 您不再到處看到 10 GB 的 Photoshop 文件。 儘管如此，仍然存在巨大的 Sketch 文件，它們會降低 Sketch 的速度。 結果，您的工作效率也會降低。

老實說：不是設計文件變大了。 是設計師在他們的文件中填充了未使用、未優化和隱藏的元素，佔用了不必要的空間。

我們在創業公司 Flawless App 中遇到過這個問題。 我們傾向於為每個產品提供一個單獨的 Sketch 文件。 “產品”是指我們的核心菜單欄應用程序、網站、社交資料、新聞資料袋、我們的 Medium 博客上的文章插圖等等。 由於不斷的迭代和對不同設計決策的測試，這些文件過去會隨著時間的推移而增長很多。 結果，Sketch 越來越難以以適當的性能管理它們。

和其他工程師一樣，我們決定編寫一個小腳本來自動清理和優化 Sketch 文件。

腳本很棒——也就是說，如果您使用與終端相同的語言。 最終，我們決定需要一種更人性化的方法來讓團隊中的更多人使用它。 我們還想讓它在以後免費和公開可用。

第一個原型

在繪製任何 UI 之前，我有一些抽象概念。 主要目標是製作出讓我們始終觸手可及的東西，並讓我們能夠盡快優化文件。 菜單欄應用程序是一個顯而易見的選擇：

1. 我們已經有一個菜單欄應用程序的內部框架，實現了很多自定義功能。 給你一些背景知識：我們的核心產品 Flawless App 是一個菜單欄應用程序，它可以將預期的設計與開發人員的實現進行實時比較。 這個內部框架是為我們的核心產品構建的。
2. 即使 Sketch 未打開，您也可以使用菜單欄應用程序。
3. 開發原生 macOS 應用程序對我們來說比使用 CocoaScript 的 Sketch 插件要快得多（因為我們之前的經驗）。

讓用戶能夠為不同的文件切換不同的優化選項也很重要。

這是第一個線框，繪製在老式紙上，沒有花哨的原型製作工具。

經驗教訓#1

在做任何 UI、花哨工具中的原型甚至是紙上的線框之前，請考慮一下您需要通過設計實現哪些目標。 誰將使用它，以及用戶將如何與應用程序交互。

調色板和排版

在與團隊的討論中，我們沒有在線框中發現任何關鍵的用戶體驗問題。 我首先創建了一個調色板並選擇了一個字體模式。

我希望該應用程序輕巧且在視覺上與我們的核心產品 Flawless App 不同。 所以，我想出了以下調色板：

第一行是文本顏色（加上開頭的淺色背景）。 第二行是強調色。 所有顏色都是通過對 HSB 顏色系統應用簡單規則（H 代表色相，S 代表飽和度，B 代表亮度）從一種基本強調色派生而來的。

假設我們有一個基色 #4A90E2（藍色），在 HSB 中是 (212, 67, 89)。 為了獲得更暗的顏色，我們需要降低亮度，增加飽和度並稍微移動色調。 因此，我們將得到#2477C9，即 HSB 中的 (210, 82, 79)。 我對所有其他顏色都使用了相同的方法。

最終，我選擇了第一個調色板（橙色）。 Sketch 文件和 Sketch 標誌也是橙色的，所以我們的應用程序看起來更有機。

經驗教訓#2

顏色對我來說總是很棘手。 我通常會花很多時間尋找合適的顏色。 以下是我幾乎每天使用的一些資源來幫助我探索顏色：

• Adobe Kuler 可以幫助您找到任何顏色的顏色伴侶。
• Khroma 是一種基於 AI 的工具，可根據您的喜好生成調色板。
• Erik Kennedy 的文章“UI 設計中的顏色：一個（實用的）框架”是一個純粹的寶石。 我大約八個月前讀過它，從那時起，我在 Sketch 中使用 HSB 顏色系統比 RGB 多得多。

關於排版，在大多數情況下，最好使用原生 macOS 應用程序的默認字體，除非您正在構建超級自定義的東西。 渲染時間更快，並且在開發過程中更容易實現。 但我很高興能在原生 macOS 應用程序中嘗試蒙特塞拉特，我無法抗拒。

經驗教訓#3

有很多很棒的資源可以探索字體。 儘管如此，我還是使用老式的 Google 字體來了解一種特定的字體。

第一次設計迭代

我完全從我在初始線框中繪製的內容開始。 這是應用程序中的一般用戶流程：

1. 拖放草圖文件。
2. 選擇優化選項。
3. 縮小所選文件。
4. 保存。

我在 Sketch 中進行設計，我對整體 UI 非常滿意。 因為我之前設計了一個菜單欄應用程序，所以文本大小和邊距對我來說是相當標準的。 然而，第一次迭代有一些明顯的問題，我將在後面描述。

經驗教訓#4

如果您以前從未為 macOS 設計過任何東西，那麼一定要查看 Facebook 桌面設計工具包。 你會在那裡找到所有常見的 macOS UI 元素。 它會讓你了解 UI 元素的大小和偏移量。 對於 macOS 菜單欄應用程序，12 到 14 磅的字體大小是完全正常的。

問題 #1：遺漏狀態

一切都很棒，除了我忘記在應用程序處理 Sketch 文件時在中間建立一個狀態。 根據我的經驗，設計階段的錯過狀態等於開發階段的頭痛。

開發人員多久抱怨設計師在真空中設計？ 你知道，他們談論的是中間缺失狀態、空狀態、使用完美數據集等問題。

經驗教訓#5

在將您的設計發送給開發人員之前，請確保您沒有忘記任何東西。 確保你已經指定了所有狀態，這樣開發人員以後就不會問你，“這在 [某些特殊情況] 下應該如何？” 找到這些遺漏狀態的一個好方法是使用原型工具。 到目前為止，Sketch 的 Craft 插件（由 Invision 創建）及其原型設計功能是進行此類測試的最快方法。

問題 #2：自定義元素過多

您幾乎總是在為特定平台進行設計。 在我們的例子中，它是 macOS。 macOS 已經有了一些標準元素。 因此，除非您的產品在沒有定制解決方案的情況下無法工作，否則請在有意義的地方使用標準元素。 開發人員也會感謝您。

考慮到這些想法，我刪除了自定義復選框並將其替換為默認複選框。 我還通過刪除所有不必要的自定義指標來簡化進度窗口。

經驗教訓#6

為了了解每個平台的默認元素，我建議查看這些材料：

• iOS：Apple UI 設計資源，可用於 Sketch、Photoshop 和 Adob​​e XD
• Android：材料設計套件
• macOS：Facebook 桌面工具包

問題 #3：結尾不夠強調

在與團隊進行了幾次反饋會議後，很明顯最終屏幕超載了。 沒有跡象表明文件大小從優化中改變了多少。 所以，我製作了一個單獨的屏幕，上面有一個很好的壓縮文件插圖和帶有文件大小信息的標籤。

經驗教訓#7

我們使用 Slack 作為交流的主要場所。 Send to Slack 是一個小插件，可以將 Sketch 中的畫板直接共享到 Slack 頻道。 這對於團隊反饋會議非常方便。 分享更多，經常分享。

問題#4：大細節

以下問題是在開發過程中發現的。 但無論如何我都會把它們放在這里以保持文章的結構一致。

我開始實施設計。 第一次啟動後，我意識到用戶無法退出應用程序。

我們還希望通過我們自己的渠道而不是 Mac App Store 來分發我們的應用程序。 因此，向應用程序添加自動更新系統對我們來說至關重要。 並且用戶應該能夠看到當前版本並檢查更新。 我最終得到了一個菜單，該菜單在一個地方顯示了這些信息和輔助操作。

最後錯過的細節是關閉優化文件並返回主屏幕而不進行任何保存的功能。 我添加了與右上角“優化列表”窗口中相同的“關閉”按鈕。

經驗教訓#8

與開發人員密切合作總是有益的。 即使在我的情況下，由同一個人進行設計和開發，立即查看所有問題也具有挑戰性。 我必須真正開始構建才能看到這些功能問題。 無論如何，請盡快讓開發人員參與進來。 您可以獲得很多關於功能性事物的寶貴見解。

準備開發設計

最終，設計迭代結束了。 好吧，從技術上講，設計迭代永遠不會結束。 所以，假設我們達到了一個足夠好的狀態，我們可以進入開發階段。

在實施設計之前，我固定了元素的間距，確保所有元素都與 4 像素參考線對齊。 這種以指南為導向的思維方式將在開發階段獲得回報。

經驗教訓#9

當所有元素都正確排列時，您的開發時間將大大減少。 因為我也負責開發，所以我直接從 Sketch 獲得了所有的屬性。 但是確保所有元素都在正確的位置，所有顏色都來自同一個調色板，並且資產已準備好用於多種分辨率，這絕對是有意義的。

標誌和名稱

最後但並非最不重要的一點是，我們的應用程序的名稱很快就出現了。 我想到了兩個詞：“減少”和“縮小”。 我檢查了 Product Hunt，“shrink”已經在使用，所以我們選擇了“reduce”。

徽標對我來說是一場真正的鬥爭。 因為它是一個菜單欄應用程序，所以我必須先為菜單欄創建一個圖標。

因為菜單欄圖標必須是 16 × 16 像素，所以最好不要使用任何微小的元素。 圖標應同時具有獨特性和可讀性。

經過幾天與簡單形狀的鬥爭，我放棄並打開了谷歌字體的“精選”部分。 我一直在尋找一種適合徽標（以及菜單欄圖標）的漂亮彎曲字體。 最終，Pacifico 字體出現了，它非常適合我們的目標。

經驗教訓 #10

請記住，macOS 中有兩個版本的菜單欄：深色和淺色。 為兩者準備菜單欄圖標。 此外，測試您的圖標如何與默認選擇背景一起使用。 默認情況下，當用戶按下菜單欄圖標時，macOS 將使用用戶在其常規設置中選擇的任何顏色突出顯示它。 （Apple 在 macOS 中有一個很好的顏色指南。）為了測試它，我為所有默認顏色創建了符號，以便我可以在它們之間切換並查看圖標在不同背景下的外觀。

使用初始調色板中的強調色，我將“R”放在一個帶有微小彎曲邊框的圓圈中。 那時，這個標誌對我來說已經足夠好了。

結論

還有很大的改進空間。 正如我所提到的，設計迭代永遠不會結束。 但是，如果您永遠迭代，產品將永遠保留為模型。 發貨快更好。 短迭代意味著更快的反饋，更快的反饋意味著更好的產品。 Reduce 應用程序是在一個半星期內完成的，因為我們的主要目標是讓它快速且有用。

我們收到了來自團隊的大量積極反饋。 事實證明，菜單欄應用程序比終端腳本使用起來更快、更容易理解。 此外，在我們的公開發布期間，社區為我們提供了很多關於下一步可以實施的功能以及我們如何改進應用程序的想法。

以下是我們在創建 Reduce 應用程序中學到的東西的總結：

• 在製作任何線框或原型之前，請考慮產品的目標和用例。
• 使用 Adob​​e Color 和 Khroma 等工具更快地選擇正確的調色板。 對 HSB 顏色系統的基本了解也會有所幫助。
• 不要害怕嘗試自定義字體。
• 每個平台都有自己的一套標準。 在設計之前學習它們。
• 使用原型工具來了解整個流程。
• 不要用自定義元素壓倒您的設計。 有時最好堅持給定平台的默認控件。
• 儘早獲得有關您的設計的反饋。
• 儘早讓開發人員參與進來。 您可以獲得很多關於功能元素的寶貴見解，以及實現“帶有螺旋動畫的小漸變按鈕”需要多少時間。
• 使用平台標準網格來排列所有元素。 開發人員稍後會感謝您。
• 在最終確定 UI 之前，針對不同的用例（如淺色和深色菜單欄）測試您的設計。

如果您覺得 Reduce 應用程序也可以簡化您的生活（以及您的 Sketch 文件），您可以免費下載。 請給我們一些反饋。 我們相信這是可以從用戶那裡得到的最有價值的東西。