33 ChatGPT Prompts That Handle the Non-Design Parts of Design Work

Write the microcopy for [describe the feature/screen/flow]. Product: [product name and type]. Brand voice: [describe — friendly, professional, playful, etc.]. Elements needing copy: [list all UI elements: buttons, labels, tooltips, empty states, success messages, error messages, onboarding steps, etc.] For each element: write the copy (concise, clear, action-oriented), explain why you chose these words, provide 2 alternatives, and flag any copy that needs A/B testing. Follow these principles: use the user's language (not internal jargon), be specific (not "something went wrong" — say what went wrong), lead with the verb for buttons ("Save changes" not "Changes saved"), and keep it scannable (users don't read, they scan).

Write error messages for [product/feature]. Here are the error states: [List each error: what went wrong, when it happens, what the user was trying to do] For each error, write a message that: explains what happened (in human language, not error codes), tells the user what to do next (specific action), doesn't blame the user ("we couldn't process" not "you entered incorrectly"), maintains brand voice even when things break, and includes a recovery path (button, link, or instruction). Create three tiers: inline validation (instant, brief), form-level errors (after submission), and system errors (server issues, outages). For system errors, include: what information to show, whether to suggest retrying, and when to show a support contact.

Design empty state content for these screens in [product]: [List screens that have empty states: dashboard with no data, inbox with no messages, search with no results, etc.] For each empty state: write the headline and body copy, suggest an illustration style or visual, include a clear call-to-action (what should the user do?), make it feel encouraging not empty, and explain the strategy (education, motivation, or guidance). Create two versions: first-time user (they've never used the feature) and returning user with no current content (they know the feature but there's nothing to show). Empty states should feel like opportunities, not dead ends.

Write the copy for an onboarding flow for [product]. The flow has [number] steps: [Describe each step: what the user needs to do and why] Target user: [describe — technical level, motivation, context] Goal: get users to [key activation metric] For each step: write the screen title, body copy (under 30 words), button label, help text where needed, and progress indicator copy. Overall principles: keep it progressive (don't overwhelm with everything at once), connect each step to a benefit ("Add your team so you can collaborate in real-time"), allow skipping where possible (with a subtle note about why they shouldn't), and celebrate completion (the final screen should feel rewarding). Include a "skip-all" path for power users who don't need onboarding.

Create a UI copy style guide for [product name]. Brand personality: [describe]. Target audience: [describe]. The style guide should cover: voice and tone guidelines (with examples), capitalization rules (sentence case, title case, when to use each), punctuation rules (periods in buttons? Oxford comma?), terminology preferences (sign in vs log in, remove vs delete, etc.), number formatting (numerals vs words, dates, currencies), do's and don'ts with before/after examples, microcopy patterns for common elements (buttons, tooltips, errors, confirmations), and accessibility writing guidelines (alt text, aria labels, screen reader copy). Include 10+ before/after examples showing the style guide in action.

Write copy for these transactional notifications in [product]: [List each notification: trigger event, channel (email/push/in-app), purpose] For each notification: subject line or push title (under 50 characters), body copy (concise, actionable), call-to-action (specific button/link), tone appropriate to the context (urgent for security, friendly for milestones, etc.), and timing recommendation (when to send relative to the trigger). Follow these rules: only notify if the user needs to do something or would want to know, never be annoying (respect notification fatigue), include enough context that the user doesn't need to open the app to understand, and make the CTA button do the obvious next action. Create a notification priority framework: which notifications are critical vs nice-to-know.

Write a design brief for [feature/project]. Context: Product: [product name and description] Business goal: [why we're building this] User problem: [what user need this addresses] Scope: [what's included and excluded] Timeline: [design and development timeline] Constraints: [technical, brand, accessibility, etc.] The brief should include: problem statement (specific, measurable), user stories with acceptance criteria, success metrics (how we'll know the design works), competitive context (how others solve this), technical constraints the designer needs to know, brand and design system requirements, accessibility requirements (WCAG level), and open questions that need design exploration. Write it as a collaboration document — opinionated enough to guide the designer but open enough for creative solutions.

Document this design system component for my team: Component: [name — e.g., Button, Modal, Card, Toast] Variants: [list variants — primary, secondary, destructive, etc.] Used in: [list contexts/pages where it appears] Create comprehensive documentation: component description and purpose, when to use this component vs alternatives, all variants with use cases for each, props/parameters with types and defaults, states (default, hover, active, disabled, loading, error), accessibility requirements (ARIA, keyboard, screen reader behavior), spacing and sizing specifications, responsive behavior, do's and don'ts with visual examples described, and code usage examples. Include edge cases: what happens with very long text, missing data, or error states.

I'm handing off a design to developers. The feature is [describe feature]. Design files: [tool — Figma/Sketch/XD] Design system used: [name] Create handoff notes that: walk through the user flow step by step, specify interactions and animations (timing, easing, triggers), call out responsive breakpoints with behavior at each, list all states for interactive elements, specify loading states and skeleton screens, describe error handling and edge cases, note accessibility requirements (focus order, aria labels, color contrast), highlight where the design deviates from the design system (and why), and list any assets that need to be exported. Organize by screen/component for easy developer reference.

I need to document the design decisions made during [project/feature] design. Key decisions: [List each decision: what you decided and the alternatives considered] For each decision, document: the decision made, alternatives considered (with screenshots or descriptions), rationale (why this option won), evidence supporting the decision (user research, data, best practices), trade-offs acknowledged, stakeholder who approved, and conditions under which we'd revisit this decision. Create a format that's easy to reference months later when someone asks "why did we do it this way?" Include a summary table for quick scanning.

Conduct a conceptual accessibility audit for [product/feature]. I'll describe the current design: [Describe the UI: layout, interactive elements, colors, content structure, forms, navigation] Audit against WCAG 2.1 [AA/AAA] standards: perceivable (color contrast, text alternatives, captions, adaptable content), operable (keyboard accessibility, focus management, timing, navigation), understandable (readable, predictable, input assistance), and robust (compatible with assistive technology). For each issue found: severity (critical/major/minor), WCAG success criterion violated, specific location in the design, recommended fix, and implementation effort. Include a summary score and prioritized fix list. Note: this is based on design description — a full audit requires testing with assistive technology.

Help me write a design case study for my portfolio. Project: Project name: [name] Company/client: [who] My role: [what I did] Duration: [timeline] Outcome: [results, metrics, impact] Structure the case study: hook (compelling opening that summarizes the impact), challenge (the problem in business and user terms), process (my approach — research, ideation, testing, iteration), key design decisions (the interesting choices, not every screen), results (measurable outcomes), and reflection (what I learned, what I'd do differently). For each section: suggest what visuals to include, what to emphasize for hiring managers, and the ideal word count. Write it in first person, showing my thinking process — not just the final output. This should demonstrate how I think, not just what I made.

Help me plan a [3/5]-day design sprint for [problem/opportunity]. Team: [who's participating, roles] Format: [remote/in-person/hybrid] Tools: [Figma/Miro/FigJam/etc.] The challenge: [describe the problem we're solving] Create a sprint plan with: day-by-day agenda with timing for each activity, facilitation instructions for each exercise, templates and frameworks to prepare in advance, async pre-work to maximize synchronous time, decision-making process for each phase, specific adaptations for remote facilitation (remote sprints need different timing and tools), and a testing plan for the final prototype. Include: icebreakers, energy management, and how to handle dominant voices and quiet participants.

I need design concepts for [feature/problem]. Constraints: Technical: [what's technically possible/impossible] Brand: [design system, visual guidelines] Business: [revenue model, stakeholder requirements] User: [research insights, accessibility needs] Timeline: [when it needs to ship] Generate 5 distinct design approaches that all work within these constraints. For each concept: describe the approach in 2-3 sentences, explain the core interaction pattern, identify which constraint it optimizes for (and which it sacrifices), user experience trade-offs, implementation complexity (low/medium/high), and a "why it might fail" honest assessment. Then recommend which 2 concepts to prototype and test, and why.

Evaluate this design against Nielsen's 10 usability heuristics (or specify another framework): [Describe the design in detail: screens, flows, interactions, copy] For each heuristic: score (1-5) with justification, specific examples of compliance and violation, severity of any violations (cosmetic/minor/major/catastrophic), and recommended improvements. Heuristics: visibility of system status, match between system and real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency, aesthetic and minimalist design, help users recognize/diagnose/recover from errors, and help and documentation. Provide an overall score and the top 3 improvements that would have the biggest impact.

I'm designing [feature] and need to think through edge cases. The happy path is: [Describe the ideal user flow] Help me identify and design for: empty states (no data, first use), loading states (slow connection, large data), error states (validation, system, network), permission states (unauthorized, expired session), extreme content (very long names, many items, no items), interrupted flows (back button, refresh, abandoned process), multi-device scenarios (started on mobile, continued on desktop), and accessibility edge cases (keyboard-only, screen reader, reduced motion). For each: describe the scenario, explain the user's mental state, and suggest the design approach. Prioritize by likelihood and impact.

Help me structure a design critique for [feature/screen]. The design: [Describe the design or paste a detailed description] Design goal: [what this design is trying to achieve] Critique the design on: does it solve the stated problem? Is the visual hierarchy guiding attention correctly? Is the information architecture intuitive? Are the interactions clear and predictable? Does the copy support the user's task? Is there unnecessary complexity that could be removed? How does it perform at different viewport sizes? Are there accessibility concerns? Provide feedback in the format: "What's working well," "What could be improved," and "Questions to explore." Be specific — "the CTA button gets lost" is useful; "improve the visual hierarchy" is not.

I need to present my design concept for [feature/project] to [audience: executives/product managers/engineers/clients]. The design: [describe the concept] Key decisions: [the important choices you made] Research backing: [data supporting the design] Concerns I anticipate: [what stakeholders might push back on] Create a presentation outline: opening that connects design to business goals, problem statement with user evidence, design walkthrough organized by user story (not by screen), rationale for key decisions (connect each to data), prototype demo talking points, tradeoffs and alternatives considered, metrics we'll track to measure success, and next steps and timeline. Include speaker notes and anticipated questions with responses. The presentation should work for a non-designer audience.

Write a design proposal for [client/project]. Client: [describe the client and their business] Project scope: [what they want designed] Timeline: [their deadline] Budget: [range or "to be proposed"] Create a proposal with: executive summary (1 paragraph), understanding of the client's challenge (prove you listened), proposed design approach and methodology, project phases with deliverables at each, timeline with milestones and review points, team and roles, pricing structure (retainer/project/hourly with justification), terms and conditions highlights, and portfolio examples relevant to this project. Write in a tone that builds confidence: we understand your problem and we've solved similar ones before. Include a "why us" section that doesn't sound like a generic pitch.

I received feedback on my design from [stakeholder role]. Their feedback: [Paste the feedback — the good, the bad, and the "make the logo bigger"] Help me: categorize each piece of feedback (actionable design insight / subjective preference / valid business concern / misunderstanding / out of scope), craft professional responses for each, identify which feedback to accept, which to push back on (with reasoning), and which to explore further, write a response email that: thanks them for engagement, clarifies misunderstandings, proposes solutions for valid concerns, diplomatically addresses subjective preferences, and sets expectations for the next review. Tone: collaborative, not defensive. The goal is alignment, not winning an argument.

I need to convince [stakeholder] that my design decision is the right one. They want [their preference] but I believe [your recommendation] is better. My recommendation: [describe your design choice] Their preference: [describe what they want] Context: [the feature, the users, the business goal] Build a case that: starts with shared ground (what we agree on), presents evidence for my recommendation (research data, best practices, competitive analysis), honestly acknowledges the merits of their preference, shows the risks of their preference (with specific examples or data), proposes a way to validate (A/B test, user test, phased rollout), and offers a compromise if one exists. Don't frame it as "I'm right, you're wrong." Frame it as "here's what the data suggests, and here's how we can verify."

Summarize a design review session for team members who couldn't attend. Feature reviewed: [feature name] Design stage: [concept/wireframe/high-fidelity/pre-dev] Attendees: [who was there] Key discussion points: [Summarize what was discussed] Write a review summary that: captures every decision made with rationale, documents feedback received and how it'll be addressed, lists open questions and who's responsible for answering them, identifies changes to be made before the next review, includes before/after descriptions for any agreed-upon changes, and sets the date and scope of the next review. Format for async consumption (scannable, linked to design files, clear action items). Include a "respond by" date for anyone with concerns.

Help me audit and improve my design process. Current workflow: [Describe your current process: how briefs come in, how you design, how you test, how you hand off, tools used, team size] Pain points: [what's slow, broken, or frustrating] Team feedback: [what colleagues say about working with design] Analyze: where are the bottlenecks? Where does quality suffer due to process (not skill)? What's duplicated or unnecessary? Where does communication break down between design and [engineering/product/stakeholders]? Suggest improvements: streamlined process with fewer steps, better templates and reusable assets, handoff improvements, feedback loop optimization, and tools that could help. Compare my current process to industry best practices. Be honest about what I'm overcomplicating and what I'm skipping that I shouldn't be.

I need to create a design system for [product/company]. Current state: Product(s): [what exists] Team: [number of designers and developers] Existing patterns: [any consistency that exists] Technology: [React/Vue/etc.] Design tool: [Figma/Sketch/etc.] Create a plan for building the design system: what to include in V1 (minimum viable design system), component inventory (audit what exists and what's needed), token system (colors, typography, spacing, shadows), component priority (which to build first based on usage frequency), documentation strategy (what to document and where), governance model (who maintains it, how changes are proposed), adoption plan (how to get the team actually using it), and metrics to track (adoption rate, consistency, dev time savings). Include a phased roadmap: what to build in month 1, 3, 6, and 12. Don't try to build everything at once — that's how design systems die.

Document the design tokens for [product/design system]. Tokens to document: [List: colors, typography, spacing, shadows, border radius, breakpoints, animation, z-index] For each token category: list all tokens with their values, explain the naming convention, show usage guidelines (when to use which token), document the semantic meaning (why this color is called "danger" not "red"), specify responsive behavior where applicable, and include do's and don'ts with examples. Create a quick reference card that developers can keep open while coding. Include the implementation format (CSS variables, Tailwind config, SCSS, or design-tool-specific format).

Create design principles for [product/team/company]. Product: [what we build] Users: [who we serve] Brand values: [company values] Design challenges: [recurring tensions — speed vs quality, simplicity vs power, etc.] Create 5-7 design principles that: are specific to our product (not generic "make it simple"), resolve real design tensions (when two good things conflict, which wins?), are memorable (short enough to remember, interesting enough to reference), include an example of each principle in action, and rank-order them (when principles conflict, which takes priority?). For each principle: the principle statement, a one-line explanation, an example of a design decision it would resolve, and the counter-principle it beats. Test: if the opposite of your principle is something no reasonable person would argue for, it's too vague.

Help me create a design QA process for my team. Current situation: Team: [designers and developers] Deployment cadence: [how often you ship] Current QA: [what exists — or nothing] Common issues: [what goes wrong between design and production] Create a QA process that: specifies when to QA (which environments, at what stage), provides a checklist for visual review (spacing, typography, colors, alignment), covers interaction review (animations, transitions, states), includes responsive review (key breakpoints, touch targets), addresses accessibility review (contrast, keyboard nav, screen reader), establishes a bug filing process (severity, screenshots, expected vs actual), and sets SLA for design bug fixes (which get fixed before release vs post-release). Include a "QA-ready" checklist for developers to self-check before requesting design QA. Keep the process lightweight enough to actually follow.