Có cần pattern library không

Trong nhiều dự án design system (hệ thống thiết kế), Sinh Vũ nhận được câu hỏi này khá muộn, sau khi đội đã xây xong component library (thư viện thành phần giao diện) và bắt đầu nhận ra có những tình huống không biết xếp vào đâu. Câu trả lời không phải lúc nào cũng là "có" hoặc "không", mà phụ thuộc vào mức độ phức tạp thực của sản phẩm và số đội đang cùng làm.

Pattern và component: hai tầng khác nhau

Đây là điểm phân biệt quan trọng nhất, và cũng là nơi nhiều đội nhầm nhất.

Component là viên gạch: nút bấm, ô nhập liệu, thẻ thông tin, huy hiệu trạng thái. Mỗi component hoạt động độc lập và có thể tái dùng ở nhiều chỗ. Pattern (tình huống giao diện) là cách ghép những viên gạch đó lại để giải một bài toán trải nghiệm cụ thể, ví dụ: luồng đặt hàng nhiều bước, bảng dữ liệu có lọc và phân trang, biểu mẫu đăng ký có xác thực theo thời gian thực.

Component trả lời câu hỏi "Đây là cái gì?" Pattern trả lời câu hỏi "Làm thế này thế nào?"

Nathan Curtis, EightShapes

Theo khung Atomic Design của Brad Frost, component tương ứng với tầng atom và molecule. Pattern tương ứng với organism và template, là nơi các phần nhỏ được ghép lại có mục đích. Hai tầng này bổ sung cho nhau và không thể thay thế nhau.

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

• Độ phức tạp của sản phẩm: Sản phẩm có nhiều luồng nhiều bước, bảng dữ liệu lớn, hoặc các tình huống tìm kiếm và lọc phức tạp không? Nếu không, component lõi thường là đủ.
• Số đội cùng làm: Một đội có thể thống nhất miệng. Nhiều đội cần tài liệu chuẩn chung, nếu không mỗi đội sẽ tự chế một kiểu cho cùng một tình huống.
• Tần suất lặp lại: Nếu một tình huống chỉ xuất hiện một lần trong toàn bộ sản phẩm, ghi chú trong file thiết kế là đủ. Nếu lặp lại ở nhiều màn hình và nhiều luồng, cần pattern thành văn.
• Khả năng duy trì: Pattern library cần được cập nhật song song với component. Nếu đội không có người chịu trách nhiệm duy trì, tạo ra rồi bỏ đó còn tệ hơn không có.

Khi nào cần, khi nào chưa cần

Lỗi thường gặp nhất

• Nhồi mọi thứ vào một kho không phân tầng: Kết quả là người dùng không biết đang tìm viên gạch hay đang tìm cách xây, kho trở nên khó tra cứu khi lớn dần.
• Làm pattern library quá sớm: Khi sản phẩm chưa đủ phức tạp, pattern library trở thành tài liệu bày ra cho có, không ai dùng và không ai cập nhật.
• Có pattern nhưng không kèm hướng dẫn dùng: Một pattern không có mô tả khi nào dùng, khi nào không dùng, và tại sao chọn cách này, thực chất chỉ là ảnh chụp màn hình trong một kho lạnh.

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

Trong bàn giao A3 cho các sản phẩm có độ phức tạp trung bình trở lên, Sinh Vũ tách rõ thư viện component lõi và pattern library thành hai tầng riêng. Những tình huống giao diện phức tạp đã có lời giải chuẩn sẵn, đội không phải nghĩ lại mỗi lần gặp cùng một bài toán.

Với sản phẩm còn đơn giản, Sinh Vũ tư vấn khoan làm pattern library. Không phải vì không có giá trị, mà vì làm sớm khi chưa đủ tình huống thực tế dễ dẫn đến pattern xây trên giả định, không khớp với cách sản phẩm thực sự vận hành sau này. Tốt hơn là để pattern nảy sinh từ những tình huống lặp lại thật, sau đó chuẩn hóa.

Nguyên tắc Sinh Vũ theo: pattern library phục vụ đội, không phải ngược lại. Nếu Anh Chị phải thuyết phục đội dùng nó, có thể làm sớm hơn nhu cầu thực.