Figma Component Best Practices Audit

מבצע ביקורת על קובצי Figma כדי לזהות חוסר עקביות, שימוש לא יעיל בקומפוננטות, והמלצה על אופטימיזציות לשמירה על סקיילביליות וקלות תחזוקה.

תחום: עיצוב

מתי להשתמש

יש להפעיל מיומנות זו לפני מסירה של קבצי עיצוב למפתחים, או כאשר עובדים על פרויקט עיצוב גדול הדורש עקביות ותחזוקת קומפוננטות יעילה.

תגיות: Figma, Design System, UX/UI, Optimization, Component Audit

SKILL.md

--- name: Figma Component Best Practices Audit description: Audits Figma files for inconsistencies, inefficient component usage, and recommends optimizations for scalability and maintainability. --- ## Overview This skill helps designers maintain clean, efficient, and scalable Figma files by auditing their component usage against best practices. It identifies issues such as unlinked instances, inconsistent naming conventions, unnecessary complexity in components, and opportunities for componentization. The goal is to improve collaboration, reduce design debt, and streamline the handover process to development. ## When to use Invoke this skill when: 1. Preparing design files for developer handoff. 2. Integrating new features into an existing design system. 3. Onboarding new designers to a project to ensure adherence to standards. 4. Experiencing performance issues with large Figma files due to complex component structures. 5. Periodically to maintain the health and consistency of your design system. ## How it works 1. **Input Analysis**: The user provides the shared link to a Figma file or a detailed description of the Figma file's component structure and usage patterns. If a link is provided, Claude will simulate analyzing the file based on typical Figma structures and user descriptions. 2. **Best Practice Comparison**: Claude compares the described component usage against established Figma and design system best practices, including (but not limited to): * Using variants and properties effectively. * Maintaining a clear naming convention (e.g., BEM, atomic design principles). * Ensuring all design elements that should be components *are* components. * Identifying instances that potentially lost their parent component link. * Detecting redundant components or layers that can be simplified. * Assessing the modularity and reusability of components. 3. **Issue Identification**: Based on the comparison, Claude pinpoints specific areas of concern in the Figma file. 4. **Actionable Recommendations**: Claude provides concrete, step-by-step recommendations for improving the Figma file's component structure and usage, complete with rationale. 5. **Summary Report**: Delivers a comprehensive report summarizing findings and recommendations. ## Example usage **User Input:** "I need an audit of my Figma file. We've built out a new section for our e-commerce site, and I want to ensure our components are set up correctly before we hand it off. We have buttons, form fields, and product cards. I'm concerned about consistency and if we've used variants correctly. Here's a brief description of how we've organized it: * Buttons: We have primary, secondary, and tertiary buttons, each with small, medium, and large sizes. They are all separate components named `Button/Primary/Small`, `Button/Secondary/Medium`, etc. * Form Fields: We have text inputs, dropdowns, and checkboxes. Text inputs are one component, but dropdowns and checkboxes are separate frames that we copy-paste. * Product Cards: These are built as a main component `ProductCard`, but designers often detach instances to change text or images, then re-group them. We have variants for 'on sale' and 'out of stock' states. Please provide an audit focusing on efficiency, scalability, and adherence to Figma best practices." **Claude's Expected Output (simulated):** ```markdown ### Figma Component Audit Report **Overall Assessment:** The file shows a good foundation for component usage but has several areas for optimization to improve scalability, maintainability, and consistency. --- #### Findings & Recommendations: 1. **Buttons Component Structure:** * **Finding:** Buttons are currently structured as separate components for each state and size (e.g., `Button/Primary/Small`). This approach creates a large number of individual components and makes updates difficult. * **Recommendation:** Refactor button components to use ***variants and properties*** within a single main `Button` component. Create properties for `Type` (Primary, Secondary, Tertiary) and `Size` (Small, Medium, Large). This will significantly reduce component count, improve reusability, and centralize updates. * **Example (Conceptual):** A single `Button` component with two properties: `Type` (Primary | Secondary | Tertiary) and `Size` (Small | Medium | Large). 2. **Form Fields Componentization:** * **Finding:** Text inputs are components, but dropdowns and checkboxes are described as 'separate frames that we copy-paste'. This introduces inconsistency and makes global updates impossible. * **Recommendation:** Convert all distinct form elements (dropdowns, checkboxes, radio buttons, etc.) into ***reusable Figma components***. Implement variants for different states (e.g., Default, Hover, Focused, Disabled, Error, Filled) for each field type. This ensures consistency and allows for easy updates across the entire design. * **Actionable Step:** Create a `Dropdown` component with variants for opened/closed states, and a `Checkbox` component with variants for checked/unchecked/indeterminate/disabled states. 3. **Product Card Instance Management:** * **Finding:** Designers frequently detach instances of `ProductCard` to make content changes. While variants exist for 'on sale' and 'out of stock', detaching instances breaks the link to the main component, preventing future updates from propagating. * **Recommendation:** Implement ***content properties*** (e.g., `Image`, `Title`, `Price`, `Description`) for the `ProductCard` main component. Also, consider using ***nested components*** for elements like price tags or call-to-action buttons within the card. This allows for content overrides directly on the instance without detaching, maintaining the component link. * **Actionable Step:** Add content properties to the `ProductCard` component for dynamic text and image content. Educate designers on using content overrides instead of detaching. 4. **Naming Conventions & Organization:** * **Finding:** While `Button/Primary/Small` shows some structure, consistency across all components is unclear. The existing button naming can be improved by adopting a more scalable convention or relying more on variants. * **Recommendation:** Establish a clear and consistent **naming convention** for all components and layers (e.g., using a `/` structure for categories, or following a design system methodology like Atomic Design). Group related components within their respective pages in Figma (e.g., 'Buttons', 'Form Fields', 'Cards'). * **Actionable Step:** Review and standardize the naming of all new and existing components to create a logical and easily searchable component library. --- **Next Steps:** Prioritize addressing the button and form field componentization issues first, as these will have the largest impact on consistency and efficiency. Follow up with refining the Product Card component and establishing universal naming conventions. Regular audits (e.g., monthly or per major feature release) are recommended to maintain design system health. ``` ## References * [Figma Documentation: Components](https://help.figma.com/hc/en-us/articles/360038622154-Guide-to-components-in-Figma) * [Figma Documentation: Variables & Modes](https://help.figma.com/hc/en-us/articles/9323315682199-Variables-and-Modes-in-Figma) * [Figma Documentation: Properties](https://help.figma.com/hc/en-us/articles/12693899434007-All-about-component-properties) * [Brad Frost: Atomic Design](https://atomicdesign.bradfrost.com/) * [Figma Best Practices for Design Systems](https://www.figma.com/blog/build-a-design-system-in-figma-best-practices/)