Đo adoption rate design system bằng chỉ số nào

Chốt nhanh

Cần đo ở cả hai lớp: Figma (designer có dùng component từ thư viện không) và code (developer có import từ component library không). Chỉ đo một lớp là có lỗ hổng lớn, vì designer có thể dùng đúng trong thiết kế nhưng developer tự viết lại khi code. Ngoài đo số lượng adoption, cần đo thêm chất lượng qua detach rate và audit ngẫu nhiên để biết đội đang dùng đúng hay đang lách.

Adoption rate (tỉ lệ áp dụng) là câu hỏi mà hầu hết đội ngũ đặt ra sau khi design system được bàn giao, nhưng ít đội thực sự biết đo đúng. Phần lớn dừng lại ở khảo sát tự khai, hỏi designer và developer có dùng không rồi ghi nhận câu trả lời. Cách đó không đủ tin cậy vì không ai tự nhận mình không dùng hệ thống mà đội đã bỏ công xây.

Hai lớp cần đo song song

Adoption xảy ra ở hai nơi hoàn toàn độc lập: công cụ thiết kế và codebase sản phẩm. Thiếu một lớp là thiếu nửa bức tranh.

Lớp Figma: Figma có sẵn thống kê thư viện cho phép Anh / Chị xem component nào đang được dùng, dùng bao nhiêu lần, và đặc biệt là bị detach (tách rời khỏi thư viện) bao nhiêu lần. Số lần detach là chỉ số quan trọng hơn số lần dùng vì nó cho biết đội có đang tin tưởng component không hay đang phải lách.
Lớp code: Đo bằng script đếm số lần import từ component package trong codebase, hoặc dùng công cụ như Chromatic (phân tích giao diện tự động) hay Lode (đo dependency). Đội nhỏ có thể bắt đầu bằng script đơn giản mà không cần mua thêm công cụ.

Hai lớp này không liên thông tự động. Designer dùng component đúng trong Figma nhưng developer tự viết lại khi code là tình huống phổ biến, và nếu chỉ đo Figma thì Anh / Chị sẽ nghĩ mọi thứ ổn trong khi codebase đang phân mảnh.

Phân biệt Adoption và Coverage

Đây là điểm nhầm lẫn thường gặp nhất khi báo cáo lên quản lý hoặc khách hàng.

Adoption đo tỉ lệ thành viên trong đội đang dùng design system. Một đội 10 người mà 8 người dùng thì adoption là 80%.

Coverage đo tỉ lệ màn hình hoặc thành phần sản phẩm được build bằng component từ design system. Đội có thể dùng system nhiều nhưng chỉ cho một tính năng nhỏ, coverage vẫn thấp.

Cần cả hai con số. Adoption cao nhưng coverage thấp nghĩa là đội đang dùng đúng nhưng chưa áp đủ rộng. Ngược lại, coverage cao nhưng adoption thấp nghĩa là một vài người đang gánh toàn bộ, rủi ro cao khi người đó nghỉ.

Khi một chỉ số trở thành mục tiêu, nó ngừng là chỉ số tốt.
Charles Goodhart, nhà kinh tế học, Goodhart's Law

Hệ quả thực tế: nếu đội bị KPI theo adoption rate, họ có thể import component vào code mà không thực sự dùng đúng cách, chỉ để con số đẹp. Vì vậy cần đo kèm chỉ số chất lượng, không chỉ số lượng.

Bộ chỉ số tối giản đủ dùng

Sinh Vũ không khuyến khích xây dashboard phức tạp ngay từ đầu. Với đội nội bộ ở giai đoạn đầu triển khai, ba chỉ số sau là đủ để biết có vấn đề không:

Figma detach rate: Tỉ lệ component bị tách rời so với tổng số lần dùng. Detach tăng đột biến ở một component cụ thể là tín hiệu component đó cần được xem lại.
Số PR có dùng component library: Mỗi pull request (yêu cầu gộp code) vào nhánh chính có import từ package không. Đo theo sprint, theo dõi xu hướng qua các tháng.
Audit ngẫu nhiên hàng tháng: Chọn 10 PR ngẫu nhiên, xem tay xem có component nào bị dùng sai, bị override (ghi đè) ngoài quy định, hay bị viết lại hoàn toàn. Không cần tự động hóa bước này, làm tay vẫn đủ tín hiệu.

Lỗi thường gặp khi đo

Đo adoption một lần lúc launch rồi không đo lại. Adoption giảm dần theo thời gian mà không ai nhận ra là tình huống rất phổ biến, nhất là khi đội mở rộng và thành viên mới vào.
Không có baseline trước khi triển khai. Nếu không biết đội mất bao lâu để build màn hình mới trước khi có design system, Anh / Chị không thể chứng minh system đang tiết kiệm thời gian bao nhiêu.
Đo nhưng không hành động. Số liệu detach cao mà không ai được giao nhiệm vụ xem lại component đó thì việc đo chỉ tạo ra cảm giác kiểm soát, không tạo ra cải thiện thực sự.
Chỉ hỏi, không quan sát. Khảo sát tự khai là điểm xuất phát, không phải nguồn dữ liệu chính.

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

Trong giai đoạn ba tháng bảo trì sau bàn giao, Sinh Vũ sẽ hướng dẫn Anh / Chị thiết lập đúng ba chỉ số trên, không nhiều hơn. Mục tiêu là Anh / Chị tự đọc và tự hành động được sau khi giai đoạn bảo trì kết thúc, không phụ thuộc vào Sinh Vũ để biết design system đang được dùng tốt không. Đo đơn giản mà đo đều còn tốt hơn đo phức tạp mà đo một lần.

Nguồn tham khảo

Nathan Curtis, EightShapes, design system metrics framework. Goodhart's Law, Charles Goodhart. Chromatic, Storybook và các công cụ đo coverage phổ biến trong cộng đồng design system.

Câu hỏi thường gặp

Detach trong Figma nghĩa là gì và tại sao phải đo?

Detach (tách rời) xảy ra khi designer lấy một component từ thư viện rồi phá vỡ liên kết với bản gốc để chỉnh sửa tự do. Detach rate cao là dấu hiệu component không phù hợp thực tế, khiến đội phải lách thay vì dùng đúng. Đây là tín hiệu cần xem lại thiết kế component, không phải xem lại người dùng.

Có cần mua công cụ đặc biệt để đo adoption không?

Không bắt buộc. Figma có sẵn tính năng thống kê thư viện để xem component nào được dùng và bị detach bao nhiêu lần. Phía code, một script đơn giản đếm số lần import từ component package là đủ cho hầu hết đội nhỏ. Chromatic hay Lode hữu ích khi đội lớn và cần tự động hóa, nhưng không phải điều kiện bắt buộc để bắt đầu đo.

Adoption rate bao nhiêu là đủ tốt?

Corpus không có ngưỡng cụ thể và Sinh Vũ không cam kết con số vì ngưỡng phụ thuộc vào quy mô đội, tuổi của design system và mức độ phức tạp sản phẩm. Quan trọng hơn là có baseline từ tháng đầu và theo dõi xu hướng: adoption tăng dần hay giảm dần mới là tín hiệu cần hành động.