[TOOLS] 6 分鐘閱讀OraCore 編輯部

Microsoft Fluent 2 怎麼運作

Microsoft Fluent 2 是微軟的共用設計系統,串起 Microsoft 365、Windows、Teams 和 Azure,靠 tokens、元件與跨平台規則維持一致。

分享 LinkedIn
Microsoft Fluent 2 怎麼運作

Microsoft Fluent 2 是微軟的共用設計系統,串起 Microsoft 365、Windows、Teams 和 Azure。

說真的,這套東西很硬。微軟要同時管桌機、手機、網頁、原生 App。還要讓 365、Windows、Teams、Azure 看起來像一家人。

這篇重點很單純。就是看 Microsoft Fluent 2 怎麼靠共用規則,撐起一整個產品宇宙。你如果做過軟體介面,就會知道這件事有多麻煩。

項目內容
平台Web、Windows、iOS、Android、macOS
產品Microsoft 365、Windows、Teams、Azure
框架支援React、React Native、原生框架
設計重點簡化、一致、跨平台協調

Fluent 2 在解什麼問題

訂閱 AI 趨勢週報

每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。

不會寄垃圾信,隨時可取消。

微軟不是只做一個產品。它是做一整串產品。這些產品的使用情境差很多。Office 文件、雲端控制台、聊天工具、作業系統,全部都要長得有關聯。

Microsoft Fluent 2 怎麼運作

Fluent 2 的工作,就是把這些差異收進同一套規則裡。它提供 tokens、元件、互動邏輯。設計師和工程師不用每次都從零開始吵。

講白了,沒有設計系統,團隊就會各做各的。間距一套、字級一套、按鈕狀態也一套。做久了,產品群會像不同公司拼起來的。

  • 給設計師和工程師同一套語言
  • 元件可重用,少重工
  • 保留平台原生感,不亂長相
  • 大型團隊交付速度更穩

為什麼新版 Fluent 2 重要

Fluent 2 不是單純換皮。它把視覺語言縮得更乾淨。也把跨裝置的體驗拉得更一致。這包含間距、字體、層級,也包含你從滑鼠切到觸控時的感受。

這種系統最難的地方,不在設計稿。難在真實環境。它要扛無障礙、在地化、程式碼重用,還要面對不同平台的習慣差異。

你可以把它跟 Google Material Design 3Shopify PolarisAtlassian Design System 放一起看。大家都在解同一題,只是場景不同。

“Design is not just what it looks like and feels like. Design is how it works.” — Steve Jobs

這句話老梗,但很準。Fluent 2 不追求每個畫面都一模一樣。它要的是整體感。你一換裝置,還是知道這是微軟。

這裡有一個現實問題。產品越多,偏差越容易累積。今天一個團隊改按鈕,明天另一個團隊改卡片,三個月後整個系統就開始走鐘。

所以 Fluent 2 的價值,不只是美觀。它是在幫微軟守住產品秩序。這種秩序很無聊,但很重要。

Fluent 2 跟其他系統怎麼比

Fluent 2 最難的地方,是它得同時滿足兩件事。第一,產品要像同一家出品。第二,平台感不能死掉。這兩件事常常互相打架。

Microsoft Fluent 2 怎麼運作

Apple Human Interface Guidelines 來比,Apple 更偏平台原生。拿 IBM Carbon Design System 來比,IBM 更強在企業資料介面。Fluent 2 則是橫跨很多產品線。

這也解釋了為什麼微軟要把它做得夠彈性。不同平台的手勢、鍵盤操作、觸控邏輯都不同。你不能硬把 Windows 的互動搬到 iPhone 上。

  • Apple HIG:最重平台原生行為
  • IBM Carbon:最強企業資料與表單
  • Salesforce Lightning:強在流程和業務介面
  • Fluent 2:強在跨產品、跨平台一致性

這種比較對台灣團隊也有用。你不一定要做超大系統。可是你一定要決定,哪些元件共用,哪些地方要依平台調整。

微軟還有一個優勢。Fluent 2 有實作路徑。像 React 和 React Native 都能接。這代表設計規則比較容易落地,不會只停在 Figma

很多設計系統死掉,不是因為不好看。是因為工程團隊懶得接,或文件寫得像天書。Fluent 2 至少在這點上比較務實。

產品團隊可以學到什麼

Fluent 2 最值得學的,不是元件樣式。是它把設計系統當成決策模型。你怎麼定 token,怎麼定互動,怎麼定跨平台規則,這些都會影響開發效率。

如果你自己也在做系統,先想三件事。第一,token 要不要語意化。第二,元件在不同輸入方式下怎麼變。第三,文件要不要同時給設計師和工程師看。

再來是治理問題。設計系統不是做完就結束。它要有人維護,有版本管理,也要能接受產品線回饋。沒有治理,系統很快就變成半死不活的元件倉庫。

你也可以參考其他公司的做法。Shopify 很會寫內容規範。IBM 很重貢獻流程。Salesforce 則很擅長企業模板。

如果你想看更多案例,可以順手看 OraCore 的 設計系統案例整理。拿來對照很有感。

我自己的看法很直接。設計系統下一階段,比的不是誰圖面最漂亮。比的是誰能把無障礙、跨平台、程式碼重用一起做好。這才是硬實力。

這個系統背後的產業脈絡

設計系統會紅,不是偶然。產品數量越多,手工維護 UI 的成本就越高。尤其是 SaaS、雲端服務、企業軟體,畫面只要一亂,客服和內部支援都會跟著爆。

微軟這種公司特別需要系統化。它的使用者橫跨消費端和企業端。有人在 Windows 上工作,有人在 Teams 開會,有人在 Azure 管伺服器。每個人看到的介面都不同,但都要有一致感。

這也是為什麼 Fluent 2 值得看。它不是單一產品的 UI 指南。它是大型軟體公司怎麼維持秩序的範本。對台灣做 B2B 軟體、內部系統、雲端平台的團隊,也很有參考價值。

再講白一點。你公司如果已經有三個前端團隊、兩套元件庫、四種按鈕樣式,問題就不在設計好不好看。問題在治理。Fluent 2 就是在處理這種治理成本。

你該怎麼看 Fluent 2

如果你是設計師,就看它怎麼定規則。 如果你是工程師,就看它怎麼落地。 如果你是產品人,就看它怎麼降低溝通成本。

我會建議先從三件事下手。看 token 怎麼命名。看元件怎麼支援不同平台。看文件有沒有把例外情境講清楚。這三件事,通常決定一套系統能不能活過兩年。

我的預測很簡單。接下來的設計系統,會越來越像產品基礎建設。誰能把規則、程式碼、文件、治理串好,誰就比較不會被自己的 UI 拖垮。

如果你正在做自己的 design system,先別急著做更多元件。先問一句:你現在的規則,能不能撐住下一個產品線?