Trang bấm thử hay tệp tĩnh: chọn theo cách đội dùng
Câu trả lời nằm ở một điểm duy nhất: hệ của Anh / Chị có mã nguồn component cho lập trình viên dùng hay không.
Nếu hệ có mã nguồn component cho đội kỹ thuật dùng, tài liệu tương tác kiểu Storybook gần như bắt buộc. Tệp tĩnh như PDF hay ảnh đủ cho tài liệu hướng dẫn nhận diện dành cho người đọc, nhưng sẽ lệch với bản đang chạy ngay khi hệ thay đổi. Ranh giới quyết định không nằm ở quy mô hay ngân sách, mà nằm ở chỗ có mã nguồn hay không.
- có mã nguồn component, nhiều đội, người mới vào thường xuyên
- hệ thay đổi thường xuyên, cần tài liệu luôn khớp bản chạy
- chỉ là hướng dẫn nhận diện cho người đọc, không kèm code
- ít thay đổi, tệp tĩnh đủ dùng
Câu hỏi về Storybook thường bị hỏi nhầm hướng. Nhiều chủ doanh nghiệp hỏi "có nên dùng Storybook không" như thể đây là câu hỏi về công cụ hay ngân sách. Thực ra đây là câu hỏi về bản chất tài liệu: tài liệu đó dùng cho ai và cái gì đang thay đổi bên dưới nó.
Ranh giới quyết định: có mã nguồn hay không
Có thể chia tài liệu của một hệ thiết kế thành hai loại theo đối tượng nhận.
Loại thứ nhất là tài liệu cho con người đọc: hướng dẫn nhận diện thương hiệu, bộ quy tắc màu sắc, kiểu chữ, bố cục, thường ở dạng PDF hoặc tệp Figma chia sẻ. Người nhận là quản lý thương hiệu, đối tác in ấn, đơn vị thứ ba. Không ai cần tương tác với code ở đây.
Loại thứ hai là tài liệu cho máy đọc được: bộ component mã nguồn, token thiết kế dưới dạng biến số, dành cho lập trình viên tích hợp vào sản phẩm. Người nhận cần biết component thật sự trông và hoạt động thế nào trong trình duyệt, không chỉ trong ảnh chụp màn hình.
Khi hệ thuộc loại thứ hai, tài liệu tĩnh không đủ. Không phải vì tệp tĩnh kém, mà vì tệp tĩnh chụp ảnh một thời điểm, còn code tiếp tục chạy và thay đổi sau đó.
Storybook làm được gì mà tệp tĩnh không làm được
Storybook là một trình khám phá component (công cụ cho phép lập trình viên xây dựng, xem và thử từng component tách biệt khỏi ứng dụng chính). Điểm cốt lõi là nó chạy component thật, trong môi trường trình duyệt thật, không phải mô phỏng hay ảnh.
Component explorer dựng và trưng component trong môi trường tách biệt, cho thấy giao diện thật sự chạy thế nào chứ không chỉ mô tả nó nên trông ra sao.
Storybook, Why Storybook
Điều này có nghĩa thực tế: khi lập trình viên cập nhật một component, Storybook phản ánh thay đổi đó ngay. Tệp PDF vẫn hiện bản cũ cho đến khi ai đó nhớ vào cập nhật thủ công, thường là không ai nhớ.
Khi nào chọn hướng nào
Chọn tài liệu tương tác (Storybook hoặc tương đương) khi hệ có mã nguồn component cho đội kỹ thuật. Hoặc khi số component nhiều và thay đổi thường xuyên. Hoặc khi có nhiều đội hoặc người mới vào thường xuyên cần onboarding (làm quen hệ thống). Hoặc khi muốn giảm thời gian tra cứu và tránh lệch giữa bản thiết kế và bản chạy.
Tệp tĩnh là đủ khi tài liệu chỉ dành cho con người đọc, không kèm code. Hoặc khi hệ ít component và thay đổi rất ít. Hoặc khi không có đội kỹ thuật nội bộ nhận mã nguồn.
Lỗi thường gặp khi chọn sai định dạng
- Viết tài liệu PDF cho một hệ có code. Vài tháng sau PDF lệch hẳn với bản đang chạy, lập trình viên dừng đọc tài liệu vì không tin nó còn đúng.
- Dựng Storybook nhưng không gắn vào quy trình cập nhật. Kết quả là tài liệu tương tác nhưng chết, còn tệ hơn PDF vì tạo ảo giác đang được duy trì.
- Dùng Storybook cho một bộ hướng dẫn nhận diện không kèm code. Đây là đầu tư không có điểm rơi.
Cách cân cho tình huống của Anh / Chị
Figma Code Connect nối component trong Figma với đoạn mã đang chạy, nên designer nhìn vào một component là thấy đúng code tương ứng, không phải đoạn mã ai đó gõ tay vào tài liệu rồi quên cập nhật. Đây là một cách giúp bản vẽ và bản chạy không lệch nhau.
Nếu Anh / Chị chỉ cần hướng dẫn nhận diện cho đối tác in ấn và truyền thông, tệp tĩnh hoàn toàn hợp lý. Nếu sắp tới có đội kỹ thuật nhận component để xây sản phẩm số, nên tính Storybook ngay từ đầu, đừng để hệ chạy rồi mới quay lại viết tài liệu cho nó.
Bảng kiểm quyết định
Chủ đề: Tài liệu thư viện giao diện: trang bấm thử được hay tệp tĩnh là đủ. Cẩm nang Sinh Vũ, sinhvu.com
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.
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
Storybook, Why Storybook. Brad Frost, Atomic Design (phần công cụ và tài liệu sống). Kinh nghiệm thực hành của Sinh Vũ khi bàn giao A3 kèm Storybook và Figma Code Connect.
Câu hỏi thường gặp
Chúng tôi chỉ có một lập trình viên, có cần Storybook không?
Số người không phải yếu tố chính. Yếu tố chính là hệ có mã nguồn component hay không và tần suất thay đổi. Nếu có code và component thay đổi thường xuyên, dù chỉ một lập trình viên thì Storybook vẫn giúp giảm công tra cứu và phát hiện lệch sớm. Nếu hệ chỉ là hướng dẫn màu sắc và kiểu chữ cho người đọc, tệp tĩnh là đủ.
Dựng Storybook có tốn công duy trì không?
Có, và đây là rủi ro thật sự. Storybook dựng sai quy trình, không gắn vào pipeline triển khai, sẽ thành tài liệu chết nhanh hơn PDF. Điều kiện để Storybook sống là mỗi lần cập nhật component đều kèm cập nhật story tương ứng, lý tưởng nhất là tự động hoá trong quy trình kiểm thử.
Figma đã có prototype rồi, Storybook còn cần không?
Prototype trong Figma mô phỏng giao diện theo ý định của designer. Storybook chạy component thật trong môi trường trình duyệt thật. Hai cái phục vụ hai đối tượng khác nhau: Figma cho designer và các bên liên quan xem luồng, Storybook cho lập trình viên kiểm tra và lấy code. Nếu dùng Figma Code Connect, hai bên còn nối một đổi một với nhau, giảm khoảng cách giữa bản vẽ và bản chạy.
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ý.