ux-intuition
UX Intuition
Know what feels right in a product before the data tells you.
How to use
/ux-intuitionApply UX intuition constraints to this conversation./ux-intuition <product or flow>Evaluate the user experience of the described product or flow.
Constraints
The Feel Test
- MUST use the product as a real user would before evaluating it — not as someone who built it
- SHOULD ask: does this feel fast? Does it feel predictable? Does it feel respectful of my time?
- MUST notice moments of confusion, hesitation, or friction — these are signals even when small
- NEVER dismiss "it feels off" without investigating. Intuition often catches what metrics miss.
- SHOULD test on real devices and real network conditions, not just dev machines
Interaction Judgment
- Every interaction MUST have clear feedback — the user should always know what happened
- MUST evaluate: can a user figure out what to do without instructions?
- SHOULD check state transitions: loading, empty, error, success. Each one is a user experience.
- NEVER accept "it works" as sufficient. Working and feeling good are different things.
- MUST consider edge cases the happy path ignores: first-time users, power users, error recovery
Simplicity Standard
- MUST ask: can anything be removed without losing value?
- SHOULD count the number of decisions the user has to make. Fewer is almost always better.
- MUST ensure the primary action on every screen is obvious
- NEVER add a feature without asking how it affects the experience of existing features
- Complexity should be progressive — simple by default, powerful when needed
Taste vs. Data
- MUST distinguish between personal taste and product judgment
- When intuition and data conflict, investigate — don't automatically defer to either
- SHOULD build conviction through exposure: use lots of products, notice what works
- MUST be able to articulate WHY something feels off, not just that it does
- NEVER override design decisions based on personal preference alone
Anti-Patterns
- Metric-Only Evaluation: if the numbers are fine, the experience must be fine (wrong)
- Feature Blindness: so familiar with the product that you can't see confusion points
- Taste Tyranny: overriding design because you personally don't like the font
- Happy Path Only: evaluating the best case and ignoring error states and edge cases
- Pixel Perfectionism: obsessing over visual polish while core interactions are confusing
More from dragoon0x/product-skills
prd-writing
Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.
1freemium-vs-paid-gate
Decide whether a product should offer a free tier, free trial, or go straight to paid. Structured decision framework based on economics, distribution model, and competitive landscape. Use when launching a new product or reconsidering your pricing model.
1error-recovery
When things break, guide people forward instead of leaving them stranded. Error message copy, retry patterns, graceful degradation, and recovery flows. Use when building error handling or failed state UIs.
1cta-patterns
Design calls-to-action that people actually click. Covers button copy, placement logic, urgency without manipulation, and progressive commitment. Use when reviewing pages for conversion potential or when CTA copy feels generic.
1onboarding-flow
Design first-run experiences that create the aha moment fast. Reduces time-to-value by sequencing actions, progressive disclosure, and contextual guidance. Use when building signup flows, product tours, or empty states.
1user-psychology
Apply motivation, friction, and trust patterns to product decisions. Maps cognitive biases and behavioral triggers to specific UI and copy choices. Use when reviewing flows for drop-off points or when something feels right but doesn't convert.
1