Mở đầu — vì sao bài này quan trọng
Bạn đã dành ba tuần để thiết kế một màn hình checkout đẹp long lanh. Auto Layout gọn gàng, component chuẩn chỉnh, design token đầy đủ. Bạn gửi link Figma cho team dev, gõ một dòng "Handoff nhé anh em", rồi thở phào. Hai tuần sau, bản build lên staging: nút "Thanh toán" biến mất khi màn hình co lại còn 360px, trạng thái loading không có, thông báo lỗi thẻ hiển thị bằng tiếng Anh mặc định của thư viện, và trên iPhone SE thì cả phần footer bị che. Dev thì bảo "design không có mấy cái đó", còn bạn thì cãi "tôi nghĩ những cái đó là hiển nhiên".
Đây chính là khoảnh khắc mà một handoff checklist tồn tại để ngăn chặn. Handoff không phải là hành động "gửi file". Handoff là một cam kết chất lượng: bạn khẳng định với engineer rằng thiết kế này đã đầy đủ, nhất quán, và sẵn sàng để dịch thành code mà không cần đoán mò. Mọi thứ bạn quên, engineer sẽ hoặc là (a) tự bịa ra theo cảm tính, hoặc (b) quay lại hỏi bạn — cả hai đều tốn thời gian và bào mòn niềm tin.
Bài này không dạy bạn cách dùng Dev Mode (Bài 42), cách annotate (Bài 43), hay cách export asset (Bài 48). Bài này là tấm lưới an toàn cuối cùng — cái checklist bạn chạy qua trước khi bấm nút "ship" cho phần thiết kế, để không bao giờ rơi vào tình huống trên nữa. Một designer junior giao "một màn hình đẹp". Một designer senior giao "một màn hình không thể triển khai sai".
Khái niệm cốt lõi
Pre-handoff checklist là một danh sách kiểm tra có cấu trúc mà bạn tự chạy qua trước khi bàn giao thiết kế cho engineering. Nó chia làm sáu nhóm lớn. Hãy coi mỗi nhóm là một "cửa" mà thiết kế phải đi qua.
1. Design completeness — Thiết kế có đầy đủ không?
Đây là nhóm quan trọng nhất và cũng bị bỏ sót nhiều nhất. Một màn hình "đẹp" trong Figma thường chỉ là happy path — trạng thái lý tưởng khi mọi thứ diễn ra hoàn hảo. Nhưng sản phẩm thật sống trong sự hỗn loạn.
Tất cả breakpoint. Nếu sản phẩm chạy trên mobile, tablet và desktop, bạn cần cả ba. Đừng giao mỗi bản desktop rồi bảo "mobile thì co lại là được". Co lại như thế nào? 3 cột thành 1 cột hay thành 2? Sidebar biến thành hamburger menu hay drawer? Nếu bạn không vẽ, engineer sẽ tự quyết — và thường sai.
Tất cả trạng thái (states). Với mỗi thành phần tương tác, hãy tự hỏi đủ bộ: default, hover, active/pressed, focus (rất hay quên, nhưng cực quan trọng cho accessibility và điều hướng bàn phím), disabled, loading, error, và empty. Một nút "Đăng nhập" không chỉ có một hình dạng — nó có bảy hình dạng.
Tất cả loại nội dung (content edge cases). Tên dài 40 ký tự thì sao? Giỏ hàng có 0 sản phẩm thì màn hình trông thế nào? Số tiền lên tới hàng tỷ đồng có bị tràn không? Avatar không có ảnh thì fallback ra sao? Đây là nơi mà thiết kế đẹp thường vỡ vụn ngoài đời thực.
2. Consistency — Thiết kế có nhất quán không?
Mọi màu, mọi khoảng cách, mọi kiểu chữ phải trỏ về design token / style / variable đã định nghĩa, không phải giá trị hardcode ngẫu hứng. Nếu bạn dùng #3A7BFF ở một chỗ và #3B7CFF ở chỗ khác vì gõ nhầm, engineer sẽ tạo ra hai biến màu khác nhau trong code. Chạy qua toàn bộ màn hình và kiểm tra: có chỗ nào dùng spacing 13px, 17px, 22px (lệch khỏi hệ 8) không? Có font size nào không nằm trong type scale không?
3. Structure & naming — Cấu trúc file có sạch không?
Layer đặt tên tử tế (không phải "Frame 427", "Group 12"), component dùng đúng từ library chứ không phải bản detach, Auto Layout được áp dụng để engineer hiểu được ý đồ responsive. File lộn xộn khiến Dev Mode trở nên vô dụng.
4. Assets — Tài nguyên đã sẵn sàng chưa?
Icon, hình ảnh, logo đã được đánh dấu export đúng định dạng chưa (SVG cho icon, PNG/WebP cho ảnh)? Có asset nào là ảnh bitmap dán tạm mà đáng lẽ phải là vector không?
5. Documentation — Có ghi chú đủ để giải thích cái không nhìn thấy được không?
Có những thứ pixel không nói được: hành vi khi bấm nút này dẫn tới đâu, validation rule của ô input (email phải đúng định dạng, mật khẩu tối thiểu 8 ký tự), thứ tự tab, nội dung microcopy chính xác, animation kéo dài bao lâu. Những thứ này cần annotation hoặc mô tả kèm theo.
6. Sign-off — Đã có người liên quan duyệt chưa?
Product Manager đã xác nhận đúng scope chưa? Đã có một designer khác review nhanh chưa? Nếu có phần liên quan tới nội dung pháp lý (điều khoản, chính sách), bộ phận liên quan đã xem chưa? Handoff không nên là lần đầu tiên PM nhìn thấy thiết kế.
Tình huống thực tế
Ví dụ 1 — Tiki và cái nút biến mất trên Android tầm trung
Một team tại một sàn thương mại điện tử lớn ở Việt Nam (bối cảnh tương tự Tiki) bàn giao màn hình "Chi tiết sản phẩm" mới. Designer chỉ vẽ trên khung 390px (iPhone 14). Trên Figma nút "Thêm vào giỏ" nằm cố định dưới đáy, trông rất ổn.
Khi lên thật, một lượng lớn người dùng Việt Nam dùng máy Android màn hình 360px và có thanh điều hướng ảo chiếm thêm không gian. Vì thiết kế không có breakpoint nhỏ và không ghi chú "nút này phải sticky, luôn nổi trên nội dung", engineer đã đặt nút theo luồng cuộn bình thường. Kết quả: trên khoảng 18% thiết bị, người dùng phải cuộn xuống cuối trang mới thấy nút mua. Tỷ lệ add-to-cart trên nhóm thiết bị đó thấp hơn 11% so với phần còn lại, và phải mất gần một sprint mới có người phát hiện nguyên nhân qua session replay.
Bài học: "Đầy đủ breakpoint" không phải là vẽ cho vui. Thiếu breakpoint nhỏ nhất và thiếu một dòng annotation về hành vi sticky đã tạo ra thất thoát doanh thu thực. Checklist buộc bạn hỏi: "Thiết bị nhỏ nhất mà người dùng của tôi thực sự dùng là gì?" — với Việt Nam thường là 360px, không phải 390px.
Ví dụ 2 — Grab và trạng thái loading bị bỏ quên
Một designer bàn giao luồng đặt xe: người dùng bấm "Tìm tài xế", màn hình chuyển sang bản đồ. Trong Figma có đúng hai màn: màn nhập điểm đến và màn "đã tìm thấy tài xế". Không có gì ở giữa.
Nhưng trong thực tế, việc tìm tài xế mất 5–20 giây. Vì thiết kế không có trạng thái loading (không skeleton, không spinner, không thông báo "Đang tìm tài xế gần bạn..."), engineer đã tự nhét một spinner xám mặc định của thư viện vào giữa màn hình trắng. Người dùng thấy màn hình treo cứng, nhiều người bấm back tưởng app lỗi, tạo ra các yêu cầu trùng lặp phía backend.
Bài học: Khoảng thời gian "ở giữa" — loading, chuyển tiếp, chờ đợi — là nơi trải nghiệm sống hay chết, và cũng là nơi designer hay bỏ quên nhất vì nó không "chụp ảnh đẹp" được. Trong checklist completeness, mỗi hành động bất đồng bộ (gọi API, upload, thanh toán) đều phải có trạng thái loading tương ứng được thiết kế rõ ràng, kèm thời gian dự kiến và fallback nếu quá lâu.
Ví dụ 3 — Startup fintech và cuộc "giằng co token"
Một startup fintech ở TP.HCM có 4 designer làm chung một design system. Trước khi có checklist, mỗi người handoff theo kiểu riêng. Một bạn dùng màu #1652F0 gõ tay, một bạn dùng token Primary/500 = #1A56F0. Hai giá trị lệch nhau một chút, mắt thường không thấy, nhưng trong code sinh ra hai biến. Sau ba tháng, codebase có 47 sắc thái xanh khác nhau cho cùng một thương hiệu.
Họ áp dụng một checklist bắt buộc với một mục duy nhất về consistency: "Chạy plugin kiểm tra — không còn màu/spacing/typography nào là giá trị rời (detached) ngoài token." Chỉ riêng luật này, sau hai sprint, số biến màu trong code giảm từ 47 xuống 6. Engineer bắt đầu tin tưởng file Figma đến mức họ generate code trực tiếp từ token mà không hỏi lại.
Bài học: Consistency trong checklist không phải là chuyện thẩm mỹ — nó là chuyện chi phí kỹ thuật. Mỗi giá trị hardcode trong Figma là một khoản nợ kỹ thuật (technical debt) mà engineer sẽ trả bằng thời gian và bằng bug.
Hướng dẫn từng bước
Đây là quy trình chạy checklist thực tế, từ lúc bạn "nghĩ mình đã xong" cho tới lúc thực sự bàn giao.
Bước 1 — Tạo một checklist tái sử dụng, không làm lại từ đầu mỗi lần. Đừng dựa vào trí nhớ. Lưu checklist thành một template: một trang Notion, một Figma page cố định trong file, hoặc một component "Handoff Checklist" đặt cạnh design. Mỗi dự án mới, bạn duplicate và tick.
Bước 2 — Quét completeness theo ma trận component × state. Với từng thành phần tương tác trên màn hình, kẻ một bảng: cột là các trạng thái (default/hover/focus/active/disabled/loading/error), hàng là các component (button, input, dropdown...). Đánh dấu ô nào đã có, ô nào thiếu. Ô trống là việc bạn còn phải làm.
Bước 3 — Quét breakpoint. Đặt cạnh nhau bản mobile, tablet, desktop của cùng một màn hình. Kiểm tra điểm chuyển đổi (breakpoint) chính xác ở đâu, layout thay đổi thế nào, và cả trường hợp nội dung dài/ngắn ở mỗi kích thước.
Bước 4 — Chạy plugin kiểm tra consistency. Dùng các plugin như Design Lint, Contrast, hoặc tính năng kiểm tra token có sẵn để tìm giá trị rời (detached), màu không đủ tương phản (contrast dưới 4.5:1 cho text thường), và layer thiếu style.
Bước 5 — Dọn cấu trúc file. Đổi tên layer có nghĩa, gom nhóm hợp lý, xóa các frame nháp/thử nghiệm hoặc chuyển chúng sang một page riêng tên "Archive" để không gây nhiễu.
Bước 6 — Đánh dấu asset để export. Chọn từng icon/ảnh cần export, set đúng định dạng và scale trong panel Export. Đảm bảo icon là vector SVG.
Bước 7 — Viết annotation cho phần vô hình. Ghi chú validation rule, luồng điều hướng, microcopy chính xác, thời lượng animation, thứ tự tab. Đặt chúng ngay cạnh vùng liên quan.
Bước 8 — Lấy sign-off. Gửi cho PM xác nhận scope, nhờ một đồng nghiệp review 15 phút. Chỉ khi tất cả ô đã tick, bạn mới gửi link handoff kèm một lời nhắn ngắn gọn nêu rõ: phạm vi, điểm cần chú ý, và những gì đã được duyệt.
Lỗi thường gặp & mẹo
Lỗi: Chỉ giao happy path. Đây là lỗi số một của junior. Bạn tự tin màn hình "xong" khi nó trông đẹp với dữ liệu mẫu hoàn hảo. Mẹo: mỗi lần thấy một danh sách, tự hỏi "danh sách rỗng thì sao, một phần tử thì sao, một nghìn phần tử thì sao". Mỗi lần thấy một nút gọi API, tự hỏi "loading đâu, lỗi đâu".
Lỗi: Quên trạng thái focus. Hover thì ai cũng nhớ vì nó "đẹp", nhưng focus (khi điều hướng bằng bàn phím hoặc trình đọc màn hình) thì hay bị bỏ. Đây không chỉ là chi tiết — thiếu focus state là một lỗi accessibility nghiêm trọng.
Lỗi: Coi checklist là thủ tục giấy tờ và tick cho có. Một checklist tick máy móc còn nguy hiểm hơn không có, vì nó tạo cảm giác an toàn giả. Mẹo: mỗi mục phải là một câu hỏi thật buộc bạn nhìn vào thiết kế, không phải một ô để đánh dấu.
Lỗi: Handoff là sự kiện một chiều "gửi rồi biến mất". Handoff tốt là bắt đầu một cuộc đối thoại, không phải kết thúc. Mẹo: sau khi gửi, chủ động dành 15–30 phút walkthrough cùng engineer thay vì chỉ dán link.
Mẹo: Đưa engineer vào sớm. Nếu bạn hỏi engineer "cái nào khó làm" từ giai đoạn thiết kế, checklist handoff của bạn sẽ ngắn hơn nhiều vì bạn đã tránh được những thứ bất khả thi ngay từ đầu.
Mẹo: Định nghĩa "Definition of Done" chung với team. Checklist chỉ mạnh khi cả team đồng ý nó là tiêu chuẩn tối thiểu. Biến nó thành một phần của quy trình, không phải sáng kiến cá nhân.
Bài tập thực hành
Bài 1 — Tự viết checklist của riêng bạn. Dựa trên sáu nhóm trong bài (completeness, consistency, structure, assets, documentation, sign-off), viết ra một checklist gồm 15–20 mục cụ thể phù hợp với loại sản phẩm bạn hay làm. Mỗi mục phải là một câu hỏi có thể trả lời có/không.
Bài 2 — Audit một màn hình cũ. Lấy một màn hình bạn đã thiết kế trước đây và tưởng là "đã xong". Chạy checklist vừa viết qua nó. Đếm xem bạn tìm thấy bao nhiêu lỗ hổng — thường junior sẽ tìm ra 8–12 thứ bị thiếu. Ghi lại từng cái.
Bài 3 — Dựng ma trận state. Chọn một component tương tác (ví dụ: ô input tìm kiếm có nút xóa). Vẽ đầy đủ mọi trạng thái: empty, đang gõ, có kết quả, không có kết quả, đang tải, lỗi mạng, disabled, focus bằng bàn phím. Đối chiếu với thiết kế gốc bạn từng làm để thấy mình đã bỏ sót bao nhiêu.
Bài 4 — Viết mẩu tin handoff. Soạn một đoạn tin nhắn handoff mẫu (5–7 dòng) gửi cho engineer, nêu: phạm vi màn hình, breakpoint đã có, những điểm cần chú ý đặc biệt, và trạng thái duyệt. Đây là kỹ năng giao tiếp cũng quan trọng ngang kỹ năng thiết kế.
Tóm tắt
Handoff checklist là tấm lưới an toàn cuối cùng biến "một thiết kế đẹp" thành "một thiết kế không thể triển khai sai". Nó xoay quanh sáu cửa: completeness (đủ breakpoint, đủ state, đủ edge case nội dung), consistency (mọi giá trị trỏ về token), structure (file sạch, đặt tên tử tế), assets (export đúng định dạng), documentation (ghi chú cho phần vô hình như validation, luồng, microcopy), và sign-off (PM và đồng nghiệp đã duyệt).
Ba câu chuyện thực tế — nút biến mất trên máy Android 360px, trạng thái loading bị bỏ quên khi tìm tài xế, và 47 sắc xanh trong codebase fintech — đều cho thấy cùng một điều: những gì bạn quên trong handoff không biến mất, chúng chỉ chuyển thành bug, thành thất thoát doanh thu, và thành nợ kỹ thuật mà engineer phải trả. Một designer trưởng thành được đo không phải bằng màn hình đẹp nhất họ vẽ được, mà bằng số lần engineer không phải quay lại hỏi "còn cái này thì sao?". Hãy biến checklist thành thói quen phản xạ, và bạn sẽ trở thành người mà mọi engineer đều muốn làm việc cùng.