Cần bao nhiêu component là đủ

Khi bắt đầu xây design system (hệ thiết kế), câu hỏi đầu tiên nhiều đội đặt ra là: cần bao nhiêu component? Câu trả lời thẳng của Sinh Vũ là: đủ để đội dùng lại nhiều lần, không phải đủ để trông hoành tráng. Hệ thiết kế không phải bảo tàng trưng bày, nó là công cụ vận hành thật sự.

Vì sao số nhiều chưa chắc tốt

Mỗi component đưa vào hệ là một khoản nợ bảo trì. Khi sản phẩm thay đổi, khi token (đơn vị thiết kế nền như màu, khoảng cách, kiểu chữ) cập nhật, khi nền tảng kỹ thuật nâng cấp, mỗi component đều phải được kiểm tra và điều chỉnh theo. Đội nhỏ mà ôm hệ lớn sẽ mau chóng bị kéo vào việc bảo trì thay vì dùng hệ để xây sản phẩm.

Alla Kholmatova trong cuốn Design Systems đặt vấn đề rõ: hệ thiết kế hiệu quả là tập pattern (mẫu giao diện) nhỏ, chất, kết nối nhau, không phải kho phình to và cồng kềnh. Một thư viện 200 component mà tỉ lệ áp dụng thật chỉ 30% kém hơn thư viện 60 component được dùng gần như hoàn toàn.

Các yếu tố cần cân nhắc

• Tần suất lặp lại thật: Dạng giao diện này xuất hiện trên bao nhiêu màn hình, bao nhiêu sản phẩm? Lặp lại nhiều thì đáng đưa vào hệ. Dùng một lần thì để ở sản phẩm, không cần nâng lên thành component chung.
• Chi phí bảo trì về sau: Đội có đủ người để nuôi số component đó khi hệ cần cập nhật không? Nếu không, số lượng lớn sẽ biến thành gánh nặng thay vì lợi thế.
• Sự khác biệt thật giữa các biến thể: Hai component trông khác nhau có thực sự khác nhau về hành vi và ngữ cảnh dùng không, hay chỉ là trùng lặp có thể gộp về một component có tham số (variant hoặc props, tức là các giá trị cấu hình của component)?
• Quy mô và độ phức tạp sản phẩm: Một ứng dụng đơn giản với ít luồng người dùng cần hệ nhỏ hơn nhiều so với nền tảng nhiều sản phẩm, nhiều tình huống giao diện thật sự khác nhau.

Khi nào chọn hướng nào

Nathan Curtis từ EightShapes đặt nguyên tắc phân loại rõ ràng: phần dùng lại nhiều thì đưa vào hệ, phần dùng một lần thì để ở sản phẩm. Nguyên tắc này đơn giản nhưng giúp tránh được phần lớn các quyết định sai về phạm vi.

Lỗi thường gặp

• Đo thành công bằng số lượng: "Hệ của mình có 150 component rồi" không nói lên điều gì nếu không biết bao nhiêu phần trăm trong số đó đang được dùng thật.
• Dựng sẵn phòng khi cần: Component dựng sẵn mà chưa có nhu cầu thật thường bị bỏ qua hoặc bị dùng sai ngữ cảnh, và vẫn tốn công bảo trì như những component được dùng nhiều.
• Tạo nhiều biến thể gần giống nhau: Thay vì một Button (nút bấm) có các tham số size, variant, state, đội tạo ra ButtonPrimaryLarge, ButtonPrimarySmall, ButtonSecondaryLarge, v.v. Kết quả là gánh nặng nhân lên nhiều lần mà không thêm giá trị thật.

Xây từ dưới lên theo atomic design (thiết kế nguyên tử): atom (nguyên tử, phần nhỏ nhất như nút, ô nhập), molecule (phân tử, tổ hợp vài atom), organism (cơ thể, khối giao diện hoàn chỉnh). Thêm khi có nhu cầu thật, không dựng sẵn toàn bộ.

Brad Frost, Atomic Design, Chương 2

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

Trong thực hành, Sinh Vũ thường dựng thư viện trong khoảng 40 đến 80 component lõi đầy đủ trạng thái thật. Đây là chỉ dấu quy mô tham khảo, không phải con số cố định, vì con số này thay đổi tùy độ phức tạp của sản phẩm và mức độ lặp lại thật sau khi rà soát giao diện hiện có.

Quan điểm vận hành của Sinh Vũ là: mỗi component thêm vào phải trả giá bằng công bảo trì về sau. Vì vậy tiêu chí nghiệm thu không phải "hệ có bao nhiêu component" mà là "tỉ lệ áp dụng thật của hệ trong đội là bao nhiêu". Nếu Anh Chị muốn đánh giá sức khỏe của một design system, hãy hỏi: bao nhiêu phần trăm giao diện đang chạy thật dùng component từ hệ? Con số đó mới là thước đo thật sự.