My first plugin submission to the Figma Community was rejected on the initial review, not because the actual functionality was broken, but because of several specific presentation and metadata details I had not adequately addressed, having assumed working code alone was sufficient for approval.
Why Working Code Alone Is Not Sufficient
This is the core lesson my first rejection taught me directly. The Figma Community review process evaluates more than just whether your plugin functions correctly — it also considers presentation quality, clear communication of what your plugin actually does, and adherence to specific community guidelines that go beyond pure functional correctness.
Preparing Your Plugin Listing Content
A clear, specific name: Your plugin’s name should clearly communicate its core function, avoiding overly generic or vague naming that does not help potential users understand what the plugin actually does before installing it.
A genuinely informative description: Beyond a single vague sentence, your description should clearly explain what specific problem your plugin solves and how to actually use it, written from the perspective of someone who has never seen your plugin before and needs enough information to determine whether it genuinely addresses their need.
Quality preview images or video: Visual demonstration of your plugin actually working, showing real before-and-after results or the actual interface in use, helps potential users understand your plugin’s value considerably better than text description alone, and the Community review process does evaluate whether your provided visuals adequately represent your plugin’s actual functionality.
Technical Requirements Beyond Basic Functionality
Appropriate manifest configuration: As covered in our plugin development guide, your manifest file needs correct configuration, but for publishing specifically, also ensure your manifest includes appropriate metadata fields beyond just the basic file references needed for local development and testing.
Reasonable performance: Plugins that are noticeably slow or unresponsive, particularly for their core described function, may face review concerns beyond simply working correctly in a narrow technical sense, since genuine usability, not just technical functionality, factors into the review consideration.
Appropriate permission requests: If your plugin requests specific permissions (network access, for example), ensure these requested permissions genuinely match what your plugin’s described functionality actually requires, since requesting permissions beyond what your stated functionality justifies can raise review concerns about why these additional permissions are being requested.
Common Rejection Reasons Beyond My Own Experience
Based on both my own experience and conversations with other plugin developers who have gone through this process, several rejection reasons recur with some frequency beyond the presentation issues that caused my own first rejection.
Functionality that duplicates existing, well-established Community plugins without genuine differentiation: If your plugin’s core function very closely duplicates an already well-established Community offering without providing some genuinely distinct value or approach, this can raise review questions about your submission’s unique value, though this does not mean similar functional categories are automatically rejected, simply that genuine differentiation from very closely overlapping existing options matters.
Insufficient testing across different document scenarios: Similar to the development-stage testing discussed in our plugin development guide, plugins that work in narrow testing scenarios but break or behave unexpectedly across more varied real-world document structures may face review issues if these problems surface during the review process’s own testing.
Unclear or missing instructions for non-obvious functionality: If your plugin’s actual usage is not immediately self-evident from its interface alone, providing clear in-plugin instructions or adequate description-based explanation becomes more important, since reviewers (and eventual users) should not need to guess at non-obvious functionality without adequate guidance.
The Actual Submission and Review Process
Once your plugin and its listing content are prepared, submission happens through Figma’s official developer console, which provides the current specific submission interface and process steps, again something worth referencing directly from Figma’s own current documentation rather than a potentially outdated secondhand description here, since this specific interface and process has evolved somewhat over the years I have been submitting plugins.
Review timeframes vary, and patience during this review period is genuinely necessary, since rushing to resubmit immediately after any rejection without adequately addressing the specific feedback provided tends to produce repeated rejection cycles rather than genuine progress toward approval.
Responding to Rejection Feedback Effectively
If your initial submission is rejected, as mine was, carefully reading and specifically addressing the actual feedback provided, rather than making only superficial changes and hoping for different results on resubmission, genuinely improves your chances on the next submission attempt.
For my own first rejection, this meant substantially rewriting my description to more clearly explain actual functionality, creating better preview visuals genuinely demonstrating the plugin in realistic use, and double-checking that my requested permissions matched my actual described functionality — addressing each specific piece of feedback directly rather than simply resubmitting the identical content with only minor unrelated tweaks.
Post-Publication Considerations
Once published, maintaining your plugin — addressing user-reported issues, updating for Figma platform changes over time, and potentially expanding functionality based on genuine user feedback — represents an ongoing commitment beyond the initial publication achievement itself, worth considering before publication whether you are genuinely prepared for this ongoing maintenance responsibility, rather than treating publication as a one-time completed task with no further ongoing obligation.
A Quick Reference Pre-Submission Checklist
| Category | Check |
|---|---|
| Naming | Clear, specific, communicates core function |
| Description | Genuinely informative, explains problem solved and usage |
| Visuals | Quality images/video showing actual real functionality |
| Manifest | Complete, appropriate metadata beyond basic dev requirements |
| Performance | Reasonably responsive for core described function |
| Permissions | Match actual functionality, no unjustified excess requests |
| Testing | Across varied document scenarios, not just narrow testing |
| Differentiation | Genuine distinct value if functionally similar to existing options |
What I Learned From My Rejected First Submission
That initial rejection, while frustrating at the time, taught me that the Community review process genuinely cares about more than narrow technical functionality, and addressing presentation, clear communication, and appropriate technical configuration with the same care I had applied to the actual core functionality considerably improved my subsequent submission’s success, both for that specific resubmission and for every plugin I have published since, having internalized this broader view of what publication-readiness genuinely requires beyond just working code.
Where are you in your plugin’s development — still building core functionality, or preparing for submission? Describe your situation and I can help you think through the specific next steps for your stage.