Nói về Design system, không phải bàn cãi nhiều về topic hot nhất hiện nay với bất cứ ai làm về digital product. Khi bắt tay vào xây dựng một Design system, bằng rất nhiều những nỗ lực để phân tách và làm rõ ràng từng phần bên trong đó, ta luôn phải đối mặt với những vấn đề đi từ trừu tượng đến cụ thể. Chẳng hạn như làm thế nào để phân biệt Pattern library, Style guides và Design system, Pattern Libraries Aren’t Just The Front End. Và bước đầu tiên cũng là bước quan trọng nhất khi xây dựng Design System là thiết kế ngôn ngữ sản phẩm (Design Languague).

Ngôn ngữ chung của Designer 🧑‍🎨 và Developer 🧑‍💻

Để bản thiết kế thực sự “work”, designer bắt buộc phải giao tiếp với các front-end developer, đó là lẽ tất nhiên. Nhưng, giao tiếp thế nào và sự hiệu quả tới đâu lại là những câu chuyện “biết mà không tránh” được.

Câu chuyện muôn thuở,

Designer muốn thay đổi và tinh chỉnh những chi tiết nhỏ để đem lại trải nghiệm tốt nhất cho người dùng, vì vậy họ luôn có xu hướng thử nghiệm và update mới. Nhưng với Developer (front-end developer) thì cần sự ổn định và nhất quán, vì những thay đổi nhỏ tưởng chừng đơn giản nhưng hoàn toàn không dễ dàng để thay đổi và “bảo dưỡng”, nhất là những thay đổi không thấy có giá trị đáng kể cho toàn hệ thống và tổ chức như những tinh chỉnh nhỏ ở trên.

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

Một tiến trình khi một thay đổi nhỏ được tạo ra từ designer sẽ liệt kê đơn giản như sau:

1. Designer thay đổi màu trong tool thiết kế (Sketch, Figma, …).
2. Designer cập nhật và chia sẻ với developer.
3. Developer cập nhật giá trị trong các file source code.
4. Designer có thể xem lại kết quả trong môi trường development (test, alpha hay sanbox).

Dễ thấy, team phát triển sẽ bị mất thời gian để trao đổi và thuyết phục việc thay đổi nhỏ cũng như phải chờ để xem lại kết quả. Đó cũng là một trong những lý do mà Design System được sinh ra như một cứu cánh cũng như giải pháp toàn diện để phát triển hệ thống sản phẩm.

One team, One voice

Design system là một hệ thống ngôn ngữ chung cho team, nơi designer có thể “look-and-feel”, và developer có thể biết được “how it work”.

Tham khảo trình tự khi xây dựng Design system: https://designsystemchecklist.com

Khi đã xác định được cho cả team ngôn chung, giờ là lúc để xác định việc mô tả và truyền đạt nó như thế nào. Và Design Tokens là bước tiếp theo sau Design Language.

Định nghĩa về Token

Design tokens (mã hiệu thiết kế) là một platform xác định các biến bất khả tri dùng để diễn đạt look-and-feel thương hiệu và sản phẩm của công ty. Chúng tạo thành các khối nguyên tố xây dựng cho Design system và được dùng để định nghĩa màu sắc, kiểu chữ, kích thước, khoảng cách cũng như các thuộc tính khác. Nó cung cấp nền tảng để tạo theme và tự động hoá quy trình thiết kế.

Ví dụ về design token cho màu sắc,

Hãy dừng lại một chút và bàn luận thêm về token. Như đã biết, trong ngôn ngữ lập trình, các từ khoá (keyword), hằng số (constant), định danh (identifier), chuỗi (string), con số (number), toán tử (operator) và các dấu chấm câu (symbol) được coi là các token.

Ví dụ, trong C language, với lệnh khai báo biến bên dưới,

int value = 100;

chứa các token sau:

int (keyword), value (identifier), = (operator), 100 (constant) and ; (symbol).

Tư tưởng căn bản ở đây chính là dùng các biến (keyword) khai báo (nhằm phục vụ trong nhiều mục đích trong lập trình) gán cho một giá trị cụ thể (constant). Nếu các constant này không liên quan hay ảnh hưởng đến logic, chỉ nhằm mục đích biểu đạt hiển thị bên ngoài như màu sắc, khoảng cách, kiểu chữ, hay kích thước (visual component), developer hoàn toàn không cần bận tâm đến giá trị cụ thể của nó mà chỉ quan tâm đến chức năng của biến (biến bất khả tri — biến số chưa biết giá trị). Hãy xem minh họa dưới đây:

Ông nói gà, bà nói vịt. Khi truyền đạt ý tưởng, mỗi góc nhìn đều cho ta giá trị khác nhau và đều đúng, do đó cần dùng chung một ngôn ngữ, Design Token chính là bảng chữ cái trong Design System Language đó.

Thay vì tranh luận giá trị của đối tượng đó là gì, developer và designer chỉ cần thống nhất đặt tên đối tượng đó để cùng truyền đạt. Ví dụ, chúng ta cùng nói đây là màu đỏ sơ cấp (primary-red-color), thay vì màu đỏ cherry 🍒 hay

88011d.

Design Token trong Design system

Các nhóm cấu phần chính thường được định nghĩa ở bất cứ Design system nào gồm: Colour, Layout, Typography, Iconography. Các ví dụ,

Carbon Design System (IBM)

Lightning Design System (Salesforce)

Ant Design

Xây dựng Design Token

Hãy quay lại câu chuyện đầu tiên ở trên, khi designer quyết định thay đổi màu của một button, giả định rằng anh ấy muốn thử nghiệm gì đó. Developer sẽ muốn được hiểu rõ mục đích của quyết định thay đổi này, nhờ đó họ lên các kế hoạch cho tương lai trong việc maintenance cũng như scale-up, cho dù thay đổi đó là nhỏ và ít giá trị.

Decisions. Decisions. Decisions. Faced with nearly infinite options, as a designer you make endless decisions through the design, development, and maintenance of every web site or application.

Source: Design Tokens: Scaling Design with a Single Source of Truth, Jina Anne

Để làm việc một cách có hệ thống và nhất quán, một workflow đơn giản để thiết kế token sẽ như sau:

Decision

Designer sẽ định nghĩa lớp sử dụng cho đối tượng với các giải thích cụ thể nó là cái gì (Component-specific), thống nhất gọi chung mã alias là gì, phạm vi sử dụng (căn cứ để scale-up thiết kế).

Design token types (, Adobe)

Với cách chia trên, một design token sẽ bao gồm 3 cấu phần:

• Global tokens: blue-40
• Alias tokens: cta-background-color
• Component-specific tokens: button-cta-background-color

Câu hỏi đặt ra là làm sao để phân loại các đối tượng vào các nhóm và đặt tên chúng gồm 3 cấu phần trêntrên để giữ mọi thứ luôn nhất quán theo thời gian và sự bùng nổ về khối lượng thiết kế khi scale-up design system. Một phương pháp tôi thấy khá thú vị có tên gọi là “One Big Thing” aka “1–3–5” bởi Ryan Neufeld giúp ta giải quyết vấn đề trên.

Chúng ta sẽ chia frame quyết định ra làm 3 phần, phần đầu tiên phải chứa mục lớn nhất và quan trọng nhất cần làm hoặc “việc lớn” của bạn. Phần thứ hai được chia thành ba hộp chứa ba thứ cỡ vừa của bạn. Cuối cùng, phần cuối dành cho những điều nhỏ nhặt của bạn (thường từ 5 lựa chọn trở lên).

Các Component-specific tokens sẽ là phần thứ nhất, Alias tokens sẽ là phần thứ 2 và các mã global tokens là phần còn lại.

Phương pháp này, cá nhân tôi thấy có thể kết hợp với phương pháp BEM — Block Element Modifier khi giải quyết vấn đề naming cho các component (một trong những vấn đề rất “đau đầu” với các designer).

Tham khảo thêm từ: (Style Dictionary)

Phân biệt property với token, value và attribute

Organize & Manage

Trong bối cảnh một design system được thiết kế phục vụ và đáp ứng cho nhiều platform và client device khác nhau, đồng thời sử dụng cho nhiều projects khác nhau. Mỗi môi trường thiết kế lại đòi hỏi các định nghĩa sử dụng khác biệt cho từng component.

Vì vậy, developer cần manage & read Token Data một cách dễ dàng, thuận tiện.

Manage & read Token Data via YAML

Ta có thể thấy lợi ích của việc dùng design token cách nó tiết kiệm rất nhiều mã trùng lặp và nhầm lẫn giữa nhiều nhóm vì nó đóng vai trò như một nguồn chân lý duy nhất thay vì có một số cơ sở mã có cùng yêu cầu thiết kế từ nhiều mục đích khác nhau. Bạn có thể tham khảo và khai thác sâu hơn kiến trúc của để tìm hiểu cách bắt đầu xây dựng token và cách nó làm việc.

Use

Nói cách khác, đây là bước mà Designer sẽ cấu hình, kiểm tra kết quả, còn với Developer chính là bước để theming sản phẩm, cho ra các phiên bản khi release. Điều này làm tôi nhớ đến Wordpress, một nền tảng xây dựng website và quản trị nội dung vô cùng mạnh mẽ. Ta có thể tuỳ chỉnh style, bố cục các UI block chứa content và chủ điểm (theme) một cách trực quan và “no-code”.

Customize trong WordPress

Một số ví dụ về theming trong các design system.

Giống như các công cụ WYSIWYG, lợi ích của việc có thể tuỳ biến giao diện trực tiếp trên các sanbox, giúp cho designer cũng như developer nhanh chóng phát hiện các điểm bất hợp lý về thị giác, từ đó không mất nhiều thời gian tinh chỉnh lại UI và deploy lại project. Thậm chí, việc tranh luận về tính thẩm mỹ trở nên dễ dàng hơn rất nhiều khi ta đã có sẵn chứng minh trực quan.

Sinh design token từ công cụ thiết kế Figma

Một “đẳng cấp" mới của design token được trình bày bởi Pavel Laptev, tận dụng sức mạnh của Figma API, cho phép sinh trực tiếp từ file thiết kế ra các file design token và quá trình này hoàn toàn tự động.

Điều đó có nghĩa là, file JSON (token data) không còn là cách duy nhất để quy định các “chân lý” trong design system, nó có thể liên kết trực tiếp đến ngay file thiết kế của Designer 😻.

Tổng kết

Mặc dù, quá trình để xây dựng design token không hề đơn giản, nhưng lợi ích của design token là vô cùng to lớn, nó sẽ xuyên suốt và trường tồn trong khi xây dựng và phát triển mở rộng design system. Thiếu hoặc làm xây dựng design token hời hợt, sẽ gây ra sự lãng phí về thời gian và tiền bạc trong quá trình tương tác với nhau cũng như thử nghiệm sản phẩm.