Đo mức dùng thật bằng con số thật
Ngày ra mắt hệ thiết kế (design system) không phải là thành công. Thành công là khi sản phẩm làm ra tính năng mới bằng các thành phần giao diện (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 để làm ra 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 được dùng hay đang nằm im trong kho mã nguồn.
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 người thiết kế 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 này: sản phẩm chủ lực không bị đòi hỏi đủ nghiêm túc vì mục tiêu quá thấp, trong khi sản phẩm phụ bị ép theo mức không thực tế.
Giá trị của design system hiện ra khi sản phẩm làm ra tính năng bằng các 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 để làm ra 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 tệp 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 (công cụ trưng bày các thành phần giao diện).
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 hoặc đã trả lời được, rồi bấm Tải bản gửi nhanh để gửi đi, hoặc bấm In nếu cần bản giấy.
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
Đội đã đưa design system lên npm (kho chứa thư viện mã dùng chung). Vậy là xong phần đo chưa?
Đưa hệ lên npm (kho chia sẻ thư viện mã) là điều kiện cần, không phải thành công. Có hai điều đo được. Một là sản phẩm đã khai báo hệ như một dependency (thư viện đi kèm) trong tệp package.json chưa. Hai là bao nhiêu phần trăm giao diện được dựng từ thành phần (component) của hệ. Nếu chưa có hai con số đó, Anh / Chị vẫn chưa có bằng chứng hệ được 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 bị đòi hỏi đủ nghiêm túc, sản phẩm phụ bị ép quá tay. Nên phân cấp rõ: mỗi nhóm sản phẩm có mức áp dụng kỳ vọng riêng và được 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ý.