principle-experience-first
cursor/plugins
Prioritize user delight over implementation convenience—ship fewer polished features instead of many rough ones.
What is principle-experience-first?
A design principle for product and UX decisions: when tradeoffs arise, choose what delights users over what's easiest to build. Apply this when scoping features, designing interactions, or deciding what to ship. It emphasizes quality over quantity and treating all users—end users, colleagues using your API, and future maintainers—with equal care.
- Guides feature-scope decisions by prioritizing user experience over implementation speed
- Encourages prototyping design decisions in low-cost formats before committing to production code
- Focuses on polishing core workflows and removing features that don't serve them
- Ensures details like transitions, spacing, alignment, and error states receive proper attention
- Extends the definition of 'user' to include API consumers and future code maintainers
How to install principle-experience-first
npx skills add https://github.com/cursor/plugins --skill principle-experience-firstHow to use principle-experience-first
- 1.When facing a product or UX tradeoff, ask: does this serve user delight or just implementation convenience?
- 2.Prototype design decisions in throwaway formats (HTML, sketches) before committing to production code
- 3.Evaluate each feature, control, and option—remove those that don't justify their existence
- 4.Focus on polishing the core workflow and details (transitions, spacing, feedback, error states) rather than adding more rough features
- 5.Extend 'user' to include API consumers and future maintainers; weigh their experience equally and explain impact from their perspective
Use cases
- Deciding whether to ship ten rough features or three polished ones in a product release
- Evaluating whether a new control or option is justified or adds unnecessary complexity
- Choosing between a quick implementation and a design that feels right to end users
- Prioritizing which edge cases and error states deserve careful handling
- Determining the sequence of work to tighten the core user loop first
- Product managers and designers making feature-scope decisions
- Engineers building user-facing products or libraries
- Teams balancing velocity with quality
- Anyone making tradeoffs between implementation convenience and user experience
principle-experience-first FAQ
A feature is justified if it serves the central workflow or meaningfully improves the core experience. If it adds complexity without clear user benefit, it should be removed or redesigned.
Yes, when the alternative is shipping many rough features. The principle favors depth and polish over breadth. Three delightful features beat ten that feel incomplete.
Treat the engineer using your API or library as a user with equal weight. Consider their experience when designing the interface, documentation, and error messages.
Prototype design decisions—the choices that shape user experience—in cheap formats like throwaway HTML or sketches. This is faster and cheaper than iterating in production code.
This principle governs the *target* (what you ship), not the *sequence* (how fast you get there). Foundational thinking determines order; experience-first determines quality. You can ship quickly *and* polish well by scoping ruthlessly.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: principle-experience-first description: "Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones." disable-model-invocation: true
Experience First
When implementation convenience conflicts with user delight, choose delight.
- Every feature, control, and option must be justified
- Ship less, ship better (polished experience with three features beats rough one with ten)
- Prototype before committing (design decisions are cheaper in throwaway HTML than production code)
- Get the details right (transitions, alignment, spacing, feedback, error states)
- Tighten the core loop (every feature should serve the central workflow or get out of the way)
The user is whoever consumes the work. For a UI that is the end user. For a library or an internal API it is the colleague who imports it. The engineer who maintains the code next is a user too. Weigh their experience the same way, and explain impact from their perspective.
Foundations should serve the experience. Foundational thinking governs the sequence of work. This principle governs the target.
Related skills
More from cursor/plugins and the wider catalog.
principle-fix-root-causes
Trace bugs to root causes instead of patching symptoms during debugging.
principle-foundational-thinking
Design data structures and core types before writing logic to make downstream code obvious.
principle-guard-the-context-window
Manage finite context by routing bulk data to subagents and keeping summaries in the main thread.
principle-laziness-protocol
Bias toward deletion and minimal changes—apply when refactoring, evaluating diffs, or tempted by abstractions.
principle-make-operations-idempotent
Design operations to converge to correct state regardless of crashes, restarts, or retries.
principle-migrate-callers-then-delete-legacy-apis
Migrate callers and delete legacy APIs in one refactor wave instead of maintaining compatibility layers.