Product managers · problem and fix
Figma designs miss edge cases and error states: fixes for product managers on Mac
Figma designs miss edge cases and error states because many frames show only the happy path. That is the version where data loads, the user has items, and nothing fails. Developers then build what the frame shows, and guess at the rest. This page covers what the gap costs a product team, why it keeps happening, and fixes you can use this week without buying anything.
The short answer
- Designs usually show the happy path. Empty, error, loading and no-permission states often get skipped.
- The cost shows up as developer questions, rework, and bugs that customers find first.
- In Standish CHAOS survey data, as Karl Wiegers reports it, incomplete requirements rank near the top for challenged projects.
- Fix it with a state list per screen, annotations on complex parts, and a short walkthrough before you mark a frame ready for dev.
- Lazur can explain what is on screen and draft your checklist. It cannot audit your Figma file for you.
What missing edge cases in design handoff costs you
Developer time goes to questions
Each open question costs time on both sides. A developer stops, writes a message, waits, then restarts the screen. The Bureau of Labor Statistics lists a median of $135,980 a year for software developers in May 2025, so that waiting has a real salary behind it. Count the questions in one sprint before you argue about the cost.
Rework after review or QA
A screen built on guesses often needs a redesign once QA finds the empty state. The fix is rarely one line. It touches layout, copy, and tests. The rework lands after the team has moved on, which makes it slower and more annoying.
Bugs users find first
Users reach edge cases quickly. A failed payment, an expired coupon, or a very long name can break a layout. If nobody designed those states, the first person to see them is a customer. That is the most expensive place to find a gap.
Missed dates on challenged projects
Incomplete requirements sit near the top of Wiegers' list of factors on challenged projects, based on Standish CHAOS survey responses. That is opinion data, not a measured cause. Still, a late state becomes a late ticket, and late tickets move release dates.
Trust between design and engineering
Every surprise error screen teaches a developer that the frames are not finished. Then the developer stops reading the frames closely. The next handoff gets slower, and both sides start writing long comments instead of drawing the states.
Why it happens
Designs show the happy path first
Review sessions usually focus on the screen someone asked for. The main flow gets drawn, approved, and praised. The states get pushed to later, and later often means never. Look at your last few design reviews and count how many included an empty or error frame. A low count points to this cause.
Requirements arrive incomplete
Karl Wiegers, summarizing Standish Group CHAOS survey data, lists incomplete requirements and specifications at 12.3% of responses on challenged projects. He also names a warning sign. Developers keep asking the analyst or customers many questions. If your developers ask about error messages on every ticket, the requirement was never finished.
Customers and product owners are not in the room
Wiegers links missing requirements to weak customer involvement. Developers then make requirement decisions without adequate information. He recommends a product champion for each user class. Lack of user input ranks first in the same survey summary, at 12.8%. Name one person who speaks for each type of user, and ask that person about states.
Handoff is treated as a one-time event
Many teams treat handoff as a single moment. The designer marks a frame ready, then moves on. Later changes live in chat threads and in people's memory. Figma's Dev Mode keeps frame history and a Compare changes view, but only if someone uses it. Without a record, the build drifts away from the file.
Specs show looks, not behavior
Dev Mode shows measurements, colors, and assets for a frame. It cannot show a case that no frame contains. A developer who opens a file with no empty state sees nothing to copy. The gap looks like finished work, so nobody flags it until QA runs the flow.
Scope creep is often a missed requirement
Wiegers states that apparent scope creep often means requirements were missed during elicitation. When a developer asks for an error screen in the middle of a sprint, the team pays for the gap twice. Treat every late request for a state as evidence that the list was short.
How to fix it
These work with or without any app.
Write a state list for every screen
Before you open Figma, list every state a user can see on the screen. Include default, empty, loading, error, partial data, offline, no permission, very long text, and zero or maximum items. A simple matrix works well in Google Sheets. Put screens down the side, states across the top, and a status cell where each one meets. Keep the file where the whole team can edit it.
Draw the missing states next to the happy path
Each state needs its own frame, placed beside the main flow so reviewers see the gap. Group the frames in one section and name them plainly, such as Cart, Empty. If a piece repeats across screens, a component keeps it consistent. Figma's help center and tutorials cover components in more detail.
Annotate the complex properties
Figma's handbook recommends annotations for details that might make implementation more complex. It also suggests flagging properties that need extra attention so they stand out in Dev Mode. Use annotations for truncation rules, character limits, maximum counts, and the behavior when data is missing. One clear note saves a developer a message.
Use ready for dev as a finish line, not a start line
Figma's Help Center says every plan that includes Dev Mode can set ready for dev on components, frames, and sections. Completed status is limited to Organization and Enterprise plans. Mark a frame ready for dev only when its states are drawn and annotated. Focus view then shows one ready frame at a time, which keeps the review focused.
Write acceptance criteria as test cases early
Wiegers suggests writing test cases early, because they expose requirements nobody defined. Turn each state into a short case. Use a simple form: given the cart is empty, when the user opens it, then the screen shows a message and a button back to browsing. A tester can run the case. A developer can build against it.
Mark known gaps as TBD and set an owner
Wiegers recommends marking known gaps with TBD markers and resolving them before design and construction. He adds that the goal is not a perfect spec. Put TBD beside any state nobody has decided. Give each one a name and a date. A TBD with an owner is progress. A blank space is a bug waiting to happen.
Run a short walkthrough before dev starts
Sit with one developer and one QA person. Go screen by screen through the state list. Ask the developer what they would build for each state, and write down every answer that is not your answer. Those differences are the real gaps. Keep the meeting short, and keep it to the screens that take money or data.
Name a product champion for each user type
Missing requirements often trace back to users nobody consulted. Pick one person for each type of user. That person answers state questions within a day, or sends the question to someone who can. Wiegers recommends this approach. It costs a little attention, not new software.
Why Figma designs miss edge cases and error states in a real handoff
Say your team designs a cart screen. The frame shows three items, a total, and a green Pay button. Nobody drew the empty cart. Nobody drew the screen for a price service that times out, or a coupon that expires while the user is on the page. Each one is a state. Each one is a question a developer must answer alone.
The happy path is not wrong. It is one of many screens the product will show. Figma's own handbook says design intent breaks down with the inevitable edge cases that come along with user-provided content. The same gap appears for any state a user can reach, not only the ones built from user input.
What it costs the team, in time and trust
The cost is mostly time, and time has a price. The Bureau of Labor Statistics reports a median annual wage of $135,980 for software developers in May 2025. Every hour a developer spends guessing at an error state is an hour that salary pays for. Missing states rarely fail loudly. They show up as small costs that add up across a sprint.
- Questions in Slack or Linear comments that stall a ticket for a day
- Rework after QA finds an empty or error state nobody drew
- Bugs that customers find before your team does
- Support tickets that describe a screen nobody designed
- Slower handoffs next time, because developers stop trusting the frames
91%
of developers think the design handoff could be improved, per Figma's 2025 research
Figma Resource Library: 79+ Design Statistics for 202692%
of designers think the design handoff could be improved, per Figma's 2025 research
Figma Resource Library: 79+ Design Statistics for 202684%
of designers say they collaborate with developers at least weekly
Figma Resource Library: 79+ Design Statistics for 202612.3%
of challenged-project survey responses cite incomplete requirements and specifications
Karl Wiegers, 10 Requirements Traps to Avoid (reprint)Figma's 2025 designer-developer research reports that 91% of developers and 92% of designers believe the handoff could be improved. Frequent contact does not fix missing states. It only means the gap gets noticed sooner, if someone looks for it.
Evidence from the requirements research
Requirements research is older than most design tools, but it still gives a useful lens. Karl Wiegers summarized Standish Group CHAOS survey data covering 8,380 IT projects. The chart shows the top three factors he lists for challenged projects. These are shares of survey responses, not measured causes.
Academic critics question how that survey was run, so treat the numbers as a signal. The pattern still matches what you can check in your own bug list. Pull a handful of bugs from the last quarter. Ask whether anyone drew a state for each one. That count tells you more than any chart.
A worked example: the empty cart
Start with one screen. List every state a user can see on it. For the cart, that means items present, cart empty, prices loading, price service failed, coupon expired, item out of stock, and not signed in. Write the list before you open the Figma file.
Next, decide what each state shows and what the user can do next. For the empty cart, the frame needs a message, a clear button back to browsing, and a layout that holds when there are no items. For a failed price service, decide whether to show the last known price or block checkout. That is a product call, so the PM makes it.
Figma Dev Mode and the paid plan question
Dev Mode is part of Figma's paid plans. Figma's Help Center says it is available on Professional, Education, Organization, Government, and Enterprise plans. The pricing page lists Dev seat prices in USD, shown below.
| Plan | Dev Mode included | Dev seat price (USD) | Notes |
|---|---|---|---|
| Professional | Yes | $12 per month | Billing period not stated on the pricing page. |
| Organization | Yes | $25 per month | Billed annually. Completed status is available. |
| Enterprise | Yes | $35 per month | Billed annually. Completed status is available. |
Check the pricing page before you buy anything. You may already have a seat through your company. The state list, the walkthrough, and the acceptance criteria in this page work in a shared doc on any plan.
Mistakes people make when they fix this
- Drawing every state for every screen at once. Start with flows that take money, data, or sign-ins.
- Marking a frame ready for dev before its states exist. That tells the team the work is finished.
- Relying on comments as the only record. Long threads bury them. Put the states in a frame or a ticket.
- Assuming Dev Mode shows behavior. It shows the specs of the frames you designed.
- Skipping the developer. The person who builds the screen sees the gaps you missed.
- Treating every missing state as a design problem. Many of them are product decisions.
Mac setup for a handoff review
The Figma desktop app for Mac runs on Apple silicon and Intel Macs. It needs macOS 12 Monterey or later, according to Figma's Help Center. You can also install a beta app next to the regular one. Figma labels it Figma Beta.
Figma removes support for older desktop versions six months after a release. Update the app the day before a review, not during the call. During the review, keep Figma in front and your state list beside it. Use ⌘ Tab to move between them.
Where Lazur fits, and where it does not
Lazur is a voice assistant for the Mac. Hold ⌥ ⌘ to ask about anything on screen, and Lazur answers out loud. It can point at a control and draw a circle around it. It can guide you one click at a time, waiting for each click. It does not click for you, edit your Figma file, or act as a plugin inside Figma.
For this problem, the useful jobs are small. Ask what a Dev Mode panel shows. Ask where an option sits. Hold fn to dictate your state list into Notion. Ask Lazur to draft acceptance criteria, then read them before you paste them into Linear. Lazur does not scan your file for missing states. You still decide which states matter.
Client and patient data in mockups
If your product handles client files or patient records, follow your employer's rules before you share a screen with any AI assistant. Lazur sends audio and the screenshot to AI providers to answer them. They are not stored. Use sample data in mockups and reviews when you can.
Keep the state list alive after handoff
States change after handoff. Someone adds an error message, a designer fixes a spacing bug, and a developer asks for a loading view. Dev Mode keeps frame history. Use Compare changes to see what moved between versions before you approve a build.
Mark frames ready for dev only after the states exist. If a frame changes later, add a comment that says what changed and why. Link that comment in the ticket so the next person can find it.
Faster with Lazur
Where Lazur helps with missing edge cases in design handoff
Hold ⌥ ⌘ and say what you want. Lazur sees your Figma window. Lazur draws a circle and a label around the button or menu you need.
- 1
Hold ⌥⌘ and talk
- 2
Lazur draws a circle and a label around the button or menu you need.
- 3
You stay in Figma. Nothing to copy into a chat window.
More things to say in Figma
- “Where is Compare changes in this frame?”
- “Explain what this Dev Mode panel shows for the selected frame.”
- “Walk me through marking this frame ready for dev.”
- “Hold fn and dictate the state list into Notion.”
- “Draft acceptance criteria for these five states.”
- “Research how other apps word empty cart screens.”
Free for 3 days, then $18/month. Download for Mac
You say“Where is Compare changes in this frame?”
Lazur · points at itLazur draws a circle and a label around the option. You make the click yourself.
What product managers say to Lazur for this
Each one is a single hold of ⌥ ⌘.
“Where is Compare changes in this frame?”
Lazur draws a circle and a label around the option, so you click it yourself.
Points at it
“Explain what this Dev Mode panel shows for the selected frame.”
Lazur reads the panel on screen and explains each part out loud.
Explains what's on screen
“Walk me through marking this frame ready for dev.”
Lazur gives you one click at a time and waits for each click before it goes on.
Walks you through it
“Hold fn and dictate the state list into Notion.”
Your spoken list lands as clean, formatted text at the cursor, in any app.
Types what you say
“Draft acceptance criteria for these five states.”
Lazur writes the criteria as text for you to check before you paste it anywhere.
Drafts it
“Research how other apps word empty cart screens.”
Research runs in Lazur's own Chrome tabs and comes back with a summary and a report.
Researches in the background
“Remind me to walk the states with dev tomorrow morning.”
Lazur adds an Apple Reminders entry you can see on your Mac.
Handles the small stuff
A plan you can start this week
- Day 1 morning
Find the gaps you already shipped
Pull a few recent bugs from Linear or Slack. Mark each one that came from a state the design never drew. Put those in one list. You now have evidence for the team, not just an opinion about the process.
- Day 1 afternoon
Write the state list
Pick one flow that handles money or data. List every state for each screen in Google Sheets or Notion. Add an owner column and a status column. Leave TBD where nobody has decided.
- Day 2 morning
Walk it with a developer
Sit with one developer and one QA person for a short walkthrough. Go screen by screen. Write down every answer that differs from yours. Mark unresolved states TBD with a name next to each.
- Day 2 afternoon
Draw and annotate the gaps
Draw missing states in Figma beside the happy path. Annotate limits, truncation, and empty data. Mark a frame ready for dev only after its states exist and are annotated.
- Day 3
Turn states into acceptance criteria
Convert each state into a short test case in Linear. Use the form: given the condition, when the user acts, then the screen shows this. Read more about setting up Linear for product work at /for/product-managers/linear.
- Day 5
Check the first build
After the first build, compare the built screens with the frames. For any frame that moved, use Compare changes in Dev Mode. Log each mismatch in the ticket, not in a chat thread.
Questions people ask
Why doesn't Figma flag missing edge cases for me?
Figma's Dev Mode guide covers ready for dev, Focus view, and Compare changes. It does not describe a check for missing states. Dev Mode shows specs for frames you drew, so a state nobody drew stays missing until someone adds it.
Do I need a paid Figma plan to fix this?
No. The state list, the walkthrough, and the acceptance criteria work on any plan. Dev Mode itself needs Professional or a higher plan, according to Figma's Help Center. Check Figma's pricing page for current prices.
How many states should each screen have?
Enough to cover what a user can see on that screen. A login screen has fewer states than a checkout. Start with states that touch money, data, or permissions. There is no fixed count that fits every product.
Is Lazur a Figma plugin?
No. Lazur is a voice assistant for the Mac, not a plugin or add-in for any app. It does not click or edit files for you. Hold ⌥ ⌘ and it can explain what is on your screen out loud.
Can Lazur read my whole Figma file and list the missing states?
No. Lazur sees your screen while you hold the shortcut, and it answers about what is visible. It cannot check the whole file for you. Use your state list as the check.
What about client or patient data in mockups?
Follow your employer's rules before you share screens with any AI assistant. Lazur sends audio and the screenshot to AI providers to answer, and does not store them. Use sample data in reviews when you can.
Do I need the Figma beta app?
No. The regular Figma desktop app for Mac is enough for most reviews. Figma can install a beta next to it, labeled Figma Beta, if you want to test new features.
Is there a Windows version of Lazur?
Lazur runs on macOS, on Apple silicon and Intel Macs. Windows is planned, not available. Check the download page for the current requirements before you install.
Sources
- Figma Resource Library: 79+ Design Statistics for 2026 · Figma · checked 2026-11-08
- Karl Wiegers, 10 Requirements Traps to Avoid (reprint) · Harvey Mudd College (reprint of Wiegers article) · checked 2026-11-08
- The designer's handbook for developer handoff · Figma · checked 2026-11-08
- Guide to Dev Mode in Figma · Figma Help Center · checked 2026-11-08
- Figma Pricing · Figma · checked 2026-11-08
- Guide to the Figma desktop app · Figma Help Center · checked 2026-11-08
- Software Developers: Occupational Outlook Handbook · U.S. Bureau of Labor Statistics · checked 2026-11-08
Fix missing edge cases in design handoff with Lazur, free for 3 days
Hold a key and ask. Lazur sees your screen, points at the button and talks you through it, in any Mac app. No credit card.