如何評價 Teambition 的設計語言 Clarity Design？

12-17

Teambition 的設計語言 - Clarity Design

Teambition 設計師

當初設計 Clarity Design 這套語言，更多是為了根據自身的一些設計實踐沉澱和總結一套自己的指導規範，提高設計和研發的效率與質量，輸出標準統一的產物。無意去對標一些國內外的大公司，如：支付寶的 - Ant Design，Google 的 - Material Design ，更多的是為了解決一些自身實際的問題和完善自身的設計沉澱。

畢竟，Material Design 是 Google 花了4年的時間，組建了一個龐大的設計師團隊專門來干這件事，其中遇到的問題也是困難重重。在後面的實踐運用也很多地方都一直受人詬病（[Material Design is Different, Not Better](https://android.jlelse.eu/material-design-is-different-not-better-87909af6ffe1)），但 Material Design 依然是一套優秀的設計言語，它的出現給整個界面設計行業設立了一個榜樣，對於一些設計新人來說，它絕對可以堪稱是目前史上最為完善和系統的學習教材。

Teambition 是一個創業公司，資源有限，前後也就兩三個設計師在負責整體的設計工作，在三個月內完成 Clarity Design 的第一版雛形，已經符合我們的預期。雖然還有很多不足，但我們會持續的去完善它。對於創業公司而言，能夠有意識並且願意付出實踐去做這件事，足以說明內部對設計本身的關注程度。

其實，Clarity Design 分為兩部分，一部分是面向設計，主要是的為了：

幫助新來的設計師更快速融入 Teambibion
降低設計和開發的學習、溝通成本
幫助輸出風格統一、高質量的設計
整理相應基礎組件，提高設計的效率（相應的源文件會整之後理在相應的類型下，但只有內部成員可見）

另一部分是面向研發(目前外部人員看不見)，主要是通過編寫標準、統一的控制項來降低研發的成本，提高研發的效率。

設計語言的沉澱本身就是一件長期投資的事，對公司後期的發展而言，它所產生的價值和影響是巨大的。然而在國內，去重視這件事，並努力去把它付出實踐的公司真的不多。

對於設計師來說沉澱和總結一套自己的設計指導規範，一直是內心深處非常渴望去做的一件事。除了每天的工作，我們也很渴望能夠把自己的積累和實踐能夠很好的沉澱下來並傳遞下去，雖然還有很多不足的地方，但我們希望隨著自身的不斷成長 Clarity Design 也能夠不斷的變得更為完善。

非常感謝大家的關注，我們也虛心的接受大家誠懇的建議。如果 Clarity Design 能給大家帶來一點點啟發和幫助，我們會感到非常的榮幸，因為汗水和努力得到了肯定。但對於一些無端匿名的吐槽群眾確實不敢苟同，或許把槽點勇於付出實踐，拿出更好的作品，對其他人或行業會更有幫助。

Design Language可以標誌著一家公司的設計水平，還能夠反映出公司在設計方面資源的投入狀況。在這個上面做做文章無可厚非，對外可以提高品牌知名度，對內可以提高設計部門的地位，雙贏的事情，何樂而不為？但這個東西，要想做的好，是非常考驗整個團隊的功底，同時也是一件巨量的工程，需要巨量的人力物力和時間。

先看一下Teambition公司的團隊人員 https://www.teambition.com/info/team

好像一共35個人，設計師的話估計也就六七號人。所以，精力，資源是不多的。

拋去背景再看一下內容，從交互設計師的角度來看一下Clarity Design怎麼樣吧。

設計原則：清晰、靈活、乾淨、親切。

對於設計原則，主要是給設計師看的。設計原則，是做設計決策時候的一個原則，任何一個控制項，都要先從這些原則出發，才能確保體驗的一致性。這塊內容一般難以量化，而且很抽象。對於Clarity Design來說，整體寫的確實不是很好，指導意義不明確。清晰和乾淨，內容在某種程度上有所重疊。靈活，我覺得這裡對於靈活的定義有點偏題。親切，是一個非常難以表現的概念。還有一個問題就是，這4個原則沒有優先順序。因為在設計過程中，必然會遇到概念衝突的情況。遇到這種情況，犧牲哪一條，遵從那一條是很重要的。

行業典範：Salesforce lightning

https://www.lightningdesignsystem.com/guidelines/overview/

清晰、高效、一致、美觀 4個原則依次遞減，為了清晰可以犧牲後面任何一項。描述言簡意賅，非常容易理解和遵從。甚至連導航邏輯都嚴格遵從這個原則（在web上把back按鈕都給幹掉了），這是貫穿整個系統的設計靈魂，不是為了豐滿Design Language生拼硬湊的八股文。

布局

這個東西如果拉到整個Design Language的第一層來說講的話，缺少了page level的布局和結構。而且韻律這個東西放在這比較奇怪，這應該是設計原則部分。

行業典範：SAP Fiori

Dynamic Page Layout

詳細的介紹了每一種layout的結構，組成控制項，自適應規則和交互細節。

視覺，動效，協作

這幾內容可能因為沒有開源吧，所以提供的資源不多，不做評價。

組件

這一塊內容最大的看起來太偏視覺文檔了。對於交互的部分幾乎沒有涉及，使用場景的定義，控制項結構，擴展性，控制項關聯性，交互細節等。如果說是內部的設計師，拿到sketch源文件對照著文檔看一下上手倒是蠻不錯的。如果是對外的話，內容太過基礎和匱乏了。

通常一個Design Language會有以下這麼幾個功能

作為一個指導規範，提供給第三方開發add on
作為一個指導規範，提供給內部的設計師和開發者，降低學習和溝通成本
品牌營銷，對外傳達公司的設計理念

從Clarity Design來看，它的作用屬於後兩者。內容豐富程度，沒有版本管理和搜索，推測應該還在搭建的早期階段。

總的來說，這套設計準則還是蠻規範的，但還遠達不到Design Language的成熟度。因為公司規模不大，設計資源及其有限，能夠有這樣的精力和理念確實很不錯。拿Ant Deisgn這種業界標杆來比也太不公平，估計維護Ant Design的設計師比整個teambition公司的人都多。作為設計的同行，希望Clarity Design能夠不斷的充實，成長為一套成熟的，有自己特色的Design Language。

首先，命中了 uBlock 的某條規則，導致頁面全白（可能影響範圍比較小，沒見其他人討論過）

---

說到設計語言，大家最熟悉的是 Google 的 Material Design https://material.io/ 。當然也有 Apple 從 iOS 7 開始的設計風格 Human Interface Guidelines ，以及 Microsoft 最近推出的 Fluent Design System 。

設計語言有用嗎？當然。設計語言是對設計的提煉和總結，能夠保證設計、開發和用戶體驗的統一，每個產品、網站和 App 都應該遵循設計語言。App 通常會選擇遵循各平台的設計語言，比如在 Android 平台上遵循 Material Design。也有許多 App 並不遵守平台的設計語言，除了少部分做出了體驗不錯的設計，多數都存在體驗不一致、學習成本高、使用不順暢等問題。

我的建議是每一個產品線複雜，而且有設計能力的公司都要搞一套自己的設計語言。公司規模小的話，就遵循各平台的設計語言。

但是，Web 是一個開放的平台，每個網站和 Web 應用都在做自己的風格，甚至他們自己也沒有統一的風格。在 Bootstrap 這類 Web UI 庫及 Angular/React/Vue 這類 Web 組件化框架和庫流行之後，更多的公司和開發人員開始意識到 Web 端也應該有統一的設計風格和可復用的組件庫。

螞蟻金服的 Ant Design A UI Design Language 是比較受國內前端開發者歡迎的 Web 設計語言。之所以是受前端開發者的歡迎，而非設計相關人員，是因為它提供了基於 React 的整套組件庫。實際上多數前端開發者在使用 Ant Design 的 React 組件庫時，可能並沒有詳細研究過整個設計語言的文檔，因為大家的需求就是用這套組件庫快速實現自己的業務邏輯，並不在乎其中的規則。

從設計的角度講，設計語言帶來了統一的規則，讓 UI 設計有了通用的模式。老闆說按鈕不夠大，標題不夠顯眼？我們可以搬出規則和模式來應對無理的需求。

從開發的角度講，可以做出高度可復用的組件，保證代碼邏輯清晰和容易擴展。切圖？不存在。

---

Clarity 的一些小問題：

VMware 之前出了同名的組件庫 Clarity Design System ；
二級標題沒有處理成錨點，無法直接跳轉，不方便分享；
「之間,若白駒」、「Teambition是16年3月份」等內容並沒有遵循自己的規範；
原則不夠清晰和細緻；
原則部分圖片和示例過少，大段文字看起來很枯燥；
部分文檔缺失(/guidelines/組件, Uncaught Error: Cannot find module "./組件.md".)；
動效演示頁面無法訪問(invo.design)；
組件部分與業務關聯性過強，不過也值得參考；
「數組對象集」這個組件的命名不是很合適；

不過仍然很棒，希望能夠長久地更新和維護下去。

---

我不贊成匿名用戶對組件庫的看法：

1. 組件庫只是設計語言的一個實現，並不是設計語言的核心（Material Design 的輪子這麼多，質量特別高的可是少數）；

2. 開發和維護一套開源組件庫的成本比較高，可能還需要跟公司內部的業務組件分離。沒有足夠的人力和精力，可能應付不來。

Clarity Design 官網上沒有提到這將會被實現為一個開源組件庫
設計稿風格統一可以提高工程師的生產力
是不是抄的我不知道，這個"設計語言"的風格至少與 Teambition 多年以來的設計風格是融匯貫通的，很多規範都是從大量的業務場景中提煉出來的，可以自圓其說
文檔裡面的組件設計並不是工程組件設計，而是設計組件，這一點不能從工程師角度去看。具體的工程組件設計在公司內部的 Teambition 項目裡面，並沒有開放出來
已經有一個 React 的組件庫實現，目前託管在 Teambition 內部的 Gitlab 和 cnpm 上，並沒有開源計劃。因為社區已經有非常多優秀的組件庫和相關的最佳實踐，Teambition 的 Clarity Design 誕生最初的目的並不是推廣與分享，而是將公司內部設計師的一些實踐沉澱下來，提高公司內部的設計師與工程師的生產力
公司內無論是工程師還是設計師都無意對標 Element 或 Ant Design 或其它優秀的開源組件庫，這個東西存在只是為了解決公司內部的問題，還不足以上升到回饋社區

利益相關，即將變成前 Teambition 前端工程師

這種東西叫做小白設計師的心靈毒雞湯，他們看了之後猶如撿到一本絕世秘籍，對自身職業發展充滿信心，幸福感爆棚，有種準備在前端領域大幹一番的使命感！

自從螞蟻造了個 Ant Design 然後突然「自我認知」自己是一個「設計語言」之後，各路前端 + UED 團隊們好像就覺得不這麼造輪子就顯得自己不洋氣了，光做組件庫還不行了，非要在前面加上一堆設計外行看著高大上內行看著全是廢話的「指南」。

然後這指南和組件設計吧，就是東抄抄 Apple HIG 西抄抄 Google Material Design 再從平時苦逼業務里吸收點靈感，這麼一混吧，總結出一套自己看著順眼用著還蠻去的設計規範，然後強行換個逼格高的名字順便拉低拉低「一個『創新』的設計語言」這件事的門檻。

你看這些東西也就是前端天天在這討論得熱鬧，哇新的組件庫耶。你看說到底還是組件庫，還非要憋個「Clarity Design」這種名字你自己難受不……你看餓了么那個 Element UI 多實誠啊，就是一個組件庫，不扯淡。

這類產品里，就算是發展得最為健全的 Ant Design，你出門找個靠譜點的設計師問問，這玩意有多少設計上的學習價值，但是人家使用價值多高啊：誒你前端不想折騰啊，誒我也不想折騰，就照著這玩意改改上了吧。

至於 Teambition 這個，尼瑪組件庫都還沒做出來呢，就一堆廢話 + 截圖，星星都騙不了。

為了避免友善度被扣爆，匿了。

antd算是中度偏重度使用者來說兩句，看到這個cdesign還是挺欣喜的，畢竟有多一分選擇不是壞事，還是挺希望看到ui組件庫興興向榮。

螞蟻這套東西，從pc到mobile都用了，不得不說非常完善，從文檔到功能到解答，覆蓋了業務所需。讓整個前端開發變得更輕鬆。

當然，tb這套組件庫還沒出來，不知道用起來怎樣，無論如何我還是挺期待

我覺得還是不錯的，起碼Teambition的設計和前端還是很有追求的。

設計師在設計的時候，對自家的產品肯定是有所思考的，很多組件雖然大家看起來都差不多，但是到具體的業務上又是不同的。ant design能滿足你司的需求嗎？不一定吧？這個時候如果不維護好自己的設計規範，那麼長期就會產生很多問題。比如說人員的流動，如果有了一個好的指引，新的同事來了就可以很快的理解自家產品的設計邏輯、實現方式，節省了大量的時間。作為一個對接過十來個產品經理和七八個前端的設計師來說，這樣的設計語言簡直太特么有用了。先不說是不是重複造輪子，起碼是一個有效的內部培訓工具，溝通成本降低的太多了。

不是經驗、不成知識的提問和回答，真希望 #知乎上能少點。

這種問題除了立場不同而互噴，就是中國式「閱讀題」的答覆（卯足了勁兒揣測作者含義的行為），沒啥意義。

TB 又來自問自答了？老套路了

感覺並沒有搬運 Material Design 的精髓，規範更應該是告訴讀者一個方向和思路，而不是呈現一堆組件。

適合用來提升設計素養，已轉給我在重拾設計的老婆。