Đo mức áp dụng design system bằng chỉ số thật

Trong phần lớn tổ chức, câu trả lời cho "đội có dùng design system không?" là một trong hai thứ: số component đã build, hoặc ngày ra mắt hệ. Cả hai đều đo sai đối tượng. Chúng đo kho và lịch sử, không đo hành vi thật của đội khi làm việc.

Chỉ số gốc cần đo

Có ba lớp chỉ số đo mức áp dụng thật, xếp theo mức độ trực tiếp:

• Mức phụ thuộc trong mã nguồn: sản phẩm có khai báo design system như một thư viện trong tệp gói (package.json) không. Đây là điểm neo có thể giám sát và báo cáo được cho từng sản phẩm, theo từng phiên bản.
• Độ phủ component: bao nhiêu phần giao diện của sản phẩm được dựng từ component của hệ, thay vì viết lại từ đầu hoặc dùng thư viện khác.
• Độ mới của phiên bản: sản phẩm đang dùng bản nào so với bản mới nhất của hệ. Khoảng cách càng lớn thì lợi ích từ cải tiến mới càng khó đến tay người dùng cuối.

Ba chỉ số này cộng lại cho một bức tranh đủ để quyết định: hệ đang hoạt động hay đang ngủ yên trong repo.

Tín hiệu từ Figma

Phía thiết kế có một chỉ số gián tiếp đáng theo dõi: tỉ lệ tách rời (detach) component. Khi designer tách component ra khỏi thư viện để chỉnh tay, có hai lý do chính: component chưa đủ linh hoạt cho nhu cầu thật, hoặc luồng làm việc chưa được hướng dẫn rõ.

Tỉ lệ tách rời cao không có nghĩa đội lười dùng hệ. Nó thường có nghĩa hệ chưa đủ sát nhu cầu. Đây là chỉ số chẩn đoán để cải thiện component, không phải chỉ số tổng kết để báo cáo lên quản lý.

Phân cấp mục tiêu theo loại sản phẩm

Một lỗi phổ biến là đặt một ngưỡng áp dụng chung cho toàn tổ chức. Thực tế, sản phẩm chủ lực và sản phẩm phụ có vai trò khác nhau, nguồn lực khác nhau, và chi phí chuyển đổi khác nhau.

Phân cấp rõ từ đầu giúp tránh tình huống: sản phẩm chủ lực không đạt đủ nghiêm túc vì mục tiêu quá thấp, trong khi sản phẩm phụ bị ép không thực tế.

Giá trị của design system hiện ra khi sản phẩm ship tính năng dùng phần của hệ. Nên đặt mục tiêu áp dụng theo cấp: sản phẩm chủ lực đạt mức cao, sản phẩm phụ đạt mức vừa, thay vì đòi tất cả hoặc không có gì.

Nathan Curtis, EightShapes: Measuring Design System Success

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

• Coi ngày ra mắt hệ là thành công, trong khi chưa sản phẩm nào khai báo dependency thật.
• Đo số component có sẵn trong thư viện, không đo bao nhiêu component được dùng để ship tính năng thật.
• Đo số lượt tải (download) mà không biết ai tải và dùng vào đâu.
• Không rà soát định kỳ: đo một lần rồi thôi, trong khi mức áp dụng thay đổi theo từng quý tùy tình trạng đội và ưu tiên sản phẩm.

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

Trong giai đoạn triển khai, Sinh Vũ không bàn giao hệ rồi để đội tự xoay. Chúng tôi bàn giao kèm bộ chỉ số đo mức áp dụng theo từng đội, cùng biên bản rà soát hàng quý để con số không chỉ nằm trong dashboard mà dẫn đến quyết định thật.

Cách làm bám nguyên tắc chuyển một sản phẩm điểm mẫu sang hệ trước, đo kết quả, rồi mới nhân rộng. Làm vậy để mức áp dụng có bằng chứng thật, không phải con số cho đẹp báo cáo nội bộ. Anh / Chị biết hệ đang hoạt động hay đang ngủ khi nhìn vào package.json của sản phẩm quan trọng nhất, không phải khi nhìn vào số component trong Storybook.