Mở đầu — vì sao bài này quan trọng
Bạn đã thiết kế một màn hình đẹp lung linh trên Figma. Màu sắc chuẩn, typography mượt mà, spacing cân đối. Bạn hài lòng, export ra link, gửi cho developer rồi… một tuần sau nhận lại bản code lệch hẳn so với thiết kế: nút bấm sai màu, chữ to hơn 2px, khoảng cách giữa các phần thì "tự chế", và component thì mỗi chỗ một kiểu. Bạn frustrated, dev cũng frustrated, và sản phẩm cuối cùng thì… không giống ai.
Đây là vấn đề kinh điển trong ngành: design → dev handoff — quá trình bàn giao thiết kế từ designer sang lập trình viên để biến nó thành sản phẩm chạy thật. Nó là cây cầu nối giữa "ý tưởng đẹp" và "sản phẩm thực". Cây cầu này nếu xây ẩu, mọi công sức thiết kế của bạn sẽ rò rỉ mất trên đường đi.
Ở Việt Nam, nơi nhiều team nhỏ, designer và dev ngồi cách nhau một cái bàn nhưng vẫn hiểu lầm nhau, kỹ năng handoff tốt chính là thứ phân biệt một junior designer "chỉ biết vẽ" với một designer chuyên nghiệp được dev tin tưởng. Một handoff mượt mà không chỉ tiết kiệm hàng chục giờ làm lại (rework), mà còn xây dựng uy tín của bạn trong team. Bài này sẽ dạy bạn cách chuẩn bị file, giao tiếp và bàn giao sao cho dev "code đúng ngay từ lần đầu".
Khái niệm cốt lõi
Handoff không phải là một hành động duy nhất — kiểu "gửi link rồi xong". Nó là một quy trình có chuẩn bị. Hãy nghĩ về nó giống như bàn giao một căn nhà: bạn không vứt chìa khóa cho người ta rồi đi, mà phải dọn dẹp, ghi chú "công tắc này điều khiển đèn nào", "đường ống nước ở đâu".
Handoff tốt = file sạch + thông tin đầy đủ + giao tiếp
Có ba trụ cột:
- File sạch (clean file): Loại bỏ frame thừa, đặt tên layer rõ ràng, tổ chức page hợp lý. Dev mở file ra phải thấy ngay cái gì là cái gì.
- Thông tin đầy đủ (specs): Màu, font, spacing, kích thước, behavior (hành vi khi hover, click, responsive)… phải có sẵn hoặc đọc được dễ dàng.
- Giao tiếp (communication): Một buổi walkthrough ngắn, hoặc các comment annotation giải thích những gì mắt thường không thấy được.
Dev Mode — công cụ handoff chính của Figma
Từ 2023, Figma ra mắt Dev Mode — một chế độ riêng cho developer. Khi dev bật Dev Mode (biểu tượng </> góc trên phải), họ thấy:
- Inspect panel: chọn một element là thấy ngay CSS tương ứng —
width,padding,color,font-size,border-radius… - Measurements: rê chuột giữa hai element thấy ngay khoảng cách bao nhiêu px.
- Code snippets: Figma tự sinh ra đoạn CSS (hoặc iOS/Android) gợi ý.
- Ready for dev: designer đánh dấu một frame/section là "sẵn sàng bàn giao", dev biết chỗ nào được chốt, chỗ nào còn đang vẽ.
Design tokens & variables — chìa khóa của handoff hiện đại
Đây là điểm then chốt nối với những gì bạn đã học ở bài Design Tokens. Khi bạn dùng Figma Variables cho màu (color/primary/500), spacing (space/4), typography — dev có thể map thẳng các token này sang biến CSS (--color-primary-500) hoặc Tailwind config. Sự nhất quán giữa tên token trong Figma và tên biến trong code chính là điều biến handoff từ "dịch thủ công" thành "ánh xạ 1-1".
Annotations — ghi chú những gì hình ảnh không nói được
Một số thứ developer không thể "nhìn ra" từ ảnh tĩnh: nút này dẫn đi đâu, khi loading thì hiện gì, list này sắp xếp theo tiêu chí nào, text dài quá thì truncate hay xuống dòng. Figma có công cụ Annotations trong Dev Mode để bạn ghim những ghi chú này trực tiếp lên element.
Tình huống thực tế
Ví dụ 1: Startup fintech tại TP.HCM và "2px địa ngục"
Một startup ví điện tử ở Quận 1 có team 4 người: 1 designer, 3 dev. Trong sprint đầu, designer giao màn hình "Lịch sử giao dịch" bằng cách gửi link Figma kèm câu "anh xem rồi code nha". Kết quả review: padding các dòng giao dịch trong code là 12px trong khi thiết kế là 16px; màu số tiền âm là #FF0000 đỏ chói trong code thay vì #E5484D đỏ dịu trong design.
Lý do? Dev không bật Dev Mode, mà ước lượng bằng mắt rồi gõ số tròn. Designer thì dùng màu hardcode, không có token nên dev cũng chẳng biết đâu là "màu chuẩn" của hệ thống. Mỗi màn hình mất trung bình 2 vòng sửa, nhân với 15 màn hình của MVP = gần một tuần rework.
Bài học: Sau sự cố, team áp dụng quy tắc: tất cả màu/spacing phải là Figma Variables, và dev bắt buộc lấy số từ Inspect panel chứ không ước lượng. Sprint sau, tỉ lệ "code đúng ngay lần đầu" tăng từ khoảng 40% lên hơn 85%.
Ví dụ 2: Agency outsource và buổi handoff 20 phút "cứu cả dự án"
Một agency ở Hà Nội nhận làm web cho khách Singapore. Team dev ở Đà Nẵng, designer ở Hà Nội — không ngồi cùng phòng, chênh múi giờ không nhiều nhưng giao tiếp chủ yếu qua chat. Ban đầu họ định "gửi file Figma là đủ". Lead designer quyết định làm khác: trước mỗi feature, tổ chức một buổi gọi video 20 phút, share màn hình Figma, click qua từng prototype, giải thích các state (empty, loading, error) và các edge case (tên người dùng quá dài, số tiền 0 đồng).
Kết quả: một component bảng giá có logic "nếu user đã mua gói thì nút đổi thành 'Gói hiện tại' và mờ đi" — thứ hoàn toàn không thấy được trên ảnh tĩnh — được dev nắm ngay trong buổi gọi. Nếu không có buổi walkthrough đó, dev sẽ phải đoán, code sai, rồi sửa qua 3-4 vòng chat lòng vòng.
Bài học: 20 phút giao tiếp đồng bộ (synchronous) tiết kiệm được nhiều ngày trao đổi bất đồng bộ (asynchronous) qua chat. Handoff không chỉ là file, mà là chuyển giao bối cảnh (context transfer).
Ví dụ 3: File "rác" và developer bỏ cuộc
Một bạn freelance designer giao file cho dev với 47 frame trong một page, trong đó 30 frame là bản nháp cũ, layer tên kiểu Frame 231, Rectangle 88, Group copy 3. Dev mở ra không biết frame nào là bản final. Bạn ấy ping designer hỏi từng cái một, designer thì đang bận. Cuối cùng dev code nhầm theo một frame nháp đã bỏ, đến lúc demo mới phát hiện sai cả màn hình.
Bài học: File bẩn không chỉ gây sai sót — nó phá vỡ niềm tin. Dev sẽ ngầm coi bạn là designer thiếu chuyên nghiệp. Việc dọn file mất bạn 30 phút, nhưng tiết kiệm cho dev hàng giờ mò mẫm và cứu danh tiếng của bạn.
Hướng dẫn từng bước
Đây là checklist handoff bạn nên chạy qua trước khi bấm nút "gửi cho dev":
Bước 1 — Dọn dẹp file (cleanup).
- Xóa hoặc đưa các frame nháp/khám phá (exploration) sang một page riêng tên
ArchivehoặcWIP. - Đảm bảo page chính chỉ chứa các màn hình final. Đặt tên page rõ:
Desktop,Mobile,Components. - Xóa các layer ẩn không dùng, các nhóm rỗng.
Frame 231→Card / Transaction Item.Rectangle 88→Button BG.- Dev đọc tên layer là hiểu cấu trúc component — điều này còn giúp họ đặt tên class/component trong code.
- Tất cả màu lặp lại → color variables. Spacing → number variables theo scale (4, 8, 12, 16…).
- Các element lặp lại (button, card, input) → biến thành component và publish vào library để dev truy cập được.
- Trong Dev Mode, chọn frame/section đã chốt → bật trạng thái Ready for dev. Dev biết chính xác chỗ nào an toàn để code.
- Ghi chú: link đích của nút, các state (hover/active/disabled), responsive behavior, cách xử lý text dài, dữ liệu rỗng.
- Nếu có animation/transition, mô tả thời lượng và kiểu easing (nối với bài Microinteractions).
- Đảm bảo các màn hình empty state, loading, error đều có trong file — đừng chỉ giao "happy path".
- Đặt một buổi gọi 15-20 phút. Click qua prototype, giải thích logic, edge case. Để dev hỏi tại chỗ.
- Handoff không kết thúc khi gửi file. Hãy sẵn sàng trả lời comment của dev trong suốt quá trình code, và review lại bản build để bắt sai lệch sớm.
Lỗi thường gặp & mẹo
Lỗi 1 — Hardcode mọi thứ thay vì dùng token. Khi mỗi màu là một hex riêng, dev không biết đâu là "màu hệ thống". Mẹo: trước handoff, dùng plugin để quét xem còn màu/spacing nào "rời rạc" (detached) không nằm trong variables.
Lỗi 2 — Chỉ giao happy path. Quên empty state, loading, error, dữ liệu dài bất thường. Dev sẽ tự bịa, và thường bịa xấu. Mẹo: với mỗi màn hình có dữ liệu động, luôn vẽ thêm tối thiểu 3 state.
Lỗi 3 — Spacing không theo hệ. Chỗ 13px, chỗ 17px, chỗ 22px. Dev không biết đó là cố ý hay tay run. Mẹo: ép mọi spacing vào scale 4px (4, 8, 12, 16, 24, 32…). Nhất quán quan trọng hơn "đẹp tuyệt đối".
Lỗi 4 — Giả định dev "biết tự hiểu". Designer hay nghĩ "cái này hiển nhiên mà". Không có gì hiển nhiên với người không vẽ ra nó. Mẹo: annotate dư còn hơn thiếu.
Lỗi 5 — Sửa file sau khi đã giao mà không báo. Bạn âm thầm chỉnh một frame, dev vẫn code theo bản cũ. Mẹo: dùng Ready for dev + thông báo rõ "frame X vừa update, version cũ đã archive".
Mẹo vàng — Nghĩ như developer. Trước khi giao, tự hỏi: "Nếu mình là dev mở file này lần đầu, mình có hiểu ngay không?". Một designer hiểu cơ bản về HTML/CSS, box model, Flexbox (những bài bạn đã học) sẽ giao file tốt hơn nhiều, vì bạn vẽ theo cách code biến thành được. Ví dụ: bạn biết một list nên là các item lặp lại với spacing đều, chứ không phải mỗi cái đặt thủ công lệch nhau.
Bài tập thực hành
- Audit file cũ: Mở một file Figma bất kỳ bạn từng làm. Đếm: bao nhiêu layer còn tên mặc định (
Frame,Rectangle,Group)? Bao nhiêu màu chưa thành variable? Ghi lại con số "trước", rồi dọn dẹp và ghi con số "sau".
- Tập dùng Dev Mode: Bật Dev Mode trên một thiết kế. Chọn một button, đọc CSS mà Figma sinh ra (
padding,border-radius,background). So sánh với CSS bạn nghĩ là đúng — có khớp không?
- Viết annotation: Lấy một màn hình có nút bấm và một danh sách dữ liệu. Viết ít nhất 5 annotation: nút dẫn đi đâu, state hover, điều gì xảy ra khi list rỗng, text quá dài xử lý thế nào, hành vi trên mobile.
- Vẽ đủ state: Chọn một màn hình "danh sách" (ví dụ: danh sách đơn hàng). Vẽ đủ 4 state: có dữ liệu, đang loading, rỗng, lỗi mạng.
- Mô phỏng walkthrough: Quay một video màn hình 5 phút, giả vờ bạn đang giải thích thiết kế cho một dev chưa từng thấy nó. Xem lại — bạn có giải thích được mọi behavior không, hay có chỗ ấp úng "à cái này thì… ờ"? Chỗ ấp úng chính là chỗ cần annotation.
Tóm tắt
Dev handoff là cây cầu biến thiết kế đẹp thành sản phẩm thật. Một handoff tốt đứng trên ba trụ: file sạch (dọn frame thừa, đặt tên layer rõ, dùng variables và components đã publish), thông tin đầy đủ (specs đọc được qua Dev Mode, annotation cho behavior và edge case, đủ các state), và giao tiếp (buổi walkthrough ngắn cộng kênh feedback liên tục).
Những câu chuyện từ startup fintech ở TP.HCM đến agency Hà Nội đều chỉ ra cùng một điều: vài chục phút chuẩn bị và giao tiếp tiết kiệm hàng ngày rework, đồng thời xây dựng uy tín của bạn với team dev. Đừng coi handoff là "ném file qua tường" — hãy coi nó là một phần của thiết kế. Designer giỏi không chỉ vẽ đẹp, mà còn giao đúng. Và mẹo lớn nhất luôn là: hãy nghĩ như developer trước khi bấm gửi.