Mở đầu — vì sao bài này quan trọng
Có một hiểu lầm rất phổ biến trong nghề: "PM thì cần gì biết Figma, đó là việc của designer." Nghe có vẻ hợp lý, nhưng thực tế lại khác xa. Tôi đã chứng kiến vô số PM gửi cho designer những đoạn mô tả dài ba trang Word để diễn tả một màn hình đăng nhập đơn giản, rồi sau đó ngồi giải thích đi giải thích lại trong ba cuộc họp vì designer hiểu sai ý. Trong khi đó, một PM khác chỉ cần bỏ ra mười lăm phút vẽ một wireframe thô bằng Figma, kéo thả vài hộp chữ nhật, và mọi người hiểu ngay lập tức.
Sự khác biệt nằm ở chỗ: giao tiếp bằng hình ảnh nhanh và chính xác hơn giao tiếp bằng chữ rất nhiều khi nói về giao diện. Một bức wireframe loại bỏ hàng tá hiểu lầm tiềm tàng — vị trí nút bấm, thứ tự các phần tử, cái gì hiện trước cái gì hiện sau — những thứ mà mô tả bằng lời rất dễ gây mơ hồ.
Cần nói rõ ngay từ đầu để bạn không hiểu lầm: mục tiêu của bài này KHÔNG phải biến bạn thành designer. PM không cần biết phối màu, không cần chọn font đẹp, không cần làm UI lung linh. Cái PM cần là ba thứ rất cụ thể: (1) truyền đạt ý tưởng nhanh hơn, (2) review công việc của designer một cách tự tin và có ngôn ngữ chung, (3) tự dựng wireframe thô để mang đi test với người dùng hoặc trình bày với sếp. Figma là công cụ giúp bạn làm được cả ba việc đó mà không phải phụ thuộc hoàn toàn vào người khác. Trong bài này, tôi sẽ tập trung đúng vào kỹ năng wireframing và mockup ở mức PM cần — không hơn, không kém.
Khái niệm cốt lõi
Phân biệt wireframe, mockup và prototype
Ba từ này hay bị dùng lẫn lộn, nhưng PM cần phân biệt rạch ròi vì chúng phục vụ mục đích khác nhau và đòi hỏi mức công sức khác nhau.
Wireframe là bản phác thảo bố cục ở mức thấp nhất (low-fidelity). Nó chỉ có các hộp xám, đường kẻ, chữ placeholder kiểu "Tiêu đề ở đây", "Nút CTA". Không màu mè, không hình ảnh thật. Mục đích duy nhất của wireframe là trả lời câu hỏi: Cái gì nằm ở đâu, và luồng đi như thế nào? Đây chính là thứ PM nên làm nhiều nhất.
Mockup là bản mô phỏng độ trung thực cao hơn (high-fidelity): đã có màu sắc, font chữ, icon, hình ảnh gần giống sản phẩm thật. Đây thường là sản phẩm của designer, không phải của PM. PM cần biết đọc mockup, biết góp ý, nhưng hiếm khi tự làm mockup hoàn chỉnh.
Prototype là bản có thể bấm được — các màn hình được nối với nhau bằng liên kết, bấm vào nút thì nhảy sang màn hình khác, mô phỏng trải nghiệm thật. Prototype dùng để test với người dùng hoặc demo cho stakeholder.
Một quy tắc ngầm: độ trung thực càng cao thì người ta càng ngại thay đổi. Khi bạn đưa một mockup đẹp lung linh cho sếp xem, sếp sẽ góp ý về màu nút bấm thay vì về luồng nghiệp vụ. Còn khi bạn đưa wireframe thô, mọi người tập trung vào cái thực sự quan trọng: logic và luồng. Đây là lý do PM nên yêu wireframe thô.
Vì sao chọn Figma chứ không phải công cụ khác?
Figma đã trở thành tiêu chuẩn de facto của ngành thiết kế sản phẩm ở Việt Nam và toàn cầu vì ba lý do thực dụng. Thứ nhất, nó chạy trực tiếp trên trình duyệt, không cần cài đặt nặng nề, máy cấu hình thường vẫn dùng được. Thứ hai, nó cộng tác thời gian thực giống Google Docs — PM, designer, engineer cùng nhìn vào một file, thấy con trỏ của nhau di chuyển. Thứ ba, có gói miễn phí đủ dùng cho PM và tính năng comment để góp ý ngay trên thiết kế.
Bốn khái niệm Figma mà PM bắt buộc phải nắm
Bạn không cần học hết Figma. Chỉ cần bốn thứ:
- Frame (khung): đại diện cho một màn hình. Mỗi màn hình điện thoại hay một trang web là một frame. Figma có sẵn kích thước chuẩn iPhone, Android, desktop để chọn.
- Shapes & Text (hình khối và chữ): hộp chữ nhật, hình tròn, đường thẳng, và ô chữ. Chỉ với chừng này bạn đã vẽ được 90% wireframe.
- Components (thành phần tái sử dụng): một phần tử bạn dùng đi dùng lại — ví dụ thanh điều hướng dưới cùng. Sửa một lần ở "bản gốc", tất cả bản sao tự cập nhật. Với PM, hiểu khái niệm này là đủ để không làm hỏng file của designer.
- Comment (bình luận): công cụ quyền lực nhất của PM trong Figma. Bấm vào bất kỳ điểm nào trên thiết kế và để lại ghi chú. Đây là cách bạn review designer một cách chuyên nghiệp thay vì nhắn tin chung chung "chỗ này sửa lại nhé".
Tình huống thực tế
Tình huống 1 — Startup giao đồ ăn ở TP.HCM và cái nút "đặt lại đơn cũ"
Một startup giao đồ ăn giả định tên FoodNgay, quy mô khoảng 30 người, đang muốn thêm tính năng "đặt lại đơn cũ" (reorder) để tăng tỷ lệ khách quay lại. PM tên Linh ban đầu viết yêu cầu bằng văn bản dài hai trang gửi cho designer. Sau một tuần, bản thiết kế nhận về đặt nút "đặt lại" nằm sâu trong trang lịch sử đơn hàng — đúng chữ nghĩa Linh viết, nhưng sai hoàn toàn ý định, vì Linh muốn nút này nổi bật ngay ở trang chủ.
Lần sau, Linh đổi cách làm. Cô mở Figma, mất đúng 20 phút vẽ một wireframe thô: màn hình chủ với một dải "Đặt lại món hôm trước" ngay dưới thanh tìm kiếm, mỗi món là một thẻ có ảnh nhỏ và nút "Thêm" bên cạnh. Cô gắn comment giải thích logic: "Chỉ hiện 3 món gần nhất, ưu tiên món đặt nhiều lần nhất." Designer hiểu ngay, và bản thiết kế chính thức ra đời chỉ sau hai ngày thay vì một tuần đẽo gọt.
Bài học: Wireframe thô không thay thế designer, nhưng nó "khóa" được ý định bố cục trước khi designer đổ công sức làm đẹp. Một bức tranh đáng giá hơn hai trang văn bản — đặc biệt khi nói về vị trí trên màn hình.
Tình huống 2 — Test với người dùng trước khi viết một dòng code
Một nhóm fintech ở Hà Nội đang phân vân giữa hai cách thiết kế luồng chuyển tiền: một luồng gồm ba bước (chọn người nhận → nhập số tiền → xác nhận) và một luồng gộp tất cả vào một màn hình. Tranh cãi trong nội bộ kéo dài cả tuần mà không ai chịu ai.
PM quyết định dừng tranh cãi. Anh dựng hai prototype Figma đơn giản — chỉ là wireframe nối liên kết bấm được — rồi mời 6 người dùng thật vào quán cà phê thử trên điện thoại. Kết quả: 5/6 người làm xong nhanh hơn với luồng ba bước, và quan trọng hơn, nhóm một-màn-hình mắc lỗi nhập sai số tiền nhiều hơn vì màn hình quá tải. Cuộc tranh cãi một tuần được giải quyết trong một buổi chiều, với chi phí gần như bằng không vì chưa hề viết code.
Bài học: Prototype Figma cho phép bạn kiểm chứng giả thuyết về trải nghiệm trước khi tốn tiền lập trình. Sai trên Figma chỉ tốn vài giờ kéo thả; sai trên code đã ship tốn hàng tuần và uy tín.
Tình huống 3 — Review designer mà không gây khó chịu
Một PM mới tên Tuấn ở một công ty thương mại điện tử có thói quen nhắn Slack cho designer kiểu "trang này nhìn chưa ổn lắm, sửa lại giúp anh". Designer ức chế vì không biết "chưa ổn" là chỗ nào, sửa cái gì. Quan hệ hai bên căng thẳng dần.
Sau khi học cách dùng comment trong Figma, Tuấn thay đổi hẳn. Thay vì nhận xét chung chung, anh bấm trực tiếp vào nút "Thanh toán" và để comment: "Nút này đang cùng màu với nút 'Tiếp tục mua sắm', người dùng dễ bấm nhầm. Mình muốn nút thanh toán nổi bật hơn — đây là hành động chính của màn hình." Comment gắn đúng vị trí, đúng lý do nghiệp vụ, không phán xét gu thẩm mỹ. Designer tiếp nhận dễ chịu hơn hẳn vì góp ý cụ thể và có lý do.
Bài học: Góp ý của PM nên gắn vào vị trí cụ thể và lý do nghiệp vụ/người dùng, không phải cảm tính thẩm mỹ. Comment trong Figma biến phản hồi mơ hồ thành phản hồi hành động được.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên PM mới làm theo để dựng một wireframe thô đầu tiên.
- Tạo tài khoản và file mới. Vào figma.com, đăng ký gói miễn phí. Tạo một file design mới. Đừng để giao diện nhiều nút làm bạn hoảng — bạn chỉ dùng vài công cụ.
- Tạo Frame cho màn hình. Nhấn phím tắt
F(hoặc chọn công cụ Frame), bên phải chọn kích thước có sẵn — ví dụ "iPhone 14" cho app di động. Bạn có một khung trắng đúng tỷ lệ điện thoại để bắt đầu.
- Phác bố cục bằng hộp xám. Nhấn
Rđể vẽ hình chữ nhật. Dùng các hộp xám đại diện cho từng vùng: hộp trên cùng là header, hộp dài là thanh tìm kiếm, các hộp vuông là thẻ sản phẩm. Đừng tô màu, đừng làm đẹp — đây là wireframe.
- Thêm chữ placeholder. Nhấn
Tđể gõ chữ. Viết thẳng mục đích: "Tiêu đề trang", "Nút Đặt hàng", "Giá: 99.000đ". Chữ giúp người xem hiểu mỗi hộp là gì.
- Sắp xếp và căn chỉnh. Bôi đen nhiều phần tử, dùng các nút căn lề (align) bên phải để chúng thẳng hàng. Figma còn gợi ý đường căn tự động khi bạn kéo. Bố cục thẳng hàng giúp wireframe dễ đọc hơn nhiều.
- Nhân bản frame cho các màn hình tiếp theo. Chọn frame, nhấn
Ctrl/Cmd + Dđể nhân đôi, rồi sửa thành màn hình kế tiếp trong luồng. Lặp lại cho tới khi có đủ các màn hình của luồng nghiệp vụ.
- Nối thành prototype (nếu cần test). Chuyển sang tab "Prototype" bên phải, kéo từ một nút trên màn hình A sang frame màn hình B để tạo liên kết bấm được. Nhấn nút Play để thử như người dùng thật.
- Chia sẻ và thu thập phản hồi. Nhấn "Share", đặt quyền "Anyone with the link can comment", gửi link cho designer hoặc stakeholder. Mọi người comment trực tiếp lên thiết kế. Bạn không cần xuất file, không cần đính kèm ảnh.
Lỗi thường gặp & mẹo
Lỗi 1 — PM cố làm cho đẹp. Cám dỗ lớn nhất là tô màu, chọn font, căn pixel. Đừng. Khi bạn làm wireframe quá đẹp, hai chuyện xấu xảy ra: bạn tốn thời gian vào việc không phải của mình, và bạn giẫm chân designer. Mẹo: tự đặt giới hạn — chỉ dùng màu xám và một màu nhấn duy nhất cho phần tử quan trọng nhất.
Lỗi 2 — Sửa trực tiếp lên file gốc của designer. Nhiều PM hào hứng vào file thật của designer rồi vô tình kéo lệch component, làm hỏng bố cục. Mẹo: luôn dùng comment để góp ý, đừng tự tay sửa. Nếu muốn thử ý tưởng, hãy nhân bản (duplicate) màn hình ra một frame nháp riêng rồi sửa trên đó.
Lỗi 3 — Quá chi tiết quá sớm. Vẽ wireframe với từng dòng chữ thật, từng con số chính xác ngay vòng đầu là lãng phí, vì luồng còn có thể thay đổi hoàn toàn. Mẹo: vòng đầu chỉ vẽ bố cục và luồng; chi tiết để sau khi luồng được chốt.
Lỗi 4 — Quên ghi lại "vì sao". Wireframe chỉ cho thấy "cái gì", không cho thấy "tại sao". Sáu tháng sau không ai nhớ vì sao nút lại đặt ở đó. Mẹo: dùng comment để ghi lý do quyết định ngay trên thiết kế — nó trở thành tài liệu sống.
Mẹo cộng thêm: Hãy học thuộc đúng năm phím tắt — F (frame), R (hình chữ nhật), T (chữ), V (chọn/di chuyển), và phím cách giữ để kéo màn hình (pan). Chỉ năm phím này thôi cũng tăng tốc độ làm việc của bạn gấp đôi. Ngoài ra, kho cộng đồng Figma có sẵn nhiều bộ "wireframe kit" miễn phí — kéo thả các phần tử dựng sẵn thay vì vẽ từ đầu, tiết kiệm rất nhiều thời gian.
Bài tập thực hành
- Dựng wireframe ba màn hình. Chọn một tính năng đơn giản bạn quen thuộc — ví dụ luồng "đặt lại đơn hàng cũ" hoặc "đăng ký nhận thông báo khuyến mãi". Dùng Figma vẽ ba frame thể hiện luồng từ đầu đến cuối, chỉ bằng hộp xám và chữ placeholder. Đặt giới hạn thời gian 30 phút.
- Biến nó thành prototype bấm được. Dùng tab Prototype nối ba màn hình với nhau. Nhấn Play và tự thử như một người dùng. Ghi lại bất kỳ chỗ nào bạn thấy lúng túng — đó chính là dấu hiệu của vấn đề trải nghiệm.
- Tập review bằng comment. Mở một file thiết kế bất kỳ (của đồng nghiệp, hoặc một mẫu trong cộng đồng Figma). Để lại đúng ba comment, mỗi comment phải gắn vào một vị trí cụ thể và nêu rõ lý do nghiệp vụ hoặc người dùng — tuyệt đối không góp ý kiểu "nhìn xấu" hay "chưa đẹp".
- Tự đánh giá. Đưa wireframe ở bài tập 1 cho một người chưa từng nghe bạn giải thích, nhờ họ mô tả lại luồng. Nếu họ hiểu đúng mà bạn không cần nói gì, wireframe của bạn đã đạt mục tiêu giao tiếp.
Tóm tắt
Figma đối với PM không phải là công cụ để làm đẹp, mà là công cụ để giao tiếp ý tưởng nhanh, review thiết kế tự tin, và tự dựng wireframe để test với người dùng. Bạn cần phân biệt rõ wireframe (bố cục thô, low-fidelity, đây là phần của PM), mockup (đẹp, độ trung thực cao, của designer) và prototype (bấm được, để test). Bốn khái niệm Figma đủ dùng cho PM là Frame, Shapes & Text, Components và Comment — trong đó comment là vũ khí mạnh nhất để góp ý đúng vị trí và đúng lý do. Quy trình tám bước giúp bạn dựng wireframe đầu tiên trong chưa đầy một giờ, và bốn lỗi thường gặp đều xoay quanh một nguyên tắc: PM giữ vai trò làm rõ "cái gì" và "tại sao", còn việc làm đẹp "như thế nào" hãy để designer lo. Nắm vững chừng đó, bạn đã có một kỹ năng tạo khác biệt rõ rệt so với những PM chỉ biết viết yêu cầu bằng chữ.