Bài 44 — Spec Documents & Redlines (Legacy) — UI Design and Design Handoff

Mở đầu — vì sao bài này quan trọng

Nếu bạn mới vào nghề UI trong vài năm gần đây, rất có thể bạn chưa từng nghe ai nói tới từ "redline" — và bạn tưởng rằng việc bàn giao thiết kế cho lập trình viên luôn dễ dàng như bây giờ: mở Figma Dev Mode, click vào một element, đọc luôn được padding, màu, font, thậm chí copy được cả đoạn CSS. Nhưng thế giới không phải lúc nào cũng như vậy. Trước khoảng năm 2020, khi Figma tung ra Dev Mode và các công cụ inspect tự động chín muồi, designer phải làm một công việc thủ công, tỉ mỉ và tốn thời gian đến khó tin: tự tay vẽ chú thích lên ảnh thiết kế để "kể" cho developer biết từng con số.

Vậy tại sao một kỹ năng đã "cũ" lại đáng để bạn học? Vì ba lý do rất thực tế. Thứ nhất, rất nhiều công ty ở Việt Nam và Đông Nam Á vẫn còn dùng file Sketch cũ, file XD, hoặc thậm chí file Photoshop trong các dự án legacy (dự án đã tồn tại lâu) — nơi Dev Mode không giúp được gì. Thứ hai, khi bạn làm việc với đối tác gia công (outsourcing), khách nước ngoài, hoặc team không có license Figma trả phí, bạn vẫn phải biết cách đóng gói thông tin thiết kế thành một tài liệu ai cũng đọc được. Thứ ba — và quan trọng nhất — việc hiểu redline dạy cho bạn tư duy về thông tin nào là bắt buộc phải truyền đạt. Dev Mode làm hộ bạn phần hiển thị, nhưng nếu bạn không hiểu bản chất "developer cần biết những gì", bạn vẫn sẽ bàn giao thiếu sót. Học redline chính là học cách nghĩ như một cầu nối giữa design và code.

Khái niệm cốt lõi

Spec document và redline là gì

Spec document (tài liệu đặc tả) là một tài liệu mô tả đầy đủ cách một màn hình hoặc component phải được xây dựng: kích thước, khoảng cách, màu sắc, font chữ, hành vi tương tác, và các trạng thái (states). Nó là "hợp đồng" giữa designer và developer.

Redline (đường đỏ) là một phần cụ thể trong spec document: đó là ảnh thiết kế được phủ lên các đường kẻ và số đo — thường vẽ bằng màu đỏ hoặc hồng cánh sen để nổi bật trên nền giao diện. Cái tên "redline" xuất phát từ ngành in ấn và kỹ thuật, nơi người ta dùng bút đỏ để đánh dấu chỉnh sửa lên bản vẽ. Trong UI, redline trả lời câu hỏi: "Element này cách mép trái bao nhiêu pixel? Khoảng cách giữa hai nút là bao nhiêu? Padding trong ô input là mấy?"

Một redline đầy đủ cần chứa những gì

Đây là danh sách những thông tin mà một developer cần để dựng chính xác một màn hình, và cũng là những gì Dev Mode ngày nay tự động phơi ra cho bạn:

Kích thước (dimensions): chiều rộng và cao của mỗi khối, tính bằng pixel hoặc dp.
Khoảng cách (spacing): margin (khoảng cách bên ngoài) và padding (khoảng cách bên trong), cũng như gap giữa các phần tử.
Vị trí (positioning): element neo vào đâu, cách mép container bao xa, canh giữa hay canh trái.
Màu sắc (color): giá trị HEX hoặc RGBA của nền, chữ, viền. Nếu có opacity thì phải ghi rõ.
Typography: tên font, kích thước (font-size), độ đậm (font-weight), chiều cao dòng (line-height), và letter-spacing nếu có.
Border & radius: độ dày viền, màu viền, bán kính bo góc.
Shadow / elevation: thông số đổ bóng (offset x, y, blur, spread, màu).
Assets: icon và hình ảnh cần export ra định dạng gì (SVG, PNG @1x/@2x/@3x).
States & behavior: trạng thái hover, active, disabled, error — cái mà redline tĩnh vốn rất khó diễn tả và thường phải kèm ghi chú riêng.

Vì sao redline thủ công lại tốn kém đến vậy

Hãy hình dung quy trình cũ. Designer hoàn thành màn hình trong Sketch hoặc Photoshop. Sau đó họ phải: xuất ảnh màn hình ra, mở nó trong một công cụ như Zeplin, InVision Inspect, hoặc thậm chí vẽ tay bằng chính Sketch/Illustrator, rồi đặt từng nhãn số đo, từng mũi tên, từng ô chú thích màu lên đó. Một màn hình phức tạp có thể mất hàng giờ chỉ để làm redline. Tệ hơn, mỗi khi thiết kế thay đổi — mà thiết kế thì thay đổi liên tục — toàn bộ redline phải làm lại. Đây chính là lý do các công cụ như Zeplin (ra mắt 2014) và Avocode trở nên cực kỳ phổ biến: chúng tự động trích xuất số đo từ file thiết kế, giảm bớt phần vẽ tay. Nhưng ngay cả với chúng, designer vẫn phải chủ động "publish" file, tổ chức các artboard, và bổ sung ghi chú hành vi bằng tay.

Bối cảnh lịch sử: từ redline tới Dev Mode

Dòng thời gian ngắn gọn giúp bạn định vị: giai đoạn Photoshop/Illustrator (trước 2010) gần như hoàn toàn redline thủ công; Sketch (2010) mở ra kỷ nguyên công cụ chuyên UI nhưng handoff vẫn phải nhờ plugin và tool ngoài; Zeplin/InVision (2014–2016) tự động hóa việc đọc số đo; Figma (2016) đưa mọi thứ lên trình duyệt và cho phép developer tự inspect ngay trong file; và cuối cùng Figma Dev Mode (2023) biến việc đọc spec thành một trải nghiệm dành riêng cho developer với code snippet, so sánh phiên bản, và tích hợp thẳng vào codebase. Redline thủ công, về cơ bản, đã trở thành "di sản" (legacy) — nhưng di sản đó vẫn sống trong rất nhiều ngóc ngách của ngành.

Tình huống thực tế

Ví dụ 1 — Agency Hà Nội bảo trì app ngân hàng viết bằng file Sketch cũ

Một agency thiết kế ở Hà Nội (khoảng 25 người) ký hợp đồng bảo trì và mở rộng tính năng cho ứng dụng mobile của một ngân hàng thương mại. Toàn bộ design system của app được dựng từ năm 2019 bằng Sketch, với hơn 300 artboard. Ngân hàng vì lý do bảo mật không cho phép mang file lên Figma cloud, và cũng không cấp license Dev Mode cho team engineer của họ.

Kết quả là mỗi khi agency giao một màn hình mới, họ phải xuất file Sketch, chạy qua Zeplin (bản trả phí), rồi vẫn phải ngồi bổ sung redline thủ công cho những phần Zeplin đọc sai — đặc biệt là các component có auto-layout giả lập bằng nhóm (group) lồng nhau. Một bạn junior designer kể rằng riêng màn hình "chuyển khoản" đã tốn 4 giờ làm redline, vì có tới 6 trạng thái lỗi khác nhau (số dư không đủ, sai OTP, quá hạn mức...) mà mỗi trạng thái cần ghi chú riêng.

Bài học rút ra: Khi ràng buộc là bảo mật hoặc công cụ legacy, bạn không có lựa chọn nào ngoài việc làm redline tử tế. Kỹ năng tổ chức thông tin rõ ràng — nhóm các state lại, đánh số thứ tự, tách phần "layout" và phần "behavior" — quyết định việc developer mất 1 ngày hay 3 ngày để code xong.

Ví dụ 2 — Startup fintech ở TP.HCM bàn giao cho team dev Ấn Độ

Một startup fintech ở TP.HCM thuê một team phát triển ở Bangalore để dựng phiên bản web. Team dev không quen dùng Figma, làm việc lệch múi giờ 1,5 tiếng, và giao tiếp chủ yếu qua email theo lô (batch) vì chênh lệch thời gian. Designer trưởng nhận ra rằng nếu chỉ gửi link Figma, mỗi lần dev hiểu sai một con số là mất trọn một chu kỳ 24 giờ để hỏi–đáp.

Giải pháp của cô ấy là tạo một spec document PDF cho mỗi màn hình quan trọng: ảnh redline ở trên, kèm một bảng phía dưới liệt kê token (ví dụ spacing-md = 16px, color-primary = #0A66C2), và một cột "ghi chú hành vi" mô tả bằng lời điều gì xảy ra khi người dùng bấm nút. Nhờ đóng gói mọi thứ vào một tài liệu tự-chứa (self-contained), số vòng hỏi đáp giảm khoảng 60%, theo ước tính của cô. Điểm mấu chốt: tài liệu không phụ thuộc vào việc dev phải mở đúng công cụ hay có đúng quyền truy cập.

Bài học rút ra: Redline/spec document vẫn là công cụ tuyệt vời khi bạn làm việc bất đồng bộ (asynchronous) hoặc xuyên biên giới. Một tài liệu tĩnh, đầy đủ, đọc offline được đôi khi hiệu quả hơn một file "sống" đòi hỏi truy cập realtime.

Ví dụ 3 — Bàn giao thiếu state khiến developer dựng nhầm

Tại một công ty thương mại điện tử ở Đông Nam Á, một bạn designer mới ra trường gửi redline cho màn hình danh sách sản phẩm với đầy đủ số đo pixel rất đẹp. Nhưng bạn ấy chỉ vẽ trạng thái "có dữ liệu". Developer dựng đúng y hệt. Đến khi test, mới lòi ra: không ai định nghĩa màn hình trông thế nào khi chưa có sản phẩm nào (empty state), khi đang tải (loading), hay khi mất mạng (error). Developer đành tự chế, và kết quả là một màn hình trắng trơn xấu xí lọt tới tận bản demo cho khách.

Bài học rút ra: Redline chỉ giỏi mô tả những gì bạn vẽ ra. Nó im lặng về những gì bạn quên vẽ. Đây chính là điểm yếu chí mạng của handoff tĩnh, và là lý do phần "ghi chú hành vi" cùng danh sách state đầy đủ luôn quan trọng ngang với số đo.

Hướng dẫn từng bước

Giả sử bạn phải bàn giao một màn hình mà không dùng được Dev Mode (file legacy, hoặc dev không có quyền). Đây là quy trình tạo một spec document đáng tin cậy:

Chốt (freeze) thiết kế trước. Đừng bao giờ làm redline trên một thiết kế còn đang sửa. Xác nhận với team rằng bản này là bản cuối trước khi bỏ công chú thích, nếu không bạn sẽ phải làm lại từ đầu.

Chuẩn hóa theo hệ thống, không phải theo con số lẻ. Trước khi ghi "khoảng cách = 15px", hãy kiểm tra xem hệ spacing của bạn có phải bội số của 8 không (như bài về Spacing System đã dạy). Ghi token thay vì số thô: spacing-md thay cho 16px. Điều này giúp dev nhất quán và giảm lỗi.

Xuất ảnh nền sạch. Export màn hình ở độ phân giải @2x để nhìn rõ, đặt lên một canvas rộng có chừa lề trống hai bên để có chỗ đặt nhãn chú thích.

Vẽ đường đo và nhãn. Với mỗi khoảng cách quan trọng, kẻ một đường mảnh (thường màu đỏ/hồng), đặt con số ở giữa. Chú thích padding trong, margin ngoài, và gap giữa các nhóm. Đừng chú thích mọi khoảng cách — chỉ những cái không suy ra được từ hệ thống.

Lập bảng thông số. Bên dưới hoặc bên cạnh ảnh, tạo bảng liệt kê: màu (HEX + tên token), typography (font/size/weight/line-height), border-radius, shadow. Bảng dễ tra cứu hơn nhãn rải rác trên ảnh.

Mô tả states và behavior bằng lời. Đây là phần redline tĩnh không làm được. Liệt kê: default, hover, active, focus, disabled, error, empty, loading. Với mỗi state, mô tả điều gì thay đổi. Nếu có tương tác (bấm nút thì làm gì), viết rõ.

Ghi chú responsive. Nếu màn hình co giãn, chỉ rõ element nào giữ cố định, element nào giãn (dùng khái niệm constraints từ bài Figma Basics), breakpoint nào đổi layout.

Chỉ định asset. Đánh dấu icon/ảnh nào cần export, định dạng gì, ở những tỉ lệ nào. Tốt nhất là kèm luôn file asset đã export.

Đặt tên và version tài liệu. Ghi rõ "v1.2 — cập nhật 27/06" để không ai dùng nhầm bản cũ. Đây là nỗi đau lớn nhất của handoff tĩnh: file lỗi thời trôi nổi khắp nơi.

Lỗi thường gặp & mẹo

Lỗi 1: Chú thích quá nhiều, gây nhiễu. Người mới thường sợ thiếu nên đo mọi thứ, khiến ảnh chi chít số. Developer giỏi không cần bạn ghi rằng hai element cách nhau 16px nếu cả hệ thống đã theo lưới 8px và điều đó hiển nhiên. Chỉ chú thích cái đặc biệt hoặc dễ đoán sai.

Lỗi 2: Ghi số thô thay vì token. Ghi #0A66C2 mười lần trên mười màn hình, đến khi brand đổi màu, không ai biết đường nào mà lần. Luôn ưu tiên ghi tên token/biến, và để bảng token là nguồn chân lý duy nhất.

Lỗi 3: Quên state và edge case. Như ví dụ 3 đã cho thấy — thiếu empty/loading/error là lỗi phổ biến nhất và tốn kém nhất. Tự hỏi: "Nếu không có dữ liệu thì sao? Nếu chuỗi chữ dài gấp ba thì sao?"

Lỗi 4: Không cập nhật redline sau khi sửa design. Một redline sai còn tệ hơn không có redline, vì nó khiến dev tin vào con số sai. Nếu bạn không kịp cập nhật, hãy nói rõ "phần này tham chiếu file gốc" thay vì để số cũ.

Mẹo thoát ly redline thủ công: Nếu tổ chức của bạn còn kẹt trong quy trình redline tay, hãy dùng đây làm lý lẽ chuyển sang Figma Dev Mode hoặc chí ít là Zeplin. Hãy tính thử: nếu một designer mất trung bình 2 giờ/màn hình cho redline, và team làm 40 màn hình/tháng, đó là 80 giờ — tương đương nửa tháng công. Con số đó thường đủ sức thuyết phục quản lý đầu tư công cụ.

Mẹo về tư duy: Ngay cả khi dùng Dev Mode, hãy giữ thói quen tự hỏi "developer có đủ thông tin để dựng đúng không?". Dev Mode phơi ra số đo, nhưng nó không tự nghĩ hộ bạn về hành vi, edge case, và ý đồ thiết kế. Tư duy redline vẫn còn nguyên giá trị.

Bài tập thực hành

Bài 1 — Tạo một redline hoàn chỉnh bằng tay. Chọn một component quen thuộc (ví dụ một thẻ sản phẩm — product card). Export ảnh, rồi trong Figma/Sketch tự vẽ redline đầy đủ: mọi khoảng cách quan trọng, bảng màu, bảng typography, và danh sách state. Đặt mục tiêu để một người không nhìn thấy file gốc vẫn dựng lại được y hệt.

Bài 2 — So sánh với Dev Mode. Mở đúng component đó trong Figma Dev Mode và đối chiếu. Bạn đã bỏ sót thông tin gì mà Dev Mode có? Ngược lại, có thông tin nào bạn ghi được (như ý đồ hành vi) mà Dev Mode không tự sinh ra? Viết ra 5 điểm khác biệt.

Bài 3 — Đóng gói spec document. Chuyển redline ở bài 1 thành một file PDF một trang tự-chứa, như designer ở ví dụ 2 đã làm: ảnh trên, bảng token dưới, cột ghi chú behavior bên cạnh. Gửi cho một người bạn học code thử và hỏi họ điểm nào còn mơ hồ — đó chính là những lỗ hổng handoff của bạn.

Tóm tắt

Redline và spec document là kỹ năng nền tảng của kỷ nguyên "tiền Dev Mode": designer phải tự tay chú thích kích thước, màu sắc, font và hành vi lên ảnh thiết kế để developer dựng đúng. Dù Figma Dev Mode ngày nay đã tự động hóa phần lớn việc đọc số đo, kỹ năng này vẫn sống trong các dự án legacy (file Sketch/XD/PSD cũ), các bối cảnh bảo mật ngặt nghèo, và làm việc bất đồng bộ xuyên biên giới — những tình huống rất thật ở Việt Nam và Đông Nam Á. Quan trọng hơn cả công cụ, redline dạy bạn tư duy về thông tin nào bắt buộc phải truyền đạt: không chỉ số đo, mà cả states, edge case và ý đồ thiết kế — những thứ không công cụ nào nghĩ hộ bạn. Hãy ưu tiên ghi token thay vì số thô, đừng chú thích nhiễu, luôn phủ đủ các trạng thái, và giữ tài liệu có version rõ ràng. Nắm được bản chất này, dù bạn dùng redline tay hay Dev Mode hiện đại, bàn giao của bạn sẽ luôn sạch sẽ và đáng tin cậy.