還記得沒有智能手機的時候，唯一的顯示器具有4x3的寬高比和1280x1024的分辨率。那時的主要問題是在Photoshop中剪切圓角，以制作一個在CSS中帶有圓角的按鈕。那些日子已經過去了，但復雜系統的時代已經來臨。現代設計系統可能比它們所設計的產品還要復雜。這導致了設計系統的錯誤結構，從而導致了公司所有產品的設計不足。
在本文中，將簡要討論2023年設計系統中最常見的設計錯誤。
網格布局
首先，讓我們來談談網格布局。截至2023年中期，幾乎任何東西都可以使用Web中的Flexbox + Grid + 媒體查詢 + 容器查詢來構建。任何我們想要的布局，沒有限制。然而，這種靈活性也帶來了一些挑戰，其中一些我們將在下面詳細討論。
最令人痛苦的是設計師只是拿起Figma，然后開始單獨設計布局和組件。然后將一個拉伸到另一個上面。下面的圖片有什么問題呢？
底部的組件被拉伸到了極其寬的水平。如果我們在組件中放置了照片，而實際上確實有，那么照片也會變得不雅觀。你可能會爭辯說，“卡片應該有max-width屬性”。是的，但問題在另一個層面上：我們需要一個適用于桌面Web和移動Web的簡單產品卡片作為一個組件。如果屏幕寬度為375，卡片會呈現一種方式，如果是640，它會被重新調整大小。好吧，在邊界處（639px）卡片很少看起來令人滿意。
當我們為我們的1440px設計一個組件，并將其作為可使用的組件發布到設計系統時，還會出現另一個問題。另一個團隊從設計系統中獲取該組件，然后將其添加到其1920屏幕的產品中，結果該組件總是看起來很糟糕。畢竟，它是為1440設計的！
**如何解決這個問題。**因此，我提出了這樣一個想法，即組件的適應性應該取決于環境，而不是屏幕尺寸。在Figma中，如果我們為iOS設計了375pt寬的布局，那么在“準備開發”之前，應該有一個強制性要求：在320pt寬度上檢查設計，以覆蓋iPhone 5S。所有組件都應該有約束和自動布局，以便在寬度上進行縮放而不會破壞或看起來不可接受。如果在320-375pt處的布局行為正常，那么在360pt處也會正常。如果需要，開發人員應該能夠將設計模型復制到他/她的Figma中并設置所需的寬度。
開發者端還有其他解決方案，但幾乎所有這些解決方案都不好。我的后端開發人員提出了一種稱為“后端驅動容器查詢”的方法。在后端計算正確的大小。這就是垃圾，它會復制大量的代碼，需要很長時間來引入變更，并且無法解決組件尺寸不正確和布局中組件正確定位的問題。讓我們將這個解決方案扔到桌面下的垃圾箱里。
我們在桌子上找到了另一個解決方案：調整觀察器多填充。這允許我們通過分數自動構建網格。還記得黃金法則：網格用于一般布局，Flexbox用于一些小東西。
等等，我們還有不同的平臺...老一套。讓我們無論如何討論一下。在設計系統中，將Android和iOS組件合并到一個庫中是否現實？是否值得合并它們？我們應該以什么為基礎進行合并？暫且不談那種書呆子式的回答“要看情況”...我得出的結論是，我不應該只是將不同的平臺合并到一個設計庫中。桌面依賴鼠標指針，智能手機使用手指，這就是平臺指南的基礎。Android還使用4px網格，iOS仍然在某些地方使用5px。即使在淺色和深色主題中，蘋果的指南也不建議使用陰影，在Android中，陰影非常常見。為了避免這種復雜性，目前似乎更容易和更安全地為iOS和Android各自擁有兩套組件，只要基礎代碼庫是不同的。
我們遵循一個簡單的原則：一切都需要完美地運行，否則會使擴展變得更加困難。
命名標記
不同平臺的單獨庫...這可能導致不一致性！是的，但我有一個解決方案。我們應該將通用的標記引入到共同的設計系統中，這對所有平臺都是通用的，比如標記。品牌顏色通常在所有平臺上都是相同的，所以這是一個標記。表格單元格的高度是固定的，所以也是一個標記。主要是要知道如何使用標記，這就是我接下來要討論的內容。
目前，設計師將標記視為一組常數，而不是變量。粗略地說，它們是const，在JS中不是let。常數只需定義一次，以后永遠不會被重新定義（是的，是的，是的，我知道即使const在JS中也可以被重新定義，但那不是重點）。因此，正確的標記命名至關重要，我們不必僅僅根據語義來為標記命名，即在填充物上不必像-sparter-card-medium這樣命名，有時僅使用xl就足夠了。值或語義可能會在將來發生變化，這沒問題。是的，像brand_blue這樣的標記名稱也是錯誤的。與其使用語義化的$kaspersky-color-text-disabled-on-dark這樣的名稱，我們使用通用的$kaspersky-color-palette-neutral-60。這樣，我們就可以在未來輕松進行更改，而不會丟失語義上下文。
標記只是一個技術層面的東西，用于限制變量和管理淺色/深色主題等。設計師在Figma中遇到另一個問題，他們總是在尋找或嘗試編寫插件，以便從Figma中導出變量進行開發。我認為正確的方法不是導出，而是導入。由于標記不應存在于Figma中，因為它不是一個適合的環境。真正的事實來源是JSON。甚至更多，標記不僅可以存儲在JSON中，還有更酷的東西：Common JS。在這種文件格式中，可以釋放JS的全部力量，計算一些在Figma中尚不可用的顏色邏輯。然后，標記將不再是常數，而是開始變得活躍起來。如果你愿意，你可以從Material Design插件開始探索這個主題。
從概念上講，我將設計系統的設計師視為工具的開發者。其他設計師使用這個工具，所以他們是最終用戶。更實際地說，設計系統的用戶，即中高級別的用戶，是否應該訪問標記？還是只能訪問組件？以進度條組件為例，它是一個單一的有機體。它可以有2個步驟，也可以有20個步驟，具有復雜的邏輯。從技術上講，這樣的組件是可以創建的，但試圖用變體來覆蓋所有情況是有害的。這會使組件過于復雜化，而我正試圖避免這種情況。因此，在我的團隊中，設計師有權將組件分離并進行更改，以適應他們的情況，至少是這樣。
問題在于什么可以被分離，什么不能被分離。設計師是否可以為一個產品引入自己的按鈕？目前，我認為這應該由設計系統負責人根據具體情況來決定。類比一下，迄今為止的裁決是由法院的法官作出的，因為法律并不完善，情況也非常不同，而辯護質量（律師的工作）也會影響結果。如果案件送上法庭，邏輯和審慎應該占上風，而不是嚴格的規則。對我們來說也是一樣的，如果設計師想要做一些定制的東西，而不是使用設計系統中的現成組件，那么應該允許。
想法：組件應該是方便設計師，而不是懲罰。
可讀性
原則對于所有平臺都是相同的，但我會以Android為例。在Android上，應該根據系統設置進行縮放的文本以sp（支持輔助功能設置）指定。在我的產品中，所有字體大小都在22號之內。不可縮放的文本從大于22的尺寸開始，其單位為dp（輔助功能設置不受影響）。因為這些是標題，它們本身已經足夠大，即使對于輔助功能用戶來說，也可以輕松看到。但是，應用輔助功能設置后，標題甚至可能不適應屏幕寬度。因此，標題可能會被裁剪，誰都無法閱讀文本，不僅僅是輔助功能用戶。你可能會問，為什么要根據系統設置保持字體可縮放性？我們不可以默認情況下設計所有文本，最大對比度和巨大的大小，對吧？
想一想：如果一個人因為殘疾而無法閱讀文本，那么問題會比訪問我們的站點早得多。因此，這個人已經有了解決問題的方法，只需要我們的站點/應用程序來支持。正是操作系統來處理這個問題。你可能注意到，當你激活新的iPhone時，會立即提示你啟用大約43%用戶使用的輔助功能設置。這些設置提供了許多工具，包括增強對比度、顏色反轉、字體放大等。我們的責任只是在我們的代碼庫中支持這些操作系統功能。我們不需要為視覺障礙者添加一個單獨的站點版本，只需在代碼中支持所需的設置，操作系統將以更好的方式自動完成一切。因此，我們當然不需要使占位符中的文本與填充字段一樣對比，只是為了盲目地遵循舊版本的WCAG。
非常好，但是我們如何在Figma中實現這樣的結果呢？在令牌中，文本樣式集的原則也是一樣的：對于不可縮放的元素，字體大小是固定的，這很清楚。但是對于可縮放的字體，字體大小是基本單位+乘數。
當設計師為生產準備布局時，他/她應該按照以下步驟進行：首先，在320pt的寬度下檢查布局；通過縮放字體來嘗試輔助功能。如果出現任何視覺問題，還有時間重新設計或為開發人員在有問題的地方添加評論。
結果是，我們得到一個適應性布局，可以檢查輔助功能設置，甚至有一個漂亮的設計，因為我們沒有不必要地增加文本的大小。你知道，連續增大所有字體有時會導致丑陋的用戶界面。有時候，而不總是。而用戶界面應該是美麗的，沒有丑陋的用戶界面的借口。
WCAG
我還想提出一個有趣的觀點。所有的設計師都記得WCAG是什么，但有一個問題：WCAG 2.1引入了一種確定對比度的算法，基于此算法創建了許多服務和插件。但事實證明，這個算法遠非完美。例如，算法認為黑色文本在深綠色背景上是正常的。使用這個算法可以通過對比度指數如4.5:1來確定。當然，WCAG意識到了這個問題，在WCAG3的新版本中，他們發布了一個考慮了許多參數并且更準確、更人性化的新算法。不幸的是，目前并不是所有的服務都已經轉換到新的算法，我在面試中仍然被告知對于正常文本的對比度4.5:1以及大文本的對比度3:1是足夠的。對此，我只能說 AAAAAA…
語義命名
在一個龐大的項目中，最好通過語義來設置名稱。例如，在Carbon設計系統中，只使用了語義間距。
對于顏色名稱… 當然，你可以限制自己使用簡單的主要、次要、第三、中性、負面、正面、關注、信息。這是語義的。在工作中，會出現新的組件，比如帶有星星的評分組件。如果需要單獨管理這種顏色，那么我們就為評分組件定義一個單獨的語義顏色graphic.rating-ui-200。關鍵是要理解新的UI組件是一個新實體還是現有組件的一部分。在組件級別，顏色只能從語義中分配。
請記住，產品越多，設計系統就應該越簡單，語義命名在這里效果不錯。即使只有一個產品，但設計團隊很龐大，最好也采用語義方法。減少錯誤。但要保持平衡：過度簡化和過度復雜化都是有害的。
例如，對于內邊距，使用相當簡單的8像素 = 中，16像素 = 大，24像素 = 特大，32像素 = 超大，可能是合適的。因為我們通常要避免各種各樣的內邊距和字體大小，這種命名方式有權存在。回答最常見的問題：如果我們在大和特大之間需要添加一個新的變量20像素怎么辦？由于這是一個相當罕見的情況，我們總是可以考慮一個合適的名稱。一年一次也沒關系。
我不會隱瞞“顏色命名”是一個非常有爭議的話題，每個設計團隊的需求都會有所不同。但是，了解其他團隊如何實施設計系統結構對于幫助很有幫助。
顏色比看起來更棘手
并非所有顏色在從淺色主題切換到深色主題時都會發生變化。設計系統應該有一個單獨的靜態顏色部分，這是正常且有幫助的。這些顏色不會根據主題而改變。例如，我們可以在深色主題下同時使用 text-primary 和 text-static-primary 兩個相同值的顏色。
我一直對這個系統的作者有一個問題，如果我需要在深色和較深的顏色之間添加一個中間顏色怎么辦？你能夠準確告訴我哪個顏色更亮：lighter 還是 light，而不用查看顏色本身嗎？正如我在上面幾節中所寫，我允許設計師從設計系統中分離出組件，并且我為他們提供了對令牌的完全訪問權限。這意味著顏色令牌的命名應該足夠清晰，以最小化他們在設計自定義內容時出現錯誤的機會。我如何更喜歡命名顏色？嗯，在這種情況下，語義化的命名非常適合，正如我之前所說。
現在是時候來點硬核了。有很多方法可以定義顏色方案，從非常簡單的漸變調色板到基于 ChatGPT 的復雜提示。另一個有趣的概念是基于背景顏色的連續色彩檢測。換句話說，你設置主要顏色，令牌系統會自動計算卡片、文本等的新值。每個顏色令牌不是固定值，而是一個表達式：基礎“亮度”值乘以所需對比度的系數。結果，要創建一個新的主題（淺色、深色或其他），你只需要更改基礎“亮度”值。
在嘗試實現這種方法時，我遇到了現代工具的限制。我嘗試使用 Tokens Studio 來實現這一點。我在 HSL 格式中為顏色定義了一個變量，并添加了 L + n 條件。n 是一個數字，提供所需對比度水平的亮度。但除此之外，我還必須考慮 WCAG 等額外的條件，這使得任務變得更加復雜。它變得如此復雜，以至于已經不再必要。畢竟，每個人都知道復雜的系統很容易崩潰，不易擴展，所以應該避免使用，對嗎？
但是假設你不同意我，并且你成功解決了這個問題（我也做到了）。第二個問題是 HSL 本身的不完美性。它基于 RGB 顯示器的機制，而不是人類的感知。換句話說，它是一種面向機器而非人類的系統。這種方法的最明顯問題是在更改 H 參數時亮度的不均勻性，從而導致一系列對比度問題。在這里也有解決方案，那就是切換到 OKLCH 或 LCH 顏色空間。但當然，目前在 Figma 或 Tokens Studio 中不可用。因此，我們需要再等待幾年...目前我們仍然可以使用 100-500-900 這種顏色命名。
鼓勵你不斷嘗試處理設計系統結構和命名的新方法，始終玩弄創意思維。但永遠不要忘記，每個設計師的主要目標是使服務對用戶方便。設計系統的用戶也是用戶，我們必須關心他們的便利性。
精選文章：