UX/UI Designer

Start here

Widely used and core to this role

• Figma Design(opens in new tab)

  · Design & prototyping

  Core design tool, with an AI agent in beta for generating design directions and bulk edits, and an MCP server that lets AI agents read your designs.

• ChatGPT(opens in new tab)

  · AI chat assistant

  General AI assistant for planning studies, drafting interview guides and UX copy, and critiquing your own work.

Also worth a look

Depends on your team and stack

Written from the changes above. Read and adapt one before you use it.

• Research synthesis checkDrafts findings from interviews and usability tests, each linked to raw evidenceresearch-synthesis-checkView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named research-synthesis-check. When to use it: Drafts themes and findings from moderated user research sessions, such as interview transcripts and usability test notes, links every finding to raw evidence, and lists what needs the researcher's own judgement, such as possible priming or leading questions. Use when a UX designer or researcher asks to analyse or synthesise interviews or usability sessions, code or tag session notes, separate observed behaviour from what participants said, or check an AI-generated research summary against the raw data. For high-volume feedback such as tickets or surveys, use the product manager's feedback synthesis instead.

  ---
  name: research-synthesis-check
  description: "Drafts themes and findings from moderated user research sessions, such as interview transcripts and usability test notes, links every finding to raw evidence, and lists what needs the researcher's own judgement, such as possible priming or leading questions. Use when a UX designer or researcher asks to analyse or synthesise interviews or usability sessions, code or tag session notes, separate observed behaviour from what participants said, or check an AI-generated research summary against the raw data. For high-volume feedback such as tickets or surveys, use the product manager's feedback synthesis instead."
  metadata:
    title: "Research synthesis check"
    summary: "Drafts findings from interviews and usability tests, each linked to raw evidence"
  ---
  
  # Research Synthesis Check
  
  Draft evidence-linked findings from moderated research sessions, and make clear which parts need the researcher's own judgement.
  
  This skill is for interviews and usability tests, where priming and observed behaviour matter and samples are small, so counting is not meaningful. High-volume feedback (support tickets, surveys, reviews) belongs in the product manager's feedback synthesis.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The raw material: transcripts or session notes, each with a participant ID. If only an existing AI summary is available, ask for the raw data too, or state that findings cannot be verified.
  - The research questions and study type (interviews or usability test), plus the discussion guide or task list.
  - Who the participants were (recruitment criteria, segments) and how many sessions were run.
  - Any existing summary or themes to check.
  - Confirmation that the data may be used here under the organisation's policy, with personally identifiable information removed.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Restate the research questions and the study setup. Note whether all participants are real users; if any data comes from synthetic users, keep it separate and label it as hypotheses.
  2. Read every session. Pull out observations (what people did or said) separately from interpretations (what it might mean). Tag each with the participant ID and a location in the transcript.
  3. Code observations with short, descriptive labels. Reuse labels across sessions and merge near-duplicates.
  4. Group codes into candidate themes that answer the research questions. Each theme needs evidence from more than one participant, or it is labelled as a single-participant observation.
  5. For each theme, record supporting participants, contradicting participants, and one or two verbatim quotes.
  6. For usability studies, list task outcomes per participant (completed, completed with difficulty, not completed) as described in the notes. Do not infer outcomes that the notes do not record.
  7. Flag moments that need human judgement: questions that may have led or primed the participant, moderator interventions, unusual context, or a participant saying one thing and doing another.
  8. If an existing summary was provided, compare it with your evidence. Mark each of its claims as supported, partly supported, unsupported or contradicted.
  9. Write findings as neutral statements. Keep design recommendations in a separate, clearly labelled section of ideas to discuss.
  
  ## Output format
  
  ```markdown
  # Research synthesis draft: <study name>
  
  **Research questions:** <list>
  **Sessions reviewed:** <count, participant IDs, study type>
  **Status:** AI draft; researcher to verify against raw data
  
  ## Themes
  
  ### <Theme>
  
  - **Finding:** <neutral statement>
  - **Supported by:** <participant IDs with transcript locations>
  - **Contradicted by:** <participant IDs or "none found">
  - **Quotes:** "<verbatim>" (<participant ID>)
  
  ## Task outcomes (usability studies)
  
  | Task | Participant | Outcome as recorded | Notes |
  | ---- | ----------- | ------------------- | ----- |
  
  ## Needs researcher judgement
  
  | Participant | Location | Concern (e.g. possible priming) |
  | ----------- | -------- | ------------------------------- |
  
  ## Existing summary check
  
  | Claim | Supported / Partly / Unsupported / Contradicted | Evidence |
  | ----- | ----------------------------------------------- | -------- |
  
  ## Ideas to discuss (not findings)
  
  - <idea linked to theme>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Do not rely on this draft for the whole analysis. Context such as whether the interviewer primed a participant needs the researcher's own review.
  - Synthetic user answers are not research findings. Never mix them with real participant evidence.
  - Participants saying they would do something is weaker evidence than what they did in a session. Keep the two apart.
  - Counting is not meaningful in small qualitative samples. Describe who said or did what rather than giving counts or percentages.
  - Quotes must be verbatim apart from anonymisation. Never reproduce secrets, credentials or personal data (names, emails, account details) in the output unless the user needs them; anonymise quotes by default.
  - Do not upload, share or move research data anywhere.
  
  ## Before you finish
  
  - [ ] Every finding links to participant IDs and transcript locations.
  - [ ] Observations and interpretations are kept separate.
  - [ ] Possible priming and other judgement calls are listed.
  - [ ] Recommendations are labelled as ideas, not findings.
  - [ ] No personal information appears in quotes.
  - [ ] Clearly flag your assumptions and anything the researcher must review or decide before these findings are shared.
  

• AI prototype briefWrites a detailed brief for an AI prototyping tool, plus a checklist to review the resultai-prototype-briefView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named ai-prototype-brief. When to use it: Writes a detailed, context-rich prompt brief for an AI prototyping or UI generation tool, covering users, the interaction to test, design system rules, content, states and accessibility, plus a review checklist for the generated prototype before it goes in front of users. Use when a UX designer wants to build a working prototype of a complex interaction with AI, generate screens that fit their product instead of a generic layout, or prepare a prototype for usability testing.

  ---
  name: ai-prototype-brief
  description: "Writes a detailed, context-rich prompt brief for an AI prototyping or UI generation tool, covering users, the interaction to test, design system rules, content, states and accessibility, plus a review checklist for the generated prototype before it goes in front of users. Use when a UX designer wants to build a working prototype of a complex interaction with AI, generate screens that fit their product instead of a generic layout, or prepare a prototype for usability testing."
  metadata:
    title: "AI prototype brief"
    summary: "Writes a detailed brief for an AI prototyping tool, plus a checklist to review the result"
  ---
  
  # AI Prototype Brief
  
  Give an AI prototyping tool the context it needs to produce a testable, on-brand prototype, then check what it produced.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - The interaction to prototype and the research question the usability test should answer.
  - Who the users are, their goal in this flow, and relevant findings from earlier research.
  - Design standards: design system components, patterns, spacing and type rules, tone of voice, and any screens the prototype must match.
  - Realistic content, using fictional or sample data only. Confirm no personally identifiable or confidential product data will go into the tool.
  - Which tool the designer will use and whether it is approved by the organisation. Keep the brief tool-neutral unless they ask otherwise.
  - Constraints: platform and screen sizes, accessibility requirements, and what does not need to work.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Write a one-paragraph summary of the prototype's purpose: the user, their goal, and the question the test must answer.
  2. Describe the flow step by step: entry point, each screen or state, user actions, and how the system responds.
  3. List every state the interaction needs: empty, loading, partial, error, success, undo, and edge cases such as long names or no results.
  4. Write the design context: which components and patterns to use, hierarchy rules (what must be most prominent on each screen), and patterns to avoid.
  5. Provide realistic sample content and data, written out in full. Avoid lorem ipsum, because placeholder text hides layout and hierarchy problems.
  6. State accessibility requirements explicitly: keyboard operation, visible focus, labels for inputs and icons, alt text, colour contrast and meaningful headings. Ask for real labels, not placeholder attributes.
  7. List what is out of scope so the tool does not add features.
  8. Assemble the brief into a single prompt the designer can paste into their tool, plus a shorter follow-up prompt for iterating on one screen at a time.
  9. Draft a review checklist for the designer to apply to the output before any user sees it.
  
  ## Output format
  
  ```markdown
  # Prototype brief: <interaction name>
  
  ## Purpose
  
  <user, goal, research question>
  
  ## Prompt to paste
  
  <complete prompt: context, users, flow, states, design rules, content, accessibility, out of scope>
  
  ## Follow-up prompt template
  
  "On the <screen> screen, change <specific element> so that <design intent>. Keep everything else the same."
  
  ## States covered
  
  | State | Trigger | What the user sees |
  | ----- | ------- | ------------------ |
  
  ## Review checklist before testing
  
  - [ ] Right design pattern for this task (not just a plausible one)
  - [ ] Clear visual hierarchy; the primary action stands out
  - [ ] No unnecessary repeated elements or invented features
  - [ ] All listed states exist and are reachable
  - [ ] Keyboard-only walkthrough works; focus is visible
  - [ ] Inputs and icons have real labels; placeholders were replaced
  - [ ] Only sample data is used
  - [ ] The prototype can answer the research question
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - If the brief lacks users, domain or design standards, warn that the output may be generic.
  - A polished generated prototype can look complete while using the wrong pattern, a confusing hierarchy or repeated elements. The review checklist is not optional.
  - The first output will probably not get everything right. Plan for several focused iterations rather than one large prompt rewrite.
  - Always state accessibility requirements in the brief and check them manually.
  - Real product data or personal information must not go into the prompt or the tool.
  - The prototype is for learning. Do not describe it as ready for development handoff.
  
  ## Before you finish
  
  - [ ] The brief names the users, the research question and the design standards.
  - [ ] Every state in the flow is described.
  - [ ] Accessibility requirements are written into the prompt itself.
  - [ ] Only fictional or sample data appears.
  - [ ] The review checklist is included.
  - [ ] Clearly flag your assumptions and anything the designer must review or decide before the prototype is tested with users.
  

• AI feature trust statesPlans what users see when an AI feature is unsure, slow or wrong, and how they recoverai-feature-trust-statesView · Copy · Download

  Copy instructions Download .zip Copy link to this

  How to use it

  • In any AI chat, such as ChatGPT, Microsoft 365 Copilot or Claude: choose Copy instructions, paste them at the start of a new chat, then add your material. Our suggestion
  • Install it in Claude (web or desktop): download the .zip, then go to Customize › Skills › + › Create skill › Upload a skill. Code execution must be turned on. Claude help (opens in new tab)
  • Install it in a coding agent such as Claude Code, GitHub Copilot or Codex: unzip the folder into the tool's skills folder. Folder locations

  Show the full file

  File name SKILL.md, in a folder named ai-feature-trust-states. When to use it: Maps the trust and failure states of an AI-powered feature, such as uncertain answers, errors, refusals, slow responses and wrong actions, and drafts the transparency, control and recovery design for each, plus design-intent examples of acceptable and unacceptable output. Use when a UX designer is designing an AI assistant, chatbot, agent or generated-content feature, needs to plan what users see when the AI is unsure or wrong, or wants to hand product and QA examples of the output the design intends.

  ---
  name: ai-feature-trust-states
  description: "Maps the trust and failure states of an AI-powered feature, such as uncertain answers, errors, refusals, slow responses and wrong actions, and drafts the transparency, control and recovery design for each, plus design-intent examples of acceptable and unacceptable output. Use when a UX designer is designing an AI assistant, chatbot, agent or generated-content feature, needs to plan what users see when the AI is unsure or wrong, or wants to hand product and QA examples of the output the design intends."
  metadata:
    title: "AI feature trust states"
    summary: "Plans what users see when an AI feature is unsure, slow or wrong, and how they recover"
  ---
  
  # AI Feature Trust States
  
  Plan how an AI feature earns and keeps user trust, including what users see when it is unsure, slow or wrong.
  
  ## What to gather first
  
  Ask for anything missing before you start:
  
  - What the feature does, who uses it and the task they are delegating to it.
  - What the AI can affect: does it only suggest, or can it take actions such as sending, changing or deleting something?
  - Research findings about these users: their expertise, what is at stake for them, and their current trust in automation.
  - Current designs or flows, if any, and the product's tone of voice.
  - Real or realistic example outputs, especially bad ones, with personal details removed.
  - Known technical limits from engineering: typical failure types, response time, what the system can explain about its output.
  
  Ask for anything missing once. If the user can't provide it or asks you to go ahead, proceed and record every assumption.
  
  ## Steps
  
  1. Describe the delegation: what the user hands over, what they keep control of, and what happens if the output is wrong. Rate the impact of a wrong output as low, medium or high, and explain why.
  2. List the states the feature can be in. Include at least: working, slow or long-running, confident output, uncertain or partial output, no answer, refusal or out of scope, error, wrong output the user notices, and wrong output the user does not notice.
  3. For each state, design for the four fundamentals:
     - **Transparency:** what the user is told about what the AI did and where the output came from.
     - **Control:** how the user can review, edit, stop, undo or choose not to use the output.
     - **Consistency:** how the behaviour and wording stay predictable across similar situations.
     - **Support when it fails:** how the user recovers, reaches a person or completes the task another way.
  4. For any action the AI can take on the user's behalf, add a confirmation or preview step proportional to the impact, and describe how it can be undone. If it cannot be undone, say so prominently.
  5. Draft interface copy for uncertain, refusal and error states in the product's tone. Avoid blaming the user and avoid overstating the system's confidence.
  6. Write design-intent examples of acceptable and unacceptable output to hand to product and QA, drawn from research and design intent. Product owns the pass/fail criteria and QA owns the evals.
  7. List questions for engineering about what the system can detect (for example, whether it can signal low confidence) so designs do not depend on signals that do not exist.
  8. Suggest what to test with real users, especially the states where users may not notice a wrong output.
  
  ## Output format
  
  ```markdown
  # Trust and failure states: <feature name>
  
  **Delegated task:** <what the user hands over>
  **Impact of wrong output:** <low/medium/high and why>
  **Status:** Design draft for review
  
  ## State map
  
  | State | Transparency | Control | Consistency | Support when it fails |
  | ----- | ------------ | ------- | ----------- | --------------------- |
  
  ## Actions taken on the user's behalf
  
  | Action | Confirmation or preview | Undo | Impact if wrong |
  | ------ | ----------------------- | ---- | --------------- |
  
  ## Draft copy
  
  - **Uncertain:** "<copy>"
  - **Refusal / out of scope:** "<copy>"
  - **Error:** "<copy>"
  
  ## Design-intent examples
  
  | Situation | Acceptable example | Unacceptable example | Design intent behind it |
  | --------- | ------------------ | -------------------- | ----------------------- |
  
  ## Questions for engineering
  
  - <question>
  
  ## What to test with users
  
  - <state or scenario and what to learn>
  
  ## Assumptions and open questions
  
  - <assumption or question, and who can confirm>
  ```
  
  ## Watch out for
  
  - Design the failure states first, not last.
  - Wrong outputs that users do not notice are the most dangerous state. Look for ways to help users check the output, not just to report errors.
  - Do not promise transparency the system cannot provide, such as sources or confidence it does not have. Confirm with engineering.
  - Examples of good output must come from research and design intent, not from what the model happens to produce today.
  - Never reproduce secrets, credentials or personal data (names, emails, account details) in the output unless the user needs them; anonymise quotes by default.
  - Synthetic users or AI opinions cannot tell you whether real users trust the feature. Test with real users.
  - The designer and team decide the design; this is a structured draft.
  
  ## Before you finish
  
  - [ ] Every listed state has an entry for all four fundamentals.
  - [ ] Every AI action has a confirmation, preview or undo, or a clear note that it cannot be undone.
  - [ ] Design-intent examples show both acceptable and unacceptable output.
  - [ ] Designs that rely on unconfirmed technical signals are flagged.
  - [ ] Clearly flag your assumptions and anything the designer, engineering or product must review or decide.