Bàn giao thiết kế cho lập trình viên là chuyển cho người dựng giao diện mọi thứ họ cần để dựng đúng mà không phải đoán: tệp thiết kế được tổ chức rõ, giá trị dùng chung như màu và khoảng cách, thành phần với đủ trạng thái, ghi chú hành vi khi người dùng tương tác, và tài sản như icon, ảnh ở đúng định dạng. Bàn giao tốt không phải gửi một đường dẫn tệp rồi biến mất, mà là một buổi trao đổi và một vòng soát bản dựng.
Phần lớn tranh cãi giữa người thiết kế và lập trình viên bắt nguồn từ những thứ không có trong bản vẽ: bấm vào thì sao, tên dài thì sao, chưa có dữ liệu thì hiện gì. Bài này đưa ra danh mục bàn giao cho dự án nhỏ, cách viết ghi chú hành vi, những trạng thái hay bị quên, cách xuất tài sản, và chỗ AI giúp bạn viết nháp tài liệu nhanh hơn. Bài không đi vào viết code — phần đó thuộc chuyên môn lập trình.
Vì sao bàn giao hay hỏng
Người thiết kế nhìn bản vẽ và thấy một sản phẩm hoàn chỉnh. Lập trình viên nhìn cùng bản vẽ và thấy hàng trăm câu hỏi: khoảng cách này là 14 hay 16, nút này có trạng thái đang tải không, danh sách này có phân trang không, ảnh này là ảnh cố định hay ảnh người dùng tải lên. Khi không có câu trả lời, họ hoặc hỏi lại, hoặc tự quyết theo cách dễ dựng nhất.
Nguyên nhân thứ hai là bản vẽ không nhất quán. Ba màn hình có ba khoảng cách lề khác nhau vì vẽ ở ba thời điểm; hai nút trông giống nhau nhưng khác nhau một điểm bo góc. Lập trình viên phải chọn: dựng đúng từng chỗ làm mã rối, hay gộp lại và bị trách là không giống thiết kế.
Nguyên nhân thứ ba là thiết kế được giao xong là thôi. Khi bản dựng ra, không ai đối chiếu, các sai lệch nhỏ tích luỹ dần, và đến lúc khách xem thì đã muộn để sửa rẻ. Ba nguyên nhân này đều xử lý được bằng quy trình, không cần công cụ đắt tiền.
Danh mục bàn giao cho dự án nhỏ
Danh mục dưới đây đủ cho một trang web hoặc ứng dụng nhỏ. Dự án lớn sẽ cần thêm, nhưng thiếu những mục này thì dự án nhỏ cũng khó dựng đúng.
| Hạng mục | Nội dung cần có | Ghi chú |
|---|---|---|
| Tổ chức tệp | Trang riêng cho màn hình đã duyệt, trang riêng cho thư viện thành phần, trang riêng cho bản nháp; tên màn hình rõ nghĩa | Đánh dấu rõ màn hình nào đã chốt, màn hình nào còn đang làm |
| Token | Màu theo vai trò, thang cỡ chữ, thang khoảng cách, bo góc, đổ bóng | Tên token thống nhất với lập trình viên |
| Thành phần | Mỗi thành phần với đủ biến thể và trạng thái | Ghi rõ thành phần nào lấy từ bộ có sẵn, thành phần nào tự dựng |
| Luồng | Sơ đồ luồng cho các việc chính, kể cả nhánh lỗi | Gắn màn hình tương ứng vào từng bước |
| Co giãn | Bố cục ở ít nhất hai mức bề rộng, cách khối sắp xếp lại | Ghi chữ dài thì xuống dòng hay cắt |
| Ghi chú hành vi | Bấm, vuốt, cuộn, thời gian hiển thị thông báo, hiệu ứng chuyển | Viết ngắn, đặt cạnh thành phần liên quan |
| Khả năng tiếp cận | Nhãn đọc cho icon, mô tả ảnh, thứ tự đọc, trạng thái chọn bằng bàn phím | Phần hay bị quên nhất |
| Tài sản | Icon dạng SVG, ảnh ở các kích thước cần dùng, font và giấy phép | Đặt tên tệp theo quy ước chung |
| Nội dung | Chữ thật cho nhãn, thông báo lỗi, trang trống | Không để chữ giả trong bản đã chốt |
Không cần hoàn hảo ở mọi hạng mục. Nhưng nếu thiếu cả một hàng, ví dụ không hề có ghi chú hành vi, gần như chắc lập trình viên sẽ phải tự đoán ở hàng chục chỗ.
Những trạng thái và trường hợp biên hay bị quên
Bản vẽ thường chỉ có trạng thái đầy đủ dữ liệu, mọi thứ vừa khít. Trước khi bàn giao, rà từng màn hình theo danh sách sau:
- Trống: giỏ hàng chưa có gì, chưa có đơn nào, kết quả tìm kiếm không có. Màn hình trống nên nói rõ vì sao trống và người dùng nên làm gì tiếp.
- Đang tải: khung xương mờ, vòng quay, hay giữ nội dung cũ; tải lâu thì báo gì.
- Lỗi: mất mạng, máy chủ lỗi, không có quyền xem, phiên đăng nhập hết hạn. Mỗi loại lỗi một thông báo và một lối thoát.
- Dữ liệu cực trị: tên rất dài, tên rất ngắn, số rất lớn, danh sách một mục và một nghìn mục, ảnh dọc, ảnh ngang, không có ảnh.
- Quyền và vai trò: người chưa đăng nhập, người dùng thường, quản trị viên thấy gì khác nhau.
- Trạng thái thành phần: đang nhấn, không dùng được, đang xử lý, đang được chọn bằng bàn phím.
- Lần đầu và lần sau: người dùng mới có hướng dẫn không, quay lại lần hai có bỏ hướng dẫn không.
Đây là khâu AI giúp tiết kiệm nhiều nhất. Đưa mô tả màn hình bằng chữ, nhờ AI liệt kê mọi trạng thái và trường hợp biên, rồi bạn chọn những cái áp dụng và vẽ. Khi mô tả, không cần và không nên dán dữ liệu thật của khách.
Viết ghi chú hành vi ngắn mà đủ
Một ghi chú, một hành vi. Ghi chú tốt trả lời một câu hỏi cụ thể: "Bấm vào ảnh: mở xem ảnh lớn toàn màn hình, vuốt ngang để xem ảnh khác, bấm dấu nhân hoặc vuốt xuống để đóng." Tránh ghi chú chung chung như "tương tác mượt mà".
Đặt cạnh nơi xảy ra. Ghi chú nằm ngay bên thành phần trên tệp thiết kế, có đường nối tới nó, dễ đọc hơn một tài liệu rời mà lập trình viên phải tra qua lại.
Ghi con số khi có. Thông báo ngắn hiện bao lâu, bao nhiêu ký tự thì cắt, danh sách tải thêm bao nhiêu mục mỗi lần. Nếu chưa chắc, ghi "đề xuất" và để lập trình viên phản hồi.
Dùng AI viết nháp từ lời nói. Bạn có thể mô tả hành vi bằng lời tự nhiên, rồi nhờ AI chuyển thành ghi chú gọn. Câu lệnh mẫu: "Chuyển mô tả sau thành ghi chú hành vi cho lập trình viên, mỗi hành vi một dòng, nêu điều kiện, hành động, kết quả; không thêm hành vi không có trong mô tả: [mô tả]." Câu cuối quan trọng, vì AI hay tự bổ sung những thứ bạn không định có.
Đọc lại với con mắt của người dựng. Đọc ghi chú và tự hỏi: nếu mình là người dựng, đọc xong có làm được không, hay vẫn phải hỏi lại. Chỗ nào phải hỏi thì viết thêm.
Xuất tài sản: icon, ảnh và font
Icon nên xuất dạng SVG, đã gộp nét thành hình nếu nhóm lập trình yêu cầu, xoá các lớp ẩn và điểm neo thừa, khung đúng kích thước gốc. Đặt tên theo quy ước thống nhất, ví dụ bắt đầu bằng tiền tố icon rồi tới tên chức năng viết không dấu, để lập trình viên tìm được ngay. Mở thử từng tệp trên trình duyệt để chắc nó hiển thị đúng.
Ảnh cần chuẩn bị ở các kích thước sẽ dùng, kèm phiên bản cho màn hình mật độ điểm ảnh cao nếu cần. Ghi rõ ảnh nào là ảnh cố định của thiết kế, ảnh nào là ảnh người dùng hoặc quản trị viên sẽ tải lên sau. Với loại thứ hai, quan trọng là quy định tỷ lệ khung và cách cắt, không phải tệp ảnh mẫu.
Với font, ghi tên, các độ đậm được dùng, và quan trọng nhất là giấy phép có cho dùng trên web hay trong ứng dụng hay không. Nhiều font được phép dùng cho in ấn nhưng cần giấy phép riêng cho web hoặc ứng dụng. Font tiếng Việt còn phải kiểm đủ dấu ở mọi độ đậm được dùng. Nếu chưa chắc về giấy phép, ghi rõ để khách kiểm trước khi phát hành.
Buổi bàn giao và vòng soát bản dựng
Gửi tệp chưa phải là bàn giao. Quy trình gọn cho dự án nhỏ:
- Trước buổi bàn giao, tự rà tệp theo danh mục ở trên, đánh dấu những chỗ còn chưa chắc.
- Họp ngắn với lập trình viên, đi qua luồng chính và thư viện thành phần, không đi qua từng màn hình.
- Để lập trình viên hỏi; ghi lại mọi câu hỏi và câu trả lời ngay trong tệp thiết kế, cạnh chỗ liên quan.
- Thống nhất kênh hỏi đáp trong lúc dựng và thời gian phản hồi, ví dụ trong ngày.
- Khi có bản dựng đầu tiên, soát trên điện thoại thật và máy tính: khoảng cách, cỡ chữ, trạng thái, nội dung thật.
- Có thể dùng AI để so ảnh chụp bản dựng với ảnh bản thiết kế và liệt kê khác biệt dễ thấy; sau đó tự xác nhận từng điểm vì AI đọc ảnh có thể nhầm.
- Gom sai lệch thành danh sách, xếp theo mức ảnh hưởng tới người dùng, gửi một lần thay vì nhắn lẻ từng chỗ.
Khi dán ảnh chụp bản dựng vào AI, nhớ dùng dữ liệu mẫu, không dùng bản đang chạy có thông tin khách hàng thật. Nếu bản thiết kế chưa công bố, hỏi khách trước khi dùng công cụ bên ngoài.
Ranh giới giữa thiết kế và lập trình
Người thiết kế giao diện không cần viết code, nhưng nên hiểu đủ để thiết kế thứ dựng được: nội dung co giãn theo màn hình, đơn vị đo mà lập trình viên dùng, vì sao thành phần nên tái dùng thay vì vẽ mới mỗi lần. Hiểu những điều này giúp bạn nói cùng ngôn ngữ với người dựng.
Ngược lại, có những quyết định không thuộc về bạn: chọn công nghệ, cách lưu dữ liệu, cách tối ưu tốc độ. Khi một chi tiết thiết kế làm việc dựng phức tạp lên nhiều, cách tốt là hỏi lập trình viên có phương án nào gần tương đương mà dễ hơn không, rồi cùng cân nhắc với khách.
Phần viết mã, kể cả khi dùng AI để sinh mã từ thiết kế, thuộc chuyên môn lập trình và được bàn ở trang AI Lập Trình. Ở phía thiết kế, việc của bạn là để bản bàn giao rõ tới mức lập trình viên có thể dựng mà không cần đoán.
Câu hỏi thường gặp
Có cần viết tài liệu đặc tả dài khi bàn giao không?
Với dự án nhỏ, không cần tài liệu rời dài. Ghi chú ngắn đặt ngay trong tệp thiết kế, một trang thư viện thành phần và sơ đồ luồng thường đủ. Tài liệu dài hay bị bỏ qua, còn ghi chú đúng chỗ thì được đọc.
Lập trình viên dựng khác thiết kế thì xử lý thế nào?
Trước hết hỏi lý do: có thể do bản thiết kế không rõ, do giới hạn kỹ thuật, hoặc do sơ suất. Gom các sai lệch thành danh sách xếp theo mức ảnh hưởng tới người dùng, thống nhất cái nào sửa ngay, cái nào để sau, cái nào chấp nhận.
Phần mềm thiết kế có chế độ xem thông số cho lập trình viên thì còn cần ghi chú không?
Vẫn cần. Chế độ xem thông số cho biết kích thước, màu, khoảng cách của từng lớp, nhưng không cho biết hành vi, trạng thái thiếu, trường hợp biên hay lý do của một quyết định. Những thứ đó chỉ có trong ghi chú của bạn.
Có nên để AI sinh mã từ bản thiết kế để giao luôn cho khách không?
Đó là việc của lập trình viên và cần người có chuyên môn kiểm. Mã sinh tự động có thể chạy được nhưng khó bảo trì, thiếu khả năng tiếp cận hoặc không hợp với hệ thống khách đang dùng. Người thiết kế nên tập trung bàn giao rõ ràng thay vì nhận phần việc ngoài chuyên môn.
Bàn giao cho lập trình viên ở công ty khác cần lưu ý gì?
Thống nhất từ đầu về công cụ cả hai bên mở được, quyền truy cập tệp, kênh hỏi đáp và số vòng soát bản dựng. Ghi những thoả thuận này vào hợp đồng hoặc biên bản. Che thông tin nội bộ không cần thiết trong tệp trước khi chia sẻ ra ngoài.
Nên đặt tên lớp và tên màn hình bằng tiếng Việt hay tiếng Anh?
Chọn theo thói quen của nhóm dựng. Nhiều nhóm lập trình quen tên tiếng Anh không dấu cho thành phần và token để khớp với mã. Quan trọng là nhất quán, rõ nghĩa, và có một bảng giải thích nếu dùng tên viết tắt.