Hệ thiết kế cần bao nhiêu thành phần giao diện là đủ

Chốt nhanh

Đủ là số component mà đội thật sự dùng lại nhiều lần trên các màn hình thật, không phải con số càng lớn càng oai. Một hệ vài chục component lõi được áp dụng khắp nơi giá trị hơn hàng trăm component nằm im trong thư viện. Bắt đầu từ những dạng giao diện lặp lại nhiều nhất, rồi mở rộng khi có bằng chứng nhu cầu thật.

Đối sánh nhanh

Nên chọn hướng này khi

vài chục component lõi khi mới bắt đầu, đội nhỏ
nhiều component hơn khi nhiều sản phẩm, có đội chuyên nuôi

Chưa cần khi

đo thành công bằng số lượng component
dựng sẵn phòng khi cần mà không ai dùng

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 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ì. Sản phẩm thay đổi, token (đơn vị thiết kế nền như màu, khoảng cách, kiểu chữ) cập nhật, nền tảng kỹ thuật nâng cấp. Mỗi lần như vậy, mọi component đều phải được kiểm tra và điều chỉnh lại. Độ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. Nền tảng có nhiều sản phẩm, nhiều tình huống giao diện thật sự khác nhau thì cần hệ lớn hơn.

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

Ít component lõi (khoảng vài chục): Phù hợp khi mới bắt đầu, đội nhỏ, chưa có nhiều sản phẩm song song, muốn tỉ lệ áp dụng cao ngay từ đầu. Ưu điểm là dễ duy trì, đội học nhanh, ít vướng mắc khi có thành viên mới. Nhược điểm là có thể cần mở rộng khi sản phẩm phức tạp hơn. Nhiều component hơn: Phù hợp khi đã có nhiều sản phẩm thật, nhiều tình huống giao diện đã được chứng minh là khác nhau, và có đội chuyên trách nuôi hệ. Không nên đi hướng này ngay từ đầu chỉ vì muốn trông đầy đủ.

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. Nó 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

Muốn đánh giá sức khoẻ của một hệ thiết kế, Anh / Chị có thể hỏi: bao nhiêu phần trăm giao diện đang chạy thật dùng component từ hệ? Con số đó cho biết nhiều hơn tổng số component trong thư viện.

Công cụ mang về

Bảng kiểm quyết định

Chủ đề: Thư viện giao diện cần bao nhiêu khối (nút, ô nhập, thẻ) là đủ. Cẩm nang Sinh Vũ, sinhvu.com

0 trên 6 mục

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.

Dấu hiệu cho thấy Anh / Chị nên làm

vài chục component lõi khi mới bắt đầu, đội nhỏ
nhiều component hơn khi nhiều sản phẩm, có đội chuyên nuôi

Câu hỏi cần trả lời trước khi quyết định

Anh / Chị đã rà soát những dạng giao diện nào đang lặp lại nhiều nhất trong sản phẩm của mình chưa?
Có con số chuẩn nào cho số lượng component không?
Nên dựng component trước rồi dùng sau, hay đợi có nhu cầu mới dựng?
Tại sao nhiều biến thể lại là vấn đề?

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

Alla Kholmatova, Design Systems (Smashing Magazine); Nathan Curtis, EightShapes, Design Systems; Brad Frost, Atomic Design, Chương 2. Số liệu quy mô thư viện phản ánh kinh nghiệm thực hành của Sinh Vũ, không phải cam kết kỹ thuật cố định.

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

Có con số chuẩn nào cho số lượng component không?

Không có con số chuẩn áp dụng cho mọi trường hợp. Số lượng thay đổi tuỳ độ phức tạp của sản phẩm và mức độ lặp lại thật sau khi rà soát. Tiêu chí quan trọng hơn số lượng là tỉ lệ áp dụng thực tế trong đội.

Nên dựng component trước rồi dùng sau, hay đợi có nhu cầu mới dựng?

Nên đợi có bằng chứng nhu cầu thật. Dựng sẵn component phòng khi cần là lỗi phổ biến nhất, vì phần lớn những component đó sẽ không được dùng và vẫn phải bảo trì. Rà soát các màn hình đang có, tìm những gì lặp lại nhiều nhất, rồi ưu tiên dựng những phần đó trước.

Tại sao nhiều biến thể lại là vấn đề?

Nhiều biến thể gần giống nhau làm đội khó chọn đúng cái cần dùng, tăng thời gian quyết định, và nhân gấp chi phí bảo trì khi cần cập nhật. Thường thì các biến thể đó có thể gộp về một component có tham số (props hoặc variant), vừa gọn hơn vừa dễ kiểm soát hơn về lâu dài.

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ý.