Phối hợp nhà thiết kế và lập trình: đừng để thành khoai tây nóng

Phần lớn sự cố giữa thiết kế và lập trình không xảy ra vì ai kém tay nghề. Nó xảy ra vì hai bên gặp nhau quá muộn trong quy trình. Nhà thiết kế làm xong một mình, sau đó "ném qua hàng rào" cho lập trình, và lúc đó mới phát hiện ra những chỗ trông đơn giản trên màn hình lại tốn gấp ba lần thời gian dựng, hoặc không thể dựng theo đúng cách đã thiết kế. Đây là gốc rễ của hầu hết xung đột và chậm trễ trong dự án số.

Lỗi cốt lõi: bàn giao kiểu khoai tây nóng

Thuật ngữ "hot potato handoff" (bàn giao kiểu khoai tây nóng) trong ngành mô tả đúng bản chất vấn đề: ai cũng muốn chuyển trách nhiệm đi càng nhanh càng tốt, không ai muốn cầm lâu. Nhà thiết kế coi nhiệm vụ của mình kết thúc khi file thiết kế xong. Lập trình nhận file và tự tìm cách dựng mà không hiểu ý định đằng sau từng quyết định.

Hệ quả thực tế: lập trình dựng lệch thiết kế vì hiểu sai spec, thiết kế phàn nàn lập trình không tôn trọng file gốc, hai bên đổ lỗi qua lại, và người chịu thiệt cuối cùng là sản phẩm. Không có ai sai, chỉ có quy trình sai.

Kéo lập trình vào sớm hơn bạn nghĩ

Nguyên tắc Sinh Vũ giữ: không bao giờ là quá sớm để kéo lập trình vào. Lý tưởng nhất là ngay từ giai đoạn wireframe hoặc khi thảo luận ý tưởng ban đầu, trước khi thiết kế đã có màu sắc, font chữ, và hiệu ứng.

Tại sao giai đoạn này quan trọng? Vì lập trình nhìn thấy những ràng buộc mà nhà thiết kế không thấy. Một hiệu ứng chuyển cảnh trông mượt trên prototype (bản thử tương tác) có thể đòi hỏi logic phức tạp không tương xứng với giá trị mà nó mang lại. Một bố cục linh hoạt trên màn thiết kế có thể vỡ trên thiết bị thật nếu không tính đến ràng buộc của trình duyệt. Bắt được những chỗ này từ sớm, chi phí điều chỉnh gần như bằng không. Bắt được sau khi thiết kế hoàn chỉnh, chi phí đã nhân lên đáng kể.

Ngôn ngữ chung: điều kiện để cộng tác được

Cộng tác sớm không đủ nếu hai bên không có điểm gốc chung. Đây là vai trò của token (biến thiết kế) và quy ước đặt tên thống nhất.

• Token là những giá trị dùng chung: màu chính, cỡ chữ, khoảng cách. Khi token được đặt tên nhất quán giữa file thiết kế và code, lập trình không phải đoán "màu xanh này là màu nào trong hệ thống."
• Spec rõ ràng nghĩa là ghi lại ý định, không chỉ kết quả thị giác. Tại sao nút này có trạng thái bị vô hiệu hóa? Điều gì kích hoạt trạng thái lỗi? Thông tin này nếu không ghi vào spec thì lập trình phải tự đoán.
• Quy ước đặt tên component (thành phần giao diện) giúp cả hai bên nói về cùng một thứ khi thảo luận hoặc báo lỗi.

Không có ngôn ngữ chung, mỗi bên làm việc trong ốc đảo của mình dù ngồi cùng phòng.

Phối hợp là liên tục, không phải một lần

Ngay cả khi bắt đầu tốt, nhiều dự án vẫn hỏng ở giữa vì coi phối hợp là sự kiện một lần: họp kick-off rồi mỗi bên tự làm, gặp lại khi bàn giao. Thực tế, thiết kế thay đổi suốt quá trình. Màn hình mới được thêm vào. Trạng thái bị phát hiện khi dựng. Yêu cầu khách điều chỉnh.

Nếu không có nhịp góp ý qua lại định kỳ và kiểm soát phiên bản rõ ràng, lập trình đang dựng theo file cũ trong khi thiết kế đã sang phiên bản khác. Đây là nguồn gốc của phần lớn tranh cãi về "dựng không đúng thiết kế" mà thực chất là hai bên dùng hai phiên bản khác nhau.

Đội mạnh nhất không chăm chăm vào một thời điểm bàn giao, mà dần xây hiểu biết chung và không gian để thiết kế cùng lập trình định hình sản phẩm.

Figma Blog, The Designer's Handbook for Developer Handoff

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

Vì Sinh Vũ vừa thiết kế vừa dựng website chạy thật, góc nhìn về tính khả thi kỹ thuật không phải thứ được thêm vào sau, mà đi cùng ngay từ khi xây luồng trải nghiệm. Điều này giúp bắt sớm những quyết định thiết kế trông hợp lý trên màn hình nhưng tốn kém hoặc dễ vỡ khi dựng thật.

Khi làm việc với đội kỹ thuật của khách, Sinh Vũ không bàn giao file rồi bước ra. Sinh Vũ thiết lập ngôn ngữ chung từ đầu, duy trì kênh trao đổi trong suốt dự án, và chốt rõ ai quyết định khi thiết kế và ràng buộc kỹ thuật xung đột. Đó là thứ giúp dự án không bị mắc kẹt giữa hai ốc đảo.