Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa hoàn thành một màn hình checkout tuyệt đẹp trong Figma. Bạn tự hào gửi link cho developer và nói: "Anh xem file này nha". Ba ngày sau, sản phẩm chạy trên staging và bạn nhận ra: padding của nút "Thanh toán" bị lệch 4px, màu chữ không đúng token, và khoảng cách giữa các dòng trong form thì "gần đúng" nhưng không hề đúng. Bạn thở dài, mở một file mới, gõ redline thủ công, chú thích từng con số, rồi gửi lại. Tuần sau, cùng một câu chuyện lặp lại ở màn hình khác.
Đây là nỗi đau kinh điển của quá trình handoff (bàn giao thiết kế cho lập trình). Trước năm 2023, designer và developer sống ở hai thế giới: một bên đo đạc bằng mắt và trực giác, một bên đọc CSS bằng logic. Cầu nối giữa hai bên hoặc là những công cụ bên thứ ba như Zeplin, Avocode, hoặc là những file spec dài lê thê mà không ai muốn cập nhật.
Figma Dev Mode ra đời để giải quyết chính xác nỗi đau này. Đây không phải là một tính năng "hay ho để có", mà là thay đổi căn bản trong cách designer và developer làm việc cùng nhau. Với vai trò là một UI Designer, hiểu Dev Mode không chỉ giúp bạn bàn giao nhanh hơn, mà còn nâng vị thế của bạn lên: bạn trở thành người thiết kế "có tư duy kỹ thuật", người mà developer thích làm việc cùng. Bài này sẽ cho bạn cái nhìn tổng quan về Dev Mode — nó là gì, hoạt động ra sao, và làm sao để tận dụng nó một cách chuyên nghiệp. Các bài sau (Annotations, Motion Specs, Asset Export, Handoff Checklist) sẽ đào sâu từng phần; còn bài này là bức tranh toàn cảnh bạn cần nắm trước tiên.
Khái niệm cốt lõi
Dev Mode là gì?
Dev Mode là một "chế độ xem" (view mode) chuyên biệt trong Figma, được thiết kế dành riêng cho developer. Khi bạn bật Dev Mode (nút gạt ở góc trên bên phải, hoặc phím tắt Shift + D), giao diện Figma biến hình: các công cụ vẽ vời biến mất, thay vào đó là những công cụ để đọc thiết kế — đo kích thước, lấy màu, sao chép giá trị spacing, và xuất code.
Điểm mấu chốt cần hiểu: Dev Mode là chế độ read-only (chỉ đọc) đối với người dùng ở seat "Dev". Developer mở file trong Dev Mode không thể vô tình kéo lệch một layer, xóa một component, hay chỉnh sai một màu. Thiết kế được bảo vệ. Đây là điều mà designer nào cũng biết ơn — vì trước đây, việc "cho developer quyền chỉnh file gốc" luôn là quả bom hẹn giờ.
Ba trụ cột của Dev Mode
Để nắm tổng quan, bạn nên nhìn Dev Mode qua ba trụ cột chính:
1. Inspect panel (bảng kiểm tra) — trái tim của Dev Mode. Khi developer chọn một phần tử, panel bên phải hiển thị mọi thứ họ cần: kích thước (width, height), khoảng cách (padding, gap, margin), màu sắc, typography, border radius, shadow. Quan trọng hơn, các giá trị này được xuất ra dưới dạng code snippet — CSS cho web, hoặc SwiftUI/Compose cho mobile. Developer chỉ cần chọn và sao chép. Không còn cảnh ngồi đoán "khoảng này chắc 16px".
2. Ready for Dev — hệ thống trạng thái. Một file Figma thường có hàng chục frame ở đủ trạng thái: nháp, đang sửa, đã duyệt. Dev Mode cho phép designer đánh dấu một section hoặc frame là "Ready for dev" (sẵn sàng để code). Developer nhìn vào là biết ngay cái nào chốt, cái nào còn động. Figma còn có section với dấu tick xanh, và tính năng compare changes (so sánh thay đổi) — nếu bạn sửa thiết kế sau khi đã đánh dấu ready, developer thấy được đúng phần nào đã đổi.
3. Liên kết với code thật — Dev Mode không sống một mình.
Dev Mode kết nối với Code Connect (ánh xạ component Figma sang component code thật trong design system), tích hợp với các plugin như Storybook, GitHub, Jira, Linear. Nghĩa là developer không chỉ thấy "một cái nút màu xanh", mà thấy "đây là component <Button variant='primary'> trong repo của chúng ta". Đây là bước tiến lớn nhất: từ mô tả trực quan sang mã nguồn có thật.
Dev Mode khác gì với chế độ xem thông thường?
Trước Dev Mode, developer vẫn có thể mở panel "Inspect" trong Figma bản cũ. Nhưng nó nghèo nàn: chỉ có vài giá trị CSS thô, không có khái niệm "ready", không có so sánh thay đổi, không có liên kết code. Dev Mode là một môi trường làm việc hoàn chỉnh chứ không chỉ là một cái panel. Nó giống như sự khác biệt giữa "xem bản vẽ nhà" và "đứng trong công trường có đầy đủ dụng cụ đo đạc".
Về licensing — điều thực tế cần biết
Cần lưu ý về mặt tài chính: từ 2024, để dùng đầy đủ Dev Mode (đặc biệt phần inspect nâng cao và Code Connect), tài khoản cần Dev seat hoặc Full seat trên gói trả phí. Đây là điều bạn nên trao đổi rõ với team/công ty ngay từ đầu, để tránh cảnh developer háo hức mở file rồi phát hiện bị chặn tính năng.
Tình huống thực tế
Ví dụ 1 — Startup fintech Việt: từ 5 vòng sửa xuống 1
Công ty giả định "MoMo-lite" — một startup ví điện tử ở TP.HCM với đội ngũ 3 designer và 8 developer. Trước khi dùng Dev Mode, quy trình bàn giao màn hình "Nạp tiền" của họ như sau: designer gửi link file, developer tự đo bằng mắt, code xong đẩy lên staging, designer review và ghi chú "nút này lệch", "màu này sai", "chữ nhỏ quá". Trung bình mỗi màn hình phải qua 4–5 vòng qua lại, mất khoảng 6 ngày.
Sau khi áp dụng Dev Mode một cách bài bản — designer đánh dấu "Ready for dev" cho từng section, developer inspect trực tiếp và copy đúng giá trị token — con số này giảm xuống còn 1–2 vòng, thời gian bàn giao rút còn khoảng 2 ngày. Bài học: giá trị lớn nhất của Dev Mode không nằm ở việc "copy CSS nhanh hơn", mà ở chỗ nó loại bỏ khâu đoán mò. Khi developer không phải đoán, số lỗi do hiểu sai giảm mạnh, và designer đỡ tốn thời gian review lặt vặt.
Ví dụ 2 — Agency ở Đà Nẵng và bài học "file bừa bộn"
Một agency thiết kế tại Đà Nẵng nhận dự án redesign website cho một chuỗi cà phê. Họ bật Dev Mode, tự tin rằng "có Dev Mode là handoff xong". Nhưng developer bên khách hàng liên tục phàn nàn: layer đặt tên "Frame 217", "Group 8", "Rectangle copy 3"; nhiều phần tử không dùng Auto Layout nên khi inspect ra padding rời rạc, không có gap rõ ràng; màu thì hardcode chứ không dùng variable.
Kết quả: Dev Mode có bật, nhưng phần inspect cho ra một mớ giá trị rối rắm, developer vẫn phải hỏi lại từng chi tiết. Bài học đắt giá ở đây: Dev Mode chỉ tốt bằng chất lượng file bạn đưa vào nó. Nếu thiết kế của bạn dùng Auto Layout gọn gàng (Bài 11), có design tokens (Bài 14), đặt tên layer tử tế (Bài 34), thì Dev Mode phát huy tối đa. Ngược lại, nó chỉ phản chiếu sự lộn xộn của file gốc. Dev Mode là cái loa khuếch đại — khuếch đại cả cái tốt lẫn cái xấu.
Ví dụ 3 — Team product ở Singapore và Code Connect
Một team product tại Singapore (khoảng 15 kỹ sư) dùng React với design system nội bộ. Họ cấu hình Code Connect để mỗi component trong Figma (Button, Input, Card) ánh xạ trực tiếp tới component tương ứng trong repo. Khi developer inspect một nút trong Dev Mode, thay vì thấy CSS thô, họ thấy đúng dòng: <Button variant="primary" size="md">Continue</Button>.
Tác động: một kỹ sư frontend junior mới vào có thể tự dựng màn hình mà không cần hỏi senior "component này tên gì trong codebase". Onboarding nhanh hơn, và code sinh ra nhất quán với design system thay vì mỗi người viết một kiểu. Bài học: Dev Mode ở mức cơ bản đã hữu ích, nhưng khi kết hợp Code Connect, nó chuyển từ "công cụ đo đạc" thành "cầu nối trực tiếp giữa file thiết kế và mã nguồn". Đây là đích đến mà các team trưởng thành hướng tới.
Hướng dẫn từng bước
Đây là quy trình cơ bản để bạn — với vai trò designer — chuẩn bị và làm việc với Dev Mode:
Bước 1 — Dọn file trước khi bàn giao. Trước khi nghĩ đến Dev Mode, hãy đảm bảo file "sạch": đặt tên layer có nghĩa (VD "btn-primary" thay vì "Rectangle 5"), dùng Auto Layout cho mọi thành phần có padding/gap, và bind màu-typography vào variables/styles. Đây là 80% giá trị của một lần handoff tốt.
Bước 2 — Bật Dev Mode để tự kiểm tra. Nhấn Shift + D hoặc gạt nút "Dev Mode" ở góc trên phải. Bạn sẽ thấy file qua con mắt của developer. Hãy chọn thử vài phần tử và xem panel Inspect: giá trị có gọn không? Padding có ra số đẹp (8, 16, 24) hay ra số lẻ (13, 17, 22)? Nếu ra số lẻ, quay lại sửa — vì developer sẽ thấy đúng những gì bạn thấy.
Bước 3 — Đánh dấu "Ready for dev". Chọn frame hoặc section đã chốt, mở menu chuột phải hoặc panel bên phải, chọn "Mark as ready for dev". Section sẽ có dấu tick. Chỉ đánh dấu những gì thật sự đã duyệt — đừng đánh dấu bừa, vì developer tin vào dấu này.
Bước 4 — Kiểm tra phần code snippet. Trong Inspect panel, chọn ngôn ngữ phù hợp với team (CSS, iOS, Android). Đọc lướt xem code sinh ra có hợp lý không. Nếu team dùng Tailwind hay design system riêng, hãy trao đổi để cài plugin hoặc Code Connect tương ứng.
Bước 5 — Bổ sung annotation cho những chỗ cần giải thích. Với các phần có logic đặc biệt (trạng thái hover, điều kiện hiển thị, responsive), thêm annotation ngay trong Dev Mode. Phần này sẽ được đào sâu ở Bài 43, nhưng ở mức tổng quan, hãy nhớ: Dev Mode cho developer biết "cái gì", còn annotation của bạn giải thích "tại sao" và "khi nào".
Bước 6 — Chia sẻ và hướng dẫn developer. Gửi link file. Nếu developer chưa quen, chỉ họ nút bật Dev Mode và cách chọn component để inspect. Một buổi walkthrough 15 phút ban đầu tiết kiệm hàng giờ hỏi đáp về sau.
Lỗi thường gặp & mẹo
Lỗi 1 — Tưởng Dev Mode thay thế được giao tiếp. Nhiều designer nghĩ "bật Dev Mode xong là developer tự hiểu hết". Sai. Dev Mode truyền tải giá trị đo đạc, không truyền tải ý định thiết kế. Vì sao nút này to hơn, vì sao form này chia hai cột trên desktop nhưng một cột trên mobile — những điều đó vẫn cần bạn nói/ghi chú. Dev Mode là công cụ hỗ trợ giao tiếp, không phải thay thế nó.
Lỗi 2 — Bàn giao file bừa bộn. Như ví dụ agency Đà Nẵng: layer không tên, không Auto Layout, màu hardcode. Mẹo: coi việc "dọn file" là một phần bắt buộc của handoff, không phải việc làm thêm.
Lỗi 3 — Đánh dấu "Ready for dev" rồi vẫn sửa lung tung. Nếu bạn đổi thiết kế sau khi đã đánh dấu ready mà không báo, developer có thể code theo bản cũ. Mẹo: dùng tính năng Compare changes của Dev Mode để developer thấy đúng phần đã đổi, và luôn báo một câu trong kênh chat khi có thay đổi sau khi đã ready.
Lỗi 4 — Không thống nhất về seat/license. Developer mở file phát hiện bị chặn tính năng vì không có Dev seat. Mẹo: xác nhận licensing với team ngay từ đầu dự án.
Lỗi 5 — Bỏ qua đơn vị và nền tảng. Web dùng px/rem, iOS dùng pt, Android dùng dp. Nếu team làm mobile mà bạn chỉ để CSS px, developer phải tự quy đổi. Mẹo: chọn đúng ngôn ngữ/nền tảng trong Inspect panel, và nếu làm cross-platform, trao đổi rõ về đơn vị.
Mẹo vàng: Trước mỗi lần bàn giao lớn, hãy tự mình ngồi vào ghế developer trong 10 phút: bật Dev Mode, giả vờ mình chưa biết gì về thiết kế này, và thử "đọc" nó. Chỗ nào bạn thấy khó hiểu, developer cũng sẽ thấy khó. Sửa trước khi họ hỏi.
Bài tập thực hành
- Trải nghiệm chuyển chế độ: Mở một file Figma bất kỳ của bạn, nhấn Shift + D để bật Dev Mode. Chọn 5 phần tử khác nhau và ghi lại: kích thước, padding, màu, typography mà Inspect panel hiển thị. Bạn có bất ngờ với con số nào không?
- Săn số lẻ: Trong file đó, tìm 3 chỗ mà Dev Mode cho ra giá trị "xấu" (padding 13px, gap 17px, radius 7px...). Quay lại chế độ Design, sửa chúng về hệ số 8 (Bài 9). Bật lại Dev Mode để xác nhận đã sạch.
- Đánh dấu Ready: Chọn một frame đã hoàn thiện, đánh dấu "Mark as ready for dev". Sau đó cố tình đổi màu một nút, rồi dùng Compare changes để xem Figma báo thay đổi thế nào.
- Đóng vai developer: Gửi link Dev Mode của một màn hình cho một người bạn không biết gì về thiết kế đó. Nhờ họ mô tả lại: nút chính màu gì, khoảng cách giữa các phần bao nhiêu. Nếu họ mô tả sai, đó là dấu hiệu file của bạn chưa đủ rõ.
- So sánh trước/sau: Viết ngắn (5–7 dòng) so sánh quy trình handoff cũ của bạn (nếu có) với quy trình dùng Dev Mode. Khâu nào tiết kiệm được nhiều thời gian nhất?
Tóm tắt
Dev Mode là chế độ xem read-only trong Figma dành riêng cho developer, biến file thiết kế thành một môi trường inspect chuyên nghiệp. Ba trụ cột cần nhớ: Inspect panel cho giá trị đo đạc và code snippet chính xác; hệ thống Ready for dev giúp phân biệt cái đã chốt với cái còn động; và liên kết code thật (Code Connect, tích hợp Storybook/GitHub) đưa handoff từ mô tả trực quan sang mã nguồn có thật.
Nhưng thông điệp quan trọng nhất là: Dev Mode chỉ tốt bằng chất lượng file bạn đưa vào. Auto Layout gọn gàng, design tokens đầy đủ, đặt tên layer tử tế — đó mới là nền móng. Dev Mode khuếch đại chất lượng công việc của bạn, chứ không sửa hộ sự cẩu thả. Và nó là công cụ hỗ trợ giao tiếp, không thay thế giao tiếp: ý định thiết kế vẫn cần bạn giải thích. Nắm vững tổng quan này, bạn đã sẵn sàng để đào sâu vào annotation, motion specs và asset export ở các bài tiếp theo.