Mở đầu — vì sao bài này quan trọng
Nếu bạn từng làm việc trong một team sản phẩm, chắc hẳn bạn đã chứng kiến cảnh này: designer hoàn thiện một màn hình mới trên Figma, chia sẻ link trong một kênh Slack nào đó, rồi... link đó chìm nghỉm giữa hàng trăm tin nhắn khác. Đến sprint sau, developer bắt đầu code, mở Jira ra đọc user story, nhưng không biết bản thiết kế "chính thức" nằm ở đâu. Họ mò lên Figma, thấy có ba phiên bản khác nhau của cùng một màn hình, và không ai chắc bản nào là bản cuối cùng. Kết quả: dev code theo bản cũ, QA test theo bản mới, PM thì đau đầu vì "sao lại lệch thiết kế".
Đây không phải chuyện hiếm. Đây là căn bệnh kinh niên của mọi team làm sản phẩm số: design và development sống ở hai thế giới tách biệt. Figma là nơi thiết kế "sống", còn Jira là nơi công việc "chạy". Khi hai công cụ này không nói chuyện với nhau, PM trở thành người phải chạy đi chạy lại giữa hai bên, copy-paste link, chụp màn hình, giải thích bằng miệng — một công việc thủ công, dễ sai và tốn thời gian khủng khiếp.
Bài học hôm nay giải quyết đúng nỗi đau đó. Chúng ta sẽ học cách kết nối Figma với Jira để bản thiết kế trở thành một phần hữu cơ của quy trình công việc: nhúng thiết kế thẳng vào issue, đồng bộ trạng thái design với trạng thái development, và thiết lập một "design workflow" gọn gàng mà cả PM, designer lẫn dev đều nhìn vào một nguồn sự thật duy nhất. Với vai trò PM, đây là kỹ năng giúp bạn giảm ma sát giao tiếp và đảm bảo "cái được thiết kế" chính là "cái được xây dựng".
Khái niệm cốt lõi
Vì sao Figma và Jira cần "bắt tay"
Trước khi đi vào cách làm, hãy hiểu rõ vấn đề gốc. Figma và Jira phục vụ hai giai đoạn khác nhau của cùng một dòng chảy sản phẩm:
- Figma là công cụ thiết kế giao diện (UI/UX). Đây là nơi designer dựng wireframe, mockup, prototype — tức là "hình dạng" của sản phẩm.
- Jira là công cụ quản lý công việc. Đây là nơi PM và team theo dõi ai làm gì, đang ở trạng thái nào, khi nào xong.
- Link đó dẫn tới bản thiết kế phiên bản nào (Figma cập nhật liên tục).
- Thiết kế đó đã "ready for development" chưa, hay designer vẫn đang chỉnh.
- Khi designer thay đổi thiết kế, developer có được thông báo không.
Figma for Jira — official integration
Cách tích hợp chính thống và phổ biến nhất là dùng ứng dụng Figma for Jira trên Atlassian Marketplace (chợ ứng dụng của Atlassian). Đây là app miễn phí do Figma phát hành. Sau khi admin cài đặt và kết nối tài khoản Figma của tổ chức, bạn sẽ có được các khả năng chính:
- Embed (nhúng) preview thiết kế trực tiếp vào phần mô tả (description) hoặc comment của một Jira issue. Thay vì một dòng link chữ xanh, bạn thấy ngay hình ảnh thumbnail của frame thiết kế, click vào là mở Figma.
- Live preview: bản nhúng tự cập nhật theo thiết kế mới nhất. Khi designer sửa frame, thumbnail trong Jira cũng đổi theo — không còn cảnh dev nhìn ảnh cũ.
- Design panel: một số phiên bản hiển thị một khu vực riêng liệt kê toàn bộ design đang gắn với issue đó.
Nhúng Figma frame vào issue description
Về mặt kỹ thuật, việc nhúng cực kỳ đơn giản: bạn chỉ cần copy link của một frame Figma và dán vào ô mô tả của issue. Jira (khi đã cài app) sẽ tự nhận diện đường dẫn figma.com và biến nó thành một smart card có preview.
Lưu ý quan trọng: hãy copy link của frame cụ thể (chọn frame rồi bấm "Copy link to selection"), đừng dán link của cả file. Link cả file sẽ mở ra một canvas mênh mông, dev phải tự mò tìm màn hình liên quan. Link frame cụ thể sẽ dẫn thẳng tới đúng màn hình cần xem.
Link Figma với trạng thái "Ready for Development"
Đây là phần nâng cao và cũng là phần mang lại giá trị lớn nhất cho PM. Ý tưởng là: trạng thái của thiết kế trong Figma phải khớp với luồng công việc trong Jira.
Trong Figma, designer có thể đặt trạng thái cho từng section/page bằng Figma sections với status hoặc quy ước đặt tên (ví dụ: prefix "✅ Ready for Dev", "🚧 WIP", "🔍 In Review"). Nhiều team dùng thêm plugin quản lý design status. Ý tưởng cốt lõi là: chỉ những thiết kế đạt trạng thái "Ready for Development" mới được kéo vào sprint và gắn vào issue để dev bắt đầu code.
Với PM, bạn nên thiết lập một định nghĩa rõ ràng: một issue chỉ được chuyển sang trạng thái "In Progress" (dev bắt đầu) khi thiết kế gắn kèm đã ở trạng thái "Ready for Dev". Đây chính là điểm giao thoa giữa design workflow và development workflow — và là nơi PM đóng vai trò "người gác cổng" để tránh dev code trên bản thiết kế chưa chốt.
Tình huống thực tế
Ví dụ 1 — Startup fintech tại TP.HCM: dứt điểm nạn "code sai thiết kế"
Một startup fintech ở Quận 1, TP.HCM (tạm gọi là PayZen) có team 4 dev, 2 designer và 1 PM. Trước đây, họ làm việc kiểu "Slack-first": designer xong màn hình nào thì quăng link Figma vào kênh #design. Trong một sprint làm tính năng "chuyển tiền định kỳ", designer đã cập nhật lại luồng xác thực OTP (thêm một bước) nhưng chỉ báo miệng trong daily. Một dev nghỉ phép hôm đó, khi quay lại vẫn code theo bản cũ. Kết quả: mất 2 ngày dev công, phải sửa lại, và bug lọt tới tận UAT.
Sau sự cố, PM quyết định cài Figma for Jira. Quy tắc mới: mọi user story bắt buộc phải có một Figma frame được nhúng ngay trong description; không có thiết kế nhúng thì story không được đưa vào sprint. Vì bản nhúng là live, khi designer thêm bước OTP, thumbnail trong issue tự đổi, và dev thấy ngay lập tức lúc mở issue.
Kết quả sau 3 sprint: số lần "code lệch thiết kế" giảm từ trung bình 4 lần/sprint xuống còn gần như bằng 0. Bài học rút ra: đừng để thiết kế sống trong Slack — hãy để nó sống ngay trong issue, nơi dev chắc chắn sẽ nhìn vào.
Ví dụ 2 — Agency thiết kế web ở Hà Nội: chốt bản để tránh "moving target"
Một agency ở Hà Nội chuyên làm website cho khách hàng doanh nghiệp gặp vấn đề ngược lại: họ đã dùng nhúng live, nhưng designer vẫn "táy máy" chỉnh thiết kế ngay cả khi dev đang code. Vì bản nhúng luôn cập nhật, dev liên tục thấy thiết kế đổi giữa chừng — một "moving target" khiến họ không bao giờ code xong được một màn hình.
PM của agency đưa ra giải pháp kết hợp giữa quy trình và công cụ: họ quy ước dùng Figma branch (nhánh) cho các chỉnh sửa đang thử nghiệm, và chỉ merge vào main khi thiết kế đã chốt. Đồng thời, trong Jira họ thêm một status riêng "Design Locked" vào workflow. Khi một issue đạt "Design Locked", designer cam kết không sửa frame đó nữa; nếu cần thay đổi, phải tạo một issue mới (change request).
Kết quả: cycle time trung bình cho một màn hình giảm 30%, vì dev không còn bị gián đoạn. Bài học rút ra: nhúng live rất tốt cho việc luôn cập nhật, nhưng bạn phải có một cơ chế "chốt bản" bằng quy trình (status trong Jira) để tránh biến thiết kế thành mục tiêu di động.
Ví dụ 3 — Team e-commerce Đông Nam Á: dùng design status làm điều kiện vào sprint
Một công ty e-commerce hoạt động ở Singapore và Việt Nam có 3 team phát triển song song. Với quy mô đó, PM không thể tự kiểm tra từng thiết kế đã sẵn sàng hay chưa. Họ thiết lập một quy trình rõ ràng: trong Figma, mỗi màn hình được gắn nhãn trạng thái theo quy ước ("🚧 WIP", "🔍 Review", "✅ Ready for Dev"). Trong buổi backlog refinement, chỉ những story có thiết kế đạt "✅ Ready for Dev" mới đủ điều kiện được ước lượng và kéo vào sprint sắp tới.
PM còn tạo một checklist trong Definition of Ready: "Thiết kế đã nhúng vào issue? Thiết kế đã ở trạng thái Ready for Dev?". Điều này biến một quy tắc mơ hồ thành một điều kiện kiểm tra được. Bài học rút ra: khi làm việc ở quy mô nhiều team, đừng dựa vào trí nhớ hay giao tiếp miệng — hãy dùng trạng thái thiết kế như một cổng chặn chính thức trong quy trình sprint.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn thiết lập và vận hành design workflow giữa Figma và Jira.
Bước 1 — Cài đặt Figma for Jira. Vào Atlassian Marketplace, tìm "Figma for Jira", nhấn cài đặt (thao tác này thường cần quyền admin của Jira). Nếu bạn không phải admin, hãy gửi yêu cầu cho Jira admin kèm lý do rõ ràng (giảm ma sát design-dev, tránh code sai thiết kế).
Bước 2 — Kết nối tài khoản Figma. Sau khi cài, mỗi thành viên khi lần đầu nhúng link Figma sẽ được yêu cầu ủy quyền (authorize) tài khoản Figma của mình. Đảm bảo team dùng đúng workspace Figma của tổ chức, không phải tài khoản cá nhân.
Bước 3 — Thiết lập quy ước trạng thái trong Figma. Thống nhất với designer về cách đánh dấu trạng thái thiết kế. Cách đơn giản nhất là dùng prefix tên section: "🚧 WIP", "🔍 In Review", "✅ Ready for Dev". Ghi quy ước này vào tài liệu team để ai cũng hiểu.
Bước 4 — Nhúng frame vào issue. Khi tạo hoặc refine một user story, mở Figma, chọn đúng frame màn hình, nhấn "Copy link to selection", rồi dán vào ô Description của issue. Đợi vài giây để Jira render thành preview card. Kiểm tra xem thumbnail hiển thị đúng màn hình chưa.
Bước 5 — Đưa "design ready" vào Definition of Ready. Cập nhật Definition of Ready của team: một story chỉ "ready" khi đã có thiết kế nhúng và thiết kế đó ở trạng thái Ready for Dev. Dùng checklist này trong buổi backlog refinement.
Bước 6 — Thêm status kiểm soát trong workflow (tùy chọn nâng cao). Nếu team hay gặp vấn đề "moving target", cân nhắc thêm một status như "Design Locked" vào workflow Jira, và quy ước rằng thiết kế không được sửa sau khi issue đạt status này.
Bước 7 — Thiết lập quy tắc thay đổi thiết kế. Thống nhất: nếu cần đổi thiết kế sau khi dev đã bắt đầu, phải tạo một issue change request riêng, thay vì sửa lén frame. Điều này giữ lịch sử minh bạch và không làm dev bối rối.
Lỗi thường gặp & mẹo
Lỗi 1 — Dán link cả file thay vì link frame. Đây là lỗi phổ biến nhất. Dev mở ra thấy nguyên một canvas với 40 màn hình và không biết cái nào liên quan. Luôn dùng "Copy link to selection" cho frame cụ thể.
Lỗi 2 — Coi nhúng live là "chốt bản". Vì bản nhúng luôn cập nhật, nhiều người tưởng đó là bản cuối. Nhưng nếu designer còn sửa, dev sẽ đuổi theo mục tiêu di động. Mẹo: kết hợp nhúng live với một status "Design Locked" hoặc dùng Figma branch cho các thử nghiệm.
Lỗi 3 — Không phân quyền Figma đúng. Nếu dev không có quyền xem file Figma, bản nhúng sẽ hiện lỗi hoặc trống. Đảm bảo mọi thành viên dev có ít nhất quyền "can view" trên project Figma liên quan.
Lỗi 4 — Nhồi quá nhiều frame vào một issue. Một story nên gắn với một hoặc vài màn hình liên quan trực tiếp. Nếu bạn nhúng 15 frame, dev lại rối. Chia nhỏ story nếu cần.
Mẹo — Dùng comment để trao đổi ngữ cảnh. Ngoài phần description, hãy dùng comment của issue để ghi chú các quyết định thiết kế ("bản này đã bỏ nút back theo yêu cầu khách hàng"). Điều này giúp dev hiểu "tại sao", không chỉ "cái gì".
Mẹo — Đặt tên frame trong Figma khớp với tên story. Nếu frame tên đúng như tên màn hình trong story ("Màn hình đăng nhập OTP"), việc tra cứu chéo giữa hai công cụ sẽ nhanh hơn nhiều.
Bài tập thực hành
- Thiết lập cơ bản: Nếu team bạn đã dùng Jira, hãy kiểm tra xem Figma for Jira đã được cài chưa. Nếu chưa, viết một đề xuất ngắn (3-4 câu) gửi Jira admin, nêu rõ lợi ích. Nếu đã cài, chọn một issue hiện có và nhúng một Figma frame vào description.
- Xây quy ước trạng thái: Cùng designer (hoặc tự giả định), thiết kế một bộ 3-4 nhãn trạng thái cho thiết kế trong Figma. Viết ra định nghĩa của mỗi trạng thái: khi nào một thiết kế được coi là "Ready for Dev".
- Cập nhật Definition of Ready: Viết lại Definition of Ready cho team, thêm hai điều kiện liên quan đến thiết kế (thiết kế đã nhúng + thiết kế ở trạng thái Ready for Dev).
- Tình huống xử lý: Giả sử designer sửa thiết kế khi dev đã code được nửa màn hình. Viết ra quy trình xử lý mà bạn — với vai trò PM — sẽ áp dụng để vừa cập nhật được thay đổi, vừa không gây rối cho dev. Gợi ý: nghĩ tới change request và status kiểm soát.
Tóm tắt
Bài học hôm nay giải quyết một nỗi đau kinh điển của mọi team sản phẩm: sự tách biệt giữa thế giới thiết kế (Figma) và thế giới công việc (Jira). Chúng ta đã đi qua cách tích hợp Figma for Jira từ Atlassian Marketplace, cách nhúng frame thiết kế trực tiếp vào issue để dev luôn nhìn vào đúng nguồn thiết kế, và cách gắn trạng thái thiết kế với luồng công việc để chỉ những thiết kế "Ready for Dev" mới được kéo vào sprint.
Điều quan trọng nhất cần nhớ: nhúng live giúp thiết kế luôn cập nhật, nhưng bạn — với vai trò PM — cần một cơ chế "chốt bản" bằng quy trình (Definition of Ready, status Design Locked, quy tắc change request) để tránh biến thiết kế thành mục tiêu di động. Ba tình huống thực tế từ PayZen, agency Hà Nội và công ty e-commerce Đông Nam Á đều chỉ ra cùng một chân lý: công cụ chỉ là một nửa, nửa còn lại là kỷ luật quy trình mà bạn thiết lập.
Khi làm tốt, kết quả là một dòng chảy mượt mà: designer thiết kế, đánh dấu Ready, PM kéo vào sprint, dev mở issue thấy ngay thiết kế đúng phiên bản, và không ai phải chạy đi tìm link nữa. Đó chính là design workflow mà một PM giỏi cần xây dựng.