Audit a feature, screen, or roadmap for delight (joy + surprise) using Nesrine Changuel's framework — motivators (functional + emotional), opportunities, the delight grid (low / surface / deep), the delight checklist, the 50-40-10 roadmap balance, and the three pillars (remove friction, anticipate needs, exceed expectations). Use for B2C and under-stimulation products. NOT for productivity tools used under cognitive load — use `calm-software-design-review` instead.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
skill_id
delightful-product-review
name
Delightful Product Review
description
Audit a feature, screen, or roadmap for delight (joy + surprise) using Nesrine Changuel's framework — motivators (functional + emotional), opportunities, the delight grid (low / surface / deep), the delight checklist, the 50-40-10 roadmap balance, and the three pillars (remove friction, anticipate needs, exceed expectations). Use for B2C and under-stimulation products. NOT for productivity tools used under cognitive load — use `calm-software-design-review` instead.
Use this skill to audit a feature, screen, flow, or roadmap for delight — defined as joy + surprise produced when a product solves a functional need and honors an emotional need at the same time. The skill operationalizes Nesrine Changuel's framework (4-step Delight Model, Three Pillars, Delight Grid, Delight Checklist, 50-40-10 roadmap rule) and pairs it with Dylan Field's "craft is the moat" thesis and Kole Jain's atomic UI craft moves.
This skill is opinionated and category-specific. Delight is the right lens for entertainment, social, consumer, and crowded-B2B products where emotion differentiates. It is the wrong lens for productivity tools used under cognitive load — those need calm, not surprise. Be honest about that boundary; do not import delight patterns into a calm-software product just because the framework is fun to apply.
When to Use
Audit a B2C product with a low engagement floor (entertainment, social, lifestyle, fitness, learning)
Review a consumer onboarding flow that needs to convert wonder into a habit
Differentiate a B2B SaaS product in a mature, crowded category where emotion is the only remaining moat (Linear vs. Jira, Slack vs. enterprise IM, Revolut vs. legacy banks)
Triage a roadmap against the 50-40-10 ratio when leadership suspects too much "polish" or too little
Diagnose why a feature that "should delight" is landing flat (habituation, inclusion failure, surface-only)
Pre-ship gate a celebration, animation, recap, or magic-moment feature
Build a buy-in case for delight investment with a skeptical leader
Do Not Use
Productivity tools used under cognitive load. BuildOS, Things 3, Linear (in-app), Notion in-work-mode, calendars, dashboards. Use calm-software-design-review instead. Surprise inside a thinking tool reads as noise, not delight.
Accessibility audits. Inclusion appears as a checklist item here, but real WCAG / assistive-tech / cognitive-accessibility work needs a dedicated process. Use accessibility-and-inclusive-ui-review.
Brand strategy or visual identity exploration. Delight is downstream of brand voice. If brand is unsettled, do that first.
Marketing site redesigns. Use marketing-site-design-review for landing pages and product pages.
Productivity-under-stress contexts even if the product is technically B2C. Mental-health journaling, addiction recovery, grief support — the "joy + surprise" frame is the wrong primitive. Use the calm school.
Core Framework — Nesrine Changuel's Delight Model
A 4-step pipeline backed by three operating pillars and a roadmap-balance rule.
4 steps: identify motivators → convert to opportunities → place candidates on the delight grid → validate with the delight checklist.
3 pillars: remove friction at valley moments, anticipate needs the user has not articulated, exceed expectations beyond what was asked.
50-40-10 ratio: 50% pure functionality, 40% deep delight (functional + emotional fused), 10% surface delight (pure emotional).
The goal is deep delight — features that solve a real functional problem and honor an emotional need with the same surface. Surface delight (confetti, recaps) is a small slice. Pure functionality is the floor.
Foundational Principles
Delight = joy + surprise (Plutchik's wheel of emotion). Both halves must be present. Joy without surprise is mere satisfaction; surprise without joy is shock.
Functional motivators + emotional motivators must both be honored. A perfectly functional product that ignores emotion loses to a slightly-less-functional product that does not.
Move from delight vs. functionality to delight in functionality. The framing "should we polish or ship features?" is a false dichotomy. Deep delight collapses it.
Surface delight without underlying value is anti-delight. Confetti for routine actions, animations that delay critical paths, and aesthetics layered on a broken funnel actively erode trust.
Habituation kills delight features that don't keep evolving. First use = wow, fifth use = wallpaper. Plan a continuous-innovation cadence (Google Meet's background sequence: blur → static → video → immersive → AI-generated).
Inclusion considerations come before celebration features. What's joyful for one user is painful for another. The Apple gesture-reactions-during-therapy story and the Deliveroo Mother's Day fake-call notification are the canonical failure modes — both shipped because inclusion was treated as a polish step instead of a gate.
B2H — business-to-human. As long as humans use the product, emotion is load-bearing. The "B2B is exempt from delight" claim only holds in green-field markets; once a competitor honors the emotional need, the older product loses.
Craft is the moat (Dylan Field). AI lowers the floor of "shipping working software." That raises the value of taste and judgment. "Good enough is mediocre" — delight is one expression of craft, not garnish on top of it.
Step 1 — Identify Motivators
Most teams segment by demographic (who they are) or behavioral (what they do). Add a third axis — motivational segmentation (why they use the product).
Functional motivators — what they're trying to do. Examples: book a flight, find a song, capture a thought before losing it, schedule a meeting.
Personal emotional motivators — how they want to feel while using the product. Examples: feel less lonely, feel productive, feel secure, feel nostalgic, feel in control, feel relief, feel proud.
Social emotional motivators — how they want others to see them while using the product. Examples: appear cool, appear competent, appear connected, appear thoughtful. Spotify Wrapped is the textbook example — the share-out is the product.
Demotivator inversion — when emotional motivators are hard to articulate, ask for frustrations instead. Frustrations are easier to verbalize. Invert and you have the emotional design brief. (Google Meet during COVID couldn't get clean emotional motivators; they got three demotivators — bored, low interaction, Zoom fatigue — and inverted them into reactions, self-view minimize, and immersive backgrounds.)
Concrete motivator template:
Surface: <feature or screen name>
Functional motivators (what users do here):
- <verb-noun pair>
- <verb-noun pair>
Personal emotional motivators (how they want to feel):
- <emotion>
- <emotion>
Social emotional motivators (how they want to be seen):
- <perception>
Demotivators (what frustrates them, even if they can't name what they want):
- <frustration> → invert to → <emotional motivator>
Step 2 — Convert Motivators to Opportunities
Translate the motivator list into an opportunity space — not a feature list. The shift that matters: think in terms of honoring needs, not just solving problems. "How might we…" works fine; framework is not load-bearing here. The discipline is staying in opportunity-space long enough to consider non-obvious solutions before locking into a feature.
For each motivator, write at least one opportunity statement.
Cross-reference: does the same opportunity appear under multiple motivators? Those are deep-delight candidates.
Opportunities that only show up under functional motivators → low delight territory.
Opportunities that only show up under emotional motivators → surface delight territory (use sparingly).
Step 3 — The Delight Grid
A 2-axis matrix (functional motivators × emotional motivators). Place every candidate solution on it. Output is three categories.
Type
Solves Functional?
Solves Emotional?
Examples
Low Delight
Yes
No
Faster search, performance fixes, mobile parity, calendar conflict detection
Goal = deep delight. Force-rank candidates here before sprint planning.
Surface delight should be ~10% of roadmap. Rare and intentional. If your roadmap is dominated by surface-delight ideas, the upstream emotional motivator work is incomplete.
Low delight is half the work. The framework does not tell you to skip functional reliability — it tells you not to stop there.
Step 4 — The Delight Checklist (Pre-Ship Validation Gate)
Before shipping any candidate flagged as delight, every box must be checked:
User impact — does it move a user metric we believe in? (Retention, activation, NPS, qualitative recall.)
Business impact — is it tied to a business goal, not a vibe? Delight is not an aesthetic excuse.
Feasibility — can we ship and maintain it? Every delight feature has support cost, performance cost, accessibility cost.
Familiarity — are we surprising too much? Pure novelty fails. Discover Weekly's launch metric dropped when engineers fixed the "bug" that injected familiar tracks; the buggy version was reinstated. Surprise interleaved with familiarity is delight; pure surprise is shock.
Inclusion — what's joyful for one user is painful for another. Audit edge cases hard: bereavement, mental-health context, cultural sensitivity, accessibility, neurodiversity. (See Anti-Delight Failure Modes below.)
Maintainability of surprise — is there a continuous-innovation plan? Surprise decays. Without an iteration cadence, the feature becomes invisible within weeks.
The Three Pillars (Operating Lenses)
Every delightful feature satisfies at least one. Use these during ideation and audit.
Pillar 1 — Remove Friction (Valley Moments)
Identify valley moments — points in the user journey where emotional state is at its lowest (anxious, stressed, frustrated, embarrassed). The pillar is not "make the happy path smoother"; it's "rescue the user from the valley."
Uber refund example. Driver canceled, user grabbed a taxi, ignored the app. Uber auto-assigned a new driver who arrived, waited, charged a no-show. User expected to write an essay to support; instead, the app offered a 2-click refund flow. Valley moment → rescue.
Buffer refund-the-inactive example. Buffer noticed ~2% of paying users hadn't logged in for months. They emailed: "We noticed you're not using our product. Want a refund?" Some took it (revenue lost). Many wrote back saying the integrity made them stay. Trust is delight on a long timescale.
Lenny's distillation: "Just making it easy to do something you expect to be really hard is delightful." Cancellation. Unsubscribe. Refund. Account deletion. These are anti-delight by default; making them frictionless is delight.
Audit move: walk the user journey and mark every surface where the user's emotional state is at the bottom. For each, ask: do we have a rescue, or did we ship a default error/cancel/support page?
Pillar 2 — Anticipate Needs
If you wait for users to tell you what they need, you're only honoring needs — not anticipating. Surprise requires getting there first.
Revolut eSIM example. Heavy international traveler lands in Singapore, French operator charges roaming fees. Revolut's eSIM tab — €7, applied in seconds. Why does a bank app have an eSIM? Because Revolut's users are international/expats; Revolut anticipated the travel context.
Rahul Vohra (Superhuman): "For a product to be loved, you need to set the bar higher than the users themselves."
Audit move: for each surface, ask "what could the product surface here that the user has not asked for, but would recognize as theirs the moment they see it?" Then check: do we have the data signal to do that without being creepy?
Pillar 3 — Exceed Expectations
Once a need is anticipated, over-deliver — give users more than they asked for.
Edge coupon example. Heavy Microsoft user checking out a €120 coffee machine. At payment, Edge surfaced an autofill coupon — 15% off, found and applied automatically. He wasn't asking for a discount.
Google Meet's bar. Meet didn't compare itself to Zoom or Teams — it compared itself to "what if we were all in a room together." Dyson didn't compare its vacuum to other vacuums — it compared to "what if I hired a real cleaner."
Audit move: for each surface, identify the user's stated expectation. Then ask: what's the smallest move that delivers more than the expectation, without becoming busywork?
The 50-40-10 Roadmap Rule
Audit the roadmap (quarterly or per-release) against this ratio:
List every feature/work-item in the next planning cycle.
Tag each as low / surface / deep delight using the grid.
Sum the engineering-effort estimates per category.
Compare against 50/40/10. Flag deviations.
Common diagnoses:
Over 60% functionality — team is in foundation-fix mode (often correct for early-stage; framework target is for steady-state).
Under 30% deep delight — root cause of "we're a tool, not a product people love."
Over 15% surface delight — playing aesthetic games while functional gaps lose users.
Zero surface delight — risk of habituation; users have no shareable moments.
Caveats: the 50-40-10 ratio is guidance, not data-derived. For early-stage products with broken fundamentals, 70-25-5 (or higher functionality) is often correct. The ratio is a planning gut-check, not a sacred number.
Concrete Delight Pattern Catalog
Named patterns you can apply or audit against:
Personalized year-end recap — Spotify Wrapped, GitHub Wrapped, Apple Music Replay. High social-emotional motivator (shareable). Run yearly. Deep failure mode: stale or shallow.
Tasteful celebration on milestone — Airbnb Superhost confetti, only when the underlying moment matters. Confetti for routine actions is noise; confetti for genuine status change is delight.
Magic-moment redesign — Google Meet self-view minimize. The friction was hidden in something users assumed was fixed. Redesigning the obvious-but-overlooked is deep delight.
Pre-context anticipation — Revolut eSIM on travel. Calendar-aware briefings. Location-aware utility. Requires honest data signal; creepy if the signal is invisible to the user.
Auto-completion / coupon discovery — Edge coupon at checkout. Browser-level price-tracking. Anything that does background work the user did not ask for but immediately recognizes.
Demotivator-inversion onboarding — post-COVID Meet positioning around "less Zoom fatigue, more interaction." Lead with what users hate about the category, not features.
Easter egg + craft moment — Cursor's light theme detail, Linear's command palette aesthetic, Figma's cursor-chat. Visible to power users, invisible to first-timers, signals taste without breaking flow.
Recognition without gamification — Airbnb Superhost as the model. Status that recognizes effort. Avoid Duolingo streaks (status that punishes drop-off) in any context where lapses correlate with stress, illness, or burnout.
Proud-users moment — surfaces that make the user think "I want to show this to a peer." The musician/curator startup pivoted its entire strategy around this question (see Buy-In Tactic).
Anti-Delight Failure Modes
The ways "delight" features actively destroy trust. Reject any candidate that pattern-matches one of these:
Mother's Day fake-call notification (Deliveroo France). Push notification designed to look exactly like a missed call from "Mom." Joyful for users with living mothers; gut-punch for users who'd lost theirs. Worst press of any feature in France that year. Inclusion failure.
Therapy-session fireworks (Apple gesture reactions). OS-level gesture detection triggered animations during a video therapy call when the user gestured to show his hurt finger to his therapist. "What an appropriate time for fireworks." Context-blind delight.
Confetti for routine actions — celebrating "you saved a draft" or "you logged in 3 days in a row" as if it's an Olympic medal. The underlying moment carries no weight. The animation reads as condescension.
Gamification that punishes lapses — streak loss, shaming dashboards, daily-login pressure. Devastating to ADHD, burnout, depression, post-illness, or grief users. Productivity tools are especially exposed here.
Over-organization that defeats the calm tool's purpose — adding "delightful" structure (categories, tags, taxonomies) to a tool whose value was being unstructured. Common failure mode for note-taking and brain-dump products.
Surface delight as substitute for functional reliability — animations on a feature that crashes, tone of voice on a 503 page, polish on a broken funnel. Delight cannot fix broken; it amplifies the gap.
Default-on celebrations in unknown contexts — anything that fires automatically without an opt-in toggle. Inclusion risk is too high; one bad press cycle erases the gain for everyone else.
Buy-In Tactic for Skeptical Leaders (Changuel's Reframing)
When pitching delight investment to a leader who pushes back with "we have features to ship":
Don't try to convince. Trying to convince frames you as a threat to existing priorities. "It's a lost battle."
Distinguish perception from perspective.Perception = how you see delight (a strategy). Perspective = how they see delight (a luxury, a cherry on top). Don't argue your perception; adopt their perspective and link delight to their goals.
Ask the proud-users question — "Do you think your users are proud to use this product? Proud enough to recommend it to their most discerning peer?" Routes to the same destination without using the word "delight." If the answer is no, the conversation is now about word-of-mouth and retention — both languages skeptical leaders speak.
Reframe in their goals' language. If the leader cares about retention, frame delight as habituation prevention. If they care about CAC, frame it as referral leverage. If they care about competitive positioning, frame it as the moat.
The musician/curator startup case — founder rejected delight in favor of strategy/OKRs. Nesrine asked the proud-users question. He returned two weeks later saying the entire strategy needed to pivot to making users feel proud — because that was what would unlock word of mouth.
Output Format
When reviewing, return findings grouped by:
Motivator coverage — which functional and emotional motivators are honored, which are gaps?
Delight grid placement — every flagged feature, placed on the grid, with low/surface/deep verdict.
Delight checklist results — per feature, list of which checklist items pass or fail.
50-40-10 audit — current ratio across the roadmap or release; deviations called out.
Three Pillars audit — for each surface, which pillar (or none) does it serve; valley moments and rescue assessment.
Anti-delight risks — specific surfaces flagged for inclusion, context-blindness, or habituation, with mitigations.
Recommended buy-in framing — if the audit will be presented to a skeptical leader, surface the leader's goal language.
For each issue, give:
what's wrong
why it matters
specific fix (named pattern from the catalog where possible)
severity: high / medium / low
Guardrails
Do not recommend confetti for routine actions. Celebration requires an underlying moment with weight.
Do not gamify productivity tools — no streaks, badges, daily-login shaming, or leaderboards on tools used under cognitive load.
Do not assume one user's delight is universal. Inclusion is a gate, not a checklist line. If you cannot defend the feature against the Deliveroo / Apple-fireworks examples, kill it.
Do not over-index on surface delight. Cap at ~10% of the roadmap. If your delight ideas are mostly animations and recaps, the upstream motivator work is incomplete.
Do not skip the maintainability-of-surprise step. A delight feature without an iteration plan becomes wallpaper within weeks.
Do not apply this skill to productivity-under-stress tools. Use calm-software-design-review for thinking environments, brain-dump tools, focus tools, calendars, dashboards, and anything used under cognitive load.
Do not confuse delight with reliability. A delightful animation does not fix a broken funnel. Functional reliability is the floor, not a competing investment.
Do not let "delight" become an excuse to avoid hard tradeoffs. If everything is delight, prioritization gets harder. Sometimes the most delightful move is removing a feature.
Comparison: Delight School vs. Calm School
Both are valid — applied to different categories. Be honest about which one your product belongs to.
Dimension
Delight School (Changuel, Spotify, Lovable, Airbnb, Revolut)
Calm School (Saarinen, Jainek, Fried, Maeda, Things 3, Linear)
Core primitive
Joy + surprise
Reduction of stimulation
Emotional motivator
Excite, recognize, surprise
Soothe, hold, get out of the way
Surface delight
~10% of roadmap, intentional
Near-zero; ornament reads as noise
Habituation strategy
Iterate to refresh surprise
Iterate to remove friction; habituation is the feature
Reads as overstimulating, condescending, or shame-inducing
Test
"Are users proud to share this?"
"Does this help the user think clearly when they're already overwhelmed?"
Anchor question
"What would a human-to-human version of this feel like?"
"What would the calmest possible version of this feel like?"
BuildOS positioning
Wrong school
Right school
The schools are not enemies. Spotify needs delight; Linear needs calm. Airbnb needs delight; a grief journaling app needs calm. The mistake is applying the wrong primitive to your category — not picking the wrong school.
Honest BuildOS note: BuildOS sits in the calm school. Users come to BuildOS in cognitive overload; surprise reads as noise. This skill is more useful for recognizing when a delight pattern is being misapplied to BuildOS than for applying delight to BuildOS. The genuinely useful exports from this framework for calm-school products are: the demotivator-inversion technique, the inclusion checklist, the valley-moments audit (Pillar 1), and the proud-users question. Leave the rest in the delight school.
Source Attribution
Distilled from:
Nesrine Changuel — primary source.A 4-step framework for building delightful products on Lenny's Podcast. Author of Product Delight. Ex-Google "Delight PM" (Chrome, Meet), Spotify, Skype. Source for the Delight Model, Three Pillars, Delight Grid, Delight Checklist, 50-40-10 rule, demotivator inversion, anti-delight failure modes, and buy-in tactic. Local analysis: docs/marketing/growth/research/youtube-transcripts/2026-04-28-nesrine-changuel-4-step-delightful-products-framework-ANALYSIS.md.
Dylan Field (Figma CEO) — supporting source.On Design, Craft & Quality as the New Moat on Lenny's Podcast. Source for "good enough is mediocre," craft as the AI-era differentiator, time-to-value discipline, and the blockers-team pattern. Local analysis: docs/marketing/growth/research/youtube-transcripts/2026-04-28-dylan-field-figma-ceo-design-craft-moat-ANALYSIS.md.
Kole Jain — supporting source.7 UI/UX mistakes that scream you're a beginner. Source for atomic UI craft moves (interactive feedback as a delight surface, save → badge dot pattern, click states as the bare minimum of "the system heard you"). Local analysis: docs/marketing/growth/research/youtube-transcripts/2025-06-07-kole-jain-7-ui-ux-mistakes-beginner-ANALYSIS.md.
Cross-Linked Skills
calm-software-design-review — the opposite school. Use for productivity-under-load tools. BuildOS-relevant.
ui-ux-quality-review — atomic UI quality and the optional Delight Layer. Lower-level than this skill.
marketing-site-design-review — public-facing pages. Different surface, different rules.
accessibility-and-inclusive-ui-review — when inclusion needs structural review beyond the checklist line item.
