This skill guides UX thinking across product decisions — what to show, what to hide, and how to communicate with users in a way that builds trust without exposing internal complexity.
The user provides a flow, feature, screen, or copy to review. They may include context about the audience, the goal, or a specific problem they're seeing.
Core UX Principle: Outcomes Over Implementation
Users think in goals, not systems. They want to know:
- What will this do for me?
- Is this safe / will I lose anything?
- What happens next?
They do not want to know:
- Which AI model generated this
- Which third-party API is being called
- What database query is running
- What the retry logic looks like
- Internal status codes or error stack traces
Before any copy, label, tooltip, or status message — ask: "Is this information for the user, or for the engineer?" If it's for the engineer, it doesn't belong in the UI.
UX Thinking Framework
Before suggesting changes, understand:
- Who is the user? Their mental model, vocabulary, and context. A developer reads differently than a CMO.
- What is the job to be done? The single thing they came to accomplish right now.
- Where are they in the flow? Entry, decision point, waiting, success, error, or exit.
- What do they fear? Data loss, irreversibility, cost, confusion, embarrassment.
What to Show vs. What to Hide
Show:
- Progress toward the user's goal ("Your file is ready")
- Confirmation that something worked ("Saved")
- What the user can do next
- Relevant constraints in plain language ("Max 10 members on free plan")
- Recoverable errors with a clear path forward ("Something went wrong — try again")
Hide:
- Service names, model names, vendor names unless the user explicitly chose them
- Technical error messages (log them, don't surface them)
- Processing steps the user can't act on ("Calling GPT-4o-mini..." → just show a spinner)
- Internal state transitions ("Queuing...", "Initialising...", "Hydrating...")
- Percentage progress that isn't meaningful ("12%... 13%...")
Language & Copy Guidelines
Write copy the way a calm, knowledgeable colleague would speak — not a system log:
- Action labels: Verb + object. "Save draft", "Send invite", "Export PDF". Never "Submit", "Proceed", "Execute".
- Status messages: Past tense for done ("Saved"), present continuous for in-progress ("Saving…"), imperative for next step ("Add a team member").
- Error messages: Say what happened in plain language, then what to do. Never show error codes to end users.
- Empty states: Tell the user what they'll get here and give them one clear action to start.
- Tooltips: Only if the label alone is genuinely ambiguous. Don't use them to explain implementation.
- Loading states: Name the outcome, not the process. "Getting your results" beats "Fetching data from API".
Flow Review Checklist
When auditing a flow or screen:
- Can the user tell where they are? (orientation)
- Can the user tell what to do next? (wayfinding)
- Does every piece of text serve the user's goal? (relevance)
- Are any internal details leaking into the UI? (abstraction)
- What happens on error — does the user know what to do? (recovery)
- What is the user feeling at this moment? (emotional state — anxious, excited, confused, relieved?)
- Is anything asking for effort the user shouldn't have to give? (friction)
Friction Audit
Common friction sources to eliminate:
- Asking for information you don't need yet (forms that ask for credit card before showing value)
- Requiring a decision with insufficient context ("Do you want to enable advanced mode?" — what is that?)
- Success screens that don't tell the user what to do next
- Modals that interrupt flow without a clear purpose
- Copy that explains how the system works instead of what it means for the user
- Loading states with no feedback on progress or expected duration
- Confirmation dialogs for low-stakes, reversible actions
Onboarding UX
Good onboarding shows value before asking for commitment:
- Lead with what the user can accomplish, not a feature list
- Delay account creation until the user has experienced something worth returning for
- Use progressive disclosure — reveal complexity only when the user is ready for it
- The first "aha moment" should be reachable in under 60 seconds
Applying This Alongside frontend-design
UX and UI are complementary. The [[frontend-design]] skill handles how things look and feel visually. This skill handles what is shown, what is said, and when. Apply both together:
frontend-design makes it beautifuluser-experience makes it make sense
When conflicts arise — always side with clarity over aesthetics. A stunning interface that confuses the user has failed.
1---2name: user-experience3description: This skill guides UX thinking across product decisions — what to show, what to hide, and how to communicate with users in a way that builds trust without exposing internal complexity.4---56This skill guides UX thinking across product decisions — what to show, what to hide, and how to communicate with users in a way that builds trust without exposing internal complexity.78The user provides a flow, feature, screen, or copy to review. They may include context about the audience, the goal, or a specific problem they're seeing.910## Core UX Principle: Outcomes Over Implementation1112Users think in goals, not systems. They want to know:13- What will this do for me?14- Is this safe / will I lose anything?15- What happens next?1617They do not want to know:18- Which AI model generated this19- Which third-party API is being called20- What database query is running21- What the retry logic looks like22- Internal status codes or error stack traces2324**Before any copy, label, tooltip, or status message — ask: "Is this information for the user, or for the engineer?"** If it's for the engineer, it doesn't belong in the UI.2526## UX Thinking Framework2728Before suggesting changes, understand:29- **Who is the user?** Their mental model, vocabulary, and context. A developer reads differently than a CMO.30- **What is the job to be done?** The single thing they came to accomplish right now.31- **Where are they in the flow?** Entry, decision point, waiting, success, error, or exit.32- **What do they fear?** Data loss, irreversibility, cost, confusion, embarrassment.3334## What to Show vs. What to Hide3536**Show:**37- Progress toward the user's goal ("Your file is ready")38- Confirmation that something worked ("Saved")39- What the user can do next40- Relevant constraints in plain language ("Max 10 members on free plan")41- Recoverable errors with a clear path forward ("Something went wrong — try again")4243**Hide:**44- Service names, model names, vendor names unless the user explicitly chose them45- Technical error messages (log them, don't surface them)46- Processing steps the user can't act on ("Calling GPT-4o-mini..." → just show a spinner)47- Internal state transitions ("Queuing...", "Initialising...", "Hydrating...")48- Percentage progress that isn't meaningful ("12%... 13%...")4950## Language & Copy Guidelines5152Write copy the way a calm, knowledgeable colleague would speak — not a system log:5354- **Action labels**: Verb + object. "Save draft", "Send invite", "Export PDF". Never "Submit", "Proceed", "Execute".55- **Status messages**: Past tense for done ("Saved"), present continuous for in-progress ("Saving…"), imperative for next step ("Add a team member").56- **Error messages**: Say what happened in plain language, then what to do. Never show error codes to end users.57- **Empty states**: Tell the user what they'll get here and give them one clear action to start.58- **Tooltips**: Only if the label alone is genuinely ambiguous. Don't use them to explain implementation.59- **Loading states**: Name the outcome, not the process. "Getting your results" beats "Fetching data from API".6061## Flow Review Checklist6263When auditing a flow or screen:64651. **Can the user tell where they are?** (orientation)662. **Can the user tell what to do next?** (wayfinding)673. **Does every piece of text serve the user's goal?** (relevance)684. **Are any internal details leaking into the UI?** (abstraction)695. **What happens on error — does the user know what to do?** (recovery)706. **What is the user feeling at this moment?** (emotional state — anxious, excited, confused, relieved?)717. **Is anything asking for effort the user shouldn't have to give?** (friction)7273## Friction Audit7475Common friction sources to eliminate:76- Asking for information you don't need yet (forms that ask for credit card before showing value)77- Requiring a decision with insufficient context ("Do you want to enable advanced mode?" — what is that?)78- Success screens that don't tell the user what to do next79- Modals that interrupt flow without a clear purpose80- Copy that explains how the system works instead of what it means for the user81- Loading states with no feedback on progress or expected duration82- Confirmation dialogs for low-stakes, reversible actions8384## Onboarding UX8586Good onboarding shows value before asking for commitment:87- Lead with what the user can accomplish, not a feature list88- Delay account creation until the user has experienced something worth returning for89- Use progressive disclosure — reveal complexity only when the user is ready for it90- The first "aha moment" should be reachable in under 60 seconds9192## Applying This Alongside frontend-design9394UX and UI are complementary. The [[frontend-design]] skill handles how things look and feel visually. This skill handles what is shown, what is said, and when. Apply both together:95- `frontend-design` makes it beautiful96- `user-experience` makes it make sense9798When conflicts arise — always side with clarity over aesthetics. A stunning interface that confuses the user has failed.
whyashthakker