Design ChatGPT Prompts
UI/UX design, graphic design, and creative direction prompts
Create User Personas
Build 3–4 user personas for {product} based on {research_source}. For each persona give: the job they are trying to get done, their current workaround and why it persists, the trigger that makes them look for something new, their success criteria in their own words, the objection that stops them adopting, and their technical comfort level. Ground every attribute in observed evidence and mark clearly anything that is an assumption to be validated. Skip demographic decoration — age, marital status and stock-photo names — unless it genuinely changes a design decision. Finish with the one design implication per persona and the question that would invalidate it.
Write a UX Audit Report
Write a UX audit of {site_or_app} focused on {primary_user_goal}. Evaluate against Nielsen's ten heuristics plus accessibility (WCAG 2.2 AA), then walk the three highest-value task flows end to end and note every point of friction, dead end and moment of uncertainty. For each finding give: the screen or step, the heuristic or guideline violated, the user consequence in behavioural terms, a severity rating with the reasoning, the recommended fix, and implementation effort. Separate findings that cost conversions from findings that are merely inelegant. Lead the report with the five fixes that would move the primary metric, and state what you could not assess without analytics or session data.
Design a Wireframe Annotation Guide
Create a wireframe annotation guide for {team_type}. Define what every wireframe must annotate: element purpose, data source and what happens when it is empty or still loading, interaction behaviour on click, hover and keyboard, validation and error messaging, conditional visibility rules, and navigation destinations. Establish a consistent numbering and callout convention, a rule for how much detail belongs at low versus high fidelity, and guidance on annotating what is intentionally undecided so it reads as an open question rather than an oversight. Include one fully annotated example screen and one common anti-pattern — the wireframe that looks complete but leaves every edge case to the developer's imagination.
Create Accessibility Guidelines
Write practical accessibility guidelines for {platform} targeting WCAG 2.2 AA. Organise by the work people actually do rather than by success criterion number: writing content, choosing colour, building forms, handling focus and keyboard navigation, images and media, motion and animation, and dynamic updates. For each area give the requirement, a correct and an incorrect code example, how to test it manually in under a minute, and which automated tool catches it (noting that automation finds roughly a third of issues). Include a definition of done for design, code review and QA. Add a short section on why each requirement exists in terms of a real user need, since teams comply better with rules they understand.
Write a Design Critique Framework
Design a critique framework for a {team_size} design team. Define the format: the presenter states the problem, the constraints and the specific feedback they want before showing anything; reviewers ask clarifying questions before offering opinions; feedback is tied to the stated goal rather than personal taste. Give sentence stems that produce useful critique ('I noticed X, which might make a user think Y') and name the patterns to stop — solutioning in the room, relitigating settled decisions, and the most senior person speaking first. Cover facilitation, timeboxing, how decisions and open items are recorded, and how to run this asynchronously for distributed teams.
Develop a Brand Style Guide
Create a brand style guide for {brand}, a {industry} company positioned as {positioning}. Cover: the brand idea in one sentence and the three attributes that follow from it, logo construction with clear-space and minimum sizes plus explicit misuse examples, a colour system with hex, RGB and accessible pairings including contrast ratios, type scale with weights and line heights for both display and body, photography and illustration direction with counter-examples, iconography rules, and voice and tone with side-by-side 'we say / we don't say' pairs. For every rule state the reason behind it, because rules without reasons get broken the first time they are inconvenient.
Create a Design Handoff Checklist
Build a design-to-development handoff checklist for a {team_size} team working in {tool}. Cover what must be true before handoff: all states designed including error and empty, responsive behaviour at every breakpoint, tokens applied with no detached styles, content in realistic length extremes rather than lorem ipsum, accessibility annotations for focus order and labels, assets exported at the right densities, and interaction or motion specified. Add the handoff meeting agenda, how open questions get tracked rather than lost in comments, what the developer is expected to confirm back, and the design QA pass before release. Mark which items block handoff and which can follow.
Create a Design Brief
Write a design brief for a {project_type} project for {client_or_team}. Cover: the business problem being solved and how success will be measured, the audience and what they currently do instead, scope with explicit exclusions, mandatory constraints (brand, technical, regulatory, budget, deadline), deliverables with formats and quantities, the approval process naming who can give feedback and who decides, the review milestones, and references with a note on what specifically is admired about each — since 'make it like this' without specifics causes most rework. Add the three questions the brief cannot yet answer and who must answer them before work begins.
Write Design Specifications for a UI Component
Write an implementation spec for a {component_name} component. Include: purpose and the use cases it does and does not cover, anatomy with named parts, all visual properties expressed as design tokens rather than hard-coded values, every state (default, hover, focus-visible, active, disabled, loading, error, empty) with the transition between them, responsive behaviour at each breakpoint including what happens at the awkward sizes, content rules such as maximum characters and truncation behaviour, accessibility with roles, keyboard interaction and screen-reader announcements, and the edge cases — very long text, missing data, slow network, right-to-left languages. Write it so a developer needs no follow-up questions.
Develop Design System Documentation
Write documentation for a design system supporting {product_type} across {platforms}. Structure it in three layers: foundations (colour, type, spacing, elevation, motion — all as named tokens, never raw values), components, and patterns. For each component document the anatomy, every variant and state including loading, empty, error and disabled, the props or parameters, accessibility requirements with keyboard behaviour and ARIA, responsive behaviour, and — most importantly — when NOT to use it and what to use instead. Add contribution guidelines, a deprecation process with migration paths, and versioning rules. Write for a developer who arrives via search and reads one page, not the whole site.