Why cross-functional design reviews need more than a Figma link

Design reviews get a bit harder when other teams like product and engineering need to weigh in too 

When it’s just the design team, people usually know how the files are organized, which exploration is current, and what kind of feedback is useful. Once product, engineering, and other teams join the review, some of that shared understanding disappears and the review changes.

A cross-functional design review is not only about whether the interface works visually or whether an interaction feels right. Product may be checking whether the design reflects what the team agreed to build. Engineering may be looking for edge cases, dependencies, or implementation constraints. Design may need feedback on a particular direction before spending more time on it.

For these people to give useful feedback, they need to understand the problem being solved, what the team has already decided, which constraints are known, and what part of the design is open for discussion.

A Figma link can give everyone access to the design. The harder part is giving everyone the same starting point for reviewing it.

What cross-functional reviewers need before they can give useful feedback

For someone who works in Figma every day, opening a file and finding the relevant flow may be trivial. But for someone who mainly opens Figma when they are asked to review something, there can be a few steps before the review even starts: find the right page, work out which exploration is current, understand what is ready for feedback, and avoid commenting on something the design team has already moved past.

Miracle, our product designer at Quely, described having to do exactly this before his current workflow. He would need to explain how the Figma file was organized and point people non-designer to the work he wanted them to review.

That is partly a navigation problem, but there is a more important issue underneath it.

Useful design feedback depends on reviewers understanding what they are looking at and what kind of feedback the designer needs.

Figma makes the same point in its own guidance on design critique. Before asking for feedback, it recommends giving reviewers the project context and goals and being explicit about what feedback is and is not useful. Without that background, people can end up responding to the wrong problem. 

This is more important  when the review includes several functions.

The PM may remember a requirement agreed earlier. An engineer may know about a dependency that affects one of the flows. The designer may already have explored and rejected the approach somebody is about to suggest but none of that history is visible in the current design. 

Once that information sits outside the Figma file, the team has another problem to solve: how to keep the review easy to follow as the discussion moves between people and tools.

Why design feedback gets harder to track across tools

The problem becomes later, when somebody asks why the current design looks different from what was agreed earlier? The answer may have been created across several different conversations. For instance, the original requirement is in Jira,  a product decision in Slack, an engineering constraint in a meeting note and the latest design is in Figma. To understand why the design changed, someone has to piece those parts back together.

That does not mean all design feedback should move out of Figma. If someone spots a missing state, questions an interaction, or wants to comment on a specific screen, leaving that feedback directly on the relevant frame makes sense. In one discussion among Figma users, some designers said people outside design found Figma difficult to navigate for reviews, while others preferred keeping comments there because the feedback stayed attached to the exact part of the design being discussed. 

The problem is the wider review around the design. Questions about requirements, use cases, dependencies, earlier decisions, or why the team changed direction do not always belong to one particular frame. When those discussions happen across Slack, meetings, Jira, and Figma, the team may still reach the right decision, but the reasoning is hard to recover later. One designer described dealing with feedback across Figma files, Slack, documents, and individual messages, then having to organize it manually afterwards. That is one person’s experience, but it shows the cost whic is, once the review is spread across several places, someone eventually has to reconstruct it.

That is the problem teams need to solve if they want more of the design review to happen asynchronously.

How Miracle runs cross-functional design reviews in Quely

Miracle still does his design work in Figma. Quely does not replace that part of the workflow.The difference is how he brings other people into the review.

Instead of having everything scattered across JIRA, Slack, and whatnot, we actually have one place where we can actually see this. And everybody, I mean everybody on the team, can actually contribute.

For each design task, the team has a work item in Quely and attaches the relevant Figma design to it. That gives product, engineering, and anyone else involved in the review a clear place to start. They can see the design without first having to find the right page or exploration inside the Figma file.

The discussion around the design happens there too. Before the team gets into detailed UI feedback, Miracle can share the use cases he is designing for, explain the direction he is exploring, and tag the people whose input he needs. Product can question whether the design still reflects an earlier requirement, engineering can raise a dependency, and someone else can add a use case the design needs to account for.

Because those conversations remain connected to the task, they are still available as the design changes. If the team later reviews a version that no longer matches something they agreed earlier, Miracle can go back to the previous discussion and see what was decided and why. Someone who missed that part of the review can do the same instead of asking another person to reconstruct the conversation. If it’s a long thread, Orbit our AI Assistant summarize what has already been discussed around the task.

This means more of the review can happen asynchronously. The team does not need a meeting simply to show everyone the design, explain the direction, and collect initial feedback. Some questions will still be easier to resolve live, especially when the team needs fast back-and-forth. But by that point, everyone can already see the work and the discussion that led up to it, so the meeting can focus on the part that genuinely needs a conversation.

What changes when the review history stays with the task

The benefit of keeping the review history with the task is that the reasoning behind the design remains available after the review is over.

If something was saved along the line of the review and maybe a dev was not in that review session, he can actually pick that off the conversations as well.

An engineer joining later can see the final design, but also what changed along the way: which requirement shifted, what dependency affected the design, and what the team had already agreed. They do not have to ask someone to retell an old meeting or search through Slack and earlier Figma explorations to understand why the design ended up where it did.

This is important because the output of a design review is not only the latest version of the design. The decisions and reasoning behind it are also part of what the team needs to carry into implementation.