Design Language & Nguyên tắc thiết kếDesign Language & Principles
Thuộc bộ kiến thức Design System Roadmap.
Tổng quan
Một design system chỉ mạch lạc khi những ý tưởng đứng sau nó mạch lạc. Trước khi ai đó vẽ một cái nút hay đặt tên cho một color token, cả team cần thống nhất sản phẩm nên “cảm” như thế nào và quy tắc nào dẫn dắt mọi quyết định được đưa ra nhân danh nó. Sự thống nhất đó gồm hai phần: design language — kho từ vựng thị giác và tương tác giúp sản phẩm có một cá tính nhất quán, dễ nhận ra — và design principles — tập quy tắc tường minh giúp định hướng hàng ngàn quyết định nhỏ theo đúng cá tính đó mà không cần hỏi lại designer mỗi lần.
Bỏ qua bước này, design system sẽ trở thành một component library vô hồn: nhất quán về mặt kỹ thuật (ai cũng dùng chung component button) nhưng thiếu nhất quán về triết lý (không ai giải thích được vì sao cái nút lại trông như vậy, hay nên làm gì khi gặp tình huống mới mà thư viện chưa lường trước). Bài này sẽ đi qua cách xây dựng design language từ brand identity, cách viết principle thực sự ràng buộc được quyết định, vì sao thuật ngữ dùng chung là vấn đề nền tảng (chứ không phải tiểu tiết), và design language khác — cũng như nuôi dưỡng — design system như thế nào.
Kiến thức nền tảng
Design language là gì
Design language là tổng hòa các lựa chọn về thị giác và tương tác khiến mọi màn hình, mọi component, mọi câu chữ trong sản phẩm cảm giác như đến từ cùng một nơi. Nó bao gồm:
- Shape (hình khối) — bán kính bo góc, phong cách icon, đường viền tổng thể (bo tròn mềm mại hay sắc cạnh hình học).
- Color (màu sắc) — độ rộng bảng màu, độ bão hòa, triết lý về độ tương phản (trầm và tiết chế hay đậm và bão hòa).
- Typography (chữ) — lựa chọn font, “giọng nói” mà kiểu chữ truyền tải (serif vs. sans-serif, humanist vs. grotesque).
- Motion (chuyển động) — đường cong easing, thời lượng, transition nhanh gọn dứt khoát hay chậm rãi mượt mà.
- Tone of voice (giọng văn) — cách nội dung nói chuyện với người dùng (trang trọng vs. thân mật, ngắn gọn vs. giải thích chi tiết).
- Spatial rhythm (nhịp không gian) — mật độ, khoảng trắng, kỷ luật lưới (grid).
Một khi đã có design language, không quyết định nào trong số này là ngẫu nhiên — mỗi cái đều là biểu hiện của cùng một cá tính nền tảng. Đó là bài kiểm tra cho một design language thực thụ: nếu bạn có thể đoán được một component hoàn toàn mới nên trông và hoạt động ra sao chỉ bằng cách hiểu design language, thì language đó đang làm đúng nhiệm vụ. Nếu mỗi component mới lại cần một cuộc tranh luận chủ quan từ đầu, nghĩa là language chưa tồn tại, hoặc chưa được tài liệu hóa đủ rõ để dùng được.
Nên phân biệt design language với hai khái niệm lân cận:
- Brand identity là tầng chiến lược — giá trị, định vị, cá tính của công ty (ví dụ: “chúng tôi là lựa chọn đáng tin cậy, không màu mè giữa một thị trường hào nhoáng”). Thường do team marketing/brand sở hữu, thể hiện rõ nhất qua logo, trang marketing, quảng cáo.
- Design language dịch brand identity thành các quy tắc thị giác và tương tác ở cấp giao diện mà product designer và engineer có thể áp dụng thực tế lên màn hình, component, trạng thái.
- Design system (phần cơ chế) hiện thực hóa design language thành các artifact tái sử dụng, có tài liệu, sẵn sàng đưa vào sản xuất — tokens, components, patterns.
Từ giá trị thương hiệu đến quyết định thị giác
Phần việc khó nhất và giá trị nhất khi định hình design language là dịch: biến một tính từ thương hiệu trừu tượng thành một quyết định thị giác cụ thể, có thể tranh luận. Các giá trị như “đáng tin cậy,” “vui vẻ,” “cao cấp,” hay “hiệu quả” không có một cách thể hiện thị giác duy nhất đúng — nhưng một khi cả team đã chọn một cách diễn giải, cách diễn giải đó cần được áp dụng nhất quán ở mọi nơi.
| Giá trị thương hiệu | Diễn giải thị giác khả dĩ | Diễn giải thị giác khác |
|---|---|---|
| Đáng tin cậy | Xanh dương lạnh, bão hòa thấp; bo góc sắc/tối giản; heading dùng serif hoặc sans grotesque; chuyển động chậm, chắc chắn | Cũng có thể thể hiện bằng ảnh chụp thật và testimonial dày đặc — cách dịch không duy nhất, nhưng phải được chọn có chủ đích |
| Vui vẻ | Bảng màu bão hòa, ấm; bo góc lớn; font bo tròn/humanist; easing nảy (bouncy) có overshoot | Icon minh họa thay vì ảnh chụp thật |
| Cao cấp | Bảng màu trung tính, tiết chế, tương phản cao; khoảng trắng rộng rãi; serif tinh tế hoặc sans cao cấp; chuyển động chậm, kín đáo | Điểm nhấn kim loại/gradient dùng thưa, như một “chữ ký” chứ không lan tràn |
| Hiệu quả / thực dụng | Bố cục thông tin dày đặc; ít trang trí; transition gần như tức thời; font monospace hoặc condensed cho dữ liệu | Ít biến thể màu hơn — một màu accent mạnh, dùng để chức năng chứ không để trang trí |
Bài tập mà một team nên làm rất đơn giản: liệt kê 3–5 tính từ thương hiệu, sau đó với mỗi tính từ, buộc mình đưa ra một quyết định cụ thể trên các trục hình khối, màu sắc, chữ, chuyển động. Viết quyết định đó ra — và quan trọng không kém — viết ra nó loại bỏ điều gì. “Đáng tin cậy” loại bỏ màu neon và easing nảy kiểu vui nhộn sẽ hữu ích hơn nhiều so với việc để “đáng tin cậy” mãi là một tính từ mà ai cũng diễn giải khác nhau.
Design principles: điều gì làm nên một principle tốt
Một design principle là một câu ngắn, dễ nhớ, giúp ai đó ra quyết định mà không cần leo thang lên cấp trên. Bài kiểm tra cho một principle tốt là nó phải đủ cụ thể để có thể bác bỏ — nghĩa là phải hình dung được một phương án thay thế hợp lý mà principle này không chọn. “Thân thiện với người dùng” không qua được bài kiểm tra này — không ai thiết kế thứ gì rồi nói “vâng, cái này cố tình không thân thiện với người dùng.” Nó không đưa ra bất kỳ định hướng nào khi hai phương án đều “có vẻ” thân thiện nhưng lại mâu thuẫn nhau. Một principle tốt gọi tên một tradeoff thật, và nói rõ sản phẩm nghiêng về phía nào.
Vài ví dụ thực tế minh họa rõ điều này:
- Google Material Design — “Material is the metaphor.” Câu này neo mọi quyết định thị giác vào một ẩn dụ vật lý: bề mặt có độ cao (elevation), đổ bóng, phản hồi khi chạm giống như giấy và mực thật. Nó đủ cụ thể để giải quyết tranh cãi — nếu một tương tác đề xuất không thể giải thích được bằng ẩn dụ giấy/mực (ví dụ một phần tử vừa đổ bóng vừa lại đi xuyên qua bề mặt thấp hơn), principle này nói rằng nó sai.
- Shopify Polaris đưa ra các principle như “Merchant-obsessed” (thiết kế cho người đang vận hành doanh nghiệp, không phải chỉ vì tính mới lạ thẩm mỹ), và nói rõ ràng rằng họ thiết kế cho bối cảnh chuyên nghiệp, mật độ cao, dùng lặp lại nhiều lần — chứ không phải một app tiêu dùng thông thường. Điều này giải quyết những xung đột thực tế, ví dụ ưu tiên mật độ thông tin và tương tác thân thiện với bàn phím thay vì các pattern rộng rãi, ưu tiên gesture phổ biến trong app tiêu dùng.
- IBM Carbon nhấn mạnh các principle xoay quanh sự tin cậy cho doanh nghiệp, accessibility là yêu cầu nền tảng (không phải “có thì tốt”), và nhất quán trên một danh mục sản phẩm khổng lồ, đa dạng — điều này giải thích vì sao Carbon có xu hướng lựa chọn thị giác tương đối bảo thủ, dày đặc thông tin.
- Atlassian Design System ưu tiên “clarity over cleverness” (rõ ràng hơn là khéo léo), thúc đẩy team giải quyết sự mơ hồ theo hướng chọn phương án dễ hiểu ngay lập tức hơn, kể cả khi có một phương án “thông minh” hơn khác.
Điểm chung của những ví dụ này: mỗi principle đều chọn một phe. Nó không cố gắng làm hài lòng tất cả mọi người; nó đánh đổi tường minh với một phương án thay thế thật mà một designer hợp lý có thể đã chọn.
Viết design principles của riêng bạn
Một khung làm việc khả thi cho team lần đầu viết principle là một “thẻ” ba phần cho mỗi principle:
- Tên (Name) — một cụm từ ngắn, dễ nhớ (2–5 từ), có thể nói ra trong một câu chuyện hành lang hay một comment trong code review.
- Giải thích một dòng — principle này giải quyết tradeoff nào, và nghiêng về phía nào.
- Ví dụ do/don’t cụ thể — một quyết định giao diện thật hoặc gần thật minh họa principle đang hoạt động, tốt nhất đi kèm với phương án bị từ chối.
Ví dụ thực hành:
Principle: “Progressive disclosure, not overwhelm.” (Bộc lộ dần dần, không gây quá tải) Giải thích: Chỉ hiển thị những gì cần cho bước hiện tại; các tùy chọn nâng cao chỉ xuất hiện khi người dùng chủ động tìm đến. Do: Màn hình settings hiển thị năm tùy chọn phổ biến ngay từ đầu, phần “Advanced” thu gọn mặc định. Don’t: Màn hình settings hiển thị phẳng cả ba mươi tùy chọn trên cùng một trang vì “power user có thể cần bất kỳ cái nào.”
Một kỷ luật hữu ích: phác thảo 8–10 principle ứng viên, sau đó kiểm chứng từng cái bằng câu hỏi “tôi có nghĩ ra được một màn hình thật trong sản phẩm, nơi tuân theo principle này đồng nghĩa với việc từ chối một phương án nghe có vẻ hợp lý khác không?” Nếu câu trả lời là không, principle đó quá mơ hồ để giữ lại. Đa số team hội tụ về khoảng 3–7 principle cuối cùng — đủ ít để nhớ được, đủ cụ thể để viện dẫn trong một buổi design review mà không cần giải thích thêm.
Khái niệm chính
Thuật ngữ và naming: vì sao từ vựng chung quan trọng
Design language không chỉ là thị giác — nó còn là từ vựng. Nếu một team gọi component là “Modal” còn team khác gọi cùng pattern đó là “Dialog,” sự mơ hồ sẽ chồng chất: engineer xây các component gần như trùng lặp, tìm kiếm trong tài liệu trả về kết quả không đầy đủ, designer bàn giao file mà reviewer hiểu nhầm, và việc onboarding thành viên mới mất nhiều thời gian hơn vì cuộc trò chuyện nào cũng cần một vòng “khoan, ý bạn là cái nào?” Naming không phải là việc “sổ sách” hình thức — nó là giao diện giữa ý định thiết kế và các artifact (code, tài liệu, file thiết kế) hiện thực hóa ý định đó.
Glossary (bảng thuật ngữ) là artifact khắc phục điều này: một danh sách duy nhất, chính thức, mỗi thuật ngữ có một tên ưu tiên, một định nghĩa ngắn, và các từ đồng nghĩa bị loại bỏ được liệt kê rõ (hoặc chuyển hướng về tên chính thức). Một mục glossary có thể trông như sau:
| Thuật ngữ chính thức | Định nghĩa | Từ đồng nghĩa đã loại bỏ |
|---|---|---|
| Dialog | Bề mặt modal ngắt luồng hiện tại, yêu cầu người dùng ra quyết định trước khi đóng | Modal, Popup, Overlay (khi nói riêng về pattern này) |
| Toast | Thông báo tạm thời, không chặn luồng, tự động biến mất | Snackbar (trừ khi team cố tình dùng thuật ngữ của Material), Alert (dành riêng “Alert” cho một component khác, mang tính lâu dài hơn) |
| Badge | Nhãn nhỏ thể hiện trạng thái hoặc số lượng, gắn vào một phần tử khác | Tag, Chip, Pill (nên định nghĩa là các component riêng biệt nếu hệ thống có nhiều hơn một) |
Naming convention cho components và tokens
Ngoài glossary về khái niệm, design language còn cần quy ước về cách xây dựng tên, để mỗi tên mới có thể đoán trước được thay vì bị “sáng tác” tùy hứng mỗi lần.
- Đặt tên component thường theo mẫu
Category+Variant+Modifier(ví dụ:Button/Primary/Disabled,Card/Elevated). Một số team mượn tư duy kiểu BEM từ CSS — Block (Card), Element (Card__Header), Modifier (Card--elevated) — kể cả bên ngoài phạm vi class CSS, vì nó cho một hình dạng tên nhất quán, dễ phân tích trong file thiết kế, component library và tài liệu. - Đặt tên token nên mang tính ngữ nghĩa (semantic), không phải theo giá trị thô, ở bất cứ đâu token thể hiện ý định thay vì một giá trị cụ thể: ưu tiên
color-background-dangerhơncolor-red-500, vì tên ngữ nghĩa sẽ sống sót qua một lần rebrand (danger có thể chuyển sang màu cam) trong khi tên theo giá trị thô sẽ trở nên gây hiểu lầm. Một quy ước phân lớp phổ biến là:- Global/reference tokens: giá trị thô (
blue-500 = #1565C0). - Alias/semantic tokens: tên theo ý định, trỏ tới một global token (
color-action-primary = blue-500). - Component tokens: giới hạn phạm vi cho một component cụ thể (
button-primary-background = color-action-primary).
- Global/reference tokens: giá trị thô (
Sự phân lớp này (được trình bày chi tiết ở bài về tokens) chỉ hoạt động nếu quy ước đặt tên được viết ra và áp dụng nhất quán — nếu không, mỗi người đóng góp sẽ tự sáng tạo cách riêng, và hệ thống phân mảnh đúng theo cách mà nó vốn được sinh ra để ngăn chặn.
Keywords và controlled vocabulary cho tài liệu
Khi tài liệu của design system phát triển, khả năng tìm kiếm phụ thuộc vào việc gắn tag nhất quán. Một controlled vocabulary (từ vựng có kiểm soát) — danh sách từ khóa cố định, đã thống nhất, dùng để gắn tag cho component, pattern, guideline — giúp tìm kiếm và tham chiếu chéo trở nên đáng tin cậy. Nếu không có nó, một component như date picker có thể được gắn tag là “date,” “calendar,” “input,” “form-field,” hay “picker” tùy vào ai viết trang đó, và tìm kiếm theo một từ khóa duy nhất sẽ bỏ sót các từ còn lại. Với controlled vocabulary, mỗi người đóng góp chọn từ cùng một danh sách hữu hạn các danh mục và tag (ví dụ: một taxonomy cố định gồm “Component type,” “Pattern,” “Status: stable/beta/deprecated,” “Platform: web/iOS/Android”), nhờ đó tìm kiếm, lọc, điều hướng hoạt động dự đoán được trên toàn bộ trang tài liệu.
Design language khác design system như thế nào
Đáng để làm rõ ranh giới giữa hai artifact này, vì việc nhầm lẫn chúng gây ra vấn đề thực sự (team tranh luận về “principles” trong một pull request spec component, hoặc tranh luận về giá trị pixel trong một buổi workshop thương hiệu).
| Khía cạnh | Design language | Design system |
|---|---|---|
| Trả lời câu hỏi | ”Vì sao chúng ta chọn quyết định này? Nó nên ‘cảm’ như thế nào?" | "Quyết định này được hiện thực hóa và tái sử dụng ra sao?” |
| Artifact | Giá trị thương hiệu, principles, hướng dẫn tone of voice, mood board, glossary | Design tokens, components, patterns, code, thư viện Figma |
| Chủ sở hữu | Lãnh đạo brand/design, thường phối hợp cùng product | Team design systems, engineer, designer cùng phối hợp |
| Tần suất thay đổi | Hiếm — gắn liền với sự tiến hóa của thương hiệu | Thường xuyên — component mới, cập nhật token, sửa lỗi |
| Hệ quả nếu thiếu | Hệ thống cảm giác thiếu nhất quán về tinh thần dù đồng nhất về mặt thị giác | Language mãi chỉ là ý định, không có cách áp dụng ở quy mô lớn |
Mối quan hệ này diễn ra theo cả hai chiều: design language định hướng những gì hệ thống nên xây dựng (một language “vui vẻ” ngụ ý các motion token nảy nhẹ và component bo góc lớn), và ngược lại, những ràng buộc thực tế của hệ thống lại tinh chỉnh language (nếu engineering không hỗ trợ được easing overshoot trên thiết bị cấu hình thấp, principle về motion trong language cần được sửa lại thành thứ khả thi). Nên coi đây là một vòng phản hồi (feedback loop), không phải một lần bàn giao duy nhất.
Best Practices
Bám rễ mọi quyết định thị giác vào một giá trị thương hiệu đã nêu rõ, không phải sở thích cá nhân. Khi tranh luận về bán kính bo góc hay độ bão hòa màu nổ ra, câu hỏi có ích không phải là “bạn thích cái nào hơn?” mà là “cái nào thể hiện tốt hơn giá trị thương hiệu mà chúng ta đã thống nhất?” Điều này biến những bất đồng chủ quan thành những bất đồng có thể giải quyết được.
Giữ danh sách principle ngắn gọn và đã qua kiểm chứng. Ba đến bảy principle mà mọi người có thể đọc thuộc lòng còn tốt hơn hai mươi cái chỉ nằm trong một tài liệu chẳng ai đọc lại. Nếu một principle chưa từng được viện dẫn để từ chối một phương án thật, hãy đặt câu hỏi liệu nó có thực sự hữu dụng không.
Viết phần “don’t” cẩn thận không kém phần “do.” Một principle chỉ đưa ra ví dụ được chấp thuận rất dễ bị hiểu nhầm thành một sở thích phong cách. Đi kèm với một phương án bị từ chối sẽ làm rõ tradeoff — và do đó làm rõ “sức nặng” thật sự của principle.
Quản trị và version hóa glossary như code. Coi các quyết định đặt tên là artifact có chủ sở hữu, có changelog, chứ không phải truyền miệng. Khi một thuật ngữ thay đổi (ví dụ “Popup” chính thức bị loại bỏ để dùng “Dialog”), hãy cập nhật glossary, thêm ghi chú redirect/alias, và thông báo thay đổi — đừng để hai tên tồn tại song song vô thời hạn.
Đưa engineering vào sớm trong việc đặt tên và viết principle. Những tên gọi và principle nghe hay trong một buổi workshop nhưng không sống sót khi va chạm với API thực tế của component (xung đột tên với từ khóa dành riêng của framework, principle giả định các pattern tương tác mà tech stack không hỗ trợ) sẽ gây ma sát về sau. Một buổi kiểm tra thực tế ngắn với engineering ngay từ đầu rẻ hơn nhiều so với việc đổi tên sáu tháng sau.
Định kỳ kiểm tra độ trôi (drift). Mỗi quý, lấy ngẫu nhiên một số màn hình đã lên sản phẩm và kiểm tra xem chúng có còn phản ánh đúng design language và principles đã nêu hay không. Language và principles đúng vào thời điểm ra mắt sẽ âm thầm lỗi thời khi có tính năng mới và thành viên mới tham gia; việc kiểm tra định kỳ giúp phát hiện điều này trước khi nó trở thành chuẩn mực mới (nhưng chưa từng được ghi lại).
Đừng để phần design language chỉ dừng ở một mood board không có sức nặng. Một trang gồm các tính từ và hình ảnh truyền cảm hứng là điểm khởi đầu, không phải sản phẩm bàn giao. Sản phẩm bàn giao thực sự là bảng dịch (giá trị thương hiệu → quy tắc thị giác cụ thể) và các thẻ principle (tên → giải thích → do/don’t) mà ai đó có thể áp dụng được ngay cả khi không có designer ngồi cạnh.
Để xem những principle và từ vựng này được dịch thành các khối xây dựng cụ thể của giao diện ra sao, xem Introduction to Design Systems để hiểu design language nằm ở đâu trong bức tranh tổng thể của hệ thống, và Design Tokens & Visual Foundations để xem các quyết định thị giác nói ở đây (màu sắc, hình khối, chuyển động) được mã hóa thành các token tái sử dụng, có thể hiện thực hóa như thế nào.
Tài liệu tham khảo
Part of the Design System Roadmap knowledge base.
Overview
A design system is only as coherent as the ideas behind it. Before anyone draws a button or names a color token, a team needs to agree on what the product should feel like and what rules guide every decision made in its name. That shared agreement has two parts: a design language — the visual and interaction vocabulary that gives a product a recognizable, consistent personality — and a set of design principles — the explicit rules that steer thousands of small decisions toward that personality without anyone having to ask a designer every time.
Skip this step and a design system becomes a component library with no soul: technically consistent (everyone uses the same button component) but philosophically incoherent (nobody can say why the button looks the way it does, or what should happen when a new situation the library didn’t anticipate comes up). This note covers how to build a design language from brand identity, how to write principles that actually constrain decisions, why shared terminology is a foundational (not cosmetic) concern, and how design language differs from — and feeds into — the design system itself.
Fundamentals
What a design language is
A design language is the sum of the visual and interaction choices that make every screen, every component, and every piece of copy in a product feel like they came from the same place. It spans:
- Shape — corner radii, iconography style, silhouette (rounded and soft vs. sharp and geometric).
- Color — palette breadth, saturation, contrast philosophy (muted and restrained vs. bold and saturated).
- Typography — typeface choice, voice conveyed by letterforms (serif vs. sans-serif, humanist vs. grotesque).
- Motion — easing curves, duration, whether transitions are snappy and mechanical or slow and fluid.
- Tone of voice — how copy talks to the user (formal vs. casual, terse vs. explanatory).
- Spatial rhythm — density, whitespace, grid discipline.
None of these decisions is arbitrary once a design language exists — each one is an expression of the same underlying personality. That’s the test of a real design language: if you can predict how a brand-new component should look and behave just by knowing the language, the language is doing its job. If every new component requires a fresh subjective debate, the language either doesn’t exist yet or isn’t documented well enough to be usable.
It helps to distinguish design language from two neighboring ideas:
- Brand identity is the strategic layer — the company’s values, positioning, and personality (e.g., “we are the trustworthy, no-nonsense option in a flashy market”). It’s usually owned by marketing/brand teams and expressed most visibly in the logo, marketing site, and advertising.
- Design language translates brand identity into interface-level visual and interaction rules that product designers and engineers can actually apply to screens, components, and states.
- Design system (the mechanics) implements the design language as reusable, documented, production-ready artifacts — tokens, components, patterns.
From brand values to visual decisions
The hardest and most valuable work in defining a design language is translation: turning an abstract brand adjective into a concrete, arguable visual decision. Brand values like “trustworthy,” “playful,” “premium,” or “efficient” don’t have a single correct visual expression — but once a team commits to an interpretation, that interpretation should be applied consistently everywhere.
| Brand value | Possible visual translation | Possible visual translation (alternate) |
|---|---|---|
| Trustworthy | Cool, low-saturation blues; sharp/minimal corner radii; serif or grotesque sans for headings; slow, deliberate motion | Could also be conveyed with heavy use of real photography and testimonials — translation isn’t unique, but it must be chosen deliberately |
| Playful | Saturated, warm palette; large corner radii; rounded/humanist type; bouncy easing curves with overshoot | Illustrated iconography instead of photographic imagery |
| Premium | Restrained, high-contrast neutral palette; generous whitespace; refined serif or high-end sans; slow, understated motion | Metallic/gradient accents used sparingly as a signature, not throughout |
| Efficient / utilitarian | Dense information layout; minimal decoration; fast, near-instant transitions; monospace or condensed type for data | Fewer color variants — one strong accent color used functionally, not decoratively |
The exercise a team should run is simple: list 3–5 brand adjectives, then for each one, force a concrete decision across shape, color, type, and motion. Write the decision down and — critically — write down what it rules out. “Trustworthy” ruling out neon accent colors and playful overshoot easing is more useful than “trustworthy” left as an adjective everyone interprets differently.
Design principles: what makes one good
A design principle is a short, memorable statement that helps someone make a decision without escalating it. The test of a good principle is that it is falsifiable and specific enough to disagree with a plausible alternative. “Be user-friendly” fails this test — no one would ever design something and say “yes, this is intentionally not user-friendly.” It gives zero guidance when two user-friendly-seeming options conflict. A good principle names a real tradeoff and states which side of it the product favors.
Some real-world examples illustrate this well:
- Google Material Design — “Material is the metaphor.” This grounds every visual decision in a physical metaphor: surfaces have elevation, cast shadows, and respond to touch the way physical paper and ink would. It is specific enough to resolve arguments — if a proposed interaction can’t be explained via the paper/ink metaphor (e.g., an element that both casts a shadow and passes behind a lower surface), the principle says it’s wrong.
- Shopify Polaris states principles like “Merchant-obsessed” (design for the person running a business, not just for aesthetic novelty) and being explicit about designing for a professional, high-density, repeat-use context rather than a casual consumer app. This resolves real conflicts, e.g., choosing information density and keyboard-friendly interactions over the more spacious, gesture-first patterns common in consumer apps.
- IBM Carbon emphasizes principles oriented around enterprise trust, accessibility as a baseline requirement (not a nice-to-have), and consistency across an enormous, multi-product portfolio — which explains Carbon’s comparatively conservative, information-dense visual choices.
- Atlassian Design System favors “clarity over cleverness,” pushing teams to resolve ambiguity in favor of the option that is more immediately understandable, even if a cleverer alternative exists.
What these have in common: each principle takes a side. It doesn’t try to be everything to everyone; it explicitly trades off against a real alternative a reasonable designer might have chosen instead.
Writing your own design principles
A workable framework for a team writing its first principles is a three-part card for each principle:
- Name — a short, memorable phrase (2–5 words) that can be said in a hallway conversation or code review comment.
- One-line explanation — what tradeoff the principle resolves and which side it favors.
- A concrete do/don’t example — a real or realistic interface decision showing the principle in action, ideally paired with the alternative it rejects.
Worked example:
Principle: “Progressive disclosure, not overwhelm.” Explanation: Surface only what’s needed for the current step; defer advanced options until the user asks for them. Do: A settings screen shows five common options up front, with an “Advanced” section collapsed by default. Don’t: A settings screen shows all thirty options flat on one page because “power users might need any of them.”
A useful discipline: draft 8–10 candidate principles, then stress-test each one by asking “can I think of a real screen in our product where following this principle would mean rejecting an option that otherwise looks reasonable?” If the answer is no, the principle is too vague to keep. Most teams converge on somewhere between 3 and 7 final principles — few enough to memorize, specific enough to invoke in a design review without further explanation.
Key Concepts
Terminology and naming: why a shared vocabulary matters
A design language isn’t just visual — it’s also lexical. If one team calls a component “Modal” and another calls the same pattern “Dialog,” the ambiguity compounds: engineers build near-duplicate components, documentation search returns incomplete results, designers hand off files that reviewers misread, and onboarding new team members takes longer because every conversation needs a round of “wait, which one do you mean?” Naming isn’t cosmetic bookkeeping — it’s the interface between design intent and the artifacts (code, docs, design files) that implement it.
A glossary is the artifact that fixes this: a single canonical list of terms, each with one preferred name, a short definition, and explicitly listed synonyms to avoid (or redirect to the canonical term). A glossary entry might look like:
| Canonical term | Definition | Deprecated synonyms |
|---|---|---|
| Dialog | A modal surface that interrupts the current flow and requires a decision before dismissal | Modal, Popup, Overlay (when referring specifically to this pattern) |
| Toast | A transient, non-blocking notification that appears and auto-dismisses | Snackbar (unless the team deliberately adopts Material’s term), Alert (reserve “Alert” for a different, persistent component) |
| Badge | A small label indicating status or count, attached to another element | Tag, Chip, Pill (these should be defined as distinct components if the system has more than one) |
Naming conventions for components and tokens
Beyond a glossary of concepts, a design language needs conventions for how names are constructed, so that new names are predictable rather than invented ad hoc each time.
- Component naming typically follows a
Category+Variant+Modifierpattern (e.g.,Button/Primary/Disabled,Card/Elevated). Some teams borrow BEM-style thinking from CSS — Block (Card), Element (Card__Header), Modifier (Card--elevated) — even outside of CSS class names, because it gives a consistent, parseable shape to names in design files, component libraries, and documentation alike. - Token naming should be semantic, not literal, wherever the token expresses intent rather than a raw value: prefer
color-background-dangerovercolor-red-500, because the semantic name survives a rebrand (danger might become orange) while the literal name would become misleading. A common layered convention is:- Global/reference tokens: raw values (
blue-500 = #1565C0). - Alias/semantic tokens: intent-based names that point to a global token (
color-action-primary = blue-500). - Component tokens: scoped to a specific component (
button-primary-background = color-action-primary).
- Global/reference tokens: raw values (
This layering (covered in depth in the tokens note) only works if the naming convention is written down and applied consistently — otherwise every contributor invents their own scheme and the system fragments exactly the way it was meant to prevent.
Keywords and controlled vocabulary for documentation
As a design system’s documentation grows, discoverability depends on consistent tagging. A controlled vocabulary — a fixed, agreed-upon list of keywords used to tag components, patterns, and guidelines — makes search and cross-referencing reliable. Without one, a component like a date picker might be tagged “date,” “calendar,” “input,” “form-field,” or “picker” depending on who wrote the page, and a search for any single term misses the others. With a controlled vocabulary, every contributor picks from the same finite list of categories and tags (e.g., a fixed taxonomy of “Component type,” “Pattern,” “Status: stable/beta/deprecated,” “Platform: web/iOS/Android”), so search, filtering, and navigation behave predictably across the whole documentation site.
Design language vs. design system
It’s worth being precise about the boundary between these two artifacts, because conflating them causes real problems (teams end up debating “principles” in a component-spec pull request, or debating pixel values in a brand workshop).
| Aspect | Design language | Design system |
|---|---|---|
| Answers | ”Why do we make this choice? What should it feel like?" | "How is this choice implemented and reused?” |
| Artifacts | Brand values, principles, tone-of-voice guides, mood boards, glossary | Design tokens, components, patterns, code, Figma libraries |
| Owner | Brand/design leadership, often collaborative with product | Design systems team, engineers, designers jointly |
| Changes | Rarely — tied to brand evolution | Frequently — new components, token updates, bug fixes |
| Failure mode if missing | System feels inconsistent in spirit even when visually uniform | Language stays an intention with no way to apply it at scale |
The relationship runs both ways: the design language informs what the system should build (a “playful” language implies bouncy motion tokens and rounded-corner components), and the system’s real-world constraints in turn refine the language (if engineering can’t support the overshoot easing curve on low-end devices, the language’s motion principle gets revised to something achievable). Treat them as a feedback loop, not a one-time handoff.
Best Practices
Root every visual decision in a stated brand value, not personal taste. When a debate about corner radius or color saturation arises, the productive question isn’t “which do you prefer?” but “which choice better expresses the brand value we already agreed on?” This turns subjective disagreements into resolvable ones.
Keep the principle list short and stress-tested. Three to seven principles that people can recite from memory beat twenty that live only in a document nobody rereads. If a principle has never been invoked to reject a real option, question whether it’s actually doing work.
Write the “don’t” as carefully as the “do.” A principle that only shows the approved example is easy to misread as a style preference. Pairing it with a rejected alternative makes the tradeoff — and therefore the principle’s actual teeth — visible.
Version and govern the glossary like code. Treat naming decisions as owned artifacts with a changelog, not folklore. When a term changes (e.g., “Popup” formally deprecated in favor of “Dialog”), update the glossary, add a redirect/alias note, and communicate the change — don’t let two names coexist indefinitely.
Involve engineering early in naming and principle-writing. Names and principles that look good in a workshop but can’t survive contact with a component API (naming collisions with framework-reserved words, principles that assume interaction patterns the tech stack can’t support) create friction downstream. A five-minute engineering sanity check up front is cheaper than a rename six months later.
Audit for drift periodically. Pull a random sample of shipped screens every quarter and check whether they still reflect the stated design language and principles. Language and principles that were true at launch quietly go stale as new features and new contributors join; an audit catches this before it becomes the new (undocumented) norm.
Don’t let the design language section become a mood board with no teeth. A page of adjectives and inspiration images is a starting point, not a deliverable. The deliverable is the translation table (brand value → concrete visual rule) and the principle cards (name → explanation → do/don’t) that someone can actually apply without a designer in the room.
For how these principles and this vocabulary translate into the concrete building blocks of an interface, see Introduction to Design Systems for where design language fits in the overall system, and Design Tokens & Visual Foundations for how the visual decisions described here (color, shape, motion) get encoded as reusable, implementable tokens.