I spend a lot more time in Figma as an engineering manager than I expected to. I am still not the person anyone should ask to adjust kerning. I am there because a design file is often the first place I can see the work becoming real.
A clean frame can make a feature look settled. Then an engineer opens it and asks what happens when the request fails, the account has no data, or somebody pastes a name long enough to ruin the afternoon. Those questions are part of the product. Figma gives us a place to ask them before the answer becomes whatever was easiest to build on Thursday.
I use the file to understand intent, find missing decisions, and help the team agree on the size of the work. I have no interest in hovering over a designer and requesting that a button move four pixels to the left. They would stop inviting me, and they would be right.
I read the file before refinement
I like to open the Figma file before a story reaches refinement. I click through the prototype, read the notes, and follow the path a user is supposed to take.
I am looking for the point where the design and the ticket start telling different stories. Maybe the ticket says “edit profile,” while the design includes image cropping, validation, a confirmation state, and a new permissions rule. None of those pieces are unreasonable. Together, they are a different amount of work.
Finding that gap before refinement gives the product manager, designer, and tech lead time to talk about it. We can decide whether the whole flow belongs in the first release or whether one part can wait. The conversation goes much better while we are looking at a frame instead of an estimate somebody has already repeated to leadership.
The interesting work lives around the frame
The main flow gets most of the attention because it has something worth presenting. I spend more time looking around it.
I check the empty state and the failure state. I look for what happens while data loads and whether the person can back out halfway through. If the screen changes based on a role or permission, I want to see which version each person gets.
Responsive behavior deserves the same attention. A desktop frame can hide a pile of decisions about what wraps, what collapses, and what disappears on a phone. “Make it responsive” leaves an engineer to answer those questions in CSS. Sometimes that is fine. Sometimes the mobile version needs a different order because the desktop layout depended on space that no longer exists.
I am not trying to make the file exhaustive. I want the team to notice the decisions with engineering cost or product risk. A missing hover color can wait. A missing path for a failed payment cannot.
My comments need to earn their little pin
Figma comments can turn into a wall of colored dots with no owner and no conclusion. I try to leave comments that help somebody make a decision.
“Can we rethink this?” gives the designer a mood. “Do we keep the entered values when this request fails?” gives them a behavior to answer.
I add the reason when it changes the conversation. A question about a modal may come from keyboard focus, browser history, or the amount of state the team would need to preserve. That context lets the designer solve the underlying problem instead of treating my comment as a design request from somebody proud to have discovered rectangles.
I also avoid using comments for a conversation that needs five people. If a thread has product scope, API behavior, and design intent tangled together, I pull the group into a short call and put the decision back in the file afterward. Nobody should have to reconstruct a product decision from fourteen replies under a pin labeled “Question.”
I use the file to talk about scope
A backlog item can make a feature sound like one thing. A Figma file shows the surfaces it touches.
I can see that a new setting also changes onboarding. The table needs a new column, which changes the mobile layout. The confirmation message needs data the current API does not return. Those connections help me ask better questions about sequencing and staffing.
The file also helps when we need to cut scope. Pointing at a frame is more useful than saying, “We need a smaller MVP,” and waiting for somebody else to perform the shrinking. We can keep the core path, postpone a secondary state, or reuse an existing component for the first pass. Everybody can see what stays and what moves.
That conversation includes the designer. Cutting a random frame can break the logic of the flow. I want the person who designed the experience in the room while we decide which parts can move without leaving a weird hole for the user.
Engineers should get into Figma early
I do not want the first engineering review to happen after design hands over a finished file. A tech lead or engineer can spot a constraint while the team still has room to respond to it.
They may know that we already have a component that covers most of the interaction. They may see that a transition depends on data we do not have, or that the proposed table will have a bad time with the amount of content customers put in it. That input makes the design stronger and gives the engineer context before a ticket lands in the sprint.
I ask engineers to comment on behavior and constraints, then work with the designer on the answer. I do not want them treating the frame as a contract or building a different version without telling the designer because the original looked hard. Both paths create a surprise for someone.
I am there to connect decisions
I am not the design approver. My job is to make sure the right conversations happen with enough time to change the answer.
Figma lets me connect the design to the people building it, the product decision behind it, and the delivery plan around it. I can see where the team still owes an answer and where a small visual choice carries a larger implementation cost.
I keep the file open while the work moves through development. If an engineer finds a missing state, we add it. If the implementation exposes a bad assumption, we talk about it in the same place we made the first decision. The file becomes a record of how the feature works instead of a picture of how we thought it might work three weeks ago.
That is enough Figma for me. The designers can keep the kerning.