P4.5 — Design System như một sản phẩm nội bộ

Module: P4 - UX và Product Design

Mục tiêu đọc: Sau chương này, bạn có thể:

Xác định khi nào Design System đáng đầu tư.
Nối mục đích sản phẩm với nguyên tắc, hành vi, mẫu chức năng, mẫu cảm nhận và ngôn ngữ chung.
Phân biệt Design System với Style Guide, Pattern Library và Component Library.
Chọn mức nghiêm ngặt, mức mô-đun và mức tập trung phù hợp.
Kiểm kê giao diện theo mục đích, quyết định gộp, tách, tạo biến thể hoặc giữ giải pháp dùng một lần.
Thiết kế quyền đóng góp, tuyển chọn, triển khai, phủ quyết và leo thang.
Đo chi phí nội bộ, kết quả người dùng, rủi ro và tác động con người.

Nguồn tổng hợp: Design Systems — Alla Kholmatova; Laws of UX — Jon Yablonski; Don’t Make Me Think — Steve Krug.

Đọc chương giúp hình thành mô hình quyết định. Đọc không thay thế kinh nghiệm dự án, quan sát người dùng, kiểm thử, phát hành và chịu trách nhiệm khi quyết định sai.

Mental model

Intuition — trực giác

Design System không phải kho nút bấm. Nó là cách tổ chức dùng để tạo, chọn, triển khai, giải thích, đo và thay đổi những lời giải lặp lại trong sản phẩm.

Một thư viện có thể chứa nhiều thành phần đẹp nhưng vẫn thất bại nếu:

Không ai biết dùng mẫu nào.
Cùng hành vi có nhiều tên.
Mã nguồn và thiết kế lệch nhau.
Không có người chịu trách nhiệm.
Quy tắc không giúp đội giải quyết đánh đổi.
Hệ thống làm nhanh hơn nhưng làm trải nghiệm sai hơn.

Design System là sản phẩm nội bộ vì nhà thiết kế, lập trình viên, quản lý sản phẩm, người viết nội dung, kiểm thử viên và marketing là người dùng của nó. Người dùng cuối hưởng lợi gián tiếp qua giao diện nhất quán, dễ hiểu, dễ tiếp cận và dễ bảo trì.

Precise definition — định nghĩa chính xác

Style Guide tập trung vào màu sắc, kiểu chữ, biểu tượng và quy tắc thương hiệu.
Pattern Library ghi nhận mẫu, ví dụ, biến thể và hướng dẫn dùng.
Component Library cung cấp thành phần có thể tái sử dụng trong mã nguồn.
Design System bao gồm mẫu liên kết, nguyên tắc, ngôn ngữ chung, công cụ, quy trình, quyền sở hữu, triển khai, tài liệu, đo lường và thực hành thay đổi.

Không có Shared Practice, danh mục thành phần chỉ là kho mô-đun. Không có mục đích sản phẩm, thư viện dễ phình to, bị dùng sai hoặc bị bỏ rơi.

Chuỗi quyết định:

P4.5 - Design System như một sản phẩm nội bộ — diagram 1

Source mermaid — có thể chỉnh sửa

flowchart TB
    A["Mục đích sản phẩm<br/>Product Purpose"] --> B["Tinh thần và thương hiệu<br/>Ethos / Brand"]
    B --> C["Nguyên tắc thiết kế<br/>Design Principles"]
    C --> D["Hành vi mong muốn<br/>Desired Behavior"]
    D --> E["Mẫu chức năng<br/>Functional Patterns"]
    E --> F["Mẫu cảm nhận<br/>Perceptual Patterns"]
    F --> G["Ngôn ngữ chung<br/>Shared Language"]
    G --> H["Thiết kế, mã nguồn và tài liệu"]
    H --> I["Kết quả người dùng và chi phí vận hành"]
    I --> C

Mỗi mẫu phải truy ngược được về hành vi và mục đích. Mỗi thay đổi phải được xem qua hai chiều:

Hiệu quả quy trình: thời gian thiết kế, xây dựng, kiểm thử, sửa và bảo trì.
Hiệu quả trải nghiệm: mức hiểu, khả năng hoàn thành mục tiêu, khả năng tiếp cận, niềm tin và mức phù hợp với mục đích.

Why it exists — vì sao hệ thống tồn tại

Design System giải quyết bốn nhóm chi phí:

Chi phí lặp: nhiều đội giải cùng vấn đề.
Chi phí sai khác: thiết kế, mã nguồn và nội dung không thống nhất.
Chi phí thay đổi: một thay đổi phải sửa nhiều nơi.
Chi phí quyết định: đội mất thời gian tranh luận tên, trạng thái, mức nhấn và quy tắc.

Hệ thống không tự tạo giá trị. Nó chỉ khuếch đại năng lực tổ chức hiện có. Nghiên cứu yếu, chiến lược sai hoặc governance yếu sẽ lan nhanh hơn khi được đóng gói thành mẫu.

Minimal example — ví dụ tối thiểu

Hai sản phẩm cùng dùng thẻ:

Sản phẩm giao dịch tài chính cần mật độ cao, quét nhanh và thao tác đồng thời.
Nền tảng học tập cần đọc sâu, tiến độ và một nhiệm vụ mỗi thời điểm.

Một “thẻ dùng chung” chỉ vì hình thức giống nhau có thể tạo nhất quán bề mặt nhưng phá mục đích. Gộp mẫu chỉ hợp lý khi mục đích và cấu trúc lõi giống nhau.

Real-work use — dùng trong công việc thật

Bắt đầu bằng một luồng quan trọng, không bắt đầu bằng việc xây nền tảng mã.

Tạo Purpose-to-pattern chain:

Lớp	Câu hỏi
Mục đích sản phẩm	Sản phẩm tồn tại để tạo kết quả nào?
Tinh thần và thương hiệu	Sản phẩm cần tạo cảm nhận nào?
Nguyên tắc	Khi đánh đổi, đội ưu tiên điều gì?
Hành vi	Người dùng cần làm gì?
Mẫu chức năng	Cấu trúc nào hỗ trợ hành vi?
Mẫu cảm nhận	Hình thức, giọng điệu, chuyển động tạo cảm nhận nào?
Ngôn ngữ chung	Đội gọi và thảo luận mẫu ra sao?

Failure mode / boundary — lỗi và ranh giới

Không bắt đầu từ nút bấm rồi tìm mục đích sau. Không chọn mẫu theo xu hướng. Không chuẩn hóa từng màn hình rồi bỏ quan hệ toàn hành trình. Không biến mọi bất định thành biến thể.

Core

1. Mục đích và Design Principle

Trực giác: nguyên tắc thiết kế giúp đội chọn khi hai phương án đều có lý.

Định nghĩa: Design Principle là hướng dẫn có quan điểm, dùng trong một bối cảnh cụ thể để xử lý đánh đổi.

Vì sao tồn tại: “đơn giản”, “hữu ích”, “dễ dùng” quá phổ quát. Nguyên tắc phải nói rõ giá trị được ưu tiên và giá trị bị giảm.

Ví dụ tối thiểu: “Định hướng hơn lựa chọn” ưu tiên rõ ràng, chấp nhận giảm linh hoạt.

Artifact: Design Principle Record

Trường	Nội dung
Tên ngắn	Cụm từ dễ nhớ
Ý nghĩa	Nghĩa trong bối cảnh sản phẩm
Hướng dẫn hành động	Thiết kế phải làm gì
Ví dụ	Giao diện thể hiện nguyên tắc
Đánh đổi	Điều bị giảm hoặc từ bỏ
Mức ưu tiên	Nguyên tắc thắng khi xung đột
Điều kiện	Khu vực hoặc trạng thái áp dụng

Bộ nguyên tắc nên ngắn, thường ba đến năm nguyên tắc. Cùng giá trị không buộc mọi điểm chạm có cùng cường độ. Marketing có thể táo bạo; thanh toán cần ổn định; hỗ trợ khi sự cố cần thẳng thắn.

Failure mode: nguyên tắc chỉ nằm trên poster, không được dùng trong review, nghiên cứu hoặc quyết định roadmap. Khi nguyên tắc xung đột mà không có thứ tự ưu tiên, nó không giúp phá thế hòa.

2. Pattern theo hành vi

Trực giác: tên “header có ảnh” khóa lời giải vào hình thức. Tên “quảng bá khóa học” giữ mục đích khi hình thức tiến hóa.

Định nghĩa: Functional Pattern là lời giải tái sử dụng hỗ trợ hành vi. Module là biểu hiện cụ thể như nút, biểu mẫu, menu hoặc thẻ.

Vì sao tồn tại: nhóm cần tái sử dụng quyết định, không chỉ tái sử dụng hình dạng.

Pattern Map:

Giai đoạn	Mục đích	Hành vi	Mẫu hiện có	Khoảng trống	Mẫu ứng viên

Interface Inventory nên kiểm kê theo mục đích:

Ảnh hoặc thành phần	Ngữ cảnh	Mục đích	Hành vi	Biến thể	Trùng lặp	Sai khác	Chủ sở hữu	Quyết định

Quy trình tối thiểu:

Chọn 10–12 màn hình thuộc luồng cốt lõi.
Sắp theo hành trình.
Xác định hành vi chính.
Tách thành phần theo hành vi.
Nhóm theo mục đích, không theo màu hoặc hình.
Quyết định gộp, tách, biến thể hoặc giữ riêng.
Ghi chủ sở hữu và bước tiếp theo.

Failure mode: kiểm kê mọi biểu tượng trước khi hiểu hành trình. Điều kiện chạy kiểm kê: mục tiêu, nội dung và kiến trúc thông tin tương đối rõ; không dùng để che lỗi chiến lược hoặc thay toàn bộ định hướng sản phẩm.

3. Quy tắc gộp, tách và biến thể

Trực giác: hai giải pháp nhìn giống nhau chưa chắc nên cùng tên.

Định nghĩa:

Gộp: mục đích và cấu trúc lõi giống nhau.
Biến thể: mục đích và cấu trúc lõi giống nhau; ngữ cảnh hoặc mức nhấn khác.
Tách: mục đích khác, hoặc cấu trúc phải khác để đạt cùng mục đích.
Dùng một lần: mục đích đặc thù, chưa có tín hiệu tái sử dụng hoặc thuộc vùng thử nghiệm giới hạn.

Decision rule: nếu mẫu này đổi, mẫu kia có nên đổi cùng không? Nếu có, chúng có thể cùng mẫu hoặc cùng hệ biến thể.

Rule of Three là chính sách quản trị, không phải chân lý. Tổ chức có thể:

Ghi nhận mọi phần tử mới và kiểm tra trùng lặp bắt buộc.
Ghi nhận ở lần tái sử dụng thứ hai hoặc thứ ba.
Ghi nhận khi có tiềm năng tái sử dụng rõ.

Giải pháp dùng một lần phải được công khai, nêu lý do và ghi vào:

Chủ sở hữu	Mục đích	Nơi dùng	Mức đặc thù	Tín hiệu tái sử dụng	Ngày xem lại

Failure mode: tái sử dụng cưỡng ép làm trải nghiệm bị bóp để vừa component. Ngược lại, biến thể không giới hạn biến thư viện thành danh mục ngoại lệ.

4. Cấu trúc mẫu và nội dung

Trực giác: nội dung thật làm lộ cấu trúc yếu.

Định nghĩa: Pattern Structure Sketch mô tả mục đích, nội dung, thứ bậc, nhóm, trạng thái, ràng buộc, ngữ cảnh và tiêu chí thành công trước khi chỉnh lớp sơn.

Trường	Nội dung
Mục đích	Mẫu giúp ai làm gì
Nội dung bắt buộc	Thiếu sẽ phá mục đích
Nội dung tùy chọn	Có thể bỏ
Thứ bậc	Thứ được thấy trước
Nhóm	Quan hệ logic
Tương tác	Hành động, trạng thái, phản hồi
Ràng buộc	Độ dài, kích thước, dữ liệu
Ngữ cảnh	Nơi được phép dùng
Tiêu chí thành công	Hành vi cần quan sát

Content là giả thuyết kiểm tra cấu trúc. Khi nội dung không khớp:

Mục đích sai: quay lại hành vi.
Cấu trúc sai: sửa cấu trúc.
Nội dung bị ép vào sai mẫu: sửa nội dung hoặc chọn mẫu khác.

Failure mode: thêm kiểu tùy chỉnh để vá từng trường hợp. Cách này tạo component dễ vỡ.

5. Quy luật trải nghiệm

Các quy luật UX là Heuristic, không phải luật cứng. Chúng hỗ trợ giải thích và tạo giả thuyết; chúng không thay nghiên cứu người dùng.

Jakob’s Law: người dùng mang mô hình quen thuộc từ sản phẩm khác. Theo quy ước với tìm kiếm, thanh toán, điều hướng và biểu mẫu; chỉ phá quy ước khi lợi ích đủ bù chi phí học.
Fitts’s Law: mục tiêu lớn, gần và tách biệt dễ chọn hơn. Apple nêu 44x44 pt; Google Material Design nêu 48x48 dp; tài liệu WCAG có tiêu chí riêng theo phiên bản và ngữ cảnh. Không biến các đơn vị này thành một 44x44px cho mọi nền tảng.
Hick’s Law: số lượng và độ phức tạp lựa chọn làm tăng thời gian quyết định. Nhóm lựa chọn, tạo thứ bậc, làm nổi hành động chính và dùng Progressive Disclosure cho tùy chọn nâng cao.
Miller’s Law: không dùng con số bảy làm giới hạn menu. Dùng phân cụm có nghĩa, tiêu đề và nhận diện thay cho hồi tưởng.
Postel’s Law: đầu vào có thể linh hoạt, đầu ra cần ổn định. Chấp nhận khoảng trắng hoặc gạch nối trong số điện thoại khi an toàn; vẫn phải xác thực tại trust boundary, chuẩn hóa và bảo vệ dữ liệu.
Tesler’s Law: độ phức tạp không biến mất. Hệ thống nên xử lý phần ổn định; người dùng vẫn phải thấy phần cần hiểu để quyết định.
Doherty Threshold: phản hồi nhanh giữ mạch thao tác. Dưới 100ms thường tạo cảm giác tức thời; khoảng dưới 400ms thường giữ tương tác trôi chảy; chậm hơn cần trạng thái rõ. Giao diện lạc quan phải có hoàn tác hoặc phục hồi khi xử lý nền thất bại.
Aesthetic–Usability Effect: giao diện đẹp có thể được cảm nhận là dễ dùng dù người dùng vẫn thao tác sai. Quan sát hành vi, không chỉ nghe lời khen.

Boundary: hành động xóa, chuyển tiền hoặc công bố dữ liệu cần Friction có chủ ý. Tốc độ không thắng an toàn và khả năng phục hồi.

6. Mẫu cảm nhận và thương hiệu

Trực giác: thương hiệu thường nằm trong quan hệ và tỷ lệ giữa màu, chữ, khoảng cách, hình ảnh, chuyển động và giọng điệu; không nằm trong một mã màu.

Định nghĩa: Perceptual Pattern là cách hệ thống tạo cảm nhận và tính cách qua thị giác, ngôn ngữ, chuyển động, âm thanh và sự phối hợp giữa chúng.

Design Persona:

Trường	Nội dung
Đặc tính mong muốn	Năm đến bảy đặc tính
Đặc tính phải tránh	Ranh giới chống lệch
Hình mẫu	Người, nơi chốn hoặc không khí
Giọng điệu	Cách sản phẩm nói
Biểu đạt thị giác	Màu, chữ, hình, khoảng cách
Biểu đạt tương tác	Phản hồi, chuyển động, âm thanh

Ranh giới tốt: vui nhưng không trẻ con; thân mật nhưng không cẩu thả; mạnh nhưng không phức tạp.

Công cụ khám phá:

Mood Board: định hướng rộng, độ hoàn thiện thấp.
Style Tile: màu, chữ và phần tử giao diện.
Element Collage: mảnh giao diện gần sản phẩm thật hơn, chưa tạo kỳ vọng như màn hình hoàn chỉnh.

Mẫu đặc trưng chỉ nên gia nhập hệ thống khi có ý nghĩa ngoài trang trí, được lặp có chủ đích, nối với mẫu khác, có giới hạn ngữ cảnh và vẫn đúng khi dữ liệu tăng.

Màu phải được định nghĩa theo vai trò: văn bản, liên kết, hành động, thành công, cảnh báo, lỗi, nền, đường viền, biểu đồ và cảm xúc thương hiệu. Không dùng màu làm tín hiệu duy nhất. Kiểm tra Accessibility trong lúc tạo bảng màu; tỷ lệ 4.5:1 là một ngưỡng phổ biến cho văn bản thường theo WCAG, nhưng tiêu chí cụ thể phụ thuộc cỡ chữ, nội dung và phiên bản tiêu chuẩn áp dụng.

Chuyển động phải có mục đích:

Mục đích	Hiệu ứng	Cảm nhận	Thuộc tính
Đổi trạng thái	Màu, opacity, scale	Mềm, chắc	Theo trạng thái
Hiện thông tin	Trượt, mờ dần	Bình tĩnh	Vị trí, opacity
Nhấn mạnh	Pulse, bounce	Năng động	Scale, transform

Hỗ trợ giảm chuyển động. Vùng lỗi, thanh toán hoặc mất dữ liệu cần giọng nghiêm túc, không dùng giọng vui để che hậu quả.

7. Shared Language và Pattern Library

Trực giác: đội không thể cộng tác nếu cùng từ chỉ các vật khác nhau.

Định nghĩa: Shared Language gồm tên, định nghĩa, mục đích, ranh giới và cách dùng chung trong thiết kế, mã nguồn, tài liệu và hội thoại.

Tên “nút hồng” hoặc “header có ảnh” dễ lỗi thời. Tên theo mục đích hỗ trợ tiến hóa.

Naming Decision:

Trường	Nội dung
Tên chính thức	Tên dùng ở mọi nơi
Mục đích	Mẫu giúp ai làm gì
Điểm phân biệt	Khác mẫu gần nhất ở đâu
Ví dụ	Trường hợp chuẩn
Tên bị loại	Kiểm tra lịch sử
Chủ quyết định	Người chốt cuối
Nơi cần đồng bộ	Thiết kế, mã nguồn, tài liệu

Khó đặt tên thường báo hiệu mục đích chưa rõ, ranh giới chồng lấn hoặc thành phần tồn tại vì thuận tiện kỹ thuật.

Pattern Library tối thiểu phải cho biết:

Mẫu là gì.
Phục vụ mục đích nào.
Khi nào dùng và không dùng.
Biến thể khác nhau ra sao.
Mẫu thay thế gần nhất.
Trạng thái triển khai và phiên bản.
Người đóng góp và chủ sở hữu.

Bắt đầu Content-first bằng công cụ cộng tác sẵn có. Chỉ xây nền tảng riêng khi nhu cầu nội dung, quy trình và tìm kiếm đã rõ.

Trường bản ghi	Mức
Tên	Bắt buộc
Mục đích	Bắt buộc
Ví dụ thị giác và mã	Bắt buộc
Biến thể và điều kiện	Bắt buộc
Trường hợp không dùng	Nên có
Mẫu thay thế	Khi cần
Phiên bản, thay thế, ngừng dùng	Khi cần
Người đóng góp và chủ sở hữu	Khi cần quản trị

Token màu, cỡ chữ, khoảng cách và thời lượng không đủ. Tài liệu phải ghi vai trò, tỷ lệ, ngữ cảnh, quy tắc tiếp cận, ví dụ đúng–sai và lý do.

Source of Truth phải được chỉ định theo loại quyết định. Tài liệu có thể là nguồn cho hướng dẫn; mã nguồn sản xuất là nguồn cho hành vi thực thi; tệp thiết kế là nguồn cho tài sản thiết kế. Gọi mọi nơi là một nguồn duy nhất tạo mâu thuẫn.

Applied

Tình huống mô phỏng: Bếp Vui

“Bếp Vui” giúp người mới nấu món lành mạnh bằng nguyên liệu phổ biến. Ba nhóm phụ trách khám phá công thức, hướng dẫn nấu và cộng đồng.

Sau một năm, sản phẩm có bốn loại thẻ công thức, sáu biến thể nút chính, hai cách gọi cùng một bước nấu, màu nhấn dày đặc, nội dung dài đẩy hành động khỏi vùng nhìn và thay đổi nhỏ phải sửa nhiều nơi. Nhóm cộng đồng muốn thêm hiệu ứng mới để tăng tương tác.

Đây là tình huống mô phỏng. Các dữ kiện không phải số liệu thực tế của tổ chức.

Case record

Thành phần	Nội dung
Facts	Bốn loại thẻ; sáu biến thể nút; tên bước không thống nhất; nội dung dài; sửa đổi chạm nhiều nơi; nhóm cộng đồng muốn thêm hiệu ứng
Current behavior	Mỗi nhóm tự giải quyết trong luồng riêng; chưa có mẫu chung, quyền rõ hoặc thư viện đáng tin
Underlying need	Người mới cần nấu đúng, nhanh và tự tin; đội cần giảm lặp, sai khác và rủi ro tiếp cận
Options	Xây toàn bộ thư viện ngay; không đầu tư; chạy Pilot trong luồng nấu; chỉ chuẩn hóa visual token
Decision criteria	Tác động hành vi cốt lõi, chi phí thay đổi, khả năng tiếp cận, tín hiệu tái sử dụng, năng lực bảo trì, rủi ro làm chậm đội
Decision	Chạy Pilot trong luồng cốt lõi; gộp thẻ có cùng cấu trúc; giữ thẻ cộng đồng riêng; dùng công cụ tài liệu sẵn có trước
Authority	Product Manager sở hữu phạm vi và kết quả; Design Lead chốt nguyên tắc và trải nghiệm; Engineering Lead chốt khả năng triển khai; Accessibility owner phủ quyết lỗi tiếp cận; Product Leader phân xử khi mục tiêu kinh doanh xung đột
Artifact	Purpose-to-pattern chain, Pattern Map, Interface Inventory, Pattern Submission Template, Design System Business Case, Pattern Impact Review
Consequence if wrong	Gộp sai làm mất mục đích; chuẩn hóa quá mức làm luồng nấu khó dùng; thư viện thiếu quyền làm bị bỏ rơi; hiệu ứng sai ngữ cảnh làm giảm tin cậy; đo sai làm tiếp tục đầu tư vào hệ thống không tạo giá trị

1. Chốt mục đích và nguyên tắc

Mục đích sản phẩm: giúp người mới nấu món ngon, lành mạnh và tự tin trong thời gian ngắn.

Nguyên tắc	Hướng dẫn	Đánh đổi	Điều kiện
Tôn trọng thời gian	Bước ngắn, phản hồi nhanh, bỏ thông tin không cần	Giảm tùy biến	Luồng nấu
Tự tin hơn tối ưu	Làm rõ trước khi rút ngắn	Tăng một số bước	Hành động dễ sai
Khích lệ, không phô trương	Giọng ấm, chuyển động nhỏ	Giảm hiệu ứng nổi bật	Sản phẩm chính
Sáng tạo có kiểm soát	Cho thay thế nguyên liệu và thử nghiệm	Giảm đồng dạng tuyệt đối	Khám phá và marketing

Marketing có thể dùng hình dạng và màu mạnh hơn. Luồng nấu cần ít nhiễu vì người dùng có thể có tay bẩn, thời gian ngắn và chú ý phân tán.

2. Bản đồ hành vi

Facts	Current behavior	Underlying need	Options	Decision criteria	Decision	Authority	Artifact	Consequence if wrong
Khám phá có thẻ và bộ lọc khác nhau	Mỗi nhóm dùng cấu trúc riêng	Người dùng cần quét, lọc và lưu	Giữ bốn thẻ; gộp toàn bộ; gộp thẻ cùng mục đích	Cấu trúc lõi, hành vi, nội dung	Gộp thẻ có cùng cấu trúc; giữ biến thể thường và nổi bật	Design Lead chốt cấu trúc; PM chốt phạm vi	Pattern Map, Interface Inventory	Gộp sai làm người dùng khó chọn hoặc mất ngữ cảnh
Luồng nấu có nhiều bước	Nội dung dài che hành động	Người mới cần biết thông tin quyết định trước khi bắt đầu	Rút toàn bộ; thêm nhãn nhỏ; phân tầng nội dung	Hiểu, hoàn tất, khả năng tiếp cận, bản dịch	Giữ thời gian, độ khó, nguyên liệu chính và cảnh báo dị ứng ở đầu; chuyển câu chuyện sang đọc thêm	PM sở hữu mục tiêu; Content Lead sở hữu nội dung	Pattern Structure Sketch	Người dùng bắt đầu sai hoặc bỏ cuộc
Nút có sáu biến thể	Mỗi nhóm gọi “primary” khác nhau	Người dùng cần thứ bậc hành động rõ	Chuẩn hóa ba cấp; định nghĩa theo phạm vi; giữ mọi biến thể	Mức nhấn, ngữ cảnh, khả năng phục hồi	Một hành động chính mỗi màn hình; phân biệt hành động mặc định, điều hướng và hành động ngữ cảnh	Design Lead chốt semantics; Engineering Lead chốt mã	Naming Decision	Hành động cạnh tranh, chọn nhầm hoặc không biết bước kế
Nhóm cộng đồng muốn hoạt ảnh	Hiệu ứng chưa có giới hạn	Người dùng cần khoảnh khắc hoàn tất tích cực, không bị cản nhiệm vụ	Dùng mọi nơi; cấm toàn bộ; thử giới hạn	Ý nghĩa, tần suất, giảm chuyển động, lỗi và hậu quả	Pilot khi đăng ảnh thành công; cấm trong lỗi, thanh toán và cảnh báo	PM quyết định thử; Accessibility owner có quyền phủ quyết	Pattern Impact Review, Undocumented Pattern Log	Giao diện phô trương, người nhạy cảm bị ảnh hưởng, giảm tin cậy
Đội sửa nhiều nơi	Thiết kế và mã lệch	Đội cần giảm chi phí thay đổi	Xây nền tảng toàn bộ; dùng tài liệu sẵn có; không làm gì	Tín hiệu tái sử dụng, chi phí, năng lực bảo trì	Dùng công cụ cộng tác sẵn có; thay dần bằng component sống khi mã ổn định	PM chốt đầu tư; Engineering Lead chốt lộ trình mã	Business Case, Pattern Library	Đầu tư lớn trước khi biết nhu cầu hoặc thư viện không được dùng

3. Xử lý nội dung và Accessibility

Đội xác định thông tin cần trước khi bắt đầu, chuyển câu chuyện đầu bếp sang vùng đọc thêm, giữ dữ liệu quyết định ở đầu và thử với cỡ chữ lớn, bản dịch dài, bàn phím và trình đọc màn hình.

Không dùng màu làm tín hiệu duy nhất. Kiểm tra mục tiêu cảm ứng theo chuẩn nền tảng được chọn. Nếu hành động lạc quan được dùng, phải có hoàn tác hoặc phục hồi khi xử lý nền thất bại.

4. Thư viện tối thiểu

Đội dùng công cụ viết cộng tác hiện có. Bản ghi đầu tiên gồm tên, mục đích, cấu trúc, ví dụ, biến thể, trường hợp không dùng, trạng thái mã nguồn và chủ sở hữu.

Ảnh chụp được chấp nhận trong Pilot. Component sống được thay dần khi hành vi, API và trạng thái đã ổn định. Documentation Completeness không phải chờ Implementation Maturity hoàn hảo.

5. Đo kết quả

Đội lập số nền trước Pilot và so sánh sau Pilot:

Thời gian thiết kế, xây dựng và kiểm thử luồng.
Số biến thể mới.
Số lỗi lệch giữa thiết kế và mã.
Thời gian tìm mẫu.
Tỷ lệ hoàn tất bước nấu.
Lỗi chọn nhầm.
Mức tự tin sau nhiệm vụ.
Lỗi tiếp cận.
Số yêu cầu hỗ trợ.

Không tuyên bố “giảm vài tuần xuống vài ngày” nếu chưa có số đo. Business Case phải ghi kết quả, nguồn dữ liệu, phạm vi thử nghiệm và điều chưa chứng minh.

Senior Lens

1. Ba phổ vận hành

Ba phổ độc lập:

P4.5 - Design System như một sản phẩm nội bộ — diagram 2

Source mermaid — có thể chỉnh sửa

flowchart TB
    X["Ba phổ độc lập<br/>Không gộp thành chuỗi"]

    X -.-> A["Nghiêm ngặt ↔ Linh hoạt"]
    A --> A1["Chọn theo: thiệt hại khi sai, nhu cầu dự đoán,<br/>tốc độ đổi, năng lực review, quyền phủ quyết"]
    A1 --> A2["Nghiêm ngặt: cần đồng bộ;<br/>sai khác gây rủi ro thương hiệu,<br/>pháp lý hoặc vận hành"]
    A1 --> A3["Linh hoạt: ngữ cảnh đổi mạnh,<br/>cần thử nghiệm"]
    A2 --> A4["Đánh đổi: chậm thử nghiệm,<br/>đội né hệ thống"]
    A3 --> A5["Đánh đổi: phụ thuộc Tacit Knowledge,<br/>khó mở rộng, dễ vỡ khi nhân sự đổi"]

    X -.-> B["Mô-đun ↔ Tích hợp"]
    B --> B1["Mô-đun: nhiều lặp, nhiều nhóm,<br/>cần làm song song"]
    B --> B2["Tích hợp: chiến dịch, portfolio,<br/>trải nghiệm có định hướng nghệ thuật"]
    B1 --> B3["Đánh đổi: tái sử dụng<br/>nhưng có thể chung chung"]
    B2 --> B4["Đánh đổi: câu chuyện tốt<br/>nhưng khó bảo trì"]
    B --> B5["Reuse không phải mục tiêu tự thân"]
    B5 --> B6["Cân bằng User Benefit<br/>và Technical Efficiency"]

    X -.-> C["Tập trung ↔ Phân tán"]
    C --> C1["Tập trung: tiêu chuẩn<br/>và quyền rõ"]
    C --> C2["Phân tán: tăng tự chủ"]
    C1 --> C3["Đánh đổi: có thể thành nút thắt"]
    C2 --> C4["Đánh đổi: dễ lệch"]
    C --> C5["Mô hình lai: mở đóng góp;<br/>tập trung tuyển chọn và quyết định rủi ro cao"]
    C1 --> C6["Chỉ tuyên bố tập trung khi nhóm trung tâm<br/>có nguồn lực và quyền quyết định thật"]
    C6 --> C7["Thiếu một trong hai:<br/>không thể tuyên bố mô hình tập trung"]
    C --> C8["Conway’s Law: cấu trúc hệ thống<br/>phản chiếu cấu trúc giao tiếp"]

Nghiêm ngặt–linh hoạt

Nghiêm ngặt hợp khi cần kết quả dự đoán được, nhiều nền tảng phải đồng bộ hoặc sai khác tạo rủi ro thương hiệu, pháp lý hay vận hành. Rủi ro là chậm thử nghiệm và khiến đội né hệ thống.

Linh hoạt hợp khi ngữ cảnh thay đổi mạnh, cần thử nghiệm và nhóm nhỏ có tri thức chung. Rủi ro là phụ thuộc Tacit Knowledge, khó mở rộng và dễ vỡ khi nhân sự thay đổi.

Decision criteria: mức thiệt hại khi sai, nhu cầu dự đoán, tốc độ đổi, năng lực review và quyền phủ quyết.

Mô-đun–tích hợp

Mô-đun hợp sản phẩm có nhiều lặp, nhiều nhóm và nhu cầu làm song song. Tích hợp hợp chiến dịch, portfolio hoặc trải nghiệm có định hướng nghệ thuật riêng.

Mô-đun tạo tái sử dụng nhưng có thể chung chung. Tích hợp tạo câu chuyện tốt nhưng khó bảo trì. Reuse không phải mục tiêu tự thân; User Benefit phải cân bằng Technical Efficiency.

Tập trung–phân tán

Tập trung tạo tiêu chuẩn và quyền rõ nhưng có thể thành nút thắt. Phân tán tăng tự chủ nhưng dễ lệch. Mô hình lai mở đóng góp, tập trung tuyển chọn và quyết định rủi ro cao.

Conway’s Law gợi ý hệ thống phản chiếu cấu trúc giao tiếp. Không tuyên bố tập trung nếu nhóm trung tâm không có nguồn lực hoặc quyền thật.

2. Tách quyền và trách nhiệm

Quyền	Câu hỏi	Chủ thể điển hình	Ranh giới
Đóng góp	Ai được đề xuất?	Mọi nhóm sản phẩm	Không tự động được chấp nhận
Tuyển chọn	Đề xuất có đúng mục đích và không trùng?	Nhóm hệ thống hoặc hội đồng nhỏ	Phải trả lý do
Triển khai	Ai sở hữu mã, phát hành, hỗ trợ?	Nhóm hệ thống hoặc nền tảng	Chịu trách nhiệm vận hành
Phủ quyết	Ai chặn rủi ro hệ thống?	Product, Design, Engineering và Accessibility owner theo rủi ro	Chỉ dùng cho tiêu chí đã công khai
Quyết định sản phẩm	Mẫu có đáng ưu tiên không?	Product Manager hoặc Product Leader	Cân bằng kết quả người dùng và chi phí

Governance phải tham gia sớm như đối tác. Chỉ bắt lỗi ở cổng cuối tạo làm lại và văn hóa đối đầu.

Pattern Submission Template:

Trường	Nội dung
Tên đề xuất	Tên tạm
Tác giả và ngày	Truy trách nhiệm
Mục đích	Giúp ai làm gì
Liên hệ mục đích sản phẩm	Lý do tồn tại
Mẫu tương tự	Đã kiểm tra gì
Cấu trúc	Nội dung và tương tác lõi
Ngữ cảnh	Nơi dùng
Bằng chứng tái sử dụng	Hiện có hoặc tiềm năng
Tác động tiếp cận	Bàn phím, trình đọc màn hình, tương phản, chuyển động
Tiêu chí đo	Hành vi và kết quả
Kế hoạch thay thế	Khi mẫu cũ lỗi thời

Documentation phải nằm trong Definition of Done của thay đổi mẫu.

3. Luận chứng đầu tư

Dấu hiệu đáng đầu tư:

Designer giải lại cùng vấn đề.
Developer tùy chỉnh từng component.
Thiết kế triển khai lệch.
Thay đổi nhỏ chạm nhiều nơi.
Có nhiều nút, màu hoặc tên gần giống.
Tốc độ phát hành giảm khi sản phẩm lớn lên.
Không ai biết mẫu nào là chuẩn.

Design System Business Case:

Phần	Nội dung
Chi phí nền	Thiết kế, xây, kiểm thử, sửa, bảo trì
Phạm vi Pilot	Một luồng, một sprint, hai người
Kết quả trước–sau	Thời gian, lỗi, mức dùng lại
Tác động kinh doanh	Tốc độ, chi phí, rủi ro
Tác động người dùng	Hoàn tất, hiểu, tiếp cận, niềm tin
Giới hạn	Điều chưa chứng minh
Nguồn lực	Người, thời gian, công cụ
Mốc xem lại	Tiếp tục, đổi hoặc dừng

Lộ trình cần hai luồng:

Hệ thống hóa giao diện: nguyên tắc, mẫu, thư viện, tệp thiết kế, kiến trúc.
Thiết lập thực hành: đặt tên, chia sẻ, onboarding, đóng góp, review và quyền.

Đưa công việc vào roadmap và bảo trì thường kỳ. Không giữ hệ thống như dự án phụ vô hạn.

4. Stakeholder, thử nghiệm và leo thang

Khi stakeholder yêu cầu “hào nhoáng”, tách Intent khỏi Proposed Solution.

Trường	Nội dung
Ý định kinh doanh	Nhận diện, doanh thu, dữ liệu hoặc niềm tin
Nhiệm vụ người dùng	Việc bị ảnh hưởng
Lợi ích dự kiến	Phương án có thể cải thiện gì
Rủi ro	Khả năng sử dụng, thiện cảm, thương hiệu, hiệu suất
Phương án khác	Cách ít gây hại hơn
Điều kiện chấp nhận	Vùng, thời gian, tần suất
Kế hoạch kiểm tra	Câu hỏi và hành vi
Tiêu chí giữ–sửa–bỏ	Quyết định sau phát hành

A/B Testing phù hợp khi có đủ lưu lượng, chỉ số đúng mục tiêu và rủi ro đạo đức thấp. Usability Testing quan sát nguyên nhân và mức hiểu; A/B Testing đo khác biệt hành vi tổng hợp. Không dùng một phương pháp thay phương pháp kia.

Khi tranh luận kéo dài:

Chuyển tranh luận thành câu hỏi kiểm thử.
Dựng phiên bản nhỏ nhất đủ quan sát.
Kiểm thử với ba hoặc bốn người.
Ghi bằng chứng trong ngày.
Sửa lỗi lớn.
Kiểm thử hồi quy.

Vấn đề	Bằng chứng	Tác động nhiệm vụ	Khả năng tự phục hồi	Quyết định	Chủ sở hữu	Kiểm thử lại

Escalation boundary:

Rủi ro an toàn, bảo mật, dữ liệu, khả năng tiếp cận hoặc hành động không thể đảo ngược: dừng phát hành, chuyển owner có quyền phủ quyết.
Rủi ro trải nghiệm có thể phục hồi: thử phạm vi nhỏ, ghi giả thuyết và theo dõi.
Rủi ro thấp, giải pháp dùng một lần: ghi nhật ký, đặt ngày xem lại và không tạo abstraction sớm.

5. Tác động con người và đạo đức

Một mẫu nhất quán vẫn có thể gây hại. Mẫu có thể tăng click hoặc doanh thu nhưng làm người dùng mất thời gian, tiền, quyền kiểm soát hoặc niềm tin.

Pattern Impact Review:

Trường	Câu hỏi
Mục tiêu thương mại	Chỉ số nào cần cải thiện?
Kết quả con người	Người dùng nhận giá trị gì?
Hành vi tối ưu	Hệ thống khuyến khích gì?
Nhóm hưởng lợi	Ai nhận lợi ích?
Nhóm chịu thiệt	Ai bị loại trừ hoặc gánh rủi ro?
Nguy cơ thiên lệch	Dữ liệu hoặc tương tác thiên về ai?
Nguy cơ hối tiếc	Người dùng có thể hối tiếc gì?
Khả năng phục hồi	Có hoàn tác, rời đi hoặc sửa lỗi không?
Đo sau phát hành	Tác động được theo dõi thế nào?

Dùng Friction có chủ ý cho xóa dữ liệu, chuyển tiền, công bố thông tin, đổi quyền truy cập và hành động hậu quả lớn. Không dùng phần thưởng biến đổi hoặc cơ chế gây nghiện chỉ để tăng Engagement. Accessibility và Inclusion là ngưỡng chất lượng.

6. Failure patterns

Nhà máy thành phần: sản xuất module mà không kiểm tra mục đích.
Cảnh sát thiết kế: chỉ kiểm tra tuân thủ và tham gia quá muộn.
Danh mục sinh tự động: tạo website từ mã rồi tuyên bố đã có hệ thống.
Thư viện một chuyên môn: designer và developer không cùng sửa được.
Tri thức ngầm: hệ thống chỉ hoạt động khi vài người lâu năm còn ở lại.
Tài liệu chậm hơn mã: phát hành xong nhưng không biết cách dùng.
Đồng bộ tuyệt đối: mọi thay đổi bị chặn đến khi mọi nơi hoàn hảo.
Biến thể vô hạn: mọi trường hợp riêng được vá thành option.
Tên theo hình thức: tên chết khi hình thức thay đổi.
Tái sử dụng cưỡng ép: trải nghiệm bị bóp để vừa component.
Chuẩn hóa mất thương hiệu: mọi vùng thành đồng dạng.
Thước đo một chiều: chỉ đo mức dùng thư viện hoặc tốc độ phát hành.
Engagement bằng giá trị: xem tương tác là lợi ích người dùng.
Accessibility cuối dự án: tiếp cận bị xử lý như lớp phủ.
Sao chép tổ chức khác: sao chép mô hình mà không có đội, công cụ, đồng bộ và quyền tương ứng.

Quick reference

Cây quyết định cho mẫu mới

Checklist

Tiêu chí	Câu hỏi
Mục đích	Mẫu phục vụ mục đích sản phẩm nào?
Hành vi	Mẫu giúp ai làm gì?
Bằng chứng	Nhu cầu đến từ nghiên cứu, dữ liệu hay quan sát nào?
Trùng lặp	Mẫu tương tự đã tồn tại chưa?
Cấu trúc	Nội dung bắt buộc, tùy chọn và không phù hợp là gì?
Thứ bậc	Hành động quan trọng nhất có rõ không?
Biến thể	Ranh giới biến thể nằm ở đâu?
Quy ước	Có phá mô hình quen thuộc không?
Khả dụng	Có tạo bất định không cần thiết không?
Tiếp cận	Bàn phím, trình đọc màn hình, tương phản, cỡ chữ và giảm chuyển động đạt chưa?
Nội dung	Chịu được dữ liệu thật và bản dịch dài không?
Hiệu suất	Phản hồi đủ nhanh và rõ không?
Đạo đức	Ai hưởng lợi, ai chịu thiệt, có nguy cơ hối tiếc không?
Tài liệu	Tên, mục đích, ví dụ, biến thể và trường hợp tránh đã có chưa?
Sở hữu	Ai đóng góp, tuyển chọn, triển khai và chốt cuối?
Đo lường	Theo dõi hành vi và kết quả nào?

Ma trận rủi ro và xử lý

Rủi ro	Xử lý
An toàn, bảo mật, dữ liệu, tiếp cận, không thể đảo ngược	Xử lý trước; owner có quyền phủ quyết quyết định
Trải nghiệm có thể phục hồi	Thử giới hạn; ghi giả thuyết; theo dõi
Thấp và dùng một lần	Ghi nhật ký; đặt ngày xem lại; không abstraction sớm

Đánh giá hiệu quả

Chiều	Chỉ số gợi ý
Chi phí thiết kế	Thời gian tạo luồng, số lần vẽ lại
Chi phí phát triển	Thời gian xây, kiểm thử và sửa
Chi phí thay đổi	Số nơi phải chạm, lỗi hồi quy
Mức dùng	Tỷ lệ dùng mẫu phù hợp
Khả năng tìm	Thời gian tìm đúng mẫu
Chất lượng	Lỗi sai khác, lỗi tiếp cận, lỗi nội dung
Kết quả người dùng	Hoàn tất, lỗi, thời gian, mức hiểu, tự tin
Niềm tin	Khiếu nại, hỗ trợ, quay lại, thiện cảm
Sức khỏe hệ thống	Biến thể, mẫu lỗi thời, thời gian review
Tác động con người	Bao trùm, hối tiếc, phục hồi, nhóm chịu thiệt

Thuật ngữ sử dụng trong chương

Thuật ngữ	Giải nghĩa tiếng Việt
Design System	Hệ thống mẫu và thực hành chung để tạo, dùng, quản trị và phát triển trải nghiệm
Design Pattern / Pattern	Lời giải lặp lại cho một vấn đề, nhu cầu, hành vi hoặc cảm nhận
Functional Pattern	Mẫu gắn với chức năng và hành vi
Perceptual Pattern	Mẫu tạo cảm nhận, thẩm mỹ và tính cách thương hiệu
Module	Biểu hiện giao diện cụ thể của mẫu chức năng
Pattern Library	Công cụ ghi nhận và chia sẻ mẫu cùng hướng dẫn
Style Guide	Tài liệu tập trung vào phong cách và thương hiệu
Shared Practice	Cách chung để tạo, đánh giá, chia sẻ, dùng và thay đổi mẫu
Shared Language	Tên, định nghĩa và cách hiểu chung
Governance	Quy tắc, quy trình và quyền quyết định
Design Principle	Hướng dẫn có quan điểm để xử lý đánh đổi
Interface Inventory	Hoạt động thu thập, nhóm và đánh giá giao diện
Pattern Map	Bản đồ nối hành trình, hành vi và mẫu
Variant	Biến thể giữ mục đích và cấu trúc lõi
Design Token	Giá trị thiết kế có tên như màu, khoảng cách hoặc thời lượng
Usability	Khả năng hoàn thành mục tiêu với khó khăn chấp nhận được
Accessibility	Khả năng người khuyết tật tiếp cận và sử dụng sản phẩm
Cognitive Load	Nỗ lực trí óc cần để hiểu và dùng sản phẩm
Goodwill	Mức kiên nhẫn, tin tưởng và thiện chí người dùng dành cho sản phẩm
Source of Truth	Nguồn tham chiếu chính cho một loại quyết định
Decision Owner	Người có quyền chốt quyết định cuối
Pilot	Thử nghiệm nhỏ có phạm vi và số đo rõ
Regression Risk	Nguy cơ thay đổi làm hỏng hành vi đang hoạt động
Intent	Ý định hoặc kết quả muốn đạt
Proposed Solution	Giải pháp được đề xuất
Tacit Knowledge	Tri thức ngầm, khó truyền đạt bằng tài liệu
Friction	Ma sát có chủ ý trong thao tác
Goodwill	Thiện cảm và niềm tin tích lũy của người dùng

Nguồn và giới hạn

Nguồn chính

Design Systems — Alla Kholmatova: mục đích, nguyên tắc, mẫu chức năng, mẫu cảm nhận, ngôn ngữ chung, thư viện, ba phổ vận hành, kiểm kê và governance.
Laws of UX — Jon Yablonski: các heuristic về quen thuộc, mục tiêu thao tác, lựa chọn, phân cụm, tốc độ, độ phức tạp, thẩm mỹ và trách nhiệm đạo đức.
Don’t Make Me Think — Steve Krug: rõ ràng, quét nhanh, quy ước, phân cấp thị giác, kiểm thử nhẹ, thiện cảm và xử lý yêu cầu stakeholder.

Các số đo và ngưỡng kỹ thuật trong chương được nêu như tham khảo theo nguồn hoặc nền tảng tương ứng, không phải cam kết áp dụng cho mọi sản phẩm. 44x44 pt, 48x48 dp, 4.5:1, 100ms và 400ms cần được kiểm tra theo nền tảng, loại nội dung, phiên bản tiêu chuẩn và ngữ cảnh.

Giới hạn

Phần lớn luận điểm về vận hành hệ thống có thể cần kiểm chứng định tính và định lượng trong từng tổ chức.
Số liệu năng suất hoặc ROI từ một tổ chức không tự động áp dụng cho tổ chức khác.
Công cụ, tên sản phẩm và chuẩn kỹ thuật thay đổi; logic chọn công cụ bền hơn tên công cụ.
Heuristic tâm lý học không phải luật cứng. Áp dụng máy móc có thể tạo thiết kế tệ.
Nội dung thiên về web, ứng dụng số, thiết kế tương tác và thiết kế thị giác. Game, thiết bị nhúng, voice interface hoặc môi trường an toàn cao cần điều chỉnh.
Khung đạo đức nêu câu hỏi quản trị, chưa định lượng đầy đủ chất lượng sống hoặc tác động xã hội dài hạn.
Design System không sửa được chiến lược sai, nghiên cứu yếu, kiến trúc thông tin hỏng hoặc văn hóa thiếu trách nhiệm. Nó làm cơ chế hiện có lan nhanh hơn, theo hướng tốt hoặc xấu.
Đọc chương không chứng minh năng lực vận hành. Năng lực chỉ được kiểm chứng khi người đọc tự thu thập bằng chứng, chốt quyết định, phân bổ quyền, phát hành có kiểm soát và chịu trách nhiệm với hậu quả.