You Do Not Need to Be a Designer
Product managers do not need to learn Figma the way designers use it. You do not need to know how to draw frames, create auto-layouts, or build component variants. What you need is to read design files confidently, leave comments that actually help, and understand enough about design systems to have informed conversations with your product trio.
Most PM-focused Figma guides teach you how to design. This one teaches you how to collaborate with designers effectively, which is a different and more valuable skill.
Reading Figma Files
When a designer shares a Figma link, you are looking at one of two things: a design file (static screens) or a prototype (clickable flow). Knowing which one you are looking at changes how you review it.
Navigating design files
The left panel shows the page structure. Designers organize files into pages, typically one per feature area or flow. Click through pages to find what you need. If the file has dozens of pages and you cannot find anything, ask the designer for a walkthrough. Poorly organized Figma files are common, and it is not your job to decode them.
Key things to look for
When reviewing a design, PMs should focus on:
- User flow completeness. Does the design cover the full happy path? What about error states, empty states, loading states, and edge cases? The most common design gap is missing states. If the designer only shows the "everything works perfectly" version, ask about the rest.
- Content accuracy. Are the labels, microcopy, and data examples realistic? Placeholder text like "Lorem ipsum" or "John Doe" hides content problems. Real content reveals whether the layout actually works with actual data.
- Interaction patterns. How does the user move between screens? Where are the entry points and exit points? Designers sometimes create beautiful individual screens without clearly defining how the user transitions between them.
- Consistency. Does this new screen match the existing product? Look for font size discrepancies, different button styles, or spacing that feels off compared to what is already shipped. You do not need to measure pixels. If something looks different, flag it.
Using the comment and inspection tools
Press C to enter comment mode. Click anywhere on the canvas to leave a comment. Use @ mentions to tag specific people. Keep comments anchored to the specific element you are discussing, not floating in empty space.
For inspection, click any element and look at the right panel. You can see dimensions, spacing, colors, and fonts without asking the designer. This is useful when you need to reference specific values in a spec or ticket.
Leaving Useful Comments
The quality of PM feedback in Figma directly affects the design process. Vague comments slow things down. Specific, actionable comments speed things up.
What good PM comments look like
Instead of: "This feels off."
Write: "The CTA button is below the fold on mobile. Can we move it above the feature list so users see it without scrolling?"
Instead of: "Can we make this simpler?"
Write: "This form has 8 fields. Our analytics show 60% drop-off at field 5. Can we split this into 2 steps or remove the optional fields?"
Instead of: "Love it!"
Write: "This covers the happy path well. Can you add the empty state (new user, no data yet) and the error state (API timeout)?"
The comment framework
Structure your feedback around these questions:
- Does it solve the user problem? Reference the problem statement from the PRD or the user research that informed this design.
- Is it technically feasible? If you know about constraints (API limitations, performance concerns, third-party integrations), surface them early.
- What is missing? Edge cases, error handling, accessibility, and responsive behavior are common gaps.
- What are the trade-offs? If a design is more complex than expected, discuss scope with the designer rather than cutting features unilaterally in a comment.
Timing matters
Leave design feedback early in the process, ideally during exploration or low-fidelity stages. Requesting fundamental changes after high-fidelity designs are complete is expensive and demoralizing for the designer. If you are only seeing designs for the first time at the high-fidelity stage, the product trio process needs fixing.
Understanding Design System Components
You do not need to build components, but understanding what they are changes how you think about product features.
What components are
A design system component is a reusable UI element: a button, a card, a modal, a navigation bar. Designers build these once and reuse them across the entire product. When the button style changes in the component library, it updates everywhere.
Why PMs should care
Components constrain what can be built quickly. If your product has a well-maintained design system, features that use existing components ship faster than features that require new ones. When scoping work:
- Ask the designer: "Can this be built with existing components, or does it need new ones?" New components add design and engineering time.
- Check the component library. Most design systems have a Figma page or separate file listing all available components. Browse it to understand what your team has to work with.
- Consider design system debt. If designers keep creating one-off components instead of reusing existing ones, the product's visual consistency degrades over time. This is the design equivalent of technical debt.
Component naming conventions
Designers name components with a hierarchical slash notation: Button/Primary/Large, Card/Feature/With Image, Input/Text/Error State. When engineers reference these names in code, they need to match. PMs who understand this naming convention can write clearer specs and catch inconsistencies between design and implementation.
Using FigJam for Workshops
FigJam is Figma's whiteboard tool. For PMs, it is useful for remote workshops, brainstorming sessions, and collaborative planning exercises.
PM-specific FigJam uses
Design sprints. FigJam has templates for the full design sprint process: mapping, sketching, deciding, prototyping. The built-in voting (dot stickers) and timer features make facilitation easier.
Story mapping. Create a story map with sticky notes arranged in the classic backbone (activities) and walking skeleton (user tasks) structure. Color-code by release or priority. This works surprisingly well as a remote equivalent of the physical sticky-note wall.
Retrospectives. The "Start, Stop, Continue" template is built in. Team members add stickies asynchronously before the meeting, then you group and discuss live. This saves 15 minutes of silent writing time in the actual meeting.
Prioritization exercises. Set up a 2x2 matrix (impact vs effort, or value vs complexity) and have the team place sticky notes for each feature candidate. FigJam's voting feature lets everyone dot-vote independently before discussion.
FigJam facilitation tips
- Prepare the board before the session. Do not set up the template live while people wait. Have sections, instructions, and examples ready before participants join.
- Use the timer. Timeboxing exercises prevents discussions from running over. FigJam's built-in timer is visible to all participants.
- Lock the background. After setting up the structure, lock the frames so participants cannot accidentally move them. Only stickies and stamps should be unlocked.
- Export the results. After the session, screenshot the key outcomes and share them in your meeting notes or decision log. FigJam boards get messy fast and are hard to reference later without a clean summary.
Dev Mode for Handoff Review
Figma's Dev Mode is designed for engineers, but PMs benefit from understanding it too.
What Dev Mode shows
Switch to Dev Mode (the toggle) and click any element to see:
- CSS properties: Exact colors, fonts, spacing, and dimensions
- Component details: Which design system component is being used and its variant
- Annotations: Designer-added notes about behavior, animations, or interactions
- Asset exports: Icons and images ready for download
Why PMs should use Dev Mode
When reviewing implemented features, Dev Mode lets you compare what was built against what was designed. Click the design element, check the specs, then compare against the shipped product. This is faster than asking the designer "does this match the mockup?" and more precise than eyeballing it.
Dev Mode also helps when writing tickets. Instead of describing a UI change in words ("make the button bigger and change the color"), you can reference the exact specs: "Update the CTA to match the Button/Primary/Large component: 16px padding, #06B6D4 background, 600 font weight."
Prototypes and User Testing
Figma prototypes are clickable versions of the design that simulate the user experience. PMs use them in two contexts: internal review and external user testing.
Internal prototype review
When a designer shares a prototype link, click through every path. Specifically:
- Test the primary flow end-to-end
- Try to break it (click things that should not be clickable, navigate backward, try unexpected paths)
- Check mobile vs desktop behavior if the design is responsive
- Time yourself going through the flow. If it takes you 30 seconds to complete a task and you already know the interface, a new user will take much longer
Prototype-based user testing
Figma prototypes are good enough for concept testing and basic usability testing. They are not good enough for testing interactions that depend on real data, performance, or complex state management.
For prototype testing, set up the prototype so it covers the specific task you are testing. Remove dead ends (clicks that go nowhere) or add a "not yet built" screen so participants do not get stuck. Share the prototype link directly with participants or use it within your usability testing platform.
Making Figma Work for PMs
Figma is a design tool that PMs can use effectively without becoming designers. The key habits:
- Review designs early and often. The earlier you provide feedback, the less rework is needed. Ask to be added to design files at the exploration stage, not the handoff stage.
- Learn to read, not to draw. Your value in Figma is feedback quality, not design production. Invest time in understanding components and flows rather than learning how to manipulate frames.
- Use FigJam for workshops. It is the fastest way to run remote collaborative sessions. The built-in templates eliminate setup time.
- Reference specs in tickets. When you can cite exact component names and dimensions, engineering tickets become unambiguous. This reduces back-and-forth by 50% or more.
- Stay out of the designer's way. PMs who rearrange elements, duplicate screens, or create their own mockups in the designer's file are not being helpful. Use comments and conversations, not direct manipulation.