Design system của bạn cần một người “thực thi”

Design system là những công cụ mạnh mẽ. Chúng đảm bảo tính nhất quán trong thiết kế hình ảnh và tương tác, giúp các team tập trung giải quyết vấn đề thực của người dùng thay vì chỉnh từng pixel. Khi được xây dựng tốt, chúng còn tích hợp sẵn kiến thức về accessibility và design vào hệ thống, để không phải designer hay engineer nào cũng cần là chuyên gia.

Design system có mức độ phức tạp khác nhau. Một số chỉ bao gồm những yếu tố cơ bản như typography, màu sắc và quy chuẩn thương hiệu. Một số khác cung cấp các component code cho những tính năng như search và navigation. Những hệ thống tiên tiến nhất còn định nghĩa cả interaction pattern, bao gồm gesture, timing của animation và các loại feedback.

Nhưng có một điểm chung ở tất cả design system: chúng đều cần một người “thực thi”.

Trong bài viết này

• Người thực thi design system làm gì

• Vì sao việc thực thi lại quan trọng

• Làm thế nào để thực thi hiệu quả

• Mục tiêu thực sự

Người thực thi design system làm gì

Vai trò “thực thi” nghe có vẻ mang tính áp đặt, nhưng thực chất là về việc quản lý và gìn giữ hệ thống.

Một người thực thi:

• Đảm bảo các team sử dụng design system. Khi di chuyển nhanh hoặc không hiểu rõ hệ thống, các team rất dễ tự xây giải pháp riêng.

• Đảm bảo những thay đổi cần thiết được đưa ngược lại vào hệ thống. Đôi khi các team cần pattern hoặc component mới. Người thực thi đảm bảo những đổi mới này mang lại lợi ích cho toàn bộ tổ chức, không chỉ một team.

• Giúp các team tìm điểm cân bằng khi nhu cầu xung đột. Mỗi team sẽ muốn những thứ khác nhau. Người thực thi điều phối các cuộc thảo luận này và đưa ra quyết định cuối cùng khi không đạt được đồng thuận.

Vì sao việc thực thi design system lại quan trọng

Bạn có thể nghĩ: “Chúng ta đã tuyển người giỏi, họ sẽ làm đúng.” Và đúng là họ sẽ cố gắng. Nhưng ý định tốt là chưa đủ.

Không phải ai cũng là chuyên gia design system.
Những người xây dựng và duy trì design system hiểu cách nó vận hành trên toàn tổ chức. Trong khi đó, mỗi team chỉ hiểu một phần sản phẩm của họ. Bạn cần một người có góc nhìn tổng thể để đưa ra các quyết định ảnh hưởng toàn cục.

Những sai lệch nhỏ sẽ tích lũy rất nhanh.
Tôi từng làm ở một công ty ecommerce có một component product carousel tiêu chuẩn. Nó hoạt động hoàn hảo cho đến khi từng product manager bắt đầu yêu cầu những thay đổi “nhỏ” cho khu vực của họ. Người thì muốn tên sản phẩm lớn hơn. Người khác cần hiển thị giá khác đi. Người thứ ba muốn khách hàng mua trực tiếp ngay trên carousel.

Theo thời gian, chúng tôi có hàng chục biến thể carousel. Engineer không thể bảo trì vì mỗi cái có logic riêng. Tệ hơn, người dùng bị rối. Trên cùng một trang, các carousel hoạt động hoàn toàn khác nhau. Một tương tác đáng lẽ phải nhất quán và dễ học lại trở thành gánh nặng nhận thức và một mớ hỗn độn thị giác. Carousel đã biến thành nhiều carousel khác nhau, và không cái nào tốt bằng bản gốc.

Các team tối ưu cục bộ, không phải toàn cục.
Một product manager phụ trách checkout sẽ có động lực khác với người phụ trách browse hay account settings. Mỗi người sẽ thúc đẩy những thay đổi giúp cải thiện chỉ số của riêng họ. Nếu không có ai nhìn tổng thể sản phẩm, bạn sẽ có một “quái vật Frankenstein” gồm các pattern cạnh tranh nhau, đặc biệt ở những component như search — vốn cần hoạt động giống nhau ở mọi nơi.

Designer cần được hỗ trợ.
Khi product manager khăng khăng yêu cầu một thay đổi có thể phá vỡ tính nhất quán vì họ tin nó cải thiện hiệu suất feature của họ, designer cần có điểm tựa. “Design system không cho phép” dễ nói hơn nhiều so với “Tôi nghĩ đây là ý tưởng tệ.” Nó chuyển cuộc tranh luận từ ý kiến cá nhân sang nguyên tắc đã được thiết lập.

Làm thế nào để thực thi design system hiệu quả

Có người thực thi không có nghĩa là cứng nhắc hay xây dựng một “tháp ngà”. Nó có nghĩa là phát triển hệ thống một cách có suy nghĩ và nhất quán.

Có sự ủng hộ từ lãnh đạo.
Team design system cần quyền từ chối những thay đổi phá vỡ tính nhất quán. Nếu không có sự hậu thuẫn từ trên xuống, việc thực thi chỉ là gợi ý mà các team sẽ bỏ qua khi bất tiện. Hãy đảm bảo lãnh đạo hiểu rằng tính nhất quán là một tính năng, không phải rào cản.

Có sự hỗ trợ từ engineering.
Engineer có thể là đồng minh tốt nhất. Design system tốt không chỉ cải thiện sản phẩm mà còn giúp cuộc sống của engineer dễ hơn, khi họ không phải bảo trì hàng chục phiên bản của cùng một component. Giống như designer, họ có thể tập trung vào những bài toán kỹ thuật khó thay vì chỉnh sửa nhỏ về giao diện.

Tổ chức các buổi review định kỳ.
Bạn không thể thực thi những gì bạn không biết. Hãy lên lịch review định kỳ với các product team để xem họ đang xây gì và vì sao họ cần thay đổi cụ thể. Những buổi này không nên mang cảm giác audit, mà là collaboration, nơi người thực thi có thể đề xuất giải pháp sẵn có hoặc phát hiện những khoảng trống thực sự trong hệ thống.

Chọn thời điểm review hợp lý.
Review quá sớm thì chưa có gì để đánh giá. Review quá muộn thì đã ship rồi. Hãy tìm điểm cân bằng khi thiết kế đủ rõ để đánh giá nhưng chưa quá muộn để thay đổi trở nên đắt đỏ. Thường là sau giai đoạn khám phá ban đầu nhưng trước khi implement cuối cùng.

Tạo quy trình đóng góp rõ ràng.
Các team cần một cách đơn giản, ít ma sát để đề xuất thay đổi hoặc component mới. Nếu quy trình không rõ ràng hoặc quá rườm rà, họ sẽ tìm cách lách. Một form submit đơn giản hoặc office hours định kỳ là đủ. Hãy document rõ bạn cần thông tin gì và timeline ra quyết định như thế nào.

Phản hồi nhanh và hợp lý.
Đây là phần khó nhất. Nếu bạn từ chối mọi thứ, các team sẽ né bạn. Nếu bạn chấp nhận mọi ngoại lệ, hệ thống trở nên vô nghĩa. Bạn cần sự phán đoán.

Tôi từng thấy người thực thi thành công với một nguyên tắc:

• Nếu thay đổi này giúp 3 team trở lên, nó nên thuộc về hệ thống.

• Nếu nó chỉ phục vụ một use case riêng, đó có thể là ngoại lệ.

• Nếu chưa chắc, hãy prototype với một team trước, rồi quyết định có nên chuẩn hóa hay không.

Mục tiêu thực sự

Điều khiến nhiều người hiểu sai là họ nghĩ việc thực thi là nói “không”. Thực ra, đó là nói “có” — nhưng đúng thứ, đúng thời điểm.

Tôi từng làm việc với một team design system đang gặp vấn đề. Các team bỏ qua component của họ và tự xây giải pháp riêng. Khi tìm hiểu, tôi phát hiện người thực thi quá cứng nhắc. Họ xây một hệ thống họ rất yêu thích và bảo vệ nó khỏi mọi thay đổi.

Họ không sai khi cho rằng thay đổi sẽ làm giảm “độ tinh khiết” của hệ thống. Nhưng họ sai về ưu tiên. Một hệ thống hoàn hảo mà không ai dùng thì vô giá trị. Một hệ thống hơi “lộn xộn” nhưng giải quyết vấn đề thực thì lại có giá trị.

Sau khi chúng tôi điều chỉnh cách tiếp cận (review nhanh hơn, tiêu chí rõ ràng hơn cho yes/no, và sẵn sàng phát triển hệ thống theo nhu cầu), mức độ adoption tăng vọt. Các team bắt đầu sử dụng component vì họ tin hệ thống sẽ phát triển cùng họ.

Một team khác tôi từng làm việc thì hoàn toàn ngược lại. Họ thiết kế một hệ thống quá lỏng lẻo và mở, cho phép các team làm gần như bất cứ điều gì miễn là dùng đúng màu và font công ty. Kết quả là hỗn loạn. Các team liên tục redesign những component đơn giản thay vì tái sử dụng, và kết quả gần như tệ như việc không có system.

Kết luận

Design system là một khoản đầu tư lớn. Nó cần bảo trì liên tục, tài liệu hóa và truyền thông nội bộ. Nhưng nếu không có sự thực thi, khoản đầu tư đó sẽ bị bào mòn bởi hàng nghìn thỏa hiệp nhỏ, cho đến khi bạn quay lại điểm xuất phát — nơi mỗi team làm một kiểu.

Vai trò người thực thi không phải là kiểm soát. Nó là hiểu khi nào cần giữ vững tính nhất quán và khi nào cần tiến hóa. Nó là giúp các team phối hợp dù có nhu cầu khác nhau. Và quan trọng nhất, là đảm bảo hệ thống phục vụ người dùng trước, không phải sự tiện lợi nội bộ.

Design system của bạn cần một người thực thi. Hãy trao cho họ quyền hạn, công cụ và sự hỗ trợ cần thiết — bạn sẽ nhận được đúng những lợi ích mà design system hứa hẹn.