PM và BA viết spec dựa trên component — không vẽ lại màn hình

Spec cũ mô tả hình, spec mới mô tả ghép

Một spec giao diện kiểu cũ thường là một bộ ảnh màn hình kèm chú thích: "nút màu xanh, cao 44, chữ trắng 16". Spec như vậy có hai vấn đề. Nó mô tả lại thứ mà thư viện đã định nghĩa, nên có thể mâu thuẫn với thư viện. Và nó khiến kỹ sư dựng lại từ đầu, vì mọi thứ trông như mới.

Khi có design system, spec nên làm việc khác: nói màn hình được ghép từ những component nào, ở biến thể và trạng thái nào, với dữ liệu gì, và chỉ mô tả chi tiết phần thật sự mới. Phần lớn công sức của BA chuyển từ mô tả giao diện sang mô tả hành vi, dữ liệu và trường hợp biên, đúng là chỗ BA mạnh nhất.

Ví dụ ở Giỏ Xanh: tính năng "Mua lại đơn cũ"

Squad Giỏ hàng và thanh toán làm tính năng cho phép khách mở một đơn đã giao và thêm lại các món vào giỏ. BA viết spec theo cách mới.

Bảng này dài chưa tới một trang, nhưng kỹ sư biết chính xác cần gọi gì. Designer chỉ cần vẽ một khuôn để kiểm tra bố cục, không cần vẽ lại từng nút.

Phần nào mới thì nói rõ là mới

Không phải spec nào cũng ghép được hoàn toàn từ thư viện. Khi cần thứ mới, spec phải tách rõ:

Ở Giỏ Xanh, biến thể ngang của ProductCard không có sẵn. BA không tự mô tả nó trong spec mà ghi "đề xuất biến thể ngang, chờ đội nền tảng giao diện duyệt", kèm lý do. Đề xuất đi theo quy trình ở bài 7, và khi được duyệt, mọi squad đều có thể dùng.

Tiêu chí chấp nhận theo component

Tiêu chí chấp nhận (acceptance criteria) cũng thay đổi. Thay vì "nút có màu xanh", BA viết tiêu chí về hành vi và về việc dùng đúng component. Cách viết tiêu chí rõ ràng được nói kỹ ở Use case và tiêu chí chấp nhận.

Ví dụ tiêu chí cho "Mua lại đơn cũ":

• Cho một đơn cũ có 10 món, trong đó 2 món hết hàng, khi khách bấm "Thêm tất cả vào giỏ", thì 8 món được thêm, 2 thẻ hiển thị trạng thái "hết hàng" và Toast cảnh báo ghi "Đã thêm 8 món, 2 món hết hàng".
• Cho một món có giá hiện tại khác giá trong đơn cũ, thì thẻ của món hiển thị Badge "Giá đã thay đổi" và giá hiện tại.
• Khi đang thêm vào giỏ, nút ở trạng thái đang tải và không bấm lại được.
• Màn hình chỉ dùng component từ thư viện phiên bản hiện tại, trừ biến thể ngang của ProductCard đã được duyệt.

Tiêu chí cuối cùng giúp QA biết phải kiểm gì: không phải đo điểm ảnh, mà kiểm tra đúng component được dùng. Màu, khoảng cách, cỡ chữ đã được thư viện đảm bảo.

Lợi ích đo được

Squad Thanh toán so sánh hai tính năng có độ lớn tương đương: "Lưu địa chỉ giao hàng" làm theo cách cũ trước đó, và "Mua lại đơn cũ" làm theo cách mới.

Đây chỉ là một cặp tính năng, chưa đủ để kết luận chung. Nhưng nó cho thấy chỗ tiết kiệm nằm ở đâu, và bài 9 sẽ đo điều này trên cả sản phẩm.

Những thói quen cần bỏ

• Dán ảnh màn hình từ sản phẩm đối thủ làm spec. Nó kéo theo một bộ nguyên tử khác hẳn thư viện của bạn.
• Ghi "giống màn X nhưng ..." Màn X có thể đang dùng component cũ. Hãy ghi tên component.
• Để designer quyết định có dùng thư viện hay không một mình. Quyết định tạo thứ mới có chi phí sản phẩm; PM nên biết và đồng ý.
• Viết spec trước khi xem thư viện có gì. Năm phút xem tài liệu design system có thể tiết kiệm một tuần.

Làm ngay

Chọn một tính năng sắp làm trong backlog của bạn. Viết lại phần giao diện của spec dưới dạng bảng ghép: phần màn hình, component, biến thể và trạng thái, dữ liệu. Đánh dấu rõ phần nào dùng nguyên, phần nào là biến thể mới, phần nào là component mới. Viết lại ba tiêu chí chấp nhận sao cho chúng kiểm hành vi và việc dùng component, không kiểm điểm ảnh. Gửi cho kỹ sư và hỏi: thiếu gì để bắt tay làm?