Khi hệ thống thiết kế (Design System) của bạn sống trong Figma và trang web của bạn được xuất bản trực tiếp từ Figma, nghe có vẻ như sự kết nối giữa chúng nên diễn ra hoàn toàn tự động. Nhưng trên thực tế, tôi nghĩ có một khoảng cách lớn mà chúng ta cần phải chú ý nhiều hơn. Tôi bắt đầu suy nghĩ về điều này từ một bài toán thiết kế rất đỗi bình thường.
Một trang của khách hàng cần phải hoàn thiện gấp. Thời hạn (deadline) đã đến rất gần. Designer đã có sẵn một component trông gần đúng yêu cầu. Thay vì mất thời gian tìm component gốc trong thư viện, họ chọn cách detach (ngắt kết nối) nó ra, chỉnh sửa vài chỗ, điền cứng một mã màu (hardcode), điều chỉnh lại khoảng cách rồi chuyển sang việc khác. Trang web trông vẫn hoàn toàn chính xác. Không ai phàn nàn cả. Deadline được hoàn thành.
Nhưng vài tuần sau, khi có sự thay đổi trong Design System, đột nhiên trang web đó không còn là một phần của hệ thống nữa. Nó chỉ trông có vẻ như thuộc về hệ thống mà thôi. Sự khác biệt đó trở nên thú vị hơn khi tôi bắt đầu suy nghĩ về Figma Sites. Nếu chúng ta thiết kế một trang web trong Figma và xuất bản nó ngay từ Figma, tôi bắt đầu tự hỏi: Chính xác thì những gì đang được truyền từ Design System vào trang web đã xuất bản? Điều gì sẽ xảy ra khi một thứ trông giống như component của Design System lại không hề thực sự kết nối với hệ thống?
Trang web có thể nhìn đúng nhưng cấu trúc vẫn sai
Đây có lẽ là cách đơn giản nhất để giải thích vấn đề này. Hãy tưởng tượng một nút bấm chính (primary button) từ Design System. Component gốc sử dụng một màu thương hiệu được kết nối với Variable (biến):
Button / Primary
Fill → Color.Primary
Bây giờ, hãy tưởng tượng ai đó sao chép nút đó sang một trang khác và detach nó. Về mặt thị giác, không có gì thay đổi. Nó vẫn trông giống hệt nút bấm chính ban đầu. Nhưng về mặt cấu trúc, mối quan hệ đã thay đổi hoàn toàn. Nút bấm gốc nói rằng: “Màu sắc của tôi đến từ hệ thống.” Nút bấm đã detach lại nói rằng: “Màu sắc của tôi là bất kỳ giá trị nào mà ai đó đã để lại đây.” Sự khác biệt đó không thể nhìn thấy bằng mắt thường khi bạn quan sát trang web. And đó chính là điều làm cho nó trở nên nguy hiểm.
Tôi muốn nhìn thấy sự khác biệt thay vì chỉ nói suông
Vì vậy, tôi đã làm một thí nghiệm nhỏ. Tôi tạo ra hai phiên bản của cùng một section trên trang landing page. Chúng nhìn gần như giống hệt nhau.
– Phiên bản A: Sử dụng các component đã bị detach và điền cứng (hardcode) các giá trị màu sắc.
– Phiên bản B: Sử dụng các component từ thư viện và tham chiếu đến các Variable cho các quyết định thiết kế liên quan.
Thoạt nhìn, hầu như không có gì để so sánh. Cả hai đều trông như thuộc về cùng một Design System. Đó chính xác là những gì tôi muốn. Bởi vì nếu hai phiên bản nhìn khác hẳn nhau, thí nghiệm sẽ không còn nhiều ý nghĩa. Câu hỏi thực sự là điều gì sẽ xảy ra sau khi hệ thống thay đổi.
Sau đó, tôi thay đổi một mã màu
Tôi thay đổi màu thương hiệu chính trong bộ Variable. Chỉ vậy thôi. Tôi không thiết kế lại section. Tôi không thay đổi thủ công các component. Tôi chỉ thay đổi giá trị nguồn.
– Phiên bản kết nối (B): Tự động cập nhật theo sự thay đổi.
– Phiên bản hardcode (A): Giữ nguyên giá trị cũ.
Thí nghiệm nhỏ đó giúp sự khác biệt trở nên dễ hiểu hơn rất nhiều. Trước khi thay đổi: Phiên bản A ≈ Phiên bản B Sau khi thay đổi: Phiên bản A ≠ Phiên bản B. And đó là phần làm tôi hứng thú nhất về quản trị hệ thống thiết kế (Design System Governance). Vấn đề không hề lộ ra khi mọi thứ ổn định. Vấn đề chỉ xuất hiện khi hệ thống tiến hóa. Một Design System không thực sự được kiểm chứng khi không có gì thay đổi. Nó chỉ được kiểm chứng khi có sự thay đổi diễn ra.
Đây là lúc Figma Sites làm cho câu hỏi trở nên thú vị hơn
Figma Sites thay đổi mối quan hệ giữa việc thiết kế và việc xuất bản. Thay vì thiết kế một trang rồi bàn giao cho đội ngũ khác chuyển thành code, bản thân thiết kế giờ đây có thể tiến gần hơn rất nhiều đến trang web thực tế. Điều đó nghe có vẻ cực kỳ hữu ích. And thực sự là vậy. Nhưng nó cũng có nghĩa là chất lượng của mối liên kết giữa trang web và Design System trở nên quan trọng hơn bao giờ hết. Nếu trang web được xây dựng từ các component và Variable được kết nối chuẩn chỉnh, một thay đổi trong hệ thống có thể lan tỏa xuyên suốt toàn bộ sản phẩm. Nếu trang web chứa các component bị detach và giá trị hardcode, mối quan hệ đó có thể đã bị phá vỡ ngay trước khi bạn nhấn nút Publish. Figma Sites không thể tự động khôi phục lại một ý định thiết kế đã bị xóa bỏ trước đó trong quá trình làm việc. Đó là điểm khác biệt mà tôi quan tâm: Xuất bản từ Figma không có nghĩa là tự động xuất bản từ Design System của bạn.
Một trang Figma có thể mang vẻ ngoài chuẩn mực nhưng lại thiếu đi kiến trúc cốt lõi
Đây là điều mà trước đây tôi chưa từng suy nghĩ một cách rõ ràng. Khi review một trang, chúng ta thường chỉ nhìn vào bề nổi:
– Nút bấm nhìn đã đúng chưa?
– Màu sắc đã chuẩn chưa?
– Typography có chính xác không?
– Khoảng cách có nhất quán không?
– Nó có khớp với thương hiệu không?
– Tất cả những câu hỏi đó đều hữu ích, nhưng chúng hầu như chỉ là câu hỏi về trạng thái hiện tại.
Một câu hỏi mang tính Design System sẽ hơi khác một chút: Trang này có thực sự kết nối với nguồn thông tin chuẩn (source of truth) hay không? Điều đó đòi hỏi phải nhìn vào bên dưới kết quả thị giác:
– Đây có phải là component trong thư viện không?
– Nó có bị detach không?
– Màu sắc có đến từ Variable không?
– Giá trị này có đang bị hardcode không?
– Typography có đang dùng Style của hệ thống không?
– Các component có còn nhận được các bản cập nhật không?
Những câu hỏi này không bắt mắt về mặt thị giác, nhưng chúng quyết định liệu trang web có thể “sống sót” qua lần thay đổi tiếp theo của hệ thống hay không.
Thực tế công việc tại các agency khiến điều này khó khăn hơn
Đây là lúc kinh nghiệm làm việc xung quanh các dự án agency/client của tôi được thể hiện. Tốc độ làm thay đổi cách mọi người sử dụng Design System. Khi bạn đang dựng một trang mới cho khách hàng, con đường nhanh nhất không phải lúc nào cũng là con đường chuẩn xác nhất về mặt hệ thống. Bạn có thể đã có sẵn thứ gì đó trên canvas đạt 90% nhu cầu. Vì vậy bạn nhân bản (duplicate) nó, detach nó, đổi màu, chỉnh padding, đổi tên và tiếp tục thiết kế. Dưới góc độ deadline, quyết định đó có vẻ hoàn toàn hợp lý. Tôi đã chứng kiến những quyết định như vậy tích tụ dần qua từng trang dễ dàng như thế nào. Một trang thì không sao. Nhưng hãy tưởng tượng điều đó diễn ra trên 10 trang, rồi 20 trang, rồi bàn giao file đó cho một designer khác. Thư viện component gốc vẫn tồn tại, các trang vẫn nhìn thống nhất, nhưng sợi dây kết nối giữa chúng ngày càng trở nên mong manh.
Vấn đề chỉ trở nên đắt giá về sau
Đây là phần mà tôi nghĩ các đội ngũ thiết kế đôi khi đánh giá thấp. Các component bị detach thường không gây ra sự cố ngay lập tức. Chúng tạo ra khối lượng công việc trong tương lai. Giả sử màu thương hiệu thay đổi:
– Các component được kết nối chuẩn có thể tự động cập nhật theo hệ thống.
– Các component hardcode cần phải được tìm và sửa thủ công từng cái một.
Bây giờ hãy tưởng tượng điều tương tự xảy ra với: Typography, Khoảng cách (spacing), Bo góc (border radius), Kiểu nút, Kiểu card, Màu sắc, Behavioral responsive… Design System có thể được bảo trì hoàn hảo, trong khi các trang web lại từ từ trôi xa khỏi nó. Đó là lý do tại sao tôi nghĩ “trông nó giống Design System” không còn là một bài kiểm tra đủ tiêu chuẩn nữa.
Vậy Figma Sites nằm ở đâu trong bức tranh này?
Đối với tôi, Figma Sites không phải là nguyên nhân gây ra vấn đề ở đây. Đó là một sự phân biệt quan trọng. Figma Sites có thể làm cho mối quan hệ giữa thiết kế và sản phẩm thực tế trở nên khăng khít hơn rất nhiều. Nhưng nó không loại bỏ các quyết định thiết kế diễn ra trước khi xuất bản. Nếu một trang bị ngắt kết nối về mặt cấu trúc khỏi Design System, việc xuất bản nó từ Figma không giải quyết được điều đó. Trên thực tế, nó thậm chí còn làm cho hậu quả trở nên nghiêm trọng hơn: Trang web sẽ đi từ “bản thiết kế bị ngắt kết nối” trở thành “trang web thực tế bị ngắt kết nối”. Bước xuất bản không tạo ra vấn đề quản trị. Nó chỉ đơn giản là cung cấp cho trang web bị ngắt kết nối đó một nơi để hiển thị.
Tôi bắt đầu nghĩ về một quy trình kiểm tra trước khi xuất bản (Pre-publish Check)
Điều này dẫn tôi đến một ý tưởng đơn giản. Trước khi xuất bản một trang Figma Sites, tại sao không đưa việc kiểm tra kết nối Design System vào danh sách kiểm tra (checklist) trước khi xuất bản? Không cần một cuộc kiểm tra quá đồ sộ, chỉ cần 5 câu hỏi:
– Các component có còn kết nối với thư viện không? Nếu một component đã bị detach, lý do là gì? Việc detach đó có phải là cố ý hay không?
– Các giá trị hệ thống có đang đến từ Variable không? Đặc biệt là màu sắc và các giá trị dự kiến sẽ thay đổi trên toàn hệ thống.
– Có ai điền cứng (hardcode) giá trị lẽ ra phải lấy từ hệ thống không? Một trang có thể nhìn đúng hôm nay nhưng vẫn sai về mặt cấu trúc.
– Điều gì xảy ra nếu giá trị thương hiệu chính thay đổi vào ngày mai? Nếu câu trả lời là “chúng tôi sẽ phải tìm và sửa thủ công”, đó là điều cần biết trước khi bấm xuất bản.
– Trang này có thực sự đang sử dụng hệ thống hiện tại không? Không phải: “Nó có trông giống hệ thống hiện tại không?”, mà là: “Nó có được kết nối với hệ thống hiện tại không?”
Tôi không nghĩ mọi sự detach đều là xấu
Đó là một điều khác tôi phải cẩn trọng khi suy nghĩ qua thí nghiệm này. Component bị detach không tự động bị coi là lỗi. Có những lý do chính đáng để tách khỏi một component trong thư viện:
– Khách hàng cần một tương tác đặc thù duy nhất.
– Component đó cần phải tiến hóa.
– Thư viện chưa hỗ trợ một use-case cụ thể nào đó.
– Bạn đang cố tình thử nghiệm điều gì đó mới trước khi đề xuất nó quay lại hệ thống.
Vấn đề không phải là: “Không bao giờ được detach component.” Vấn đề là: “Đừng để sự detach vô tình trở nên vô hình.” Một ngoại lệ có chủ đích là quản trị (governance).
Thí nghiệm đã thay đổi cách tôi nhìn nhận sự tuân thủ Design System
Trước đây, tôi có thể nhìn vào một trang và nghĩ: “Trang này đang dùng Design System của chúng ta.” Giờ đây, tôi muốn đặt câu hỏi thứ hai: “Thứ gì thực sự đang kết nối với Design System của chúng ta?” Đó không phải là cùng một câu hỏi.
– Một trang có thể dùng đúng màu mà không dùng Variable.
– Nó có thể có đúng nút bấm mà không dùng component từ thư viện.
– Nó có thể có đúng typography mà không kết nối với Style tương ứng.
– Nó có thể trông hoàn hảo trong một buổi review nhưng vẫn thất bại ở lần cập nhật hệ thống tiếp theo. Đó là một định nghĩa khác về tính nhất quán.
Tôi sẽ theo dõi điều gì nếu một đội ngũ bắt đầu dùng Figma Sites?
Tôi sẽ không bắt đầu với một khung quản trị phức tạp. Tôi sẽ bắt đầu với tính minh bạch (visibility). Designer nên dễ dàng nhận biết khi nào họ đang làm việc với:
– Kết nối (Connected) vs Ngắt kết nối (Detached)
– Dựa trên Variable vs Hardcoded
Những sự phân biệt đó cần phải dễ hiểu trong công việc hằng ngày. Sau đó, tôi sẽ đưa vào một quy trình review nhẹ nhàng trước khi xuất bản — không phải để làm chậm tiến độ của designer, mà là để bắt gọn những vấn đề vốn dĩ rất rẻ để sửa trước khi xuất bản, nhưng lại cực kỳ đắt đỏ để sửa sau đó. Bởi vì mục tiêu của quản trị Design System không phải là tạo ra thêm nhiều cấp phê duyệt, mà là để ngăn chặn sự trôi dạt vô hình.
Đây có thực sự là vấn đề của Figma?
Càng suy nghĩ về nó, tôi càng thấy không phải. Figma chỉ đơn giản là làm cho một điều vốn đã và đang diễn ra trở nên dễ thấy hơn. Các designer vẫn luôn tạo ra các giải pháp tình huống, vẫn luôn detach component và hardcode giá trị khi deadline cận kề. Điều đó có nghĩa là hậu quả của những quyết định đó tiến gần hơn đến người dùng cuối. Design System không còn có thể được coi là thứ chỉ giúp designer tạo ra các bản mockup nhất quán nữa. Nó ngày càng cần phải “sống sót” cho đến tận trải nghiệm được xuất bản cuối cùng.
