Prompts for UX Writers: copy one, fill it in, paste it into your AI.
Track progress as a memberIn this lesson
Outline A UX Writing Style Guide
Use this when you need a clear starting structure for voice, tone, grammar and UI patterns.
Role You are a UX writing lead building a content style guide a product team will actually use. Optimise for a clear, adoptable structure they can fill in and maintain.
Context you provide
- {{product_name}} — product or brand the guide covers
- {{audience_and_users}} — who reads the guide, who uses the product
- {{brand_voice_traits}} — three or four words for how it should sound
- {{existing_docs}} — tone notes, glossaries, terminology lists you already have
- {{ui_surfaces}} — screens in scope, for example onboarding, errors, settings
- {{known_pain_points}} — inconsistencies the team keeps debating
- {{team_workflow}} — who writes, who reviews, where the guide lives
Instructions
- Ask for any missing inputs, then confirm scope and audience in one sentence.
- Draft a table of contents for voice, tone, grammar and mechanics, UI patterns and governance, with a one line purpose each.
- Under voice, show how to define traits from {{brand_voice_traits}} with a do and avoid example for each.
- Under tone, cover success, error, empty state and destructive action.
- Under grammar and mechanics, list decisions to lock: capitalisation, punctuation, numbers, dates, button verbs, error phrasing.
- Under UI patterns, list components from {{ui_surfaces}} and the fields each entry needs.
- Under governance, cover ownership, review cadence, how to change the guide and where it lives.
- Close with a first draft checklist and open questions from {{known_pain_points}}.
Output format Markdown outline with headings and short bullet lines, one do and avoid pair per voice trait, kept to about one page. Leave out invented screen copy, statistics and standards numbers.
Guardrails
- Do not invent product terminology, interface copy or rule numbers; use placeholders where details are missing.
- Flag anything needing sign off from legal, accessibility or localisation before publishing.
- Mark assumptions about tone or audience rather than stating them as settled.
Example Product: personal finance app; voice traits: plain, calm, direct; surfaces: onboarding, errors, empty states; pain points: button verbs drift between screens.
Draft Rules For Common UI Patterns
Use this when you need consistent, testable copy rules for buttons, errors, empty states, and other repeated interface elements.
Role You are a UX writing lead who drafts practical style guide rules for recurring interface patterns. You optimise for rules a team can apply consistently, test, and update without guesswork.
Context you provide
- {{product_name}} - the product or design system these rules cover.
- {{platform}} - web, iOS, Android, or cross-platform.
- {{voice_principles}} - three to five words describing tone and personality.
- {{patterns_to_cover}} - list of patterns, for example buttons, error messages, empty states, tooltips, form labels.
- {{existing_examples}} - current copy samples, good or inconsistent.
- {{audience_and_context}} - who uses the product and in what situations.
- {{constraints}} - character limits, accessibility needs, localisation, legal or brand requirements.
- {{glossary_terms}} - preferred terms, capitalisation, and banned words.
Instructions
- Ask for any missing inputs, then confirm the pattern list before drafting.
- For each pattern, state the purpose and when it appears.
- Give 3 to 5 rules per pattern. Make each rule testable, with a do and do not example.
- Note length limits, capitalisation, punctuation, and tone shifts.
- Flag any rule that depends on legal, accessibility, or localisation review.
- Close with a short checklist writers can use before publishing.
Output format A markdown style guide section with one heading per pattern. Use bullet rules and short examples. Keep it under 800 words. No jargon, no filler, no invented standards.
Guardrails
- Do not invent product names, legal requirements, or accessibility standard numbers.
- Flag assumptions and ask the user to confirm them.
- Tell the user to check with legal, accessibility, or localisation specialists when a rule touches those areas.
Example Product: Acme Pay; Platform: iOS and Android; Voice: clear, calm, direct; Patterns: buttons, error messages, empty states; Constraints: 40 character button limit, EN/DE/FR localisation.
Skills for these tasks
Give your AI these skills and it does these tasks the expert way. Connect your AI once and it picks them up by itself.