Storybook hay file tĩnh: chọn đúng bản chất hệ thống
Câu trả lời nằm ở một điểm duy nhất: hệ của Anh Chị có bàn giao mã nguồn component cho lập trình viên 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. File 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, file 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
Sinh Vũ phân biệt hai loại tài liệu design system theo đối tượng nhận.
Loại A2 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 file Figma chia sẻ. Người nhận là quản lý thương hiệu, đối tác in ấn, agency thứ ba. Không ai cần tương tác với code ở đây.
Loại A3 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ệ là A3, tài liệu tĩnh không đủ. Không phải vì file tĩnh kém, mà vì file 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à file 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. File 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ệ bàn giao mã nguồn component cho đội kỹ thuật; số component nhiều và thay đổi thường xuyên; 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); 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.
File tĩnh là đủ khi: tài liệu chỉ dành cho con người đọc, không kèm code; hệ ít component và thay đổi rất ít; không có đội kỹ thuật nội bộ nhận bàn giao 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ì.
- Nhầm tài liệu A2 với A3, 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.
Góc nhìn của Sinh Vũ
Khi Sinh Vũ bàn giao A3, tài liệu Storybook đi kèm không phải tùy chọn thêm mà là một phần của sản phẩm. Lý do: nếu thiếu nó, lập trình viên bên nhận phải tự mò component bằng cách đọc code, dễ dùng sai, dễ ghi đè, và hệ thống bắt đầu phân kỳ ngay từ tuần đầu bàn giao.
Sinh Vũ còn nối Figma với Storybook qua Figma Code Connect, tức là khi designer nhìn vào một component trong Figma, họ thấy đúng đoạn code đang chạy tương ứng, không phải đoạn code ai đó gõ tay vào tài liệu rồi quên cập nhật. Đây là cách duy nhất Sinh Vũ biết để giữ bản vẽ và bản chạy không bao giờ cách nhau quá một bước.
Nếu Anh Chị đang ở giai đoạn chỉ cần hướng dẫn nhận diện cho đối tác in ấn và truyền thông, file tĩnh hoàn toàn hợp lý và Sinh Vũ sẽ nói thẳng điều đó. Nhưng nếu sắp tới có đội kỹ thuật nhận component để xây sản phẩm số, hãy tính Storybook vào ngay từ đầu, đừng để đến khi hệ đã chạy rồi mới quay lại viết tài liệu cho nó.
Checklist quyết định
Chủ đề: Có cần Storybook hay file 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ù 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à font cho người đọc, file 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à stakeholder 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, loại bỏ khoảng cách giữa bản vẽ và bản chạy.