Có cần pattern library không

Pattern library (thư viện tình huống giao diện, là tập hợp các cách lắp ghép component để giải quyết những vấn đề UX phức tạp như form nhiều bước, bảng dữ liệu lớn, hay luồng đăng ký mới) nghe có vẻ như thứ mọi design system đều cần. Thực tế thì không phải vậy. Với phần lớn khách của Sinh Vũ, câu trả lời là chưa cần, ít nhất là ở thời điểm bắt đầu.

Component và pattern: hai thứ khác nhau

Trước khi quyết định, Anh Chị cần phân biệt rõ hai khái niệm. Component là đơn vị giao diện độc lập. Button, Input, Badge đều là component. Pattern là câu trả lời cho một câu hỏi thiết kế cụ thể, được tạo ra bằng cách kết hợp nhiều component lại với nhau.

• Ví dụ pattern: Empty State (màn hình trống khi chưa có dữ liệu) dùng Icon, Heading, Button và Text.
• Ví dụ pattern: Wizard Form (form nhiều bước có thanh tiến trình) dùng Stepper, Input, Button và Validation Message.
• Ví dụ pattern: Error Recovery (hướng dẫn người dùng thoát khỏi lỗi) dùng Alert, Link và mô tả hành động tiếp theo.

Component library trả lời câu hỏi "cái này trông như thế nào". Pattern library trả lời câu hỏi "vấn đề này giải quyết ra sao". Nếu Anh Chị chỉ đang cần sự nhất quán về hình thức, component library là đủ.

Khi nào nên xây, khi nào chưa cần

Lỗi thường gặp khi xây pattern library

• Xây quá sớm: Pattern library cần được đúc rút từ giải pháp đã kiểm chứng trong sản phẩm thực. Xây trước khi có đủ flow thực tế đồng nghĩa với xây lý thuyết, và lý thuyết thiết kế rất ít khi sống sót qua thực tế.
• Gộp component và pattern vào một chỗ: Điều này tạo ra nhầm lẫn về mức độ trừu tượng. Người dùng tài liệu không biết đang tìm đơn vị nhỏ hay giải pháp tổng thể.
• Không cập nhật khi sản phẩm thay đổi: Pattern library không được bảo trì sẽ trở thành tài liệu sai lạc, nguy hiểm hơn không có tài liệu vì nó tạo cảm giác an toàn giả.
• Xây pattern quá cứng nhắc: Pattern là tham chiếu, không phải luật. Nếu tài liệu không cho phép ứng biến, designer sẽ bỏ qua nó hoặc làm theo rồi ra sản phẩm không phù hợp.

Pattern nên được rút ra từ giải pháp đã được kiểm chứng trong sản phẩm, không nên xây lý thuyết trước khi có thực tế.

Quan điểm thực hành ngành, Nielsen Norman Group

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

Sinh Vũ không đưa pattern library vào phạm vi mặc định của gói design system. Thay vào đó, Sinh Vũ đưa vào Storybook một số usage examples (ví dụ sử dụng thực tế) cho các component phức tạp. Đây là mức tài liệu hóa đủ dùng cho phần lớn khách trong giai đoạn đầu triển khai.

Pattern library sẽ được Sinh Vũ đề xuất bổ sung khi Anh Chị có đội thiết kế từ ba người và sản phẩm đã qua ít nhất một năm vận hành thực tế, đủ để có pattern thật sự đáng đúc rút. Trước thời điểm đó, đầu tư vào component chắc chắn và usage examples rõ ràng sẽ mang lại giá trị thực tế hơn nhiều.

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

Pattern library khác component library ở điểm nào?

Component là đơn vị giao diện độc lập, ví dụ một Button hay một Input. Pattern là cách kết hợp nhiều component để giải quyết một vấn đề trải nghiệm cụ thể, ví dụ cách xử lý trạng thái trống (empty state), cách dẫn dắt người dùng qua form nhiều bước, hay cách phục hồi sau lỗi. Nói ngắn: component trả lời câu hỏi 'cái này trông như thế nào', còn pattern trả lời câu hỏi 'vấn đề này giải quyết ra sao'.

Nếu chưa có pattern library, designer trong team tham chiếu gì khi gặp tình huống phức tạp?

Sinh Vũ thường đưa vào Storybook một số usage examples (ví dụ sử dụng thực tế) cho các component phức tạp, đây là mức tài liệu hóa đủ dùng cho phần lớn team nhỏ. Ngoài ra, việc review thiết kế thường xuyên giữa các thành viên thay thế được phần lớn vai trò của pattern library trong giai đoạn đầu.

Khi nào nên bắt đầu xây pattern library?

Dấu hiệu rõ nhất là đội thiết kế bắt đầu tranh luận lặp lại về cách xử lý cùng một tình huống UX, hoặc designer mới vào team mất nhiều thời gian để hiểu cách sản phẩm đang vận hành. Ngoài ra, sản phẩm nên đã qua ít nhất một năm vận hành thực tế để có đủ pattern đã được kiểm chứng mà đúc rút, thay vì xây pattern lý thuyết từ đầu.