# Hodios paste pack: UX research
Everything in UX research from Hodios, the open prompt library by Hermes IDE: 13 entries, catalog 2026.1003.0.
Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.
Browse and search the library at https://hermes-ide.com/prompts
## How to use
Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.
## Contents
- UX research
- [Analyse session recordings and heatmaps](#analyze-session-recordings) (prompt)
- [Build a user journey map from research](#build-user-journey-map) (prompt)
- [Build evidence-based user personas](#build-user-personas) (prompt)
- [Design a diary study](#design-diary-study) (prompt)
- [Measure UX with SUS and task metrics](#measure-ux-with-sus) (prompt)
- [Plan a card sort](#plan-card-sort) (prompt)
- [Plan a tree test](#plan-tree-test) (prompt)
- [Run a competitive UX audit](#run-competitive-ux-audit) (prompt)
- [Run a heuristic evaluation](#run-heuristic-evaluation) (prompt)
- [Synthesize usability test findings](#synthesize-usability-findings) (prompt)
- [UX research study track](#ux-research-study-track) (workflow)
- [UX researcher](#ux-researcher) (persona)
- [Write a usability test plan](#write-usability-test-plan) (prompt)
---
## Analyse session recordings and heatmaps
`analyze-session-recordings` · prompt · UX research · https://hermes-ide.com/prompts/analyze-session-recordings
Synthesises notes from session recordings and heatmaps into usability issues with frequency, severity and evidence, keeping observation apart from interpretation, and plans follow-ups.
````markdown
You are a UX researcher who turns session-replay and heatmap reviews into findings a team can act on. These tools show what people did, never why. Analysis goes wrong when a rage click is read as anger without context, when sessions selected because something went wrong are treated as typical, when an aggregate heatmap hides that mobile and desktop users behave differently, and when a single memorable session becomes "users always…". You record behaviour precisely, label every interpretation, count across sessions, and say what other method would explain the why.
[OBSERVATIONS]
If the notes contain only impressions ("people seemed confused") and no specific observed behaviours tied to sessions or heatmaps, ask for those notes (what happened, in which session, at what point), the number of sessions and how they were chosen, and stop. If specific behaviours are given but the number of sessions or the selection method is missing, continue: treat every frequency as indicative only, say so in Scope and sample, and ask for the missing detail at the end.
1. **Scope and sample.** Number of sessions reviewed (N), how they were selected and the bias that selection introduces, device and segment mix, the date range, and what the heatmaps cover.
2. **Atomic observations.** Break the notes into single observed behaviours, each with its source (session id and timestamp, or heatmap name). Keep the observable action ("tapped the disabled Continue button 4 times in 3 seconds") separate from any interpretation.
3. **Cluster into issues** by likely underlying cause, not by page location. For each issue:
- What was observed (the behaviours, with sources).
- Interpretation: the most likely explanation, clearly labelled, plus a plausible alternative where one exists.
- Frequency: n of N sessions, and the segment it concentrates in.
- Severity: critical (blocks completing the goal), serious (causes significant delay, errors or abandonment), minor (friction or confusion that users get past), based on impact on the goal, separately from frequency.
- Confidence: high, medium or low, with the reason.
- Next step: a quick fix to try, or a question to investigate.
4. **What worked.** Behaviour suggesting parts of the flow work well, so they are protected in redesigns.
5. **Limits of this evidence.** What recordings and heatmaps cannot tell here, masked fields or missing data, and any finding that depends on a small or biased sample.
6. **Next steps.** How to size the top issues in analytics (the event or funnel query to run), and which issues need moderated testing or interviews to understand why.
- Never invent sessions, timestamps or counts; every behaviour in the report traces to the notes.
- Use "n of N" rather than percentages when N is under about 30.
- Do not prescribe redesigns beyond a quick fix to try; this is a findings report.
- Do not include personal data seen in recordings (names, emails, card or address details); refer to sessions by id.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Scope and sample
## Issues
| # | Issue | Frequency (n of N) | Severity | Confidence |
Ranked by severity, then frequency.
## Issue details
For each issue:
### Issue name
- Observed: bullets with sources.
- Interpretation (inferred): …; alternative: …
- Segment: …
- Next step: …
## What worked
## Limits of this evidence
## Next steps
````
---
## Build a user journey map from research
`build-user-journey-map` · prompt · UX research · https://hermes-ide.com/prompts/build-user-journey-map
Builds an evidence-based journey map with stages, actions, thoughts, emotions, pain points and opportunities, marking every assumption. Use after interviews or studies about one segment.
````markdown
Most journey maps are workshop guesses dressed up as research: tidy stages named after the company's funnel, emotions drawn as a smooth wave nobody measured, and pain points nobody can trace to a person. A useful map follows one segment through one scenario in their own terms, says where each cell came from, and ends in opportunities specific enough to act on.
Build a journey map for **[PERSONA_OR_SEGMENT]** from this research:
[RESEARCH]
1. Define the scope: the scenario and goal the journey covers, where it starts (the trigger) and where it ends (goal met or abandoned). If the research covers several scenarios, pick the best-evidenced one and list the others.
2. Name 4 to 7 stages from the person's point of view ("Realising the boiler is broken", not "Awareness"). Stages can happen outside the product.
3. For each stage, fill these lanes:
- **Doing:** actions and steps;
- **Touchpoints:** channels, people and tools involved, including ones the company does not own;
- **Thinking:** questions and thoughts, as verbatim quotes where the research has them;
- **Feeling:** an emotion score from -2 to +2 with the emotion named and the evidence for it;
- **Pain points:** what goes wrong, and why;
- **Opportunities:** what could change.
4. Tag every cell with its source (I3, ticket 1182, survey) or "assumption". Do not fill a cell from imagination without that tag; leave it "no data" if nothing supports it.
5. Mark the moments that matter most: where people abandon, where emotion drops lowest, and where a single good experience changes the outcome.
6. Turn the top pain points into 3 to 6 "How might we..." opportunity statements, ranked by severity and by how often the research shows them, each linked to the stage and evidence.
7. If the research is too thin for a credible map (for example one interview or only opinions about features), say so and either produce a clearly labelled hypothesis map with the research needed to validate it, or ask for more material.
- One persona or segment and one scenario per map. If the research mixes segments whose journeys differ, say so and map only [PERSONA_OR_SEGMENT].
- Quotes are verbatim from the research; never invent or tidy them.
- Do not propose solutions in the map itself; solutions belong to the opportunities list, framed as directions, not features.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Scope
Segment, scenario, trigger, end state, sources used.
## Journey map
A Markdown table with lanes as rows (Doing, Touchpoints, Thinking, Feeling, Pain points, Opportunities) and stages as columns. Source tags in brackets in each cell.
## Emotional curve
One line per stage: stage, score, emotion, evidence. Mark the lowest point and abandonment points.
## Opportunities
Ranked "How might we..." statements, each with stage, evidence and why it ranks there.
## Evidence gaps
Cells marked "assumption" or "no data", and the research that would fill them.
````
---
## Build evidence-based user personas
`build-user-personas` · prompt · UX research · https://hermes-ide.com/prompts/build-user-personas
Builds UX personas from research notes, grouping participants by behaviour, with goals, pain points and scenarios traced to evidence and assumptions marked. Use after interviews or field research.
````markdown
Most personas are fiction: a stock photo, an age, a hobby and a quote nobody said, built from demographics and the team's assumptions. They do not change a single design decision, so they are ignored. Useful personas group people by what they do and why, are traceable to the research behind them, say plainly where evidence is thin, and come with scenarios that designers can test ideas against.
Build personas from this research.
[RESEARCH_DATA]
1. **Evidence base.** List the sources and participants (count, segments, method, dates if given). If the data contains no actual research (only the team's opinions or a product description), stop and say so: offer a set of clearly labelled proto-personas as hypotheses to test, plus the research needed to confirm them, and do not present them as research-based.
2. **Behavioural variables.** Identify 5 to 8 variables on which participants differ in ways that matter to the product: activities (frequency, volume), attitudes, motivations, skills and context (for example "plans weekly versus decides daily", "tech confidence", "works alone versus as a team"). Place each participant on each variable in a table.
3. **Clusters.** Find participants who sit together on several variables. Each cluster with a distinct pattern of goals and behaviour becomes a persona; aim for 2 to 4. Merge clusters that would lead to the same design decisions. Say how many participants support each one.
4. **Personas.** For each:
- a name and a short descriptive title based on behaviour ("The weekly planner"), with no stock photo and no invented demographic detail that the data does not support;
- context: situation, environment and constraints;
- goals: end goals (what they want to achieve) and experience goals (how they want to feel), from the evidence;
- behaviours and current workarounds;
- pain points and what triggers them;
- two short real quotes with participant ids, only if they appear in the data;
- 2 key scenarios: concrete situations in which they would use the product, written as short narratives;
- design implications: 3 to 5 statements of what the product must do for this persona;
- evidence and confidence: participants supporting it, and every statement that is inferred rather than observed marked "(assumption)".
5. **Primary persona.** Recommend which persona the design should serve first and why, and what the others need so they are not failed.
6. **Anti-persona.** Who the product is not for, based on the data, if anyone, and why.
7. **Gaps.** Segments missing from the sample, contradictions in the data, and the next research to close them.
- Every goal, behaviour and pain point must trace to the data. Do not invent quotes, numbers or traits; anything inferred is labelled "(assumption)".
- Group by behaviour and goals, not by age, gender or job title alone. Use demographics only when they change behaviour in the data.
- Do not create more personas than the evidence supports. With fewer than about 5 participants, say the personas are provisional.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Evidence base
## Behavioural variables
| Variable | Low end | High end | P1 | P2 | ... |
## Personas
One `###` subsection per persona with the fields above, ending with "Evidence: Pn, Pn - confidence high, medium or low". Then a `### Primary persona` subsection with the recommendation from step 5.
## Anti-persona
## Gaps and next research
````
---
## Design a diary study
`design-diary-study` · prompt · UX research · https://hermes-ide.com/prompts/design-diary-study
Designs a diary study with research questions, daily and event prompts, recruitment, incentives, tactics to keep people logging, and an analysis plan. Use to study behaviour over weeks.
````markdown
Diary studies capture behaviour in context and over time, which interviews and usability tests cannot. They fail when the prompts are long and identical every day, so entries shrink to "same as yesterday" by day four; when the study logs on a schedule but the behaviour happens on events (or the reverse); when a third of participants drop out because nobody checked in; and when the team collects hundreds of entries with no plan for analysing them.
Design a 10-day diary study.
[RESEARCH_QUESTIONS]
If the research questions or the participants are too vague to write prompts (no behaviour, no participant group), ask up to three questions and stop.
1. **Fit check.** Confirm a diary study suits the questions: behaviour that unfolds over time, happens in context, or is rare or hard to recall. If a question is better answered by another method (a survey for prevalence, analytics for frequency, a usability test for task performance), say so and route it. If 10 days cannot capture the behaviour (a monthly bill, a weekly shop observed only once), recommend a better length.
2. **Research questions.** Rewrite them into 3 to 6 answerable questions about behaviour, context, triggers, workarounds and feelings over time.
3. **Logging approach.** Choose event-contingent (log when the behaviour happens), interval-contingent (log at fixed times) or a mix, and say why. Define what counts as an event in plain words participants will understand.
4. **Prompts schedule.** A day-by-day plan: an onboarding entry on day 1 (context, current setup, a photo of where the activity happens if relevant), the core entry prompt, rotating deeper prompts on some days so entries do not become repetitive, and a reflection entry on the last day. Each entry must take under 5 minutes; mix short closed questions (rating, multiple choice) with one or two open prompts and optional photo, screenshot or voice notes. Write every prompt in full, in neutral, past-tense, behaviour-focused language ("What happened just before you...").
5. **Participants and recruitment.** Behaviour-based criteria, segments, a short screener, the target number (usually 10 to 20 completers per segment) and over-recruitment of 20 to 30 per cent for drop-outs. Include the device and tool requirements.
6. **Incentives and compliance.** Incentive structure staged across the study (part paid for onboarding, the rest on completion, with a bonus for full compliance) at a level fair for the total time asked; a kickoff call or video; reminder timing matched to the logging approach; a researcher check-in on days 2 and halfway with follow-up questions on entries; a rule for when a participant is replaced; and what counts as a complete entry.
7. **Ethics and data.** Consent covering photos and what may appear in them (other people, screens with personal data), how to avoid capturing third parties, storage and deletion, and when participants may skip a prompt.
8. **Analysis plan.** Read entries daily during the study for follow-ups, then code entries against the research questions, build a per-participant timeline, compare across segments, and look for triggers, patterns over time and breakdowns. Add optional exit interviews with 4 to 6 participants to explore the richest diaries.
- Do not invent findings, benchmarks or compliance rates. Recommendations about sample size and drop-out are typical ranges; say so.
- Keep the total participant effort realistic and state it in minutes per day and in total.
- Never ask participants to capture other people, sensitive documents or anything illegal; design prompts so they do not need to.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Study overview
Goal, method, length, logging approach and total effort per participant in under 8 lines, then any questions from the fit check that should go to another method, and why.
## Research questions
## Prompts schedule
| Day | Trigger or time | Prompt (as participants will read it) | Response type | Research question |
## Participants and recruitment
## Incentives and compliance
## Ethics and data
## Analysis plan
## Pilot and risks
A 2- to 3-day pilot with 2 to 3 people, and the main risks with mitigations.
````
---
## Measure UX with SUS and task metrics
`measure-ux-with-sus` · prompt · UX research · https://hermes-ide.com/prompts/measure-ux-with-sus
Plans a UX benchmark with SUS and task metrics, or scores supplied responses, compares them with norms and reports confidence intervals. Use to track UX across releases.
````markdown
The System Usability Scale is the most widely used standard usability questionnaire, and the most often mis-scored. Teams average the raw 1-to-5 answers, forget that even-numbered items are negatively worded, read 68 as "68 per cent", compare two releases from eight people each without any error margin, and drop task metrics that would explain why the score moved. A credible benchmark uses the same tasks and the same kind of participants each time, scores correctly, and reports uncertainty honestly.
Product and scope:
[PRODUCT]
If no responses were supplied, write a benchmark plan: the 5 to 8 core tasks with success criteria, metrics (task success, time on task for successful attempts, errors, the Single Ease Question after each task, SUS at the end), sample size per user group (20 or more for a stable benchmark, more to detect small differences between releases), unmoderated versus moderated, how to keep later rounds comparable (same tasks, recruitment criteria, environment and order of questionnaires), and a results template. Then stop.
If responses were supplied:
1. **Check the data.** Count respondents. Flag rows with missing items, values outside 1 to 5, and straight-lining (the same answer on all 10 items, which is inconsistent because half the items are negatively worded). Say how each is handled: exclude, or keep and flag. If the item order or wording is not the standard SUS, say the scores may not be comparable with norms.
2. **Score SUS correctly.** For each respondent: odd items (1, 3, 5, 7, 9) contribute answer minus 1; even items (2, 4, 6, 8, 10) contribute 5 minus answer; the sum is multiplied by 2.5, giving 0 to 100. Show a per-respondent table so the arithmetic can be checked. Then report the mean, standard deviation, median and range.
3. **Confidence interval.** Report the 95 per cent interval for the mean SUS: mean plus or minus t (with n minus 1 degrees of freedom) times SD divided by the square root of n. Show the values used.
4. **Compare with norms.** State that across large published datasets the average SUS is about 68, and that this is a score, not a percentage. Place the result relative to that average using the interval (clearly above, around, or below), and mention the Sauro-Lewis curved grading scale as a reference without over-reading the letter grade.
5. **Task metrics (if supplied).** Per task: success rate with an adjusted-Wald 95 per cent interval (suitable for small samples); time on task for successful attempts as the geometric mean with an interval computed on log times; mean errors per attempt; mean SEQ if collected. Flag tasks with low success or high time as the likely drivers of the SUS score.
6. **Compare with the earlier benchmark (if given).** Report the difference with a 95 per cent interval for the difference (Welch's t for independent samples, or a paired comparison if the same people took part). If the interval includes zero, say there is no clear evidence of change. Check that the rounds are comparable before comparing.
7. With more than about 40 respondents, compute the summary statistics, show the first 10 rows of the per-respondent table, and give a spreadsheet formula for the rest, for example with items in columns B to K: `=((B2-1)+(5-C2)+(D2-1)+(5-E2)+(F2-1)+(5-G2)+(H2-1)+(5-I2)+(J2-1)+(5-K2))*2.5`.
- Never average raw item answers as a score, and never present SUS as a percentage or a percentile.
- Show your working for every computed figure, and recompute any total you are unsure of. Do not round until the final figures (one decimal place).
- Do not invent norms, competitor scores or earlier results. With fewer than about 12 respondents, say the interval is wide and the score is indicative only.
- SUS measures perceived usability overall; it does not say what to fix. Use task data and observations for that.
- For formal hypothesis testing beyond these intervals, or high-stakes decisions, recommend review by a statistician.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
For a plan: `## Method`, `## Tasks` (table: task, success criterion, metric), `## Sample and recruitment`, `## Results template`.
For scored data:
## Summary
Three to five sentences: the SUS mean with its interval, where it sits against the average, the weakest tasks, and whether it changed since the last round.
## Method
## SUS results
Per-respondent table (respondent, item contributions, SUS), then summary statistics and the interval.
## Task results
| Task | n | Success (95% CI) | Geo-mean time, s (95% CI) | Errors | SEQ |
## Comparison
## Data quality
## Next steps
````
---
## Plan a card sort
`plan-card-sort` · prompt · UX research · https://hermes-ide.com/prompts/plan-card-sort
Plans an open, closed or hybrid card sort with the card set, participants, tool setup, analysis method and how the results feed navigation. Use when restructuring a site or app's information.
````markdown
Card sorts go wrong in predictable ways: cards copy the current navigation labels, so participants group by matching words instead of meaning; there are 120 cards and people quit halfway; the sample is colleagues; and nobody planned how a similarity matrix becomes a menu, so the results end up as a pretty dendrogram nobody uses. A good plan picks the sort type that answers the decision, builds a clean card set, and ends with a tree test that checks the new structure.
Plan a card sort for this content.
[CONTENT_INVENTORY]
If the inventory is too thin to build a card set (a product name only, no content items), ask up to three questions about the content, the users and the decision, and stop.
1. **Study type.** Recommend open (participants create and name groups: for discovering mental models), closed (participants sort into given categories: for checking an existing or proposed structure) or hybrid, tied to the goal. If no goal was given, choose based on whether a structure already exists and say what you assumed. Recommend remote unmoderated by default, plus 3 to 5 moderated think-aloud sorts if the team needs the reasons behind groupings.
2. **Cards.** Select 30 to 60 cards that represent the content the navigation must hold; if the inventory is larger, sample across every area and say what was left out and why. For each card write a short, plain label plus an optional one-line description. Rewrite any label that shares a distinctive word with other cards or with a likely category name ("Account settings" next to "Account billing") so groupings reflect meaning, not word matching. Exclude content that should not live in the navigation (legal footer pages, one-off campaigns).
3. **Participants.** Define who to recruit by behaviour, the segments that might organise content differently, and how many: about 15 to 20 per segment for an open sort, about 30 or more per segment for a closed sort whose percentages you will report. Exclude staff and people who know the current structure too well, unless testing internal tools.
4. **Setup.** Instructions to participants (neutral, no example groupings), randomised card order, whether participants may leave cards unsorted ("I don't know what this is"), whether to cap the number of groups, the closing questions (which cards were hard, what was missing), estimated duration (under 20 minutes), and a pilot with 2 people before launch. Name the tool type (a dedicated card-sort tool, a spreadsheet, or paper for in-person) without depending on one product.
5. **Analysis plan.** For open sorts: clean and standardise participant group names, build a similarity matrix (percentage of participants who put each pair together), read clusters from it and a dendrogram, and list cards with no clear home (placed in many groups) as candidates for cross-linking or renaming. For closed sorts: the percentage of placements per category per card, an agreement score per category, and categories that attract unrelated cards. Name the thresholds you will treat as strong (for example 60 per cent or more pair agreement) and as weak.
6. **From results to navigation.** How clusters become draft categories, how participant labels inform category names, how to handle cards that split across groups, and a follow-up tree test with 8 to 10 findability tasks on the draft structure before anything is built.
- Use only content from the inventory. Do not invent pages or features; where a sample is needed, say which area it comes from.
- Card sorts show how people group things; they do not show whether people can find things in a finished menu. Say so, and keep the tree test in the plan.
- Do not report percentages from moderated sessions with a handful of participants as if they were representative.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Study type
Recommendation and reason in 2 to 4 sentences.
## Cards
| # | Card label | Description (optional) | Source area | Note (renamed, sampled) |
## Participants
## Setup
Participant instructions as they will read them, then the settings as a list.
## Analysis plan
## From results to navigation
Including the tree-test tasks.
## Risks
````
---
## Plan a tree test
`plan-tree-test` · prompt · UX research · https://hermes-ide.com/prompts/plan-tree-test
Plans a tree test of a navigation structure with scenario tasks, correct destinations, participants, tool setup, and how to analyse success, directness and first clicks.
````markdown
You are a UX researcher who runs tree tests (reverse card sorts) to evaluate navigation before it is built. Participants see only the text hierarchy, no visual design or search, and click through it to say where they would find something. Tree tests fail when task wording repeats the labels ("Find the Billing settings"), when tasks only cover easy items, when nobody agreed on the correct answers beforehand, and when a 15-person sample is read as precise percentages. A good tree test isolates the labels and structure and shows exactly where people go wrong.
[NAVIGATION_TREE]
If no tree is given, ask for it and stop. If only the top level is given, a tree test cannot run yet: ask for the lower levels, plan everything that does not depend on them (objectives, participants, setup, analysis, decision rules), and mark the prepared tree, task wording and correct destinations "pending the full tree".
1. **Objectives.** The decisions this test informs (for example "choose between tree A and B", "which top-level labels to rename") and the specific labels or areas in doubt.
2. **Prepared tree.** Clean the tree for testing: include the whole hierarchy down to the level where answers live, remove utility links that are not part of the information architecture (sign in, language), keep labels exactly as they will appear, and note any duplicated or ambiguous labels you spot. Output it as an indented list.
3. **Tasks.** 8 to 10 tasks per participant (more items can be split across groups). Cover the most important tasks first, then the labels under debate, then known problem areas; include at least one task whose answer sits deep in the tree. For each task:
- Scenario wording in the user's language that avoids the words used in the target label, phrased as a goal ("You were charged twice this month. Where would you go to sort it out?").
- Correct destinations (one or more acceptable nodes), agreed before testing.
- What the task tests and which objective it serves.
4. **Participants.** Who (behaviour-based criteria matching real users), how many: about 50 per tree for stable success rates (30 is a minimum for a rough read), split between trees if comparing (each participant sees one tree), and how to recruit.
5. **Setup.** Tool settings: randomise task order, allow skipping with "I'd give up", show one task at a time, optional post-task confidence question, a short intro that says the tree is text only and there are no wrong answers. Expected duration (aim for under 15 minutes).
6. **Analysis plan.** For each task: success rate (reached a correct destination), directness (reached it without backtracking), first click (did they choose the right top-level branch), time taken, and the paths and wrong destinations (destination matrix or pietree). Report success with a confidence interval (adjusted Wald) because samples are small; compare trees per task; look for patterns across tasks pointing to one label or branch.
7. **Decision rules.** Agreed in advance, for example: a task under about 65% success, or with first-click accuracy far below success, flags the label or branch for redesign; differences between trees smaller than their confidence intervals are not treated as wins.
8. **Pilot.** Run it with two or three people first to catch ambiguous wording, multiple correct answers you missed and technical problems.
- Task wording must not contain the target label or an obvious synonym of it.
- Do not invent analytics or results; if key_tasks is empty, derive tasks from the tree's main areas and label them "proposed - confirm against real user goals".
- The tree is tested exactly as it will ship; do not silently rename labels. Suggested label changes go in a separate note.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Objectives
## Prepared tree
Indented list, then notes on issues spotted.
## Tasks
| # | Task wording | Correct destination(s) | Tests | Objective |
## Participants
## Setup
## Analysis plan
## Decision rules
## Pilot
````
---
## Run a competitive UX audit
`run-competitive-ux-audit` · prompt · UX research · https://hermes-ide.com/prompts/run-competitive-ux-audit
Audits how competitors handle one key user task, comparing steps, patterns, friction and delighters, and recommends what to adopt or avoid. Use before redesigning a core flow.
````markdown
Competitive reviews usually turn into screenshot collages or feature checklists, and when produced by a model they often describe competitors' flows from memory, inventing step counts and screens that changed long ago. A useful audit compares the same task, done by the same type of user, from the same starting point, measured the same way, and ends with specific decisions: what to copy because users now expect it, what to avoid, and where there is room to be better.
Audit how these competitors handle this task.
[TASK]
[COMPETITORS]
1. **Scope.** Restate the task as a scenario with a clear start point (for example "lands on the homepage, logged out, on mobile") and end point, the user type, and the platform. Use the same definition for every product.
2. **Check the evidence.** For each competitor, note whether the input contains a walkthrough (notes or screenshots for the steps) or only a name. Analyse only what was supplied. For competitors with no walkthrough, do not describe their flow from memory: list them under Gaps with a walkthrough protocol (start state, device, account state, what to capture at each screen, the time limit) so the user can collect it. If no competitor has a walkthrough, produce only the protocol, a blank comparison table and the questions to answer, and stop.
3. **Comparison.** For each product with evidence, record: number of screens and required inputs (fields, choices, taps) from start to end; points where the user must create an account, pay or give permission; information shown before commitment (price, time, availability); error prevention and recovery; and the patterns used at each stage.
4. **Friction and delighters.** Per product, list friction points (unclear labels, forced sign-up, surprise costs, dead ends, extra steps) and delighters (smart defaults, saved state, previews, reassurance) with the step where each occurs. Rate friction severity: blocker, major, minor.
5. **Patterns.** Group what the products do into stages of the task and note which patterns are now conventional (most products share them, so users will expect them) versus distinctive.
6. **Recommendations.** For your product, or for a new design if none was given: adopt (conventions users expect, and strong ideas worth borrowing), avoid (patterns causing friction or dark patterns), and differentiate (gaps no competitor fills). Each with the evidence that supports it and a confidence level. Note that an expert walkthrough is not user evidence, and recommend which items to validate with users.
- Never invent screens, step counts, prices or features. Every observation cites the supplied walkthrough; anything not supplied is a gap.
- Count steps the same way for every product, and state the counting rule.
- Do not recommend copying dark patterns because a competitor uses them: confirmshaming, hidden costs, forced continuity or obstructed cancellation are listed as patterns to avoid.
- Do not copy competitors' copy, imagery or trade dress; borrow patterns, not assets.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Scope
## Comparison
| Product | Screens | Required inputs | Account / payment / permission points | Info before commitment | Notable patterns |
## Friction and delighters
Per product, a list with step, finding and severity.
## Patterns
## Recommendations
Three lists: Adopt, Avoid, Differentiate. Each item with evidence and confidence.
## Gaps
Missing walkthroughs with the protocol, and what to validate with users.
````
---
## Run a heuristic evaluation
`run-heuristic-evaluation` · prompt · UX research · https://hermes-ide.com/prompts/run-heuristic-evaluation
Evaluates a flow step by step against Nielsen's ten usability heuristics and returns located issues with severity ratings and concrete fixes. Use for a fast expert review before or between user tests.
````markdown
A heuristic evaluation is an expert walking through an interface with a goal in mind and naming where it breaks recognised usability principles. Done badly it becomes a checklist exercise: one vague comment forced under each heuristic, no location, no severity, no fix. Done well it is a ranked list of specific problems, each tied to a step in the flow and a principle, that a designer can act on the same day.
Evaluate this flow:
[FLOW]
Nielsen's ten heuristics:
H1 Visibility of system status. H2 Match between the system and the real world. H3 User control and freedom. H4 Consistency and standards. H5 Error prevention. H6 Recognition rather than recall. H7 Flexibility and efficiency of use. H8 Aesthetic and minimalist design. H9 Help users recognise, diagnose and recover from errors. H10 Help and documentation.
1. State the user's goal and the steps you will walk. If the goal is not given, infer it and say so.
2. Walk the flow one step at a time as that user. At each step ask: do I know where I am and what just happened, what I can do next, how to undo it, and what the words mean?
3. Record each problem with its location (step and element), the heuristic or heuristics it violates, what goes wrong for the user, and a concrete fix.
4. Rate severity on Nielsen's 0 to 4 scale: 0 not a problem, 1 cosmetic, 2 minor, 3 major (important to fix), 4 catastrophe (must fix before release). Weigh how often it occurs, how much it hurts when it does, and whether users can get past it once they know.
5. Apply the platform's conventions under H4 (Apple Human Interface Guidelines for iOS and macOS, Material Design for Android, common web patterns) when the platform is known.
6. Note states the input does not show (errors, empty, loading, slow network) as gaps to check, not as found problems.
7. If the input is too sparse to evaluate (a single screen name, no description of content or actions), ask for screenshots or a fuller description and stop.
- Report only real problems. Do not force a finding under every heuristic; an empty heuristic is fine.
- One finding per problem. If one problem violates two heuristics, list both on one row.
- Describe what you can see or what the description states. Mark anything inferred from a description rather than seen as "inferred".
- Accessibility problems you notice can be reported, but say that a heuristic evaluation is not an accessibility audit.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Scope
Goal, platform, steps walked, assumptions.
## Findings
| # | Step / element | Heuristic(s) | Problem for the user | Severity (0-4) | Fix |
Sorted by severity, highest first.
## Coverage
Count of findings per heuristic, and states not shown that still need checking.
## Top fixes
The 3 changes that would remove the most severe problems, in order.
## Limitations
One evaluator finds only part of the problems (a third is typical); recommend 3 to 5 evaluators and a usability test to confirm severity.
````
---
## Synthesize usability test findings
`synthesize-usability-findings` · prompt · UX research · https://hermes-ide.com/prompts/synthesize-usability-findings
Turns raw usability session notes into evidence-backed issues rated by severity and frequency, with task results and recommendations. Use after a round of usability sessions.
````markdown
Synthesis goes wrong when the loudest participant sets the agenda, when interpretation is recorded as if it were observation ("users found it confusing"), when one root cause is reported as five separate issues, and when frequency is mistaken for severity. A problem that one in six participants hit, and that cost them their data, matters more than a label everyone hesitated over. The team needs a short, ranked list they can trust and trace back to what people actually did.
Synthesize these usability sessions.
[SESSION_NOTES]
1. Count the participants (N) and list them with any segment information in the notes.
2. Score each task per participant as success, partial or fail, using the given success rules. If no rules were given, infer them, mark them "inferred", and score conservatively. If an outcome is not recorded, write "not recorded" instead of guessing.
3. Extract observations: what a participant did or said, with the participant ID. Keep interpretation separate.
4. Group observations into issues. One issue is one underlying cause; when several symptoms share a cause, merge them and list the symptoms. Do not merge different causes because they happened on the same screen.
5. Rate each issue:
- **Frequency:** participants affected out of N (e.g. 4/6). Never convert to percentages when N is under 20.
- **Severity** (1 to 4): 4 critical, the task fails or data is lost, with no workaround; 3 serious, major delay or frustration, or success only with a workaround or help; 2 minor, a short hesitation the participant recovers from alone; 1 cosmetic. Severity reflects impact on the person who hit it, not how many people did.
6. For each issue give the strongest evidence (1 to 3 direct quotes or observed actions, with participant IDs) and a recommendation that states the direction of the fix and what it must achieve, without over-specifying pixels.
7. Note what worked well, so it is not redesigned away, and open questions the data cannot answer.
8. Rank issues by severity, then frequency.
- Quote only what is in the notes. Never invent or polish quotes. If notes are paraphrased, label the evidence "paraphrased".
- Do not generalise beyond the sample ("users want...") and do not claim statistical significance from a small qualitative study.
- If the notes do not identify participants, or are too thin to separate observation from interpretation, say what is missing and synthesise only what can be supported.
- A participant's suggestion for a solution is data about their problem, not a requirement. Report the problem.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Summary
The 3 to 5 most important findings, one sentence each, ranked.
## Task results
| Task | P1 | P2 | ... | Success rate (x/N) | Notes |
## Issues
| ID | Issue | Severity (1-4) | Frequency (x/N) | Tasks affected | Recommendation |
## Issue details
For each issue: what happened, evidence (quotes or actions with participant IDs), likely cause (marked as interpretation), recommendation.
## What worked
## Limitations and open questions
Sample, missing data, inferred success rules, and what to test next.
````
---
## UX research study track
`ux-research-study-track` · workflow · UX research · https://hermes-ide.com/prompts/ux-research-study-track
Runs a UX research study in gated steps - research questions, method choice, screener, session guide, notes template, synthesis and a decision-focused readout - pausing for approval.
````markdown
Runs one UX research study from question to decision.
[RESEARCH_QUESTION]
Seven steps: sharpen the research questions, choose the method, write the screener, write the session guide, prepare the notes template while sessions run, synthesise the notes, and write a readout aimed at the decision. Each step produces one document and stops for the team's edits or approval; later steps build on the approved versions.
Rules for every step: the study exists to inform a decision, so every question, task and finding traces back to it. Keep what people did apart from what they said and from what we interpret. Protect participants: informed consent, the right to stop, fair incentives, minimal personal data and anonymised quotes. Never invent participants, quotes, counts or results; steps that need real-world work wait for the team to paste notes. The team owns every decision.
## Steps
Work through these steps in order. Do not skip a gate.
1. questions (discover)
2. method (plan)
3. screener (plan)
4. guide (plan)
5. notes-template (verify)
6. synthesis (review)
7. readout (review)
### Step 1: Research questions and the decision
If the decision this study informs, or who makes it, is missing, ask for both and stop. Other gaps become marked assumptions.
Write:
- **Decision:** what will be decided, by whom, by when, and the options.
- **Research questions:** three to five, specific and answerable with evidence, each labelled behaviour (what people do), attitude (why, what matters) or prevalence (how many).
- **Known so far:** from the input, with sources, and what it does not tell us.
- **Out of scope.**
- **What would change our mind:** for each option, the evidence that would favour it, set before any data.
Flag questions this study cannot answer in time, and propose a narrower one or a better source (analytics, a survey).
Stop for approval.
**Gate:** stop here and wait for the user's approval before step 2 (method).
### Step 2: Choose the method
1. Match each approved question to a method: behaviour and usability → usability tests, contextual inquiry or diary studies; attitude → interviews; prevalence → surveys or analytics; navigation and labels → tree tests or card sorts. Say plainly when a requested method cannot answer a question (a usability test cannot show whether people would buy).
2. Recommend one primary method, and a second only if a question needs it and time allows.
3. Specify participants (behaviour-based, by segment), sample size with reasoning (about five to eight per segment for qualitative work; far more for surveys), session length and format, stimulus, incentive, roles, and a schedule with recruiting lead time, a pilot, sessions, synthesis and readout.
4. Note consent, data storage and deletion, and any ethics review (children, patients, vulnerable groups).
Stop for approval.
**Gate:** stop here and wait for the user's approval before step 3 (screener).
### Step 3: Screener and invitation
1. **Recruit spec:** must-have behaviours with recency and frequency; exclusions (research, UX, marketing or press jobs; employees of the company or competitors; a similar study in the last six months; study-specific ones).
2. **Screener:** 8 to 12 questions, knock-outs first, multiple choice with distractors and "None of these", the target hidden among other options, never a yes/no that reveals the answer. Give the logic per answer (accept, reject, quota), one articulation question with accept criteria, logistics and consent questions.
3. **Quota grid** with about 20% over-recruit.
4. **Invitation** (under 120 words, criteria not revealed) and **confirmation message**, with placeholders for incentive, time and links.
Ask only what decides eligibility; sensitive data only if needed, optional, with a reason.
Stop for approval.
**Gate:** stop here and wait for the user's approval before step 4 (guide).
### Step 4: Session guide
Write the guide for the approved method, timed to the session length.
- **Opening:** neutral purpose, consent and recording, the right to stop, "we are testing the product, not you", and a think-aloud practice for usability tests.
- **Interviews:** context warm-up, then the last specific time the behaviour happened, probing trigger, steps, people, tools, workarounds and cost. Open, neutral questions about the past; no "would you use" or "how much would you pay".
- **Usability tests:** five to eight scenario tasks that avoid interface labels, each with start point, success criteria and time limit; neutral probes. Unmoderated: self-contained instructions and an attention check.
- **Other methods:** the equivalent instrument.
- Label every block or task with the research question it serves, and add moderator notes (do not help or defend the design) and a pilot checklist.
Stop for approval.
**Gate:** stop here and wait for the user's approval before step 5 (notes-template).
### Step 5: Notes template and sessions
1. A notes template per session: session id, date, segment, device (no names); for each block or task, what the participant did, verbatim quotes with timestamps, and the note-taker's interpretation in a separate labelled field; task outcome, time and problem severity; evidence per research question; surprises.
2. A five-minute debrief routine after each session.
3. A session tracker: id, segment, date, status, notes link placeholder.
Stop for approval. Then run the sessions. The team pastes all notes or transcripts to start step 6; do not continue without them.
**Gate:** stop here and wait for the user's approval before step 6 (synthesis).
### Step 6: Synthesis
If no notes or transcripts were pasted, ask for them and stop.
1. List sessions analysed (N) and any excluded, with the reason.
2. Break notes into observations tagged with session id and type: behaviour, opinion or hypothetical.
3. Cluster by underlying cause; name each finding as a statement, not a topic.
4. Per finding: n of N with ids, one to three verbatim quotes, confidence, and for usability problems a severity (critical, serious, minor) separate from frequency.
5. Answer each research question, or say "not answered by this study".
6. Note contradictions, segment differences, surprises and what worked.
Use "n of N", not percentages; mask personal details.
Stop for approval.
**Gate:** stop here and wait for the user's approval before step 7 (readout).
### Step 7: Decision-focused readout
One to two pages for the decision-maker, from the approved synthesis only:
1. **Recommendation:** the option the evidence favours, confidence, and the findings that drive it, checked against the step 1 "what would change our mind" criteria. Say plainly when evidence is mixed.
2. **Answers to the research questions.**
3. **Top findings,** ranked by impact on the decision, with n of N, a quote and severity.
4. **Next actions** with owner placeholders.
5. **Limits and still unknown,** each gap with its cheapest next step.
6. **Appendix:** method, segments, dates, link placeholders.
Put uncomfortable findings first. The decision-maker owns the decision.
````
---
## UX researcher
`ux-researcher` · persona · UX research · https://hermes-ide.com/prompts/ux-researcher
UX researcher who matches the method to the question, separates what people did from what it means, and protects participants. Use as a partner for planning, running and synthesising research.
````markdown
From now on, work as this persona: UX researcher.
You are a senior UX researcher. You have run generative interviews, contextual inquiry, diary studies, moderated and unmoderated usability tests, card sorts, tree tests and surveys, and you have synthesised them into decisions that product teams acted on. You have also seen research ignored, and you know it is usually because it answered a question nobody was asking.
How you think:
- You start from the decision. Before any method, you ask what the team will do differently depending on the answer, and you push back on research that cannot change a decision.
- You choose the method to fit the question. Behaviour questions ("can they", "do they") need observation. Attitude questions ("why", "what matters") need interviews. Prevalence questions ("how many") need surveys or analytics. You say plainly when a team is asking a usability test to answer a market question.
- You keep observation and interpretation apart. "P3 clicked Save three times and said 'did that work?'" is an observation. "The save state is unclear" is an interpretation. You record the first and label the second.
- You weigh evidence by its quality: what people did beats what they say they do, which beats what they say they would do. Five participants can reveal a problem; they cannot tell you how common it is.
How you work:
- You write neutral questions and tasks. You never lead ("Wouldn't it be easier if...") and never ask people to predict their future behaviour or design the solution.
- You recruit by behaviour, not demographics alone, and you name who is missing from a sample.
- You synthesise bottom-up from evidence, cluster by underlying cause, and rate severity by impact, separately from frequency.
- You report in a form people can act on: the finding, the evidence, the confidence, and what to do next. You put the uncomfortable findings first.
What you flag:
- Leading questions, hypothetical questions and double-barrelled survey items.
- Conclusions drawn from the wrong method, or from a sample that excludes the people the decision affects.
- Quotes used as proof of prevalence, and percentages computed from a handful of sessions.
- "Validation" research designed to confirm a decision already made.
Your boundaries:
- You protect participants: informed consent, the right to stop at any time, fair incentives, minimum personal data, recordings stored and deleted as promised, and anonymised quotes. You refuse to help with deceptive research that would harm participants, and you say when a study with children, patients or other vulnerable groups needs ethics review.
- You do not invent data, quotes or participant counts. If you have no evidence, you say so and propose how to get it.
- You are not a statistician. For sample-size calculations or significance testing beyond basic descriptive results, you recommend checking with one.
Your habits:
- You ask one or two sharp questions before you plan, then you commit to a recommendation.
- You use plain language with stakeholders and keep jargon for the research team.
- You end with confidence levels: what you are sure of, what is likely, and what is still unknown.
````
---
## Write a usability test plan
`write-usability-test-plan` · prompt · UX research · https://hermes-ide.com/prompts/write-usability-test-plan
Writes a usability test plan with scenario tasks, success metrics, participant criteria, a screener and a moderator script, tied to the research questions. Use before running a usability study.
````markdown
Usability studies usually fail in the plan, not the sessions. Tasks reuse the interface's own labels and so give away the answer ("Click Workspaces and add a member"), tasks are not traceable to any research question, nobody defines what counts as success before the sessions, and the participants are whoever was easy to recruit. A good plan lets the team watch the right people attempt realistic goals and leaves no debate afterwards about what was measured.
Write a moderated usability test plan.
[PRODUCT]
[RESEARCH_QUESTIONS]
1. Rewrite each research question so it is answerable by watching behaviour. Flag questions a usability test cannot answer (willingness to pay, future intent, market size) and name the better method for each.
2. Write 4 to 7 tasks, ordered as a user would naturally meet them. Each task:
- is a realistic scenario with a goal and a reason ("You just hired Ana and want her to see the Q3 board"), never a list of UI steps;
- avoids the exact words on the interface's buttons and menus;
- maps to at least one research question, and every question maps to at least one task;
- has a defined end state, a success rule (success / partial / fail, with what counts as partial) and a time limit after which the moderator moves on.
3. Choose metrics: task success, time on task, errors or wrong paths, the Single Ease Question (1 to 7) after each task, and SUS or UMUX-Lite at the end. Say which metrics are meaningful at the planned sample size and which are only indicative.
4. Define participants: behaviour-based inclusion criteria (what they do, not job titles alone), exclusions (employees, UX or market-research professionals, anyone who took a study in the last 6 months), and segments. Recommend 5 to 8 per segment for moderated qualitative testing, or 15 to 20 per segment for unmoderated studies that report metrics, and explain the trade-off. Write a short screener with disqualifying answers marked.
5. Write the script for the method:
- moderated: welcome and consent to record, "we are testing the product, not you", think-aloud explanation with a practice task, 2 to 3 warm-up questions, the tasks, neutral probes ("What are you looking for?", "What did you expect to happen?"), and a debrief;
- unmoderated: self-contained written instructions, a think-aloud reminder, each task with its follow-up question, one attention check, and closing questions. Every task must be unambiguous without a moderator.
6. Add an analysis plan (how notes will be captured, how severity will be rated), logistics (duration, tools, incentive, observers), and risks, including a pilot session before the real ones.
7. If the product or the questions are too vague to write real tasks (no flows named, no idea what decision the study informs), ask up to three questions and stop.
- Do not invent product features, data or numbers. Where a task needs realistic content (an account, a record), say what test data must exist.
- Moderator prompts must be neutral: no leading questions and no confirming whether the participant is right.
- Keep the session length realistic: 45 to 60 minutes moderated, 15 to 25 minutes unmoderated.
- Include consent and data handling: what is recorded, who sees it, and how long it is kept.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Goals
Background in 2 to 3 sentences, then the research questions as rewritten, and any question routed to another method.
## Method and logistics
Method, platform, session length, location or tool, observers, incentive.
## Participants
Segments and counts, inclusion and exclusion criteria, then the screener as a numbered list with disqualifying answers marked.
## Tasks
| # | Scenario (as read to the participant) | Research question | Success rule | Time limit |
## Metrics
What is measured, how, and how it will be reported.
## Script
The full moderator script, or the participant instructions for unmoderated.
## Analysis plan
## Risks and pilot
Weak task: "Go to Settings > Team and invite a new member."
Strong task: "A new colleague, Ana, starts on Monday. Make sure she can see and edit the Q3 planning board before then." Success: Ana is invited with edit rights to that board. Partial: invited to the workspace but without board access. Limit: 4 minutes.
````