Localization & Cân nhắc nâng caoLocalization & Advanced Considerations
Thuộc bộ kiến thức Design System Roadmap.
Tổng quan
Phần lớn design system, mà không ai chủ đích quyết định như vậy, được xây dựng cho một ngôn ngữ (thường là tiếng Anh Mỹ), một hướng đọc (trái sang phải), các quy định pháp lý của một khu vực, và các liên tưởng màu sắc của một nền văn hóa. Những giả định đó vẫn ổn cho đến khi sản phẩm mở rộng ra toàn cầu, và lúc đó chúng vỡ ra theo những cách rất rõ ràng và tốn kém: một button ghi “Submit” vừa khít bằng tiếng Anh nhưng bị cắt cụt ngay khi dịch sang tiếng Đức “Einreichen”; một chevron “back” trỏ sang trái đúng trong layout LTR lại trỏ sai hướng ngay khi giao diện được mirror (lật gương) cho tiếng Ả Rập; một ngày được hiển thị dạng 03/04/2026 được người dùng Mỹ đọc là ngày 4 tháng 3, còn hầu hết những người khác đọc là ngày 3 tháng 4; một banner “error” màu đỏ tươi mang nghĩa nguy hiểm với khán giả phương Tây nhưng lại mang nghĩa may mắn hoặc ăn mừng ở một số nơi Đông Á; và một cơ quan quản lý ở Brussels hay một tòa án ở California có thể yêu cầu một bề mặt công bố thông tin mà thiết kế chưa từng dành chỗ trên màn hình cho nó.
Đây không phải những trường hợp ngoại lệ mà một translator hay một engineer đơn lẻ có thể vá từng màn hình sau khi sự việc đã xảy ra — đây là những mối quan tâm mang tính hệ thống, xuyên suốt, chạm đến gần như mọi màn hình của sản phẩm cùng lúc, đúng hệt lập luận mà roadmap này đã đưa ra về design token và accessibility: những quyết định có phạm vi ảnh hưởng toàn hệ thống phải được giải quyết một lần, ngay trong kiến trúc, thay vì sửa (rồi lại bị phá) theo từng màn hình. Bài viết này là chương khép lại của roadmap, tập hợp những cân nhắc “nâng cao”, thường bị bỏ sót, phân biệt một design system chỉ trông hoàn thiện ở thị trường quê nhà với một design system thực sự sẵn sàng mở rộng ra toàn cầu: sự khác biệt pháp lý theo khu vực, text expansion, layout right-to-left (RTL), component nhận biết locale, khả năng liên thông định dạng file đa nền tảng, một maturity model để đánh giá hệ thống đang ở giai đoạn nào, và multi-brand theming. Cũng như mọi phần khác của roadmap này (xem bài giới thiệu), bài học lặp lại ở đây là: đây là những quyết định kiến trúc cần đưa ra sớm, không phải tính năng gắn thêm khi khách hàng quốc tế đầu tiên phàn nàn.
Kiến thức nền tảng
Localization là một quyết định kiến trúc, không phải một tác vụ dịch thuật
Đáng để tách bạch hai thuật ngữ thường bị dùng lẫn cho nhau nhưng mang ý nghĩa khác nhau. Internationalization (i18n) là phần công việc thiết kế và kỹ thuật giúp sản phẩm có khả năng được localize: tách các chuỗi văn bản cứng ra thành resource file, xây dựng layout có thể co giãn và mirror, ủy quyền việc định dạng ngày/số cho các thư viện nhận biết locale thay vì mặc định theo quy ước tiếng Anh. Localization (l10n) là phần thích nghi thực tế theo từng thị trường, được xây trên nền khả năng đó: các chuỗi đã dịch, hình ảnh đặc thù theo khu vực, định dạng ngày tháng địa phương, cách hiển thị tiền tệ của khu vực. Mối quan hệ giữa hai khái niệm này bất đối xứng và rất quan trọng: một sản phẩm có i18n kém thì không thể được localize đúng cách dù bản dịch có tốt đến đâu — một chuỗi tiếng Đức được dịch hoàn hảo vẫn sẽ bị cắt cụt trong một button được đo kích thước theo tiếng Anh nếu component chưa từng tính đến text expansion. Đó là lý do đây về bản chất là vấn đề của design system: i18n nằm trong token, component, và kiến trúc layout, còn l10n là nội dung chảy qua đường ống mà i18n đã xây sẵn. Nếu làm sai kiến trúc, mọi locale trong tương lai đều phải trả giá; nếu làm đúng ngay từ đầu, việc thêm một ngôn ngữ hay khu vực mới trở thành một bài toán nội dung và cấu hình, chứ không phải một dự án tái kiến trúc.
Yêu cầu pháp lý và quy định theo khu vực
Luật pháp không đồng nhất giữa các thị trường, và một số nhóm quy định chuyển hóa trực tiếp thành diện tích UI mà design system phải dành sẵn và chuẩn hóa, thay vì để từng product team tự ứng biến (và tất yếu là làm sai).
| Yêu cầu | Áp dụng ở đâu | Ý nghĩa với thiết kế |
|---|---|---|
| Banner đồng ý cookie / tracking | EU (ePrivacy Directive, GDPR), các quy định tương tự ở Brazil (LGPD), California (CCPA/CPRA) | Cần một bề mặt UI thường trực, có thể đóng, chặn các tracker không thiết yếu cho đến khi có đồng ý rõ ràng, với lựa chọn “từ chối” không kém nổi bật hơn “chấp nhận” |
| Luật accessibility cho web | Mỹ (ADA, Section 508), EU (EN 301 549 / European Accessibility Act), Anh (Equality Act 2010), Canada (AODA) | Cơ chế thực thi và mức độ rủi ro pháp lý khác nhau, nhưng gần như tất cả đều tham chiếu WCAG 2.1/2.2 AA làm chuẩn kỹ thuật nền tảng — xem Accessibility & Inclusive Design |
| Công bố nơi lưu trữ dữ liệu và quyền riêng tư | EU GDPR, Trung Quốc PIPL, Ấn Độ DPDP | Thường yêu cầu màn hình đồng ý chuẩn hóa, luồng xuất/xóa dữ liệu, và nội dung privacy được localize, nên được xây sẵn thành pattern tái sử dụng |
| Luồng “quyền được xóa” / xóa tài khoản | EU GDPR (và các luật tương tự ở nơi khác) | Cần một pattern settings dễ tìm, chuẩn hóa mà hệ thống nên xây một lần, không phải theo từng sản phẩm |
| Giá bao gồm thuế vs. giá chưa gồm thuế | EU (thường yêu cầu hiển thị giá đã gồm VAT), Mỹ (thuế thường hiển thị riêng ở bước checkout) | Component giá phải hỗ trợ cả hai chế độ hiển thị, được chọn theo cấu hình locale/khu vực, không hardcode theo một thị trường |
Không điều nào ở trên là boilerplate pháp lý chung chung mà content team có thể gắn thêm sau — design system nên xây sẵn component consent banner và component giá có nhận biết thuế như những pattern tái sử dụng, có thể cấu hình theo khu vực, đúng như cách nó xây một button hay một form field. Nếu bị bỏ qua, mỗi product team sẽ tự phát minh (và thường là làm sai) phiên bản riêng, và một công ty có thể kết thúc với hàng chục cookie banner không tuân thủ trên hàng chục sản phẩm.
Định dạng ngày, số, và tiền tệ
Quy ước định dạng khác nhau ngay cả giữa những ngôn ngữ trông có vẻ tương tự nhau bề ngoài, và một giả định hardcode về “số trông như thế nào” là một trong những cách phổ biến nhất khiến design system âm thầm gãy khi ra khỏi thị trường quê nhà.
| Giá trị | Mỹ (en-US) | Đức (de-DE) | Pháp (fr-FR) | Ghi chú |
|---|---|---|---|---|
| Ngày | 03/04/2026 | 04.03.2026 | 04/03/2026 | Cùng một chuỗi số 03/04 mang nghĩa mơ hồ giữa các locale — có thể là ngày 4 tháng 3 hoặc ngày 3 tháng 4 tùy quy ước |
| Số thập phân | 1,234.56 | 1.234,56 | 1 234,56 | Dấu phẩy và dấu chấm đổi vai trò giữa phân cách thập phân và phân cách hàng nghìn; tiếng Pháp dùng dấu cách làm phân cách hàng nghìn |
| Tiền tệ | $1,234.56 | 1.234,56 € | 1 234,56 € | Vị trí ký hiệu (trước hay sau số tiền) và quy ước cách chữ khác nhau |
| Ngày đầu tuần | Chủ nhật | Thứ hai | Thứ hai | Ảnh hưởng đến layout dạng lưới của bất kỳ component lịch hay date picker nào |
Component không bao giờ được tự định dạng các giá trị này bằng cách nối chuỗi thủ công. Cách làm đúng là ủy quyền cho một API định dạng nhận biết locale — Intl.DateTimeFormat, Intl.NumberFormat, và Intl.PluralRules trên web; NSDateFormatter/NumberFormatter trên iOS; các class dựa trên ICU (android.icu) trên Android — tất cả đều lấy dữ liệu từ Unicode CLDR (Common Locale Data Repository), tập dữ liệu dùng chung về quy ước locale mà thư viện internationalization của mọi nền tảng lớn đều dựa vào. Trách nhiệm của design system là truyền đúng locale xuống một cách nhất quán qua context hoặc prop; bản thân quy tắc định dạng không bao giờ nên được viết lại thủ công.
Liên tưởng văn hóa về màu sắc
Color token (xem Design Tokens & Visual Foundations) thường được xây dựng dựa trên giả định về ý nghĩa màu sắc của một nền văn hóa — thường là cách hiểu phương Tây, trong đó đỏ báo hiệu nguy hiểm hoặc “dừng lại”, xanh lá báo hiệu thành công hay “đi”, và trắng báo hiệu sự tinh khiết. Những liên tưởng này là do học được, không phải phổ quát, và có thể âm thầm đảo ngược hoặc mất nghĩa ở một thị trường khác.
| Màu | Liên tưởng phổ biến ở phương Tây | Liên tưởng văn hóa khác | Ý nghĩa với thiết kế |
|---|---|---|---|
| Đỏ | Nguy hiểm, lỗi, “dừng lại” | Trung Quốc: may mắn, thịnh vượng, ăn mừng | Một banner “error” màu đỏ không tự động mang nghĩa tiêu cực ở mọi nơi; không bao giờ chỉ dựa vào màu sắc — luôn kèm icon và văn bản rõ ràng |
| Trắng | Tinh khiết, sạch sẽ, đám cưới | Một số nơi Đông Á: tang lễ, để tang | Tránh các minh họa “ăn mừng” toàn màu trắng mà không kiểm tra hàm ý ở thị trường mục tiêu |
| Vàng | Cảnh báo/thận trọng, mượn từ logic đèn giao thông | Ý nghĩa lẫn lộn giữa các nền văn hóa, gồm cả tang lễ ở một số khu vực và niềm vui ở nơi khác | Component cảnh báo không nên phụ thuộc vào việc ý nghĩa của màu vàng là hiển nhiên |
| Xanh lá | Thành công, “đi”, thân thiện môi trường | Ý nghĩa thay thế tùy ngữ cảnh ở một số nền văn hóa và trong bối cảnh tôn giáo/chính trị | Kiểm chứng lựa chọn “xanh lá thành công” bằng nghiên cứu thị trường mục tiêu thay vì giả định nó phổ quát |
Cách khắc phục mang tính kiến trúc, không phải một việc bổ sung nội dung sau cùng: các functional color token (color-danger, color-success, tầng semantic được mô tả trong Design Tokens & Visual Foundations) không bao giờ nên là kênh duy nhất truyền tải ý nghĩa. Kết hợp màu với một icon và một nhãn văn bản có nghĩa là nếu hàm ý văn hóa của một màu khác đi ở một thị trường cụ thể — hoặc thông tin màu sắc bị mất hoàn toàn với người dùng mù màu — ý nghĩa vẫn được truyền tải. Điều này thực ra chính là yêu cầu của WCAG Success Criterion 1.4.1 (Use of Color) vì lý do accessibility, nên tính bền vững về văn hóa và accessibility củng cố lẫn nhau chứ không cạnh tranh nhau.
Khái niệm chính
Text expansion và contraction
Văn bản UI đã dịch hiếm khi chiếm cùng một diện tích ngang như chuỗi gốc, và một design system mà component ngầm giả định độ dài văn bản theo tiếng Anh sẽ gãy rõ ràng ngay khi việc dịch bắt đầu: button bị cắt cụt, nhãn wrap xuống dòng thứ hai ngoài dự tính, và icon va chạm với văn bản bị tràn.
| Văn bản gốc (tiếng Anh) | Mức expansion điển hình | Ngôn ngữ bị ảnh hưởng nhiều nhất |
|---|---|---|
| Nhãn UI ngắn (1–3 từ, ví dụ “Save”, “Cancel”) | +100% đến +300% | Tiếng Đức, Phần Lan, Nga có xu hướng expand các chuỗi ngắn nhiều nhất, vì động từ tiếng Anh gọn nhẹ thường trở thành cụm nhiều từ hoặc danh từ ghép dài |
| Văn bản độ dài câu trung bình | +30% đến +40% | Tiếng Đức, Phần Lan, Ba Lan, và hầu hết ngôn ngữ gốc German/Slav |
| Văn bản độ dài câu trung bình | −10% đến −15% | Tiếng Trung, Nhật, Hàn (CJK) — ít ký tự hơn, đặc hơn trên mỗi từ, dù mỗi ký tự chiếm chiều ngang lớn hơn |
| Văn bản độ dài câu trung bình | +15% đến +30% | Tiếng Tây Ban Nha, Pháp, Bồ Đào Nha, Ý, Ả Rập |
Quy tắc kinh nghiệm được trích dẫn rộng rãi là thiết kế chuỗi gốc tiếng Anh với kỳ vọng tăng khoảng 30–40% khi dịch sang phần lớn ngôn ngữ châu Âu, và xây component sao cho sự tăng trưởng đó không làm vỡ layout về mặt thị giác: tránh chiều rộng pixel cố định trên button và label, thay bằng min-width kết hợp kích thước linh hoạt hoặc auto, tránh âm thầm cắt cụt nhãn hành động quan trọng bằng dấu ba chấm (một button hardcode 80px sẽ cắt “Einreichen” thành “Einr…”, vốn là vấn đề usability và đôi khi cả tính rõ ràng pháp lý đối với một hành động submit), và kiểm thử layout sớm bằng pseudo-localization — một kỹ thuật QA bọc mỗi chuỗi gốc trong văn bản placeholder có dấu, được kéo dài nhân tạo (ví dụ [!!! Ŝävéd !!!]) để các giả định về chiều rộng cố định lộ ra trong QA từ rất sớm, trước khi có bản dịch thật.
| Triệu chứng | Nguyên nhân gốc | Cách khắc phục |
|---|---|---|
| Nhãn button bị cắt cụt hoặc wrap xuống hai dòng sau khi dịch | Chiều rộng pixel cố định được đo theo chuỗi tiếng Anh | Dùng min-width/kích thước linh hoạt thay vì chiều rộng cố định; kiểm chứng bằng pseudo-localization trước khi dịch |
| Button chỉ có icon bị tràn khi một locale yêu cầu kèm nhãn văn bản | Không có phương án cho các locale bắt buộc phải có văn bản | Coi icon+label là một variant được hỗ trợ chính thức, không phải phương án dự phòng gắn thêm sau |
| Các mục navigation chồng lấn nhau sau khi dịch | Ngân sách khoảng cách ngang cố định được giả định cho một số lượng nhãn tiếng Anh ngắn cố định | Dùng layout flex/grid linh hoạt có wrap hoặc menu overflow (“more”) thay vì số slot cố định |
RTL (right-to-left) support
Hàng trăm triệu người viết và đọc chủ yếu bằng tiếng Ả Rập, Hebrew, Farsi, hoặc Urdu — tất cả đều là chữ viết right-to-left — và phục vụ họ đúng cách không đơn thuần là căn văn bản sang phải. Toàn bộ giao diện được mirror theo chiều ngang, giống như một bức ảnh phản chiếu trong gương: navigation di chuyển từ mép trái sang mép phải màn hình, một chevron “back” trỏ sang trái đúng trong layout LTR phải trỏ sang phải trong RTL (vì “back” nghĩa là “về nơi bạn đã đến”, giờ đây là mép màn hình đối diện), thanh tiến trình lấp đầy theo chiều ngược lại, và ngay cả hướng của cử chỉ swipe-to-dismiss cũng đảo ngược.
| Thành phần | Có mirror trong RTL không? | Ví dụ |
|---|---|---|
| Căn chỉnh văn bản và hướng đọc | Có | Nội dung bắt đầu từ mép phải và đọc từ phải sang trái |
| Icon có tính định hướng (chevron back/forward, mũi tên carousel, “next”) | Có | Chevron “back” trỏ trái trở thành trỏ phải |
| Vị trí navigation / sidebar | Có | Navigation chính di chuyển từ mép trái sang mép phải |
| Chữ số Western trong văn bản RTL | Thường không | Hầu hết giao diện RTL vẫn hiển thị chữ số Western từ trái sang phải ngay cả trong văn bản right-to-left bao quanh |
| Icon có ý nghĩa cố định, không mang tính định hướng | Không | Dấu tích, icon thùng rác, kính lúp tìm kiếm không bị lật |
| Logo và brand mark | Không | Nhận diện thương hiệu giữ nguyên bất kể hướng đọc |
| Điều khiển phát media | Thường không | Quy ước play/pause được coi là gần như phổ quát và thường được giữ nguyên không mirror |
Cơ chế giúp việc này duy trì được lâu dài là thiết kế token và CSS xoay quanh logical properties ngay từ đầu thay vì physical properties: margin-inline-start thay vì margin-left, padding-inline-end thay vì padding-right, text-align: start thay vì text-align: left. Trong một document LTR, inline-start phân giải thành mép trái; đổi thuộc tính dir="rtl" của document, và mọi logical property tự động phân giải lại, không cần thay đổi code ở cấp component. Một component library hardcode thuộc tính theo hướng vật lý (physical direction) ngay từ ngày đầu sẽ đòi hỏi viết lại thủ công, dễ lỗi từng quy tắc spacing và căn chỉnh để retrofit RTL sau này — chính vì vậy điều này thuộc về kiến trúc token và component (xem Design Tokens & Visual Foundations) ngay từ đầu, không phải một dự án làm thêm sau. Kỷ luật tương tự cũng áp dụng cho công cụ thiết kế: mirror một frame auto-layout được cấu trúc tốt trong Figma gần như là thao tác một cú click, trong khi một màn hình được xây từ các vị trí tuyệt đối cố định phải được xây lại thủ công cho từng biến thể RTL.
Component nhận biết i18n
Ngoài layout, một số nhóm component mang các giả định đặc thù tiếng Anh (hoặc quy ước phương Tây nói chung) được cài cứng ngay trong logic của chúng, và trong mọi trường hợp, cách khắc phục đều giống nhau: ủy quyền quyết định nhạy cảm với locale cho một thư viện chuẩn, nhận biết locale, thay vì hardcode một quy tắc chỉ đúng với một ngôn ngữ.
| Component | Giả định lấy tiếng Anh làm trung tâm bị gãy ở nơi khác | Cách làm đúng |
|---|---|---|
| Date picker | Thứ tự tháng/ngày (MM/DD/YYYY), tuần bắt đầu từ Chủ nhật, chỉ dùng lịch Gregorian | Dùng dữ liệu Intl.DateTimeFormat/CLDR để chọn định dạng và ngày đầu tuần theo locale; hỗ trợ lịch thay thế (Hijri, Phật lịch, v.v.) khi thị trường mục tiêu cần |
| Định dạng số và tiền tệ | Dấu phẩy làm phân cách hàng nghìn, dấu chấm làm phân cách thập phân, ký hiệu đặt trước số tiền | Dùng Intl.NumberFormat (hoặc tương đương trên nền tảng) theo locale — không bao giờ tự nối chuỗi ký hiệu và chữ số thủ công |
| Số nhiều (pluralization) | Tiếng Anh chỉ phân biệt số ít và số nhiều (“1 item” / “2 items”) | Dùng Intl.PluralRules hoặc ICU MessageFormat — tiếng Ả Rập có sáu dạng số nhiều (zero, one, two, few, many, other), tiếng Nga có ba, tiếng Nhật không có; một kiểm tra hardcode if (count === 1) âm thầm tạo ra văn bản sai ngữ pháp ở phần lớn ngôn ngữ trên thế giới |
| Trường tên | Một trường “Full name” duy nhất, hoặc thứ tự cố định “First name / Last name” | Hỗ trợ cấu trúc và thứ tự tên phù hợp theo locale thay vì áp đặt cách chia given-name/family-name kiểu phương Tây ở mọi nơi |
| Form địa chỉ | Các trường cố định kiểu Mỹ (Street, City, State, ZIP) | Thay đổi các trường bắt buộc và thứ tự của chúng theo từng quốc gia — nhiều quốc gia không có khái niệm tương đương “state”, vị trí mã bưu điện khác nhau, một số nơi đặt city trước street |
| Sắp xếp và collation | Thứ tự alphabet ASCII/tiếng Anh đơn giản | Dùng collation nhận biết locale (Intl.Collator), vì thứ tự sắp xếp cho ký tự có dấu và chữ viết non-Latin khác với thứ tự code-point thô |
Nguyên tắc xuyên suốt bảng này là một component không bao giờ nên tự chứa logic đặc thù locale; nó nên nhận đầu vào locale (và khi liên quan, calendar hoặc numberingSystem) và trao quyết định định dạng thực sự cho API internationalization của nền tảng — cùng kỷ luật mà hệ thống đã áp dụng khi ủy quyền quyết định màu sắc và spacing cho design token thay vì hardcode chúng.
Định dạng file và khả năng liên thông đa nền tảng
Một design system trải rộng hơn cả web — ứng dụng iOS và Android native, ấn phẩm in ấn, template email — cần token và asset của nó được xuất ra định dạng mà mỗi nền tảng tiêu thụ có thể thực sự sử dụng được. Điều này mở rộng phần thảo luận về build pipeline trong Design Tokens & Visual Foundations ra ngoài các đích code, đến những sản phẩm không phải code như in ấn.
| Đích | Định dạng token/asset | Ghi chú |
|---|---|---|
| Web | CSS custom property, JSON theo định dạng DTCG, biến SCSS/LESS | Được CSS tiêu thụ trực tiếp hoặc qua một bước build |
| iOS | Hằng số Swift, color/asset catalog .xcassets, .strings/.stringsdict cho văn bản đã dịch và số nhiều | .stringsdict mã hóa riêng quy tắc dạng số nhiều theo từng locale |
| Android | Resource XML (colors.xml, dimens.xml), strings.xml với <plurals> | Thẻ <plurals> của Android hỗ trợ sẵn các danh mục số nhiều ICU theo locale |
| In ấn / ấn phẩm thương hiệu | Giá trị màu CMYK (không chỉ RGB/hex), asset vector (SVG/EPS/PDF), tham chiếu màu spot Pantone | Token màn hình (RGB/hex) không ánh xạ 1:1 sang in ấn; một hệ thống trải rộng đến in ấn cần một giá trị CMYK tương đương được chọn có chủ đích và tài liệu hóa cho mỗi màu thương hiệu, vì chuyển đổi tự động RGB→CMYK làm lệch tông màu và thường gây thất vọng khi in thật |
| CSS inline, tập tính năng font/layout hẹp hơn nhiều | Token vẫn áp dụng về mặt khái niệm, nhưng “component” xuất ra là một tập con HTML/CSS bị giới hạn bởi hạn chế render của các email client |
Bài học thực tế là kiến trúc token nên coi “platform” là một khái niệm mở, có thể cắm thêm ngay từ ngày đầu — giống cách mô hình platform/transform của Style Dictionary vận hành — thay vì mặc định web là đích duy nhất. Thêm iOS, Android, hoặc in ấn làm đích sau này nên chỉ là thêm một build target mới, chứ không phải tái cấu trúc lại nguồn token.
Maturity model của design system
Không phải tổ chức nào cũng đang ở cùng một điểm trên hành trình này, và một maturity model cho các team một từ vựng chung để trả lời “chúng ta đang ở đâu” và “khoản đầu tư tiếp theo thực sự đáng làm là gì”, thay vì cố gắng áp dụng mọi thực hành trong roadmap này cùng lúc. Hầu hết các maturity model mô tả khoảng bốn giai đoạn.
| Giai đoạn | Đặc điểm | Điều gì thường thay đổi để tiến lên giai đoạn tiếp theo |
|---|---|---|
| Ad hoc | Không có component dùng chung; mỗi team hoặc màn hình tự phát minh button, màu sắc, spacing riêng; tính nhất quán phụ thuộc hoàn toàn vào việc từng cá nhân tình cờ nhận ra sự lệch pha | Một nhóm nhỏ bắt đầu lập danh mục các pattern UI hiện có và xác định sự trùng lặp giữa các sản phẩm |
| Consistent | Có một style guide dùng chung hoặc component library cơ bản, bao phủ các thành phần phổ biến nhất (button, form, màu sắc); việc áp dụng không nhất quán và phần lớn mang tính tự nguyện | Token được chính thức hóa, component được publish thành package có version, và một chủ sở hữu (dù chỉ bán thời gian) được chỉ định |
| Scaled | Design system là một sản phẩm có version, có tài liệu, được áp dụng ở phần lớn product team; token, component, và pattern bao phủ đại đa số UI; đã có quy trình đóng góp | Đầu tư chuyển sang tooling (pipeline design-to-dev), governance, và hỗ trợ đa nền tảng (xem Building a Design System) |
| Systemic / optimized | Design system được nhúng sâu vào quy trình mặc định — tính năng mới được lắp ráp từ hệ thống thay vì thiết kế từ đầu; hệ thống phát triển thông qua các chỉ số áp dụng dựa trên dữ liệu và đóng góp từ nhiều team; các mối quan tâm nâng cao như multi-brand theming, hỗ trợ đầy đủ RTL/i18n, và tính nhất quán đa nền tảng được giải quyết ở tầng kiến trúc thay vì xử lý từng trường hợp | Đầu tư liên tục; hệ thống có roadmap riêng, quy trình deprecation, và một đội ngũ chuyên trách |
Localization, RTL, và multi-brand support thường chính là những mối quan tâm phân biệt rõ ràng nhất giữa “scaled” và “systemic”. Một hệ thống scaled có thể ra mắt ổn định một sản phẩm nhất quán bằng một ngôn ngữ, cho một thương hiệu, một hướng đọc. Một hệ thống systemic đã giải quyết những điều này ở tầng kiến trúc, nên việc mở rộng sang một locale mới, một hướng đọc mới, hay một thương hiệu mới trở thành một thay đổi cấu hình chứ không phải một lần redesign.
Multi-brand design system
Việc phục vụ nhiều thương hiệu riêng biệt từ một design system là tình huống phổ biến — một công ty sở hữu nhiều thương hiệu tiêu dùng, một holding company hình thành qua các thương vụ mua lại, hoặc một platform cung cấp white-label theming cho khách hàng của mình. Cách tiếp cận ngây thơ — fork toàn bộ design system cho mỗi thương hiệu — nhân bản mọi bản sửa lỗi và cải tiến trong tương lai trên N codebase và gần như đảm bảo các bản fork sẽ lệch dần khỏi nhau theo thời gian, tái tạo lại đúng sự phân mảnh mà design system được sinh ra để ngăn chặn (xem bài giới thiệu). Cách tiếp cận có khả năng mở rộng thay vào đó mở rộng cùng kiến trúc token ba tầng được mô tả trong Design Tokens & Visual Foundations với thêm một chiều thương hiệu: tầng global vẫn giữ tính agnostic với thương hiệu về mặt cấu trúc (nó chỉ định nghĩa rằng có tồn tại một color scale chính), trong khi tầng semantic mới là nơi bản sắc thương hiệu thực sự được đưa vào — mỗi thương hiệu xuất ra bộ giá trị tier-1/tier-2 riêng của mình (color scale riêng, họ font riêng), trong khi mọi component vẫn chỉ tiêu thụ đúng những tên semantic và component token như nhau, bất kể thương hiệu nào đang hoạt động.
| Tầng | Dùng chung giữa các thương hiệu? | Ví dụ |
|---|---|---|
| Component (markup, hành vi, logic accessibility) | Có — giống hệt nhau | Cấu trúc DOM của button, tương tác bàn phím, và thuộc tính ARIA không đổi theo thương hiệu |
| Tên semantic token | Có — tên giống hệt nhau | color-primary, font-family-base, radius-md tồn tại cho mọi thương hiệu |
| Giá trị semantic token | Không — đặc thù theo thương hiệu | Thương hiệu A: color-primary → #E4002B; Thương hiệu B: color-primary → #0057B8 |
| Logo, phong cách minh họa, hình ảnh đặc thù thương hiệu | Không — đặc thù theo thương hiệu | Được xuất dưới dạng asset gắn với thương hiệu, không phải token |
| Voice, tone, và guideline nội dung | Thường đặc thù theo thương hiệu | Mỗi thương hiệu có thể giữ voice riêng cho nội dung ngay cả khi tái sử dụng cùng một component nền tảng |
Tại runtime hoặc build time, thương hiệu đang hoạt động được chọn theo cách tương tự như chọn theme sáng/tối — một thuộc tính data-brand="brand-a", hoặc một phép thay thế token ở build time — chính vì vậy khung nhìn trước đó về dark mode như “một vấn đề hoán đổi token, không phải một thiết kế thứ hai” (xem Design Tokens & Visual Foundations) tổng quát hóa trực tiếp sang multi-brand support. Thương hiệu đơn giản chỉ là một trục theming khác, miễn là component được xây dựng ngay từ đầu để tiêu thụ token thay vì hardcode giá trị của bất kỳ thương hiệu đơn lẻ nào.
Tổng hợp lại: điều gì sẽ gãy nếu bỏ qua những điều này
| Cân nhắc nâng cao | Điều gì gãy nếu bỏ qua | Cách giảm thiểu ở thời điểm thiết kế |
|---|---|---|
| RTL support | Layout mirror sai hoặc không mirror; icon định hướng trỏ sai hướng; văn bản chồng lấn; toàn bộ thị trường (người dùng Ả Rập, Hebrew, Farsi, Urdu) nhận một sản phẩm gãy hoặc không dùng được | Xây component trên logical CSS property (inline-start/inline-end) và auto-layout có thể mirror ngay từ đầu; kiểm thử mọi component ở cả hai hướng trước khi ra mắt |
| Text expansion/contraction | Button bị cắt cụt hoặc wrap; nhãn chồng lấn; UI đặc chữ CJK trông thưa thớt trong khi UI tiếng Đức bị expand lại tràn ra ngoài | Tránh chiều rộng pixel cố định trên container văn bản; thiết kế với dư địa tăng trưởng 30–40%; pseudo-localize sớm trong QA |
| Khác biệt pháp lý/quy định theo khu vực | Sản phẩm không tuân thủ (bị phạt, buộc phát hành lại) ở thị trường EU/Mỹ/khác; thiếu consent banner hoặc UI không accessible mời gọi hành động pháp lý | Xây sẵn pattern consent, accessibility (xem Accessibility & Inclusive Design), và hiển thị thuế thành component tái sử dụng, cấu hình được theo khu vực, thay vì mỗi team tự làm riêng |
| Định dạng ngày/số/tiền tệ | Ngày bị đọc sai (sự mơ hồ 03/04), số bị parse sai, giá hiển thị sai ký hiệu hoặc sai vị trí | Ủy quyền mọi việc định dạng cho API dựa trên Intl/CLDR; không bao giờ tự định dạng thủ công hay nối chuỗi |
| Liên tưởng văn hóa về màu sắc | Một màu “success” hay “danger” mang nghĩa ngược lại — hoặc không liên quan — ở nền văn hóa khác; người dùng hiểu sai trạng thái UI quan trọng | Không bao giờ chỉ dựa vào màu sắc để truyền tải ý nghĩa (kết hợp với icon + văn bản); kiểm chứng lựa chọn màu semantic bằng nghiên cứu thị trường mục tiêu |
| Số nhiều / component nhận biết i18n | Văn bản sai ngữ pháp (“1 items”), hoặc hoàn toàn sai với các ngôn ngữ có sáu dạng số nhiều như tiếng Ả Rập | Dùng Intl.PluralRules/ICU MessageFormat thay vì rẽ nhánh hardcode số ít/số nhiều |
| Khả năng liên thông định dạng file | Ứng dụng native hoặc ấn phẩm in ấn hoàn toàn không thể tiêu thụ token, hoặc màu in ấn trông sai do lệch RGB→CMYK không kiểm soát | Coi “platform” là có thể cắm thêm trong pipeline build token ngay từ đầu; định nghĩa rõ ràng giá trị CMYK tương đương cho mỗi màu thương hiệu |
| Multi-brand support | Mỗi thương hiệu mới fork toàn bộ hệ thống, nhân bản chi phí bảo trì và đảm bảo sự lệch pha về hình ảnh/hành vi giữa các thương hiệu theo thời gian | Thêm một tầng brand vào kiến trúc token — giá trị tier-1/2 đặc thù theo thương hiệu đứng sau các tên semantic và component dùng chung |
Best Practices
- Thiết kế cho text expansion ngay từ bản mockup đầu tiên, không phải sau khi bản dịch đầu tiên trả về — dùng container chiều rộng linh hoạt, dự trù dư địa tăng trưởng 30–40% cho ngôn ngữ châu Âu, và pseudo-localize bản build sớm để các giả định chiều rộng cố định lộ ra trong QA thay vì trong báo cáo lỗi của khách hàng.
- Xây dựng trên logical CSS property, không phải physical property, ngay từ component đầu tiên —
margin-inline-startvàtext-align: startbiến RTL thành một thay đổi cấu hình;margin-leftvàtext-align: leftbiến RTL thành một lần retrofit thủ công, dễ lỗi cho từng component. - Không bao giờ để một component tự chứa logic locale riêng — ngày, số, tiền tệ, số nhiều, và collation luôn nên được ủy quyền cho API dựa trên
Intl/CLDR (hoặc tương đương trên nền tảng), không phải định dạng chuỗi tự viết chỉ tình cờ đúng với tiếng Anh. - Không bao giờ dựa vào màu sắc như kênh duy nhất truyền tải ý nghĩa — kết hợp mỗi màu semantic với một icon và văn bản rõ ràng, vừa vì liên tưởng màu sắc khác nhau theo văn hóa, vừa vì đây là yêu cầu bắt buộc cho accessibility (WCAG 1.4.1) bất kể thị trường nào.
- Xây sẵn pattern có thể cấu hình theo khu vực cho các yêu cầu pháp lý, thay vì để từng team tự ứng biến — cookie consent, giá đã gồm thuế, và component accessible-by-default nên là pattern ở cấp hệ thống đúng như một button, vì việc mỗi product team tự phát minh lại chúng độc lập gần như chắc chắn khiến một số trong đó không tuân thủ.
- Coi multi-brand và theming sáng/tối là cùng một vấn đề kiến trúc — một thương hiệu chỉ là một trục khác của tầng semantic token; nếu một component cần logic điều kiện đặc thù theo thương hiệu để render đúng, tầng token bên dưới nó chưa hoàn chỉnh.
- Coi “platform” là có thể cắm thêm trong pipeline token ngay từ ngày đầu — thêm đầu ra iOS, Android, hoặc in ấn sau này nên chỉ là cấu hình một build target mới, không phải tái cấu trúc cách token được author.
- Dùng maturity model để sắp xếp thứ tự đầu tư, không phải để over-engineer quá sớm — một hệ thống ad hoc theo đuổi RTL đầy đủ và multi-brand support trước khi có token nhất quán là đang giải quyết vấn đề của ngày mai trước vấn đề của hôm nay; maturity model tồn tại để giúp các team đầu tư đúng việc ở đúng giai đoạn.
Tài liệu tham khảo
- W3C Internationalization (i18n) Activity
- Unicode CLDR — Common Locale Data Repository
- Unicode — Language Plural Rules
- MDN — CSS Logical Properties and Values
- Material Design 3 — Bidirectionality
- W3C WAI — Web Accessibility Laws & Policies
- ADA.gov — Guidance on Web Accessibility and the ADA
- roadmap.sh/design-system
Part of the Design System Roadmap knowledge base.
Overview
Most design systems are, without anyone deciding it deliberately, built for one language (usually US English), one reading direction (left-to-right), one region’s legal norms, and one culture’s color connotations. Those assumptions hold up fine until the product goes global, at which point they crack in visible, expensive ways: a button labeled “Submit” fits perfectly in English but truncates the moment it’s translated to German “Einreichen”; a “back” chevron that correctly points left in an LTR layout points the wrong direction the instant the interface mirrors for Arabic; a date rendered as 03/04/2026 is read as March 4th by an American user and April 3rd by almost everyone else; a bright red “error” banner reads as danger to a Western audience and as luck or celebration in parts of East Asia; and a regulator in Brussels or a court in California can require a disclosure surface the design never budgeted screen space for.
These are not edge cases that a translator or a lone engineer can patch screen-by-screen after the fact — they are systemic, cross-cutting concerns that touch nearly every screen in the product simultaneously, which is exactly the argument this roadmap has already made about design tokens and accessibility: decisions with system-wide blast radius must be solved once, in the architecture, rather than fixed (and re-broken) per screen. This note is the capstone of the roadmap, gathering the “advanced,” often-overlooked considerations that separate a design system that merely looks polished in its home market from one that is genuinely ready to scale globally: regional legal variance, text expansion, right-to-left (RTL) layout, locale-aware components, cross-platform file interoperability, a maturity model for judging how far along a system actually is, and multi-brand theming. As with everything else in this roadmap (see the introduction), the recurring lesson is that these are architecture decisions made early, not features bolted on when the first international customer complains.
Fundamentals
Localization is an architecture decision, not a translation task
It’s worth separating two terms that get used interchangeably but mean different things. Internationalization (i18n) is the engineering and design work that makes a product capable of being localized: extracting hardcoded strings into resource files, building layouts that can flex and mirror, delegating date/number formatting to locale-aware libraries instead of hardcoding English conventions. Localization (l10n) is the actual per-market adaptation built on top of that capability: the translated strings, the region-specific imagery, the local date format, the region’s currency display. The relationship is asymmetric and important: a product with poor i18n cannot be properly localized no matter how good the translations are — a perfectly translated German string will still truncate in a button sized for English if the component never accounted for text expansion. That is why this is fundamentally a design-system problem: i18n lives in the tokens, components, and layout architecture, while l10n is content that flows through the pipes i18n built. Get the architecture wrong and every future locale pays the cost; get it right once and adding a new language or region becomes a content and configuration exercise rather than a re-engineering project.
Regional legal and regulatory requirements
Law is not uniform across markets, and several categories of regulation translate directly into UI surface area a design system must reserve and standardize rather than leave to individual product teams to improvise (and inevitably get wrong).
| Requirement | Where it applies | What it means for design |
|---|---|---|
| Cookie / tracking consent banners | EU (ePrivacy Directive, GDPR), similar regimes in Brazil (LGPD), California (CCPA/CPRA) | Requires a persistent, dismissible UI surface that gates non-essential trackers until explicit consent, with a “reject” option no less prominent than “accept” |
| Web accessibility law | US (ADA, Section 508), EU (EN 301 549 / European Accessibility Act), UK (Equality Act 2010), Canada (AODA) | Different enforcement mechanisms and legal exposure, but nearly all reference WCAG 2.1/2.2 AA as the underlying technical standard — see Accessibility & Inclusive Design |
| Data-residency and privacy disclosures | EU GDPR, China PIPL, India DPDP | Often requires standardized consent screens, data-export/deletion flows, and localized privacy copy shipped as reusable patterns |
| Right-to-erasure / account-deletion flows | EU GDPR (and similar laws elsewhere) | Needs a discoverable, standardized settings pattern the system should ship once, not per product |
| Tax-inclusive vs. tax-exclusive pricing | EU (VAT-inclusive display expected), US (tax typically shown separately at checkout) | Pricing components must support both display modes, selected by locale/region configuration, not hardcoded per market |
None of this is generic legal boilerplate that content teams can bolt on later — a design system should ship the consent-banner component and the tax-aware pricing component as reusable, regionally-configurable patterns exactly the way it ships a button or a form field. Left unaddressed, each product team invents (and usually gets wrong) its own version, and a company can end up with a dozen non-compliant cookie banners across a dozen products.
Date, number, and currency formatting
Formatting conventions vary even among languages that look superficially similar, and a hardcoded assumption about “how numbers look” is one of the most common ways a design system silently breaks outside its home market.
| Value | US (en-US) | Germany (de-DE) | France (fr-FR) | Note |
|---|---|---|---|---|
| Date | 03/04/2026 | 04.03.2026 | 04/03/2026 | The same numeric string 03/04 is ambiguous across locales — it can mean March 4th or April 3rd depending on convention |
| Decimal number | 1,234.56 | 1.234,56 | 1 234,56 | Comma and period swap roles between decimal and thousands separator; French uses a space as the thousands separator |
| Currency | $1,234.56 | 1.234,56 € | 1 234,56 € | Symbol position (before vs. after the amount) and spacing conventions differ |
| First day of week | Sunday | Monday | Monday | Changes the grid layout of any calendar or date-picker component |
Components must never format these values by hand-rolled string concatenation. The correct approach is to delegate to a locale-aware formatting API — Intl.DateTimeFormat, Intl.NumberFormat, and Intl.PluralRules on the web; NSDateFormatter/NumberFormatter on iOS; ICU-backed classes (android.icu) on Android — all of which draw from the Unicode CLDR (Common Locale Data Repository), the shared dataset of locale conventions that every major platform’s internationalization library is built on. The design system’s responsibility is to pass the correct locale down through context or props consistently; the formatting rules themselves should never be reimplemented by hand.
Cultural color associations
Color tokens (see Design Tokens & Visual Foundations) are usually built around one culture’s assumptions about what colors mean — typically a Western reading where red signals danger or “stop,” green signals success or “go,” and white signals purity. These associations are learned, not universal, and can silently invert or lose meaning in another market.
| Color | Common Western association | Alternative cultural association | Design implication |
|---|---|---|---|
| Red | Danger, error, “stop” | China: luck, prosperity, celebration | An “error” red banner may not automatically read as negative everywhere; never rely on color alone — pair it with an icon and explicit text |
| White | Purity, cleanliness, weddings | Parts of East Asia: mourning and funerals | Avoid all-white “celebratory” illustration treatments without checking target-market connotations |
| Yellow | Caution/warning, borrowed from traffic-light logic | Mixed meanings across cultures, including mourning in some regions and happiness in others | Warning components should not depend on yellow’s meaning being self-evident |
| Green | Success, “go,” eco-friendliness | Context-dependent alternative meanings in some cultures and religious/political contexts | Validate a “success green” choice against target-market research rather than assuming universality |
The mitigation is architectural rather than a content afterthought: functional color tokens (color-danger, color-success, the semantic tier described in Design Tokens & Visual Foundations) should never be the sole carrier of meaning. Pairing color with an icon and a text label means that if a color’s cultural connotation differs in a given market — or the color information is lost entirely for a colorblind user — the meaning still comes through. This happens to be exactly what WCAG Success Criterion 1.4.1 (Use of Color) already requires for accessibility reasons, so cultural robustness and accessibility reinforce rather than compete with each other.
Key Concepts
Text expansion and contraction
Translated UI text rarely occupies the same horizontal space as the source string, and a design system whose components silently assume English-length text will visibly break the moment translation begins: buttons truncate, labels wrap onto an unplanned second line, and icons collide with overflowing text.
| Source (English) text | Typical expansion | Languages most affected |
|---|---|---|
| Short UI labels (1–3 words, e.g. “Save,” “Cancel”) | +100% to +300% | German, Finnish, and Russian expand short strings the most, since compact English verbs often become multi-word phrases or long compound nouns |
| Average sentence-length text | +30% to +40% | German, Finnish, Polish, and most Germanic/Slavic languages |
| Average sentence-length text | −10% to −15% | Chinese, Japanese, Korean (CJK) — fewer, denser characters per word, though each character occupies more horizontal width |
| Average sentence-length text | +15% to +30% | Spanish, French, Portuguese, Italian, Arabic |
The widely cited rule of thumb is to design English source strings expecting roughly 30–40% growth once translated into most European languages, and to build components so that growth doesn’t visually break the layout: avoid fixed pixel widths on buttons and labels in favor of min-width plus flexible or auto sizing, avoid silently truncating critical action labels with an ellipsis (a button hardcoded at 80px truncates “Einreichen” to “Einr…”, which is a usability and sometimes a legal-clarity problem for a submit action), and pressure-test layouts early with pseudo-localization — a QA technique that wraps every source string in accented, artificially lengthened placeholder text (e.g., [!!! Ŝävéd !!!]) so fixed-width assumptions surface in QA long before real translations exist.
| Symptom | Root cause | Mitigation |
|---|---|---|
| Button label truncates or wraps to two lines after translation | Fixed pixel width sized to the English string | Use min-width/flexible sizing instead of a fixed width; verify with pseudo-localization before translation begins |
| Icon-only button overflows once a locale requires an accompanying text label | No accommodation was designed for text-required locales | Treat icon+label as a first-class supported variant, not a fallback bolted on later |
| Navigation items overlap after translation | Fixed horizontal spacing budget assumed for a fixed number of short English labels | Use flexible flex/grid layout with wrapping or an overflow (“more”) menu instead of a fixed slot count |
RTL (right-to-left) support
Several hundred million people write and read primarily in Arabic, Hebrew, Farsi, or Urdu — all right-to-left scripts — and serving them properly is not a matter of right-aligning text. The entire interface mirrors horizontally, the way a photograph reflects in a mirror: navigation moves from the left edge of the screen to the right edge, a “back” chevron that correctly points left in an LTR layout must point right in RTL (because “back” means “toward where you came from,” which is now the opposite screen edge), progress indicators fill in the opposite direction, and even swipe-to-dismiss gesture directions reverse.
| Element | Mirrors in RTL? | Example |
|---|---|---|
| Text alignment and reading direction | Yes | Body copy starts at the right edge and reads right-to-left |
| Directional icons (back/forward chevrons, carousel arrows, “next” affordances) | Yes | A left-pointing “back” chevron becomes right-pointing |
| Navigation / sidebar position | Yes | Primary navigation moves from the left edge to the right edge |
| Western numerals within RTL text | Usually no | Most RTL interfaces still render Western digits left-to-right even inside right-to-left surrounding text |
| Icons with fixed, non-directional meaning | No | A checkmark, a trash-can icon, or a magnifying glass for search doesn’t flip |
| Logos and brand marks | No | Brand identity stays fixed regardless of reading direction |
| Media playback controls | Usually no | Play/pause conventions are treated as near-universal and are typically left unmirrored |
The mechanism that makes this maintainable long-term is designing tokens and CSS around logical properties from the outset rather than physical ones: margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, text-align: start instead of text-align: left. In an LTR document, inline-start resolves to the left edge; flip the document’s dir="rtl" attribute, and every logical property re-resolves automatically, with zero component-level code changes. A component library that hardcoded physical-direction properties from day one requires a manual, error-prone rewrite of every spacing and alignment rule to retrofit RTL later — which is exactly why this belongs in the token and component architecture (see Design Tokens & Visual Foundations) from the start rather than as a follow-up project. The same discipline extends into design tooling: mirroring a well-structured auto-layout frame in Figma is close to a one-click operation, while a screen built from fixed absolute positions has to be manually rebuilt for every RTL variant.
i18n-aware components
Beyond layout, several categories of components carry assumptions specific to English (or to Western conventions more broadly) baked directly into their logic, and in every case the fix is the same: delegate the locale-sensitive decision to a standard, locale-aware library instead of hardcoding a rule that happens to be true for one language.
| Component | English-centric assumption that breaks elsewhere | Correct approach |
|---|---|---|
| Date picker | Month/day order (MM/DD/YYYY), week starting on Sunday, Gregorian calendar only | Use Intl.DateTimeFormat/CLDR data to select format and first day of week per locale; support alternate calendars (Hijri, Buddhist, etc.) where the target market needs them |
| Number and currency formatting | Comma as thousands separator, period as decimal separator, symbol placed before the amount | Use Intl.NumberFormat (or the platform equivalent) driven by locale — never string-concatenate symbols and digits by hand |
| Pluralization | English distinguishes only singular and plural (“1 item” / “2 items”) | Use Intl.PluralRules or ICU MessageFormat — Arabic has six plural categories (zero, one, two, few, many, other), Russian has three, Japanese has none; a hardcoded if (count === 1) check silently produces grammatically incorrect text in most of the world’s languages |
| Name fields | A single “Full name” field, or a fixed “First name / Last name” order | Support locale-appropriate name structures and ordering rather than mandating a Western given-name/family-name split everywhere |
| Address forms | US-style fixed fields (Street, City, State, ZIP) | Vary required fields and their order by country — many countries have no “state” equivalent, postal-code position varies, and some place city before street |
| Sorting and collation | Simple ASCII/English alphabetical order | Use locale-aware collation (Intl.Collator), since sort order for accented characters and non-Latin scripts differs from raw code-point ordering |
The unifying principle across this table is that a component should never contain locale-specific logic itself; it should accept a locale (and, where relevant, calendar or numberingSystem) input and hand the actual formatting decision to the platform’s internationalization API — the same discipline the system already applies by delegating color and spacing decisions to design tokens rather than hardcoding them.
File formats and cross-platform interoperability
A design system that spans more than the web — native iOS and Android apps, print collateral, email templates — needs its tokens and assets exported in formats each consuming platform can actually use. This extends the build-pipeline discussion in Design Tokens & Visual Foundations beyond code targets into non-code deliverables like print.
| Target | Token / asset format | Note |
|---|---|---|
| Web | CSS custom properties, JSON in the DTCG format, SCSS/LESS variables | Consumed directly by CSS or a build step |
| iOS | Swift constants, .xcassets color/asset catalogs, .strings/.stringsdict for translated text and pluralization | .stringsdict specifically encodes per-locale plural-form rules |
| Android | XML resources (colors.xml, dimens.xml), strings.xml with <plurals> | Android’s <plurals> tag natively supports ICU plural categories per locale |
| Print / brand collateral | CMYK color values (not just RGB/hex), vector assets (SVG/EPS/PDF), Pantone spot-color references | Screen tokens (RGB/hex) don’t map 1:1 to print; a system spanning print needs a deliberately chosen CMYK equivalent documented for every brand color, since automatic RGB→CMYK conversion shifts hue and often disappoints on press |
| Inlined CSS, a much narrower font/layout feature set | Tokens still apply conceptually, but the “component” export is a constrained HTML/CSS subset dictated by email client rendering limits |
The practical takeaway is that token architecture should treat “platform” as an open-ended, pluggable concept from day one — the same way Style Dictionary’s platform/transform model does — rather than assuming web is the only output. Adding iOS, Android, or print as a target later should mean adding a new build target, not restructuring the token source itself.
Design system maturity models
Not every organization is at the same point in this journey, and a maturity model gives teams a shared vocabulary for “where are we” and “what’s the next investment that actually matters,” rather than attempting to adopt every practice in this roadmap simultaneously. Most maturity models describe roughly four stages.
| Stage | Characteristics | What typically changes to reach the next stage |
|---|---|---|
| Ad hoc | No shared components; every team or screen invents its own buttons, colors, and spacing; consistency depends entirely on individuals happening to notice drift | A small group begins cataloging existing UI patterns and identifying duplication across products |
| Consistent | A shared style guide or basic component library exists, covering the most common elements (buttons, forms, colors); adoption is inconsistent and largely voluntary | Tokens get formalized, components are published as a versioned package, and a dedicated (even if part-time) owner is appointed |
| Scaled | The design system is a versioned, documented product with adoption across most product teams; tokens, components, and patterns cover the large majority of UI; a contribution process exists | Investment shifts to tooling (design-to-dev pipelines), governance, and cross-platform support (see Building a Design System) |
| Systemic / optimized | The design system is embedded in the default workflow — new features are assembled from it rather than designed from scratch; the system evolves through data-driven adoption metrics and contribution from many teams; advanced concerns like multi-brand theming, full RTL/i18n support, and cross-platform parity are solved architecturally rather than case by case | Continuous investment; the system has its own roadmap, deprecation process, and dedicated team |
Localization, RTL, and multi-brand support are usually exactly the concerns that separate “scaled” from “systemic.” A scaled system can reliably ship a consistent product in one language, for one brand, one reading direction. A systemic one has already solved these as architecture, so expanding into a new locale, a new reading direction, or a new brand becomes a configuration change rather than a redesign.
Multi-brand design systems
Serving multiple distinct brands from one design system is a common situation — a company that owns several consumer brands, a holding company assembled through acquisitions, or a platform offering white-label theming to its customers. The naive approach — forking the entire design system per brand — duplicates every future fix and improvement across N codebases and all but guarantees the forks drift apart over time, recreating exactly the fragmentation a design system exists to prevent (see the introduction). The scalable approach instead extends the same three-tier token architecture described in Design Tokens & Visual Foundations with a brand dimension: the global tier stays structurally brand-agnostic (it defines that a primary color scale exists), while the semantic tier is where brand identity actually gets injected — each brand ships its own set of tier-1/tier-2 values (its own color scale, its own type family), while every component still consumes exactly the same semantic and component token names regardless of which brand is active.
| Layer | Shared across brands? | Example |
|---|---|---|
| Components (markup, behavior, accessibility logic) | Yes — identical | A button’s DOM structure, keyboard interaction, and ARIA attributes don’t change per brand |
| Semantic token names | Yes — identical names | color-primary, font-family-base, radius-md exist for every brand |
| Semantic token values | No — brand-specific | Brand A: color-primary → #E4002B; Brand B: color-primary → #0057B8 |
| Logos, illustration style, brand-specific imagery | No — brand-specific | Shipped as brand-scoped assets, not as tokens |
| Voice, tone, and content guidelines | Usually brand-specific | Each brand can retain its own copy voice even while reusing an identical underlying component |
At runtime or build time, the active brand is selected the same way a light/dark theme is selected — a data-brand="brand-a" attribute, or a build-time token substitution — which is precisely why the earlier framing of dark mode as “a token-swapping problem, not a second design” (see Design Tokens & Visual Foundations) generalizes directly to multi-brand support. Brand is simply another axis of theming, provided components were built from the start to consume tokens rather than hardcoding any single brand’s values.
Bringing it together: what breaks if you ignore this
| Advanced consideration | What breaks if ignored | Design-time mitigation |
|---|---|---|
| RTL support | Layout mirrors incorrectly or not at all; directional icons point the wrong way; text overlaps; entire markets (Arabic, Hebrew, Farsi, Urdu speakers) get a broken or unusable product | Build components on logical CSS properties (inline-start/inline-end) and mirrorable auto-layout from day one; test every component in both directions before shipping |
| Text expansion/contraction | Buttons truncate or wrap; labels overlap; a CJK-dense UI looks sparse next to a German-expanded UI that overflows | Avoid fixed pixel widths on text containers; design with 30–40% growth headroom; pseudo-localize early in QA |
| Regional legal/regulatory variance | Product is non-compliant (fines, forced re-release) in EU/US/other markets; missing consent banners or inaccessible UI invites legal action | Ship consent, accessibility (see Accessibility & Inclusive Design), and tax-display patterns as reusable, regionally-configurable components rather than per-team one-offs |
| Date/number/currency formatting | Dates are misread (the 03/04 ambiguity), numbers are misparsed, prices display with the wrong symbol or position | Delegate all formatting to Intl/CLDR-backed APIs; never hand-format or string-concatenate |
| Cultural color associations | A “success” or “danger” color reads as the opposite — or as unrelated — in another culture; users misread critical UI state | Never rely on color alone for meaning (pair with icon + text); validate semantic color choices against target-market research |
| Pluralization / i18n-aware components | Grammatically broken text (“1 items”), or entirely wrong output for six-form languages like Arabic | Use Intl.PluralRules/ICU MessageFormat instead of hardcoded singular/plural branching |
| File-format interoperability | Native apps or print collateral can’t consume tokens at all, or print colors look wrong due to uncontrolled RGB→CMYK drift | Treat “platform” as pluggable in the token build pipeline from the start; define explicit CMYK equivalents for every brand color |
| Multi-brand support | Each new brand forks the whole system, duplicating maintenance and guaranteeing visual/behavioral drift between brands over time | Add a brand layer to the token architecture — brand-specific tier-1/2 values behind shared semantic names and shared components |
Best Practices
- Design for text expansion from the first mockup, not after the first translation comes back — use flexible-width containers, budget 30–40% growth headroom for European languages, and pseudo-localize builds early so fixed-width assumptions surface in QA rather than in a customer bug report.
- Build on logical CSS properties, not physical ones, from the very first component —
margin-inline-startandtext-align: startmake RTL a configuration flip;margin-leftandtext-align: leftmake RTL a manual, error-prone retrofit of every component. - Never let a component contain its own locale logic — dates, numbers, currency, pluralization, and collation should always be delegated to
Intl/CLDR-backed APIs (or platform equivalents), never hand-rolled string formatting that happens to work for English. - Never rely on color as the sole carrier of meaning — pair every semantic color with an icon and explicit text, both because color associations vary by culture and because this is required for accessibility (WCAG 1.4.1) regardless of market.
- Ship regionally-configurable patterns for legal requirements, not per-team improvisation — cookie consent, tax-inclusive pricing, and accessible-by-default components should be system-level patterns exactly like a button, since every product team reinventing them independently guarantees some of them are non-compliant.
- Treat multi-brand and dark/light theming as the same architectural problem — a brand is just another axis of the semantic token layer; if a component needs brand-specific conditional logic to render correctly, the token layer beneath it is incomplete.
- Treat “platform” as pluggable in the token pipeline from day one — adding iOS, Android, or print output later should mean configuring a new build target, not restructuring how tokens are authored.
- Use a maturity model to sequence investment, not to over-engineer early — an ad hoc system chasing full RTL and multi-brand support before it has consistent tokens is solving tomorrow’s problem before today’s; maturity models exist to help teams invest in the right thing at the right stage.
References
- W3C Internationalization (i18n) Activity
- Unicode CLDR — Common Locale Data Repository
- Unicode — Language Plural Rules
- MDN — CSS Logical Properties and Values
- Material Design 3 — Bidirectionality
- W3C WAI — Web Accessibility Laws & Policies
- ADA.gov — Guidance on Web Accessibility and the ADA
- roadmap.sh/design-system