Bàn giao thiết kế cho lập trình sao cho suôn
Mỗi lần lập trình tự đoán là một lần sản phẩm lệch khỏi thiết kế, và thường không ai biết cho đến khi đã muộn.
Bàn giao suôn nghĩa là lập trình không phải đoán bất kỳ điều gì quan trọng: khoảng cách, màu sắc, hành vi, trạng thái màn hình hay nội dung. Một bộ bàn giao đủ gồm thông số kỹ thuật rõ ràng, tài sản sẵn sàng dùng, mô tả hành vi động và bản nội dung cuối. Thiếu bất kỳ phần nào, lập trình sẽ tự điền vào chỗ trống theo cách của họ, không phải cách của thiết kế.
Bàn giao thiết kế không phải là kết thúc của thiết kế, mà là bước chuyển giao trách nhiệm. Nếu bước này không rõ ràng, lập trình sẽ tự điền vào mọi chỗ mơ hồ theo phán đoán của họ, và kết quả thường không giống thiết kế gốc. Không phải vì lập trình làm sai, mà vì họ không có đủ thông tin để làm đúng.
Bàn giao là dịch thuật, không phải chuyển file
Thiết kế và lập trình là hai nghề tư duy bằng hai ngôn ngữ khác nhau. Thiết kế nhìn bằng mắt, cảm nhận tỷ lệ, phán đoán khoảng trống. Lập trình cần con số: pixel, mã màu, chiều cao dòng, trọng số chữ. Một file Figma đẹp nhìn vào không tự nói ra được những con số đó, và nhìn vào một file tĩnh gần như không thể biết chính xác số đo pixel của từng phần tử, buộc lập trình phải đoán.
Bàn giao hiện đại không phải là chồng thêm tài liệu redline (chú thích thông số kỹ thuật lên bản thiết kế) và spec (bảng mô tả chi tiết kỹ thuật) tĩnh. Đó là tạo ra một hệ thống sống nơi thiết kế và lập trình nói cùng ngôn ngữ qua token (biến số thiết kế dùng chung), quy ước và công cụ chung.
Một bộ bàn giao đủ thành phần
Sinh Vũ coi một bộ bàn giao là đủ khi lập trình không cần phải hỏi lại về bất kỳ điều nào sau đây:
- Đủ trạng thái màn hình: bình thường, trống (chưa có dữ liệu), đang tải, báo lỗi, thành công. Thiếu trạng thái nào, lập trình tự chế trạng thái đó theo cách họ nghĩ là hợp lý.
- Thông số chính xác: khoảng cách, kích thước chữ, độ đậm, chiều cao dòng, mã màu, ánh xạ về token của hệ thiết kế.
- Tài sản sẵn sàng dùng: hình ảnh, biểu tượng dạng SVG xuất đúng định dạng và độ phân giải, không phải để lập trình tự cắt.
- Mẫu tương tác mô tả hành vi động: nút bấm phản hồi ra sao, chuyển màn diễn ra thế nào, animation (chuyển động giao diện) kéo dài bao lâu theo hướng nào.
- Bản nội dung cuối (copy deck): chữ thật để lập trình điền vào, không phải lorem ipsum (văn bản giữ chỗ) rồi để chữ giữ chỗ trôi ra sản phẩm thật.
- Đầu mối giải đáp: ai là người lập trình liên hệ khi gặp chỗ mơ hồ, và trong bao lâu sẽ có phản hồi.
Chọn hướng bàn giao phù hợp phạm vi
Bàn giao giao diện để đội kỹ thuật khách tự lập trình: Phải kèm spec và token đầy đủ vì Sinh Vũ không kiểm soát khâu dựng. Rủi ro cao hơn nếu đội kỹ thuật không quen đọc Figma hoặc không có quy ước token sẵn.
Sinh Vũ thiết kế kèm lập trình trọn gói: Bàn giao nội bộ nhẹ hơn về thủ tục, nhưng vẫn cần bản nội dung cuối và đủ trạng thái màn hình để dựng đúng ngay từ đầu.
Phối hợp với đội kỹ thuật sẵn có của khách: Cần ngồi thống nhất token và quy ước đặt tên với hệ thống hiện tại của họ trước khi bàn giao chính thức. Đây là bước nhiều bên bỏ qua và trả giá về sau.
Lỗi thường gặp khi bàn giao
- Mô hình khoai tây nóng: thiết kế xong, ném file cho lập trình rồi phủi tay, không còn ai giải đáp khi có chỗ mơ hồ. Lập trình buộc phải đoán hoặc chờ, cả hai đều tốn kém.
- Chỉ giao màn hình bình thường: quên trạng thái trống, lỗi, đang tải. Lập trình tự chế và ra kết quả lệch với thiết kế, đôi khi còn lệch với trải nghiệm người dùng mong đợi.
- Không có bản nội dung cuối: lập trình điền chữ tạm, chữ tạm đó trôi ra sản phẩm thật vì không ai nhớ cập nhật lại.
- Thông số rời rạc, không ánh xạ về token: mỗi màn một kiểu, sản phẩm dựng ra không nhất quán dù từng màn trông có vẻ ổn.
Góc nhìn của Sinh Vũ
Sinh Vũ hiểu chữ "suôn" theo nghĩa này: hai bên cùng đọc một ngôn ngữ, và không bên nào phải tự đoán điều quan trọng. Bàn giao không kết thúc ở thời điểm giao file, nó kết thúc khi lập trình dựng xong và sản phẩm khớp với thiết kế ở mức Anh / Chị có thể chấp nhận.
Vì vậy ở mọi phạm vi, kể cả khi chỉ thiết kế giao diện để đội khách tự lập trình, Sinh Vũ bàn giao kèm hướng dẫn vận hành để đội khách hiểu và tự chạy được. Không phải chỉ nhận một mớ file rồi tự đoán cách dùng.
Bàn giao hiện đại là tạo ra một hệ sống nơi thiết kế và lập trình nói cùng ngôn ngữ qua token, quy ước và công cụ chung, thay vì chỉ chồng thêm tài liệu kỹ thuật tĩnh.
Roberto Moreno Celta, Design Handoff 2.0 (UX Collective)
Nguồn tham khảo
Figma Blog, The Designer's Handbook for Developer Handoff. CODE Magazine, Eliminating Waste During Designer-to-Developer Handoff. Roberto Moreno Celta, Design Handoff 2.0 (UX Collective). IxDF, What Are Design Handoffs.
Câu hỏi thường gặp
Figma đã có inspect (xem thông số) rồi, lập trình tự đọc được không?
Figma Inspect giúp lập trình đọc thông số từng phần tử, nhưng không thay thế được bản mô tả hành vi động, danh sách trạng thái màn hình hay bản nội dung cuối. Nếu thiết kế không chuẩn bị đủ các màn trạng thái thì Inspect cũng không có gì để đọc. Công cụ hỗ trợ, nhưng không thể tự vá chỗ thiếu.
Bàn giao cần tài liệu nhiều trang không, hay chỉ cần file Figma là đủ?
Không nhất thiết phải thành tài liệu nhiều trang. Quan trọng là đủ thành phần: thông số, tài sản, trạng thái, hành vi, nội dung và một đầu mối giải đáp khi có thắc mắc. Hình thức có thể là annotation ngay trong Figma, một trang ghi chú kèm theo, hoặc buổi walk-through trực tiếp, tuỳ quy mô dự án.
Nếu đội lập trình có hệ thống token riêng thì làm sao?
Cần ngồi lại thống nhất trước khi bàn giao: token của thiết kế ánh xạ về token của đội lập trình như thế nào. Ví dụ màu primary trong Figma tương ứng với biến nào trong codebase của họ. Bước này tốn ít thời gian nhưng tránh được rất nhiều sai lệch về sau.