Thiết kế và lập trình: đừng đá việc cho nhau
Lỗi phổ biến nhất không nằm ở tay nghề mà nằm ở thời điểm hai bên gặp nhau lần đầu.
Phối hợp tốt giữa nhà thiết kế và lập trình bắt đầu sớm hơn hầu hết mọi người nghĩ. Nó bắt đầu ngay từ wireframe (bản phác thảo cấu trúc màn hình), không phải sau khi thiết kế đã hoàn chỉnh. Kéo lập trình vào sớm giúp bắt được những ràng buộc kỹ thuật trước khi thiết kế đi quá xa theo hướng không thể dựng được. Hai bên nên dùng chung một bộ đặc tả (spec) và quy ước đặt tên để hiểu đúng như nhau.
- sản phẩm có tương tác phức tạp, cần kéo lập trình vào từ wireframe
- khách đã có nền tảng riêng, cần thiết kế khớp vào hệ thống hiện hữu
- nhiều trạng thái động và nhiều màn cần đồng bộ liên tục
- bàn giao kiểu khoai tây nóng, thiết kế xong mới gặp lập trình lần đầu
- không có ngôn ngữ chung nên mỗi bên hiểu spec một kiểu
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. 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, có khi còn 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 bản thiết kế xong. Lập trình nhận bản thiết kế 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à lập trình dựng lệch thiết kế vì hiểu sai đặc tả. Thiết kế thì phàn nàn lập trình không tôn trọng bản 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 Anh / Chị nghĩ
Nguyên tắc nên giữ là kéo lập trình vào càng sớm càng tốt. 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, kiểu 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 rất thấp. Bắt được sau khi thiết kế hoàn chỉnh, chi phí đã nhân lên đáng kể.
Chung một điểm gốc: đ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 bản 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."
- Đặc tả 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 hoá? Đ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 đặc tả 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ó điểm gốc chung, mỗi bên làm việc trong ốc đảo của mình dù ngồi cùng phòng.
Bên thiết kế phối hợp với đội kỹ thuật sẵn có của doanh nghiệp: hướng này phù hợp khi doanh nghiệp đã có nền tảng và hệ thống riêng, thiết kế cần khớp vào hạ tầng đang chạy. Cần thiết lập ngôn ngữ chung và nhịp góp ý rõ ràng từ đầu.
Một bên đảm nhận trọn gói cả thiết kế lẫn dựng thật: hướng này phù hợp khi doanh nghiệp không có đội kỹ thuật hoặc muốn tránh chi phí quản lý phối hợp giữa nhiều bên. Góc nhìn kỹ thuật đi cùng ngay từ khâu dựng luồng trải nghiệm, bắt sớm chỗ trông đơn giản mà khó dựng. Đổi lại, doanh nghiệp phụ thuộc vào một đầu mối duy nhất.
Doanh nghiệp tự làm cả hai phía: hợp với đội nội bộ đã có cả người thiết kế lẫn người dựng và quen làm việc cùng nhau; điều cần giữ vẫn là điểm gốc chung và nhịp góp ý.
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 khởi động 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 bản 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. Khi thiết kế và ràng buộc kỹ thuật xung đột, cũng cần chốt từ đầu ai là người quyết, để tranh luận không bị kéo dài.
Độ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
Bảng kiểm quyết định
Chủ đề: Người thiết kế và người lập trình phối hợp thế nào. Cẩm nang Sinh Vũ, sinhvu.com
Bấm chọn từng mục Anh / Chị thấy đúng hoặc đã trả lời được, 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
Figma Blog, The Designer's Handbook for Developer Handoff; WeAreBrain, Designer-Developer Handoff: The Art of Collaboration; Lucidchart Blog, Best Practices for Designer to Developer Handoffs; kinh nghiệm thực hành Sinh Vũ.
Câu hỏi thường gặp
Nếu doanh nghiệp đã có đội lập trình riêng thì bên thiết kế nên phối hợp như thế nào?
Bên thiết kế nên làm việc trực tiếp với đội kỹ thuật của Anh / Chị, thiết lập điểm gốc chung qua đặc tả rõ ràng và quy ước đặt tên thống nhất. Thay vì bàn giao một lần rồi thôi, hai bên nên giữ nhịp góp ý qua lại trong suốt dự án để bắt sớm chỗ lệch giữa thiết kế và thực tế dựng. Cách này hợp khi hạ tầng đã chạy và thiết kế phải khớp vào đó.
Nếu thiết kế xong rồi mới tìm lập trình thì có sao không?
Được, nhưng rủi ro cao hơn đáng kể. Thiết kế xong mới gặp lập trình lần đầu là kiểu bàn giao mà ngành gọi là 'khoai tây nóng': thiết kế ném qua hàng rào cho kỹ thuật. Phát hiện muộn những chỗ không thể dựng được thì chi phí sửa đã nhân lên. Nếu bắt buộc đi theo trình tự này, ít nhất cần có đặc tả thật chi tiết và sẵn sàng điều chỉnh thiết kế sau khi lập trình đánh giá.
Token và quy ước đặt tên là gì, có cần thiết không?
Token (biến thiết kế) là những giá trị dùng chung như màu sắc, cỡ chữ, khoảng cách, được đặt tên thống nhất để cả thiết kế lẫn code dùng cùng một điểm gốc. Quy ước đặt tên giúp lập trình hiểu đúng ý định thiết kế mà không cần giải thích lại từng trường hợp. Với dự án có nhiều màn hình hoặc nhiều trạng thái, đây là thứ giúp hai bên không lạc nhau. Với một trang đơn giản, ít trạng thái, một bộ quy ước gọn là đủ.
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ý.