How to Run a Design Review with Figma + Jira: Step-by-Step Guide
A complete walkthrough for product managers who want to run effective design reviews using Figma and Jira, plus where disconnected toolchains create gaps.
TL;DR
A design review bridges the gap between design exploration and engineering execution. Figma is where designs live. Jira is where implementation work is tracked. This guide walks through running a structured design review that connects both tools, and covers where the manual linking between them starts breaking down as teams and products grow.
What Is a Design Review?
A design review is a structured evaluation of a design artifact (mockups, prototypes, interaction flows) against product requirements and user needs. It is the checkpoint where product, design, and engineering align on what will be built before implementation begins.
Design reviews are not critiques. A critique explores ideas and directions, often at an early stage when the design is still malleable. A review evaluates a specific design against defined requirements and asks: does this solve the stated problem? Does it meet the acceptance criteria? Are there edge cases or technical constraints that have not been addressed?
The output of a design review is a clear decision: approved for implementation, approved with required changes, or needs significant rework. Each piece of feedback should be actionable, assigned, and trackable. This is where Jira comes in. Without a structured way to track feedback and link it back to designs, review outcomes get lost in meeting notes and Slack threads.
Design reviews also serve a documentation purpose. They create a record of what was reviewed, what feedback was given, and what decisions were made. When a question arises later about why a design looks a certain way, the review record provides the answer.
Why Design Reviews Matter
Teams that skip design reviews pay for it in rework. According to industry estimates, finding and fixing a design issue during development costs 5-10 times more than catching it during the design phase. A 30-minute design review can prevent days of engineering rework.
Design reviews also align cross-functional teams. Engineers surface technical constraints that designers may not have considered. PMs verify that the design matches the requirements. QA identifies testability gaps. This cross-functional input strengthens the design and reduces the number of surprises during implementation.
For remote and distributed teams, design reviews are especially important. Without the ability to lean over someone's shoulder and ask about a design decision, teams need a formal process to ensure alignment. A structured review with documented outcomes replaces the informal check-ins that co-located teams rely on.
Design reviews also build shared understanding across the team. When engineers see the full design context (not just the ticket description), they make better implementation decisions. When designers see the technical constraints engineers raise, they make more feasible design choices. This shared understanding compounds over time, making future projects faster and more aligned.
Finally, design reviews create accountability. When a design is reviewed and approved by product and engineering, the team has a shared commitment to what will be built. This reduces the scope creep that happens when designs are informally shared and feedback trickles in throughout implementation.
Setting Up Your Figma + Jira Workflow
Before running your first design review, establish the connection between Figma and Jira. This foundational work pays off immediately by making it possible to link designs to tickets and track feedback in a structured way.
Install the Figma for Jira app from the Atlassian Marketplace. This integration allows you to embed Figma frames directly in Jira tickets and receive live previews. When a designer updates a frame in Figma, the preview in Jira updates automatically.
Establish a naming convention for Figma files and frames that maps to your Jira project structure. For example, if your Jira project key is “PROD,” name your Figma pages to match: “PROD-123: Onboarding Redesign.” This makes it easy to find the design for any given ticket and vice versa.
In your Jira project, create a custom field called “Figma Link” (URL type) on your story or feature issue types. Train the team to paste the specific Figma frame URL (not the file URL) into this field. Specific frame URLs take reviewers directly to the relevant screen, not the top of a multi-page file.
How to Run a Design Review with Figma + Jira: 7 Steps
Here is a detailed walkthrough for running a design review that connects Figma designs to Jira tickets and produces actionable, trackable outcomes.
Step 1: Prepare the Design for Review
Before the review, the designer should organize the Figma file for presentation. Create a dedicated page within the Figma file called “Design Review” or “For Review.” This page should contain only the frames being reviewed, organized in a logical flow (user journey order, not design iteration order).
Add annotations directly in Figma using text layers or the built-in annotation features. Annotate interaction behaviors, state transitions, and edge cases that are not obvious from the static frames. For example: “On empty state, show onboarding CTA” or “Error toast auto-dismisses after 5 seconds.”
Link the Figma frames to the corresponding Jira tickets using the Figma for Jira integration. Each frame that represents a feature or user story should be attached to its Jira issue. This creates a traceable connection between the design and the implementation ticket.
Step 2: Share Pre-Read Materials
Send a pre-read to all review attendees at least 24 hours before the review. The pre-read should include: a link to the Figma file (specific review page), links to the relevant Jira tickets, the PRD or requirements document, and a list of specific questions the designer wants feedback on.
The pre-read matters because it moves the first 10 minutes of context-setting out of the meeting. Attendees who review the designs asynchronously before the meeting arrive with informed opinions and specific questions, making the live discussion significantly more productive.
Encourage pre-read reviewers to leave comments directly in Figma before the meeting. Figma's commenting system allows comments anchored to specific pixels, which is more precise than verbal feedback. Tag comments with their urgency: “[Blocking] The error state is missing” vs. “[Suggestion] Consider a softer border radius here.”
Step 3: Run the Review Meeting
Structure the review meeting with a clear agenda. Start with 2 minutes of context (what feature, what problem it solves, what constraints exist). Then walk through the design frame by frame, following the user journey. For each frame, cover: what the user sees, what actions they can take, what happens on success, and what happens on failure or edge cases.
Use Figma's presentation mode to walk through the designs. Share your screen with the prototype view so attendees can see the interaction flow, not just static frames. If you have built a Figma prototype with connected frames, demonstrate the click-through experience.
Capture feedback in real-time. Designate a note-taker who records each piece of feedback with three attributes: the feedback itself, the severity (blocking, important, or nice-to-have), and the Figma frame it applies to. Use a shared document or Figma comments for this, not just verbal notes that will be forgotten.
End the review with a clear decision: approved, approved with changes, or needs rework. If approved with changes, list the specific changes required before implementation begins. If needs rework, schedule the follow-up review date.
Step 4: Create Feedback Tickets in Jira
After the review, convert actionable feedback into Jira tickets. Each piece of blocking or important feedback should become its own subtask or linked issue under the parent feature story. Include the Figma frame link, the specific feedback, the severity, and the assignee (usually the designer for design changes, or an engineer for technical constraints).
Use a consistent format for feedback ticket titles: “[Design Feedback] [Frame Name] - [Summary].” For example: “[Design Feedback] Onboarding Step 3 - Add error state for invalid email.” This makes feedback tickets easy to filter and find in Jira.
Link the feedback tickets to the Figma frame using the Figma Link custom field. This creates a direct path from the ticket to the specific design element that needs attention, eliminating the guesswork of “which screen is this feedback about?”
Step 5: Resolve Feedback and Update Designs
The designer addresses feedback in Figma, updating the designs based on the review outcomes. As each piece of feedback is addressed, they resolve the corresponding Figma comment and update the Jira ticket status. This creates a clear trail of what was changed and why.
For significant changes, use Figma's branching feature (available on Organization and Enterprise plans) to create a branch for the review updates. This preserves the original reviewed design for reference while the updates are in progress. Once all feedback is addressed, merge the branch back to the main file.
When all blocking feedback tickets are resolved, the design moves to the “Ready for Development” status in Jira. This is the signal to engineering that the design is approved and implementation can begin.
Step 6: Handoff to Engineering
The design handoff is the transition point where the design becomes the specification for engineering. In Figma, use Dev Mode to provide engineers with precise measurements, CSS properties, and asset exports. Dev Mode translates the visual design into the technical details engineers need without requiring the designer to manually spec every element.
In Jira, ensure the feature ticket has the final Figma frame linked, the acceptance criteria updated to reflect any review changes, and all design feedback tickets resolved. The engineer should be able to open the Jira ticket, click through to the Figma frame, and have everything they need to start building.
Schedule a 15-minute handoff sync between the designer and the implementing engineer. Even with thorough documentation, a brief walkthrough of the design catches nuances that are hard to capture in writing. This is especially important for complex interactions, animations, and conditional states.
Step 7: Track Design Fidelity During Implementation
After handoff, the PM and designer should periodically compare the implementation against the approved design. Figma's Dev Mode overlay feature allows side-by-side comparison. Create a Jira filter for “Design QA” issues that captures any implementation deviations from the approved design.
During the QA phase, the designer reviews the built feature and files any design fidelity issues as Jira tickets linked to the original feature. Include screenshots of the implementation alongside the Figma frame for visual comparison. This closes the loop between design and implementation.
Track design fidelity metrics over time. If the same types of design deviations keep appearing (spacing issues, color mismatches, missing states), it indicates a systemic problem in the handoff process that needs to be addressed, not just individual tickets to fix.
Limitations of This Approach
The Figma + Jira design review workflow above is a strong process for teams with dedicated designers and established sprint cadences. But as products and teams scale, the manual connections between tools start creating friction and gaps.
Designs drift from requirements
The design lives in Figma. The requirements live in Jira (or a PRD in Notion or Confluence). When requirements change after the initial design, the Figma file does not know. The designer must manually check for requirement updates and assess whether the design still matches. At scale, this creates a constant risk of building against outdated designs or designs that no longer match current requirements.
Feedback is scattered across tools
Design feedback arrives in Figma comments, Jira tickets, Slack threads, and meeting notes. Consolidating this feedback into a single actionable list requires manual effort. Important feedback that arrives in a Slack thread after the review meeting may not make it into a Jira ticket, creating a gap between what was discussed and what gets implemented.
No decision traceability
Design reviews produce decisions (approved this layout, rejected that interaction pattern, chose option A over option B). These decisions are captured in meeting notes at best, but they are not linked to the specific Figma frames or Jira tickets they affect. When a question arises later about why a design looks a certain way, the answer requires searching through notes and memories.
Manual linking overhead
Every connection between a Figma frame and a Jira ticket, between a review comment and a feedback ticket, between a design decision and a PRD requirement, is created and maintained manually. As the number of features, frames, and tickets grows, the linking overhead grows linearly. Teams inevitably start skipping links, which degrades the traceability the process is designed to provide.
How Vantage Handles Design Reviews Differently
Vantage is the AI operating system for building products. Instead of manually linking designs, requirements, and feedback across tools, Vantage connects them through a decision graph that maintains relationships automatically.
Here is how the workflow differs:
Connected design context
Vantage connects to Figma and Jira and automatically links designs to the requirements, decisions, and data that inform them. When a design is updated in Figma, Vantage flags the related Jira tickets and PRDs for review. When a requirement changes in Jira, Vantage flags the affected Figma designs.
Unified feedback capture
Feedback from Figma comments, Slack discussions, and Jira tickets is aggregated into the decision graph. Design review decisions are automatically linked to the frames and tickets they affect. There is no manual consolidation step because Vantage captures feedback from connected sources in real time.
Automatic drift detection
Vantage continuously monitors the relationship between designs, requirements, and implementation. If a requirement changes after a design is approved, Vantage flags the drift before it becomes a problem. This eliminates the manual checking that PMs and designers do to ensure designs stay aligned with evolving requirements.
The fundamental difference is connection. In a Figma + Jira workflow, the PM manually bridges the tools. In Vantage, the tools are connected through a decision graph that maintains relationships automatically. Design reviews produce decisions that are traceable to requirements, linked to data, and propagated to downstream deliverables without manual effort.
When to Stick with Figma + Jira
Figma and Jira are excellent tools, and for many teams the workflow described above is the right approach. Stick with Figma + Jira if:
- Your team has a manageable number of active features (under 15 per sprint) and the manual linking between Figma and Jira is feasible without significant overhead.
- Your design and engineering teams are tightly integrated and communicate frequently enough that design drift is caught informally.
- Your organization has invested heavily in the Atlassian ecosystem and adding another tool would create adoption friction.
- Your design reviews produce a small enough volume of feedback that manual Jira ticket creation is manageable.
- You have a strong process culture where team members consistently link Figma frames to Jira tickets and resolve comments promptly.
For teams in this category, invest in strong naming conventions, maintain your Figma to Jira links diligently, and build the review cadence into your sprint rhythm.
When to Consider Vantage
Vantage makes sense when the manual overhead of connecting Figma and Jira starts degrading the quality of design reviews, or when design drift becomes a recurring source of rework. Consider adding Vantage to your workflow if:
- Your team frequently discovers during implementation that designs no longer match current requirements because specs changed after the design review.
- Design feedback is scattered across Figma comments, Slack threads, and Jira tickets and important feedback regularly falls through the cracks.
- You need design review decisions to be automatically linked to the requirements and data that informed them for compliance or audit purposes.
- Your team manages multiple concurrent features and the manual linking between Figma and Jira is consuming significant PM and designer time.
- You want to detect when designs drift from requirements automatically rather than relying on manual spot-checks during QA.
Vantage does not replace Figma or Jira. It connects them. Teams continue using Figma for design and Jira for engineering tracking, while Vantage provides the decision layer that links designs, requirements, feedback, and implementation status into a connected graph.