Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm rất phổ biến trong ngành: "Figma là công cụ của designer, PM không cần đụng vào." Sự thật là PM hiện đại không thể né Figma. Bạn không cần biết vẽ icon, không cần hiểu auto-layout sâu như designer, nhưng bạn BẮT BUỘC phải biết đọc một file Figma, để lại comment đúng chỗ, theo dõi luồng màn hình (flow), và dùng nó như ngôn ngữ chung khi làm việc với cả design lẫn engineering.
Hãy hình dung thực tế: 9 giờ sáng, designer gửi cho bạn link một bản thiết kế màn hình thanh toán. Đến 9 giờ tối, engineer hỏi bạn "nút này khi nhấn xong thì hiện màn hình nào?". Nếu bạn không biết điều hướng trong Figma, bạn sẽ trở thành nút thắt cổ chai — mọi câu hỏi đều phải đợi designer trả lời, mà designer thì đang bận. Ngược lại, một PM thành thạo Figma có thể tự đọc flow, tự kiểm tra spec, và phản hồi trong vài phút.
Figma quan trọng với PM vì ba lý do. Thứ nhất, nó là nơi yêu cầu sản phẩm (requirement) được "vật chất hóa" thành thứ nhìn thấy được — chữ trên tài liệu dễ hiểu nhầm, còn màn hình thì rõ ràng. Thứ hai, Figma là nền tảng cộng tác real-time: comment, mention, version history đều nằm trong đó, giúp giảm hàng trăm tin nhắn qua lại trên chat. Thứ ba, đây là công cụ miễn phí ở mức cơ bản, được hầu hết startup và công ty công nghệ Việt Nam như Tiki, MoMo, VNG, Be dùng làm chuẩn — bạn không học thì sẽ tụt lại.
Bài này không dạy bạn thành designer. Nó dạy bạn dùng Figma đúng vai trò PM: để review thiết kế, để giao tiếp với team, và để biến ý tưởng sản phẩm thành thứ team có thể xây.
Khái niệm cốt lõi
Figma là gì dưới góc nhìn PM
Figma là công cụ thiết kế giao diện chạy trên trình duyệt (cloud-based), cho phép nhiều người cùng làm việc trên một file cùng lúc — giống như Google Docs nhưng cho thiết kế. Với PM, bạn cần phân biệt ba "chế độ" làm việc:
- Xem (View): bạn chỉ đọc, không sửa được. Đây là quyền phổ biến nhất cho PM. Bạn vẫn comment được.
- Bình luận (Can comment): thường gắn với gói trả phí, cho phép để lại comment có cấu trúc.
- Chỉnh sửa (Can edit): quyền của designer. PM hiếm khi cần, và càng không nên tự ý sửa thiết kế của designer.
Bốn thứ PM cần thành thạo
1. Đọc và điều hướng file. Dùng phím tắt cơ bản: phím cách (space) để di chuyển canvas, Ctrl/Cmd cộng cuộn để zoom, phím "Shift + 1" để xem toàn bộ file vừa màn hình, "Shift + 2" để zoom vào phần đang chọn. Bạn cần đọc được tên frame để biết màn hình nào nối với màn hình nào.
2. Comment có cấu trúc. Đây là kỹ năng PM dùng nhiều nhất. Nhấn phím "C" để vào chế độ comment, click vào đúng vị trí cần góp ý, gõ nội dung và @mention người liên quan. Comment trong Figma gắn vào TỌA ĐỘ cụ thể trên màn hình — đây là sức mạnh lớn nhất: thay vì nói "cái nút màu xanh ở đâu đó", bạn ghim thẳng vào nút đó.
3. Đọc spec để viết requirement. Ở chế độ "Dev Mode" hoặc khi click vào một phần tử, bạn xem được kích thước, màu sắc, khoảng cách, font. PM không cần đọc kỹ như engineer, nhưng cần biết kiểm tra: trạng thái lỗi (error state) đã có chưa, màn hình trống (empty state) đã thiết kế chưa, trạng thái loading ra sao.
4. Xem Prototype (luồng tương tác). Designer thường nối các màn hình thành prototype có thể bấm thử như app thật. Nhấn nút "Present" (biểu tượng play góc trên phải) để trải nghiệm flow như người dùng. Đây là cách nhanh nhất để bạn phát hiện luồng bị đứt hoặc thiếu màn hình.
Vòng đời một design review
Quy trình review thiết kế của PM thường đi theo 4 bước: (1) mở file, đi qua toàn bộ prototype; (2) để lại comment với @mention người chịu trách nhiệm; (3) designer/engineer phản hồi trong thread; (4) khi vấn đề được xử lý, resolve (đóng) thread đó. Việc resolve rất quan trọng — nó giữ file sạch và cho mọi người biết điều gì còn mở, điều gì đã xong.
Tình huống thực tế
Ví dụ 1: MoMo — Comment đúng chỗ cứu cả một sprint
Bối cảnh: Một PM tại nhóm thanh toán (giả định dựa trên cách các fintech Việt Nam vận hành) nhận bản thiết kế màn hình "Chuyển tiền" gồm 8 frame. Designer thiết kế đẹp, nhưng chỉ vẽ trường hợp chuyển tiền thành công.
Diễn giải: PM mở prototype, bấm thử và phát hiện ngay: không có màn hình khi số dư không đủ, không có trạng thái khi mạng yếu lúc đang xác thực OTP. Thay vì viết một email dài dòng mô tả "ở bước OTP nếu mạng lỗi...", PM nhấn phím C, ghim comment thẳng vào nút "Xác nhận" trên frame OTP: "@designer mình cần thêm error state khi OTP timeout sau 60 giây — user phải biết nên đợi hay gửi lại. Có khoảng 3% giao dịch rơi vào case này theo log tháng trước." Cô cũng @mention engineer lead để anh này nắm rằng sẽ có thêm 2 màn hình.
Bài học: Comment ghim đúng tọa độ cộng số liệu cụ thể (3%) biến một góp ý mơ hồ thành yêu cầu rõ ràng, có sức thuyết phục. Designer bổ sung trong cùng ngày, tránh được việc phát hiện thiếu màn hình lúc engineer đã code xong — thời điểm mà chi phí sửa cao gấp nhiều lần.
Ví dụ 2: Startup giao đồ ăn — Dùng Present để align cả team trong 15 phút
Bối cảnh: Một startup giao đồ ăn ở TP.HCM với team 12 người chuẩn bị làm tính năng "Đặt nhóm" (group order — nhiều người cùng đặt chung một đơn). Trước đây team họp 1 tiếng vẫn cãi nhau vì mỗi người tưởng tượng flow khác nhau.
Diễn giải: PM yêu cầu designer dựng prototype bấm được, rồi trong buổi standup, anh share màn hình, nhấn "Present" và cho cả team bấm thử như user thật: tạo nhóm → gửi link mời → bạn bè thêm món → chủ nhóm chốt đơn. Trong lúc trải nghiệm, một engineer phát hiện: "Nếu bạn bè thêm món sau khi chủ nhóm đã chốt thì sao?" — một edge case không ai nghĩ ra khi chỉ nhìn tài liệu chữ. PM ghim luôn comment vào frame đó để theo dõi.
Bài học: Một prototype bấm được nói nhiều hơn 10 trang tài liệu. Khi cả team "chạm" được sản phẩm trước khi code, các lỗ hổng logic lộ ra sớm. PM không cần tự dựng prototype, nhưng phải biết yêu cầu nó và biết cách present nó.
Ví dụ 3: Đội B2B SaaS — Khi PM tự ý sửa Figma gây hỗn loạn
Bối cảnh: Một công ty SaaS làm phần mềm quản lý kho cho doanh nghiệp. PM mới vào nghề, sốt ruột vì designer bận, nên xin quyền edit và tự tay đổi chữ trên vài nút cho "nhanh".
Diễn giải: Vấn đề là PM đổi chữ trực tiếp trên component gốc, khiến hàng chục màn hình khác dùng chung component đó cũng bị đổi theo — gồm cả những màn hình đã được duyệt và đang chờ engineer code. Engineer code theo bản cũ, designer thì bối rối không hiểu sao thiết kế "tự" thay đổi. Phải mất nửa ngày dùng version history để khôi phục.
Bài học: PM nên comment, KHÔNG nên edit. Nếu cần đổi text, hãy comment đề xuất và để designer thực hiện. Figma có cơ chế component (thành phần dùng lại) mà nếu không hiểu, một thay đổi nhỏ có thể lan ra toàn file. Biết ranh giới vai trò là một phần của sự chuyên nghiệp.
Hướng dẫn từng bước
Đây là quy trình review một bản thiết kế mà bạn có thể áp dụng ngay:
- Mở file ở chế độ toàn cảnh. Nhấn Shift + 1 để thấy tất cả màn hình. Đọc tên các frame để hiểu bố cục tổng thể: có bao nhiêu màn hình, chúng thuộc luồng nào.
- Chạy prototype trước, đọc chi tiết sau. Nhấn "Present" và đi qua flow như một người dùng thật. Đừng vội soi pixel — hãy cảm nhận trải nghiệm tổng thể trước. Tự hỏi: luồng này có logic không? Có bị đứt đoạn ở đâu không?
- Kiểm tra các trạng thái thiếu (state). Quay lại canvas và kiểm tra checklist: Empty state (màn hình khi chưa có dữ liệu)? Loading state? Error state? Success state? Đây là nơi PM thường tạo ra giá trị nhất, vì designer dễ chỉ vẽ "happy path".
- Để lại comment có cấu trúc. Nhấn C, ghim vào đúng vị trí, viết theo công thức: [Vấn đề] + [Lý do/dữ liệu] + [@mention người chịu trách nhiệm]. Ví dụ: "Thiếu nút quay lại ở màn hình này — user sẽ bị kẹt. @an cập nhật giúp mình nhé."
- Theo dõi và resolve. Sau khi designer phản hồi và chỉnh sửa, kiểm tra lại rồi nhấn "Resolve" để đóng thread. Đừng để comment cũ chất đống.
- Trích dẫn link cụ thể khi viết requirement. Figma cho phép copy link đến đúng một frame (chuột phải → Copy link to selection). Khi viết tài liệu yêu cầu, dán link này để engineer click thẳng vào đúng màn hình, thay vì phải tự mò.
Lỗi thường gặp & mẹo
Lỗi 1: Comment chung chung trong chat thay vì ghim trong Figma. Khi bạn nhắn "cái màn hình lúc nãy sửa giúp anh" trên Slack, không ai biết bạn nói màn hình nào. Mẹo: luôn comment trực tiếp trong Figma, ghim vào đúng phần tử.
Lỗi 2: Tự ý chỉnh sửa thiết kế. Như ví dụ 3, đây là lỗi gây hỗn loạn. Mẹo: xin quyền "Can comment" là đủ, đừng xin "Can edit" trừ khi thật sự cần.
Lỗi 3: Bỏ qua các trạng thái phụ. Chỉ duyệt happy path là cái bẫy lớn nhất. Mẹo: ghi sẵn một checklist 4 trạng thái (empty, loading, error, success) và soi mọi màn hình qua nó.
Lỗi 4: Không resolve comment. File với 80 comment chưa đóng khiến không ai biết việc nào còn dang dở. Mẹo: cuối mỗi tuần, dọn các thread đã xử lý xong.
Lỗi 5: Lẫn lộn giữa bản nháp và bản chốt. Engineer code nhầm bản nháp là thảm họa. Mẹo: thống nhất với designer một quy ước rõ ràng — ví dụ chỉ frame trong page tên "Ready for Dev" mới được code, hoặc dùng nhãn (tag) màu để đánh dấu trạng thái duyệt.
Mẹo cộng thêm: Học vài phím tắt sẽ tăng tốc đáng kể — C (comment), Shift+1 (xem toàn bộ), Shift+2 (zoom vào phần chọn), phím cách giữ để kéo canvas. Ngoài ra, bật thông báo (notification) để biết khi nào ai đó reply comment của bạn, tránh để câu hỏi treo nhiều ngày.
Bài tập thực hành
- Tự tạo file luyện tập. Mở Figma, tạo tài khoản miễn phí, tạo một file mới với 4 frame mô phỏng luồng đăng nhập của một app bất kỳ: màn hình nhập số điện thoại → nhập OTP → đăng nhập thành công → màn hình lỗi OTP sai. Mục tiêu không phải vẽ đẹp, mà để bạn quen với việc tạo và nối frame.
- Tập comment theo công thức. Lấy một file Figma cộng đồng (Figma Community có hàng nghìn file miễn phí — tìm "mobile app UI kit"). Duplicate về tài khoản của bạn, rồi để lại 5 comment theo công thức [Vấn đề] + [Lý do] + [@mention]. Tự đánh giá: comment của bạn đã đủ rõ để người khác hành động ngay chưa?
- Săn trạng thái thiếu. Vẫn với file đó, dùng checklist 4 trạng thái (empty, loading, error, success) rà soát và liệt kê tất cả màn hình còn thiếu trạng thái. Viết ra một danh sách yêu cầu bổ sung như một PM thật sự sẽ giao cho designer.
- Trải nghiệm prototype. Tìm một file Community có prototype bấm được, nhấn "Present" và đi hết flow. Ghi lại 3 điểm khiến trải nghiệm bị gãy hoặc khó hiểu. Đây chính là cách bạn rèn con mắt PM.
Tóm tắt
Figma không biến PM thành designer, nhưng PM giỏi Figma sẽ làm việc nhanh hơn, giao tiếp rõ hơn và ra quyết định sớm hơn. Bốn kỹ năng cốt lõi bạn cần nắm: đọc và điều hướng file, comment có cấu trúc với @mention, đọc spec để kiểm tra requirement, và xem prototype để phát hiện lỗ hổng trong flow.
Ba nguyên tắc vàng cần nhớ: (1) Comment ghim đúng chỗ cộng dữ liệu cụ thể luôn mạnh hơn mô tả chung chung; (2) PM comment, designer edit — đừng vượt ranh giới vai trò; (3) Luôn soi mọi màn hình qua checklist trạng thái (empty, loading, error, success), vì đây là nơi PM tạo ra giá trị lớn nhất. Cuối cùng, đừng quên resolve comment để giữ file sạch và để cả team biết việc nào đã xong.
Hãy mở Figma ngay hôm nay và làm bài tập đầu tiên. Kỹ năng này chỉ thực sự thấm khi bạn tự tay chạm vào nó.