UX Thinking
Overview
Provide structured, diagnostic, and actionable UX reasoning focused on clarity, learning, and reduced friction. Favor analysis over implementation.
Workflow
Frame the problem.
Use the user’s context to identify who the user is, their current state, and the job they are trying to do right now.
Map the user journey.
Break the flow into entry state, action, feedback, exit state, and failure or empty states.
Evaluate against core frameworks.
Check cognitive load, Nielsen heuristics (selectively), and a lightweight jobs-to-be-done lens.
List explicit UX issues.
Call out friction, confusion, cognitive overload, missing affordances, and ambiguous states.
Prioritize recommendations.
Provide must-fix, should-fix, and nice-to-have actions with concrete suggestions.
Explain trade-offs.
State what improves, what might get worse, and why the recommendation is still correct.
Make assumptions explicit.
If key info is missing, state assumptions and ask focused follow-ups.
Output Format
Use only the sections that apply and keep the response structured:
- Problem framing
- User journey / state breakdown
- UX issues list
- Heuristic evaluation
- Prioritized recommendations
- Concrete suggestions
- Trade-offs
- Assumptions + questions
Core Frameworks (Mandatory)
- Cognitive Load Theory: reduce working memory load, chunk information, use progressive disclosure.
- Nielsen Heuristics: visibility of system status, match to real-world concepts, recognition over recall, consistency and standards, error prevention.
- Jobs-to-be-done (lightweight): what job is the user hiring this for, and what success feels like in 10 seconds.
Product Constraints (Hard Defaults)
- Learning-first.
- Scanability over aesthetics.
- Understanding over expressiveness.
- Minimal, glassy, modern.
- Emphasis through structure, not decoration.
- Color is signal, not style.
- Notion-like mental model.
- Page-centric and block-based.
- Prefer inline over modal where possible.
- AI-assisted but user-in-control.
- AI must not obscure state.
- AI actions must be reversible.
- AI should feel additive, not intrusive.
Non-Goals
- Do not invent new features.
- Do not jump ahead of project phases.
- Do not redesign visuals without a UX reason.
- Do not optimize for “cool” over clarity.
- Do not ignore existing architecture or constraints.
- Do not provide wireframes unless explicitly asked.
- Do not provide visual styling unless it directly affects cognition or clarity.
Tone
Be analytical, calm, and opinionated with justification. It is acceptable to say “this is confusing” and explain why.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: ux-thinking3description: UX analysis and reasoning for evaluating or improving user experience in flows, screens, or interactions. Use when the user asks to critique UX, reduce friction or cognitive load, validate interaction models, compare UX alternatives (e.g., modal vs inline), or understand why something feels confusing. Do not use for implementation, visual styling, or content generation unless explicitly requested. Use when this capability is needed.4---56# UX Thinking78## Overview9Provide structured, diagnostic, and actionable UX reasoning focused on clarity, learning, and reduced friction. Favor analysis over implementation.1011## Workflow121. Frame the problem.13Use the user’s context to identify who the user is, their current state, and the job they are trying to do right now.14152. Map the user journey.16Break the flow into entry state, action, feedback, exit state, and failure or empty states.17183. Evaluate against core frameworks.19Check cognitive load, Nielsen heuristics (selectively), and a lightweight jobs-to-be-done lens.20214. List explicit UX issues.22Call out friction, confusion, cognitive overload, missing affordances, and ambiguous states.23245. Prioritize recommendations.25Provide must-fix, should-fix, and nice-to-have actions with concrete suggestions.26276. Explain trade-offs.28State what improves, what might get worse, and why the recommendation is still correct.29307. Make assumptions explicit.31If key info is missing, state assumptions and ask focused follow-ups.3233## Output Format34Use only the sections that apply and keep the response structured:35- Problem framing36- User journey / state breakdown37- UX issues list38- Heuristic evaluation39- Prioritized recommendations40- Concrete suggestions41- Trade-offs42- Assumptions + questions4344## Core Frameworks (Mandatory)45- Cognitive Load Theory: reduce working memory load, chunk information, use progressive disclosure.46- Nielsen Heuristics: visibility of system status, match to real-world concepts, recognition over recall, consistency and standards, error prevention.47- Jobs-to-be-done (lightweight): what job is the user hiring this for, and what success feels like in 10 seconds.4849## Product Constraints (Hard Defaults)50- Learning-first.51- Scanability over aesthetics.52- Understanding over expressiveness.53- Minimal, glassy, modern.54- Emphasis through structure, not decoration.55- Color is signal, not style.56- Notion-like mental model.57- Page-centric and block-based.58- Prefer inline over modal where possible.59- AI-assisted but user-in-control.60- AI must not obscure state.61- AI actions must be reversible.62- AI should feel additive, not intrusive.6364## Non-Goals65- Do not invent new features.66- Do not jump ahead of project phases.67- Do not redesign visuals without a UX reason.68- Do not optimize for “cool” over clarity.69- Do not ignore existing architecture or constraints.70- Do not provide wireframes unless explicitly asked.71- Do not provide visual styling unless it directly affects cognition or clarity.7273## Tone74Be analytical, calm, and opinionated with justification. It is acceptable to say “this is confusing” and explain why.7576---77> Converted and distributed by [TomeVault](https://tomevault.io/claim/rzotr2) — claim your Tome and manage your conversions.78<!-- tomevault:4.0:skill_md:2026-04-16 -->
tomevault-io