Giữ hệ thống không loãng theo thời gian

Hệ thiết kế số (design system) không chết vì xây sai. Phần lớn trường hợp Sinh Vũ quan sát thấy, hệ thống chết vì sau khi bàn giao không còn ai coi đó là việc của mình. Sáu tháng sau, Figma và code bắt đầu lệch. Một năm sau, các đội sản phẩm tự làm component riêng. Hai năm sau, hệ thống chỉ còn tồn tại trên giấy tờ.

Nguyên nhân gốc: nhầm sản phẩm với dự án

Đây là nhầm lẫn phổ biến nhất. Một dự án có ngày kết thúc. Một sản phẩm thì không. Khi tổ chức coi hệ thiết kế số là dự án để hoàn thành rồi bàn giao, họ vô tình thiết lập điều kiện cho hệ thống tự suy tàn.

Nathan Curtis từ EightShapes, người viết nhiều nhất về chủ đề này, gọi cách tiếp cận đúng là product mindset (tư duy sản phẩm): hệ thống cần có lộ trình phát triển, có người dùng nội bộ là các đội thiết kế và kỹ thuật, và có vòng phản hồi (feedback loop) liên tục. Khi nào còn coi nó là dự án một lần thì hệ thống sẽ chết sau bàn giao.

Hai điều kiện tối thiểu để hệ thống sống lâu

Không cần bộ máy phức tạp. Nhưng cần đủ hai thứ này:

• Nhóm sở hữu (core team): Dù chỉ một người, phải có tên, có thời gian được phân bổ, và có quyền quyết định thay đổi nào được đưa vào hệ thống. Không có người này, mọi đóng góp đều trở thành tranh cãi hoặc bị bỏ lơ.
• Quy trình đóng góp (contribution process) có kiểm duyệt: Các đội sản phẩm cần có con đường rõ ràng để đề xuất thêm hoặc sửa component. Nếu không có lối vào chính thức, họ sẽ tự làm ngoài hệ thống, và hệ thống dần mất đi tính đại diện cho thực tế sản phẩm.

Điểm cân bằng giữa chặt và mở

Lỗi vận hành hay gặp

• Bàn giao xong coi như xong, không có người tiếp nhận nội bộ hoặc hợp đồng duy trì.
• Token thay đổi trong Figma nhưng không ai cập nhật code, dẫn đến hai thực tế song song tồn tại mà không ai hay.
• Thiếu nhật ký thay đổi (changelog), khiến các đội không biết có gì mới, tiếp tục dùng component cũ hoặc tự làm lại component đã có.
• Tài liệu (documentation) không được cập nhật cùng lúc với code vì không ai gắn việc này vào tiêu chí hoàn thành (definition of done).
• Component được thêm vào thư viện nhưng không ai rà soát sự nhất quán với các component đã có trước đó.

Về kỹ thuật: đồng bộ token giữa Figma và code

Token là lớp dễ lệch nhất và cũng dễ kiểm soát nhất nếu có công cụ đúng. Các công cụ như Style Dictionary (do Danny Banks phát triển tại Amazon) hoặc Token Studio (do Jan Six phát triển, theo chuẩn của Design Tokens Community Group) cho phép tự động hóa việc chuyển đổi token từ nguồn duy nhất sang nhiều định dạng code khác nhau.

Tuy nhiên, công cụ chỉ giải quyết được phần cơ học. Khi có thay đổi về ngữ nghĩa, ví dụ màu gọi là color-primary nay được gán nghĩa khác trong bối cảnh thiết kế mới, vẫn cần con người xác nhận trước khi đẩy thay đổi đó ra toàn bộ sản phẩm.

Hệ thiết kế số là sản phẩm phục vụ người dùng nội bộ. Nó cần lộ trình, cần người chủ, và cần vòng phản hồi liên tục như bất kỳ sản phẩm nào khác.

Nathan Curtis, EightShapes, DesignSystems.com

Góc nhìn của Sinh Vũ

Sinh Vũ bàn giao kèm ba tháng bảo trì ban đầu và một buổi làm việc chung với đội kỹ thuật của khách để thiết lập thói quen vận hành. Mục tiêu của buổi đó không phải truyền đạt kiến thức mà là giúp đội khách thực sự chạy quy trình một lần trước khi tự chạy một mình.

Từ tháng thứ tư trở đi, khách cần có người sở hữu nội bộ hoặc ký hợp đồng duy trì (retainer). Nếu Anh/Chị chưa sẵn sàng cho một trong hai, Sinh Vũ sẽ nói thẳng điều đó trước khi ký hợp đồng, vì đây là điều kiện để đầu tư vào hệ thiết kế có ý nghĩa lâu dài. Xây một hệ thống tốt mà không có người giữ nó thì chi phí bỏ ra chỉ mua được vài năm đầu.