Figma

Công cụ thiết kế chạy thẳng trong trình duyệt, không cần cài, mở link là thấy. Điểm làm nó chiếm lĩnh thị trường là chuyện nhiều người xem và sửa cùng lúc trên một file — designer kéo thả bên này, BA comment bên kia, dev mở tab khác lấy thông số. Bài này không dạy bạn thiết kế. Bạn là BA, việc của bạn là đọc, hỏi đúng chỗ và lấy được thông tin để viết tài liệu.

BA không cần biết vẽ trong Figma. BA cần biết đọc file, comment đúng chỗ và lấy được spec.

BA cần biết đúng mấy thứ này

• Frame và page. Một file có nhiều page (thường chia theo module), mỗi page chứa nhiều frame (mỗi frame là một màn hình). Nhớ tên frame để trích dẫn trong tài liệu: [Đơn hàng / DH-03 Chi tiết đơn].
• Comment. Bấm phím C rồi click vào đúng vị trí trên màn hình để đặt bình luận neo tại chỗ đó. Comment neo vào phần tử luôn tốt hơn nhắn Zalo "cái nút ở màn kia sai rồi". Tag người bằng @, và nhớ bấm Resolve khi đã xử lý xong.
• Link chia sẻ. Copy link khi đang chọn một frame thì người nhận mở ra sẽ nhảy đúng frame đó, khỏi phải mô tả "màn thứ ba từ trên xuống, cột bên phải" trong lúc mười người đang chờ.
• Chế độ Present: bấm nút play để mở bản bấm được, gửi link đó cho khách thay vì gửi ảnh chụp.
• Version history. Xem file đã bị sửa gì, ngày nào, bởi ai. Đây là cứu cánh khi thiết kế bị đổi sau lưng và không ai báo.
• Dev Mode. Chế độ dành cho người triển khai: chọn một phần tử là thấy kích thước, khoảng cách, mã màu, cỡ chữ, và tải được icon. Lưu ý về ghế ngồi: Dev Mode đầy đủ cần ghế trả phí (Dev seat hoặc Full seat). Nếu bạn chỉ được cấp quyền xem thì vẫn đọc được kích thước, copy được mã CSS và tải được icon ở chế độ inspect, nhưng không có annotation hay bộ lọc ready-for-dev. Hỏi xin ghế từ đầu dự án, đừng để tới hôm ngồi viết đặc tả mới phát hiện.

Lấy spec để viết tài liệu

Đây là phần BA dùng nhiều nhất. Quy trình mình hay làm khi viết đặc tả cho một màn:

1. Mở Dev Mode, chọn từng ô nhập, ghi lại: nhãn hiển thị, kiểu dữ liệu, độ dài tối đa nếu thấy được, có bắt buộc không.
2. Chụp frame ở tỷ lệ 100%, chèn vào tài liệu, đánh số các thành phần bằng chú thích của riêng mình. Đừng chỉ dán ảnh trần.
3. Lập bảng đặc tả trường: STT, tên trường, kiểu, bắt buộc, quy tắc validate, thông báo lỗi, nguồn dữ liệu. Figma cho bạn ba cột đầu, bốn cột sau là việc của BA.
4. Liệt kê các trạng thái mà thiết kế chưa có: rỗng, đang tải, lỗi mạng, không có quyền. Hỏi designer ngay bằng comment, đừng để dev tự nghĩ.
5. Ghi rõ trong tài liệu: tên file Figma, tên frame, ngày chốt. Vì file Figma vẫn sẽ tiếp tục thay đổi.

Ví dụ thực tế

Dự án outsourcing cho một khách nước ngoài, 8 tuần, giao tiếp qua email và một buổi họp mỗi tuần. Designer bên khách sửa Figma bất cứ lúc nào và không ai thông báo.

Tuần thứ năm, dev VN code xong màn hồ sơ khách hàng theo bản thiết kế họ mở hôm thứ Hai. Đến buổi review, bên khách nói thiếu hai trường. Mở version history ra thì đúng là bản thiết kế đã bị sửa vào chiều thứ Tư, thêm hai trường, không comment, không email.

Sau vụ đó team đặt luật: mỗi đợt bàn giao, BA duplicate page thành bản đóng băng đặt tên theo dạng Sprint 6 - FROZEN, chụp ảnh các frame kèm vào tài liệu, và mọi thay đổi sau mốc đó phải mở comment. Mất 20 phút mỗi sprint, đổi lại hết cãi nhau.

Lỗi hay gặp

• Tưởng thiết kế là bất biến. Không có bản đóng băng thì hôm nay dev nhìn một kiểu, mai một kiểu.
• Comment thả vào chỗ trống, nổi lơ lửng cạnh frame, chẳng ai biết đang nói về phần tử nào.
• Chỉ nhìn màn desktop. Khách dùng điện thoại là chính mà cả team review trên màn 27 inch, tới lúc mở trên máy thật mới thấy bảng bảy cột không nhét vừa vào đâu cả.
• Chép nguyên chữ trên thiết kế vào tài liệu mà không kiểm — chữ trong mockup nhiều khi là chữ mẫu designer gõ tạm.

Lỗi cuối thì thuộc về phép lịch sự hơn là kỹ thuật. Đưa link file gốc cho người dùng nghiệp vụ, họ mở ra thấy trăm frame lộn xộn rồi hoảng, buổi góp ý hỏng ngay từ phút đầu. Gửi link Present của đúng luồng cần xem.