Đo mức dùng thật bằng con số thật
Ngày ra mắt hệ không phải thành công. Thành công là khi sản phẩm ship tính năng bằng component của hệ đó.
Chỉ số cốt lõi là mức phụ thuộc (dependency) của từng sản phẩm vào design system trong mã nguồn, cộng với độ phủ component và độ mới của phiên bản đang dùng. Đừng đo số component có sẵn hay số lượt tải, vì đó là đo kho, không phải đo mức dùng. Đặt mục tiêu 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ì một ngưỡng chung cho tất cả.
- hệ đã ra mã và nhiều sản phẩm cùng dùng
- muốn biết component có sát nhu cầu thật (đo tỉ lệ tách rời trong Figma)
- tổ chức có cả sản phẩm chủ lực lẫn sản phẩm phụ
- coi ngày ra mắt hệ là thành công, chưa sản phẩm nào dùng thật
- đo số lượt tải thay vì đo mức dùng để ship tính năng
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.
Sản phẩm phụ: kỳ vọng mức vừa, ưu tiên các component dùng nhiều nhất thay vì phủ toàn bộ. Ép quá tay ở nhóm này thường làm mất thời gian mà không mang lại giá trị tương xứng.
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ý tuỳ tình trạng đội và ưu tiên sản phẩm.
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.
Bảng kiểm quyết định
Chủ đề: Đo xem các đội có thật sự dùng thư viện giao diện không. Cẩm nang Sinh Vũ, sinhvu.com
Bấm chọn từng mục Anh / Chị thấy đúng, rồi bấm in hoặc lưu thành PDF để mang theo.
Nếu Anh / Chị đánh dấu phần lớn ở nhóm dấu hiệu trên, đây là lúc nên trao đổi kỹ hơn. Sinh Vũ có thể cùng Anh / Chị soi lại và đề xuất hướng đi.
Nguồn tham khảo
Nathan Curtis, EightShapes: Measuring Design System Success (độ tin cậy cao). Nathan Curtis, EightShapes: Adopting Design Systems (độ tin cậy cao). Kinh nghiệm thực hành Sinh Vũ trong giai đoạn triển khai và bàn giao hệ thống.
Câu hỏi thường gặp
Chúng tôi đã publish design system lên npm. Vậy là xong phần đo chưa?
Publish là điều kiện cần, không phải thành công. Điểm neo đo được là sản phẩm có khai báo hệ như một dependency trong package.json chưa, và tỉ lệ giao diện được dựng từ component của hệ là bao nhiêu. Nếu chưa có con số đó, Anh / Chị vẫn chưa có bằng chứng dùng thật.
Figma có chỉ số nào đo được mức dùng không?
Có một tín hiệu gián tiếp: tỉ lệ tách rời (detach) component trong tệp thiết kế. Nếu đội hay tách component ra để chỉnh tay, đó là dấu hiệu component chưa đủ sát nhu cầu thật, không phải đội lười dùng hệ. Đây là chỉ số chẩn đoán, không phải chỉ số tổng kết.
Sản phẩm phụ có cần đạt cùng mức áp dụng với sản phẩm chủ lực không?
Không cần và không nên. Đặt một mục tiêu chung cho tất cả sản phẩm thường dẫn đến hai thái cực: sản phẩm chủ lực không đạt đủ nghiêm túc, sản phẩm phụ bị ép quá tay. Nên phân cấp rõ: mức áp dụng kỳ vọng của từng nhóm sản phẩm khác nhau, rà soát riêng.
Bài viết là thông tin tham khảo. Phạm vi, giá và cam kết cụ thể của Sinh Vũ ghi trong hồ sơ đề xuất và hợp đồng đã ký.