Chỉ số sức khỏe design system cần rà soát hàng quý

Chốt nhanh

Bộ chỉ số tối thiểu cho một hệ thiết kế số gồm ba chiều: mức độ áp dụng thực tế, chất lượng kỹ thuật, và trải nghiệm của đội dùng hệ thống. Mỗi quý, Anh Chị cần ít nhất một chỉ số từ mỗi chiều để phát hiện vấn đề trước khi nó thành nợ lớn. Không cần đo đủ hết ngay từ đầu, nhưng không thể bỏ trống cả ba.

Nhiều đội xây xong design system (hệ thiết kế số) rồi coi như xong. Hệ thống vẫn chạy, component vẫn được dùng, không ai phàn nàn. Nhưng "không ai phàn nàn" không phải bằng chứng hệ thống đang khỏe. Đó chỉ là chứng minh chưa có ai để ý đủ kỹ. Rà soát hàng quý bằng chỉ số cụ thể là cách duy nhất để biết hệ thống đang tiến hay đang ngầm xuống cấp.

Ba chiều chỉ số cần đo

Không có một con số duy nhất phản ánh sức khỏe của hệ thiết kế số. Cần kết hợp ba chiều:

Chiều 1: Mức độ áp dụng (adoption rate, tỷ lệ áp dụng thực tế). Bao nhiêu phần trăm màn hình hoặc trang trong sản phẩm đang dùng component từ hệ thống? Bao nhiêu đội đang dùng? Đây là chỉ số phản ánh sức khỏe tổng thể, nhưng cũng là chỉ số khó đo nhất. Cách thực tế nhất để ước lượng là đếm số màn hình không có component nào từ hệ thống: đây là proxy (thước đo gián tiếp) cho mức độ shadow component (component tự làm ngoài hệ thống, không qua luồng kiểm soát chính).
Chiều 2: Chất lượng kỹ thuật (quality). Tỷ lệ component vượt qua accessibility audit (kiểm tra khả năng tiếp cận) là bao nhiêu? Có bao nhiêu bug đang mở, phân theo mức độ nghiêm trọng? Coverage test (tỷ lệ kiểm thử bao phủ) đang ở đâu? Chiều này cho biết hệ thống có đang giữ được tiêu chuẩn kỹ thuật không, hay đang tích nợ.
Chiều 3: Trải nghiệm của đội dùng hệ thống (developer experience, trải nghiệm lập trình viên). Đội mất bao lâu để tìm được component cần thiết? Họ có thấy hệ thống giúp họ làm việc nhanh hơn không? Nielsen Norman Group nhấn mạnh đây là yếu tố sống còn: nếu người dùng nội bộ không thấy hệ thống hữu ích, họ sẽ vòng qua nó và tự xây, tức là shadow component sẽ tăng.

Không phải mọi tổ chức cần đo đủ cả ba chiều ngay từ đầu. Nhưng bỏ trống hoàn toàn một chiều là rủi ro: bỏ adoption thì không biết hệ thống có được dùng thực sự không, bỏ quality thì nợ kỹ thuật tích lại ngầm, bỏ developer experience thì không phát hiện được hệ thống đang gây khó chịu cho đội trước khi họ bỏ sang shadow component.

Lịch rà soát thực tế

Không phải chỉ số nào cũng cần đo cùng tần suất. Dưới đây là lịch Sinh Vũ khuyến nghị:

Hàng quý: Adoption rate (ước lượng hoặc đo), số bug mở theo mức nghiêm trọng, kết quả accessibility audit mới nhất. Đây là bộ chỉ số tối thiểu cần có trước mỗi cuộc họp rà soát quý.
Hàng tháng hoặc sau mỗi sprint (chu kỳ phát triển ngắn, thường hai tuần): Số component được thêm mới hoặc cập nhật, số đóng góp từ đội ngoài nhóm core (nhóm cốt lõi phụ trách hệ thống). Đây là chỉ số hoạt động, cho biết hệ thống có đang được duy trì liên tục không.
Hàng năm hoặc theo sự kiện lớn: Khảo sát trải nghiệm đội dùng hệ thống, có thể dùng Net Promoter Score nội bộ (điểm sẵn lòng giới thiệu, đo từ 0 đến 10) hoặc câu hỏi mở ngắn. So sánh lại với mục tiêu ban đầu khi xây hệ thống.

Tín hiệu cảnh báo cần xử lý ngay

Một số thay đổi trong chỉ số không cần chờ đến kỳ rà soát quý:

Adoption rate giảm liên tục hai quý liên tiếp.
Số shadow component tăng rõ rệt mà không có lý do được ghi nhận.
Không có cập nhật nào vào hệ thống trong nhiều tháng, kể cả bản vá lỗi nhỏ.
Bug mức nghiêm trọng cao (critical hoặc high severity) tồn tại quá một tháng không được xử lý.

Nếu người dùng nội bộ không thấy hệ thống giúp họ làm việc nhanh hơn, họ sẽ bỏ qua nó.
Nielsen Norman Group, bài viết về design system adoption và developer experience

Lỗi phổ biến khi đo chỉ số

Không đo gì cả vì cho rằng hệ thống đang được dùng tức là đang khỏe. Đây là lỗi nguy hiểm nhất vì để vấn đề tích lại đến khi quá tốn kém để sửa.
Chỉ đo số lượng component. Số lượng component nhiều không đồng nghĩa với hệ thống khỏe. Một hệ thống có 200 component nhưng adoption rate thấp thì vẫn thất bại.
Lẫn lộn activity metrics với outcome metrics. Bao nhiêu lần commit trong tháng là activity metric (chỉ số hoạt động). Hệ thống có đang giúp đội ra tính năng nhanh hơn không là outcome metric (chỉ số kết quả). Cần cả hai, nhưng outcome mới là thứ quan trọng.
Đo nhiều chỉ số nhưng không có người hành động. Chỉ số chỉ có giá trị khi có người đọc, phân tích và đưa ra quyết định dựa trên nó. Đo mà không hành động thì chỉ tốn công.
Không đặt ngưỡng cảnh báo. "Adoption rate đang là 60%" không có ý nghĩa nếu không có ngưỡng để so sánh. Cần xác định trước: dưới bao nhiêu thì cần hành động?

Cách Sinh Vũ tiếp cận thực tế

Trong giai đoạn bảo trì ba tháng đầu, Sinh Vũ giúp khách thiết lập dashboard (bảng theo dõi) đơn giản bằng công cụ có sẵn: GitHub insights, Figma analytics, hoặc bảng tính nếu cần. Không nhất thiết phải xây hạ tầng đo lường phức tạp từ đầu.

Mục tiêu cụ thể Sinh Vũ hướng đến: Anh Chị có ít nhất ba chỉ số có thể tự cập nhật mỗi quý mà không cần Sinh Vũ hỗ trợ. Một chỉ số từ chiều adoption, một từ chiều quality, một từ chiều developer experience. Đủ để biết hệ thống đang khỏe hay đang cần can thiệp, không cần nhiều hơn ở giai đoạn này.

Nguồn tham khảo

Nielsen Norman Group, nhiều bài viết về design system adoption và developer experience (tác giả tiêu biểu: Anna Kaley, Therese Fessenden). Shopify Polaris, IBM Carbon, GitHub Primer, tài liệu công khai về metrics. Kinh nghiệm thực hành Sinh Vũ trong giai đoạn bảo trì hệ thống cho khách.

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

Nếu đội nhỏ, không có người chuyên trách design system, thì đo chỉ số như thế nào?

Ưu tiên ba chỉ số có thể cập nhật bằng tay mỗi quý mà không cần công cụ phức tạp: đếm số màn hình không dùng component từ hệ thống (proxy cho adoption), đếm số bug mở theo mức nghiêm trọng, và hỏi nhanh hai đến ba người trong đội về trải nghiệm dùng hệ thống. Bảng tính đủ dùng ở giai đoạn đầu. Quan trọng là có người được phân công cập nhật và đọc kết quả, dù chỉ mất một tiếng mỗi quý.

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

Corpus không cung cấp ngưỡng chuẩn, và Sinh Vũ không đặt con số vì ngưỡng phụ thuộc vào độ trưởng thành của hệ thống và đặc thù sản phẩm. Điều quan trọng hơn là xu hướng: adoption rate đang tăng, giữ nguyên, hay giảm qua các quý. Giảm liên tục hai quý là tín hiệu cần điều tra ngay, bất kể con số tuyệt đối là bao nhiêu.

Shadow component có nguy hiểm không, hay chỉ là chỉ dấu thôi?

Shadow component, tức component đội tự làm ngoài hệ thống, vừa là chỉ dấu vừa là nguyên nhân. Khi shadow component nhiều lên, giao diện sản phẩm dần mất nhất quán và chi phí bảo trì tăng. Nhưng sự tồn tại của shadow component thường báo hiệu một vấn đề thực ở hệ thống chính: thiếu component cần thiết, tài liệu không đủ, hoặc hệ thống quá khó dùng. Cần điều tra nguyên nhân thay vì chỉ xóa shadow component.