30 Claude Prompts for Figma

You are a senior design systems designer who has set naming conventions across large Figma libraries. <context> Our Figma library has inconsistent component names and I need a naming convention the whole design team can follow. </context> <inputs> - Component categories in use: [COMPONENT CATEGORIES] - Current naming examples that are messy: [CURRENT NAMING EXAMPLES] - Team size: [TEAM SIZE] - Tooling used alongside Figma: [TOOLING LIST] </inputs> <task> Define a naming convention with a clear pattern for category, component name, and variant, then rewrite the messy examples I gave you using the new pattern so the team can see it applied. </task> <constraints> Use a consistent separator and casing throughout, do not mix styles. Keep the pattern to three or fewer segments so names stay readable in the layers panel. Explain the reasoning in one sentence per rule, not a long essay. </constraints> <format> Return a Pattern line, then a Rules list, then a Before and After table for the examples provided. </format>

You are a senior Figma specialist who plans auto layout structure before building components. <context> I am about to build a component in Figma and want to plan the auto layout hierarchy first so it resizes correctly. </context> <inputs> - Component name: [COMPONENT NAME] - Content it must hold: [CONTENT LIST] - Responsive behavior needed: [RESPONSIVE BEHAVIOR] - Known edge cases: [EDGE CASES] </inputs> <task> Plan the frame hierarchy for this component: which frames need auto layout, which direction each one runs, and which elements need fixed versus fill sizing, so the component resizes correctly when content changes. </task> <constraints> Describe the hierarchy in nesting order, top level frame first. Call out any element that should NOT use auto layout and explain why. Do not describe colors or typography, this is structure only. </constraints> <format> Return a nested list showing frame name, layout direction, and sizing mode for each level. </format>

You are a senior design systems designer who structures Figma component variants. <context> I am building a button component with variants in Figma and want the variant properties named cleanly before I set them up. </context> <inputs> - Visual states needed: [VISUAL STATES] - Sizes needed: [SIZE OPTIONS] - Icon configurations: [ICON CONFIGURATIONS] - Existing property naming in the library: [EXISTING PROPERTY NAMES] </inputs> <task> Define the variant properties this button needs, name each property and its possible values, and flag any combination that should not be allowed as a real variant. </task> <constraints> Keep property names short and consistent with the existing naming I gave you, do not invent a different style. List invalid combinations explicitly so the team does not build states that will never ship. </constraints> <format> Return a table with columns Property, Values, and Notes on invalid combinations. </format>

You are a senior design systems designer who defines design token naming schemes. <context> I am setting up design tokens for color, spacing, and typography in Figma and need a naming scheme before creating the variables. </context> <inputs> - Token categories needed: [TOKEN CATEGORIES] - Current ad hoc names in use: [CURRENT AD HOC NAMES] - Number of themes to support: [THEME COUNT] - Developer handoff tool: [DEV HANDOFF TOOL] </inputs> <task> Define a naming scheme for the token categories that separates the raw value layer from the semantic usage layer, and rename the ad hoc examples I gave you into the new scheme. </task> <constraints> Use a clear two tier structure, primitive tokens and semantic tokens, do not collapse them into one flat list. Keep segment count in each name to four or fewer. Note any name that developers would find confusing next to their existing code variables. </constraints> <format> Return Primitive Layer examples, Semantic Layer examples, and a rename table for the ad hoc names. </format>

You are a senior design systems designer who audits Figma libraries for drift and duplication. <context> Our Figma library has grown messy over time and I need an audit plan before I start cleaning it up. </context> <inputs> - Total component count: [COMPONENT COUNT] - Known duplicate components: [KNOWN DUPLICATES] - Components suspected unused: [SUSPECTED UNUSED] - Team size using the library: [TEAM SIZE] </inputs> <task> Write an audit plan that orders the cleanup work by risk and impact, starting with the duplicates and unused components I listed, and propose a rule to prevent this drift from happening again. </task> <constraints> Do not propose auditing everything at once, break it into phases a single designer could realistically execute over a few weeks. Keep the prevention rule to one sentence, not a policy document. </constraints> <format> Return a phased plan, Phase 1 through Phase 3, plus one Prevention Rule at the end. </format>

You are a senior design systems writer who documents component usage rules. <context> I need usage guidelines written for a component in our design system documentation site so other designers use it correctly. </context> <inputs> - Component name: [COMPONENT NAME] - Correct use cases: [CORRECT USE CASES] - Common misuse seen so far: [COMMON MISUSE] - Related components it is often confused with: [RELATED COMPONENTS] </inputs> <task> Write a usage guidelines page for this component covering when to use it, when not to use it, and how it differs from the related components it gets confused with. </task> <constraints> Use plain declarative sentences, do not pad with filler like it is important to note. Include the actual misuse example I gave you as a do not example, generic advice will not stop a repeated mistake. </constraints> <format> Return three sections: When to Use, When Not to Use, How It Differs From [RELATED COMPONENTS]. </format>

You are a senior design systems lead who writes the founding principles page for a design system. <context> We are launching a documentation site for our design system and need a principles page that explains why the system is built the way it is. </context> <inputs> - Product type: [PRODUCT TYPE] - Company values relevant to design: [COMPANY VALUES] - A past design decision this should justify: [PAST DECISION] - Audience reading this page: [AUDIENCE] </inputs> <task> Write four to five principles that explain how decisions in this design system get made, and connect at least one principle directly to the past decision I described so readers see it applied, not just stated. </task> <constraints> Each principle needs one sentence of explanation and one concrete example, a principle with no example is just a slogan. Do not write generic values like consistency matters without tying it to something specific about this product. </constraints> <format> Return a numbered list of principles, each with a Principle line and an Example line. </format>

You are a senior accessibility specialist who writes accessibility guidelines for design systems. <context> I need an accessibility guidelines page for our design system documentation covering the components we ship most often. </context> <inputs> - Components to cover: [COMPONENT LIST] - Compliance target: [COMPLIANCE STANDARD] - Known current gaps: [KNOWN GAPS] - Primary users with accessibility needs: [USER NEEDS] </inputs> <task> Write accessibility requirements for each listed component covering contrast, focus states, and screen reader labeling, and call out the known gaps I mentioned as items still needing a fix, not as if they are already solved. </task> <constraints> Be specific about numeric contrast ratios and focus indicator requirements, not vague statements like ensure good contrast. Clearly separate what is already compliant from what is still a known gap. </constraints> <format> Return one section per component with Requirements and Known Gaps subheadings. </format>

You are a senior design systems maintainer who writes changelog entries for component updates. <context> I just updated a component in our design system and need a changelog entry so other designers and engineers know what changed and why. </context> <inputs> - Component updated: [COMPONENT NAME] - What changed: [CHANGE DESCRIPTION] - Reason for the change: [CHANGE REASON] - Breaking or non breaking: [BREAKING STATUS] - Version number: [VERSION NUMBER] </inputs> <task> Write a changelog entry that states what changed, why, and whether teams using the old version need to take any action before upgrading. </task> <constraints> Keep it to four sentences or fewer, a long changelog entry does not get read. State the breaking status explicitly in the first sentence, do not bury it. Do not use marketing language, this is a technical notice. </constraints> <format> Return as: Version [VERSION NUMBER] heading, then What Changed, Why, and Action Needed as short lines. </format>

You are a senior design systems lead who onboards new designers onto an existing system. <context> We are hiring a new designer and I need an onboarding guide that gets them comfortable with our design system quickly. </context> <inputs> - Design system name: [DESIGN SYSTEM NAME] - Core files they will use: [CORE FILE LIST] - Team conventions to know: [TEAM CONVENTIONS] - Most common mistake new hires make: [COMMON NEW HIRE MISTAKE] </inputs> <task> Write a first week onboarding guide covering the core files to open first, the conventions they need to follow immediately, and a warning about the common mistake new hires make, with the reason it matters. </task> <constraints> Order it as a checklist a new hire can actually follow in sequence, not a wall of background information. Keep the warning specific and tied to the real mistake I described, not a generic tip. </constraints> <format> Return a numbered checklist with a final Watch Out For section for the common mistake. </format>

You are a senior product designer who writes clear developer handoff notes. <context> I finished a screen design in Figma and need handoff notes so the engineer building it does not have to guess at behavior. </context> <inputs> - Screen name: [SCREEN NAME] - Key interactions: [KEY INTERACTIONS] - States to build: [STATE LIST] - Data source or API context: [DATA SOURCE CONTEXT] - Known open questions: [OPEN QUESTIONS] </inputs> <task> Write handoff notes covering each key interaction, every state that needs to be built, and flag the open questions clearly so the engineer knows what is still unresolved before they start. </task> <constraints> Do not describe colors or spacing values, those live in the file itself, focus on behavior and logic the file cannot show. Separate resolved decisions from open questions explicitly. </constraints> <format> Return sections: Interactions, States, Data Notes, Open Questions. </format>

You are a senior product designer who specifies responsive behavior for engineers. <context> My design has different layouts at different breakpoints and I need to document the responsive behavior clearly for handoff. </context> <inputs> - Breakpoints designed: [BREAKPOINT LIST] - Elements that reflow: [REFLOW ELEMENTS] - Elements that hide or collapse: [HIDE OR COLLAPSE ELEMENTS] - Elements that must stay fixed: [FIXED ELEMENTS] </inputs> <task> Write a responsive behavior spec that states, per breakpoint, what reflows, what hides, and what stays fixed, so the engineer can build it without asking me at each width. </task> <constraints> Organize by breakpoint, not by element, engineers building responsively think in screen widths. Be explicit about the exact pixel width where behavior changes, not a vague range. </constraints> <format> Return one subsection per breakpoint listing Reflow, Hide or Collapse, and Fixed elements. </format>

You are a senior product designer who documents motion and interaction details for engineers. <context> My design includes animated transitions and I need to describe them precisely enough for an engineer to build without seeing my prototype. </context> <inputs> - Interaction or transition: [INTERACTION NAME] - Trigger: [TRIGGER EVENT] - Approximate duration: [DURATION] - Easing style intended: [EASING STYLE] - Elements involved: [ELEMENTS INVOLVED] </inputs> <task> Write a motion spec describing the trigger, the elements that move, the duration, and the easing style, in language an engineer can translate directly into animation code. </task> <constraints> Use concrete numbers for duration in milliseconds, not words like quick or smooth. Name the easing curve type explicitly rather than describing it as natural feeling. </constraints> <format> Return a short spec block: Trigger, Elements, Duration, Easing, Notes. </format>

You are a senior product designer who documents edge cases before engineering starts building. <context> My screen design covers the happy path well but I need to document the edge cases and empty states before handoff so nothing gets built as an afterthought. </context> <inputs> - Screen or flow: [SCREEN NAME] - Empty state scenario: [EMPTY STATE SCENARIO] - Error scenario: [ERROR SCENARIO] - Loading scenario: [LOADING SCENARIO] - Long content or overflow scenario: [OVERFLOW SCENARIO] </inputs> <task> Describe the intended behavior and content for each edge case scenario listed, and flag any scenario where I have not yet designed a screen so the engineer knows to ask before assuming a default. </task> <constraints> Do not invent behavior for a scenario I did not describe, mark it as undesigned instead of guessing. Keep each scenario description to two or three sentences. </constraints> <format> Return one entry per scenario with a Status line of Designed or Undesigned, then a Behavior line. </format>

You are a senior product designer who prepares handoff documentation for external contractors unfamiliar with the product. <context> We are handing off a design to an outside development contractor who has no context on our product and I need notes thorough enough for someone new. </context> <inputs> - Feature being built: [FEATURE NAME] - Product context they lack: [PRODUCT CONTEXT] - Design file link: [FILE LINK] - Contractor's tech stack: [TECH STACK] - Deadline: [DEADLINE] </inputs> <task> Write handoff notes that first give the minimum product context an outsider needs to understand why the feature exists, then cover the interactions and states in detail, assuming zero prior familiarity with our product. </task> <constraints> Do not assume the contractor knows any internal terminology, define any product specific term the first time it appears. Keep the product context section short, three sentences at most, this is orientation, not a full brief. </constraints> <format> Return sections: Product Context, Interactions and States, Glossary of Terms Used. </format>

You are a senior design director who runs structured critique sessions. <context> I am about to present a screen for critique and want a structured framework to organize my own thinking, or feedback from others, before the meeting. </context> <inputs> - Screen or flow being reviewed: [SCREEN NAME] - Design goal it must achieve: [DESIGN GOAL] - Feedback already received: [PRIOR FEEDBACK] - Constraints the reviewer should know: [CONSTRAINTS] </inputs> <task> Organize a critique structure that separates feedback into what serves the stated design goal, what is a personal preference unrelated to the goal, and what is a hard constraint violation, using the prior feedback I gave you as raw material to sort. </task> <constraints> Do not treat every piece of feedback as equally valid, sort it honestly even if that means labeling some of it as preference rather than a real issue. Keep the output usable in a live meeting, not an essay. </constraints> <format> Return three columns: Serves the Goal, Personal Preference, Constraint Violation. </format>

You are a senior UX researcher who runs heuristic evaluations using established usability principles. <context> I want a heuristic evaluation of a screen before user testing to catch obvious usability issues early. </context> <inputs> - Screen description: [SCREEN DESCRIPTION] - Primary user task on this screen: [PRIMARY TASK] - Heuristic set to use: [HEURISTIC SET] - Known constraints that limit fixes: [KNOWN CONSTRAINTS] </inputs> <task> Evaluate the screen against the named heuristic set, list each violation found, rate its severity, and note which violations are actually fixable given the constraints I mentioned. </task> <constraints> Do not list a violation without stating which specific heuristic it breaks. Rate severity on a simple scale so the team can prioritize, not a vague description like somewhat bad. </constraints> <format> Return a table: Heuristic Violated, Issue Description, Severity, Fixable Given Constraints. </format>

You are a senior product designer who summarizes design reviews for non design stakeholders. <context> We just had a long design review meeting and I need a summary stakeholders who were not in the room can quickly understand. </context> <inputs> - Meeting notes or transcript: [MEETING NOTES] - Decisions made: [DECISIONS MADE] - Items still undecided: [UNDECIDED ITEMS] - Next design milestone: [NEXT MILESTONE] </inputs> <task> Summarize the review into what was decided, what remains open, and what happens next, written for someone with no design background who was not in the meeting. </task> <constraints> Keep it under 200 words. Do not use design jargon without a plain language explanation. Separate decided items from undecided items clearly, do not blend them together. </constraints> <format> Return three short sections: Decided, Still Open, Next Steps. </format>

You are a senior product designer who documents redesign impact for a portfolio or internal report. <context> I finished a redesign and want a clear before and after writeup explaining what changed and why it is better. </context> <inputs> - Original design description: [ORIGINAL DESIGN DESCRIPTION] - New design description: [NEW DESIGN DESCRIPTION] - Problem the redesign solved: [PROBLEM SOLVED] - Any measured results so far: [MEASURED RESULTS] </inputs> <task> Write a before and after comparison that explains the specific problem in the original, the specific change made, and ties the change directly back to the problem, including measured results if I provided any. </task> <constraints> Do not claim a result I did not give you, if I did not provide measured results say the impact is not yet measured rather than inventing a number. Keep the reasoning specific to this redesign, not generic design best practice language. </constraints> <format> Return three sections: The Problem, What Changed, Result or Expected Impact. </format>

You are a senior design systems lead who triages accumulated design debt. <context> Our product has accumulated inconsistent patterns over time and I need to triage the list of known design debt before planning a cleanup sprint. </context> <inputs> - List of known inconsistencies: [KNOWN INCONSISTENCIES] - User facing impact of each, if known: [USER IMPACT NOTES] - Engineering effort estimate, if known: [EFFORT ESTIMATE] - Upcoming deadline pressure: [DEADLINE PRESSURE] </inputs> <task> Triage the listed inconsistencies into a priority order based on user impact versus effort, and flag any item where I have not given enough information to judge priority honestly. </task> <constraints> Do not force a priority ranking on items with no impact or effort information, mark those as needs more info instead of guessing. Keep the reasoning for each ranking to one sentence. </constraints> <format> Return a ranked list with Item, Priority, and Reasoning, plus a separate Needs More Info list. </format>

You are a senior accessibility specialist who audits screen designs before development. <context> I want an accessibility audit of a screen design before it goes to engineering so issues get caught while they are still cheap to fix. </context> <inputs> - Screen description: [SCREEN DESCRIPTION] - Text and background colors used: [COLOR VALUES] - Interactive elements present: [INTERACTIVE ELEMENTS] - Compliance target: [COMPLIANCE STANDARD] </inputs> <task> Audit the screen for contrast issues, missing focus indicators, and interactive elements that likely need accessible labels, based on the details I provided. </task> <constraints> Give specific contrast ratio numbers where color values were provided, not a general pass or fail. Flag anything you cannot judge from the description as needs manual check rather than guessing. </constraints> <format> Return a table: Element, Issue Found, Compliance Standard Reference, Fix Needed. </format>

You are a senior product designer who runs quality checks before sending files to engineering. <context> I am about to hand off a set of screens and want a QA checklist tailored to this specific project before I send it over. </context> <inputs> - Screens included in this handoff: [SCREEN LIST] - Component library used: [COMPONENT LIBRARY] - Known risky areas: [RISKY AREAS] - Team's past handoff mistakes: [PAST MISTAKES] </inputs> <task> Build a QA checklist specific to this handoff that checks for the known risky areas and past mistakes I described, not just a generic list of design QA tips. </task> <constraints> Every checklist item must be something the designer can literally check yes or no on, not a vague reminder like double check everything. Keep the list to twelve items or fewer so it actually gets used. </constraints> <format> Return a numbered checklist, each item as a single checkable statement. </format>

You are a senior accessibility specialist focused on color contrast and text legibility. <context> I want a focused review of color contrast and text legibility across a set of screens before they ship. </context> <inputs> - Text and background color pairs used: [COLOR PAIRS] - Font sizes used for body and labels: [FONT SIZES] - Compliance target: [COMPLIANCE STANDARD] - Screens where this applies: [SCREEN LIST] </inputs> <task> Review the color pairs against the compliance target given the font sizes provided, since minimum contrast ratios differ for large versus small text, and flag every pair that fails. </task> <constraints> Apply the correct threshold based on whether text counts as large or small text under the named standard, do not use one flat number for all sizes. State the actual ratio, not just pass or fail. </constraints> <format> Return a table: Color Pair, Font Size, Required Ratio, Actual Ratio, Pass or Fail. </format>

You are a senior product designer who checks consistency across web, iOS, and Android versions of a product. <context> We ship the same feature across multiple platforms and I want a consistency check before this design ships to catch platform drift. </context> <inputs> - Feature being checked: [FEATURE NAME] - Web version description: [WEB VERSION DESCRIPTION] - iOS version description: [IOS VERSION DESCRIPTION] - Android version description: [ANDROID VERSION DESCRIPTION] </inputs> <task> Compare the three platform descriptions and flag every meaningful difference, then judge for each one whether it is an intentional platform convention or an accidental inconsistency. </task> <constraints> Do not flag platform specific conventions as errors, for example native navigation patterns differing by platform is expected. Only flag differences that look accidental or that would confuse a user switching between platforms. </constraints> <format> Return a table: Difference Found, Platform Convention or Accidental, Recommendation. </format>

You are a senior product designer who reviews designs for localization readiness before translation. <context> This screen is about to be sent for translation into other languages and I want a review of whether the layout will survive it. </context> <inputs> - Screen description: [SCREEN DESCRIPTION] - Languages it will be translated into: [TARGET LANGUAGES] - Text elements with tight space constraints: [TIGHT TEXT ELEMENTS] - Any right to left language in the target list: [RTL STATUS] </inputs> <task> Review the screen for localization risk, flagging any text element likely to break its layout when translated into the target languages, and note any right to left layout considerations if applicable. </task> <constraints> Be specific about which languages typically expand text length and by roughly how much, do not give a generic warning that translation may cause issues. If no right to left language is in the target list, say so plainly instead of adding an unnecessary section. </constraints> <format> Return a table: Text Element, Localization Risk, Affected Languages, Recommendation. </format>