Growth UX Audit
This is a read-only skill. The output is a short, evidence-backed audit, not code or a backlog dump.
- MUST NOT edit source, create files, change analytics, or write to external platforms.
- MUST observe and understand the current flow before suggesting changes.
- MUST tie every recommendation to a revenue mechanism and an observed moment in the flow.
- MUST prefer the least interruptive change likely to work.
- MUST preserve the user's primary task, existing mental model, and established visual language.
- MUST NOT recommend dark patterns, fake urgency, hidden costs, confirmshaming, forced continuity, blocked dismissal, or repeated nagging.
- MUST distinguish observed evidence from hypotheses. Never invent conversion data, user intent, or revenue impact.
- MUST keep the final audit short. Return the top three to five opportunities, not every plausible idea.
1. Establish the business context
Determine from the repository, product, analytics, pricing, plans, and existing documentation:
- Revenue model and paid value
- Target user and lifecycle stage
- Flow being audited
- Current growth goal and primary metric
- Existing experiments, prompts, limits, and upgrade surfaces
Gather accessible context directly. Ask one focused question only when the revenue model or target flow cannot be inferred safely.
2. Experience the current flow
When the product is runnable, use the browser and complete the flow as the target user. Inspect the relevant code when it explains state, eligibility, frequency, or event tracking that the interface cannot show.
Record only what affects the audit:
- User goal
- First value moment
- Monetization moment
- Existing friction and interruptions
- Exit, recovery, and repeat-use behavior
Do not judge an isolated screen when the surrounding journey changes its meaning.
3. Find revenue opportunities
Look across five mechanisms:
| Mechanism |
Question |
| Activation |
Can users reach meaningful value sooner? |
| Conversion |
Is paid value clear when purchase intent is present? |
| Expansion |
Does usage reveal a natural reason to upgrade, add seats, or adopt more? |
| Retention |
Does the flow reinforce achieved value and make return behavior easier? |
| Referral |
Is sharing or collaboration useful enough to create organic acquisition? |
Ignore ideas with no credible path to revenue, even if they might move clicks.
4. Use the interruption ladder
Consider changes in this order and stop at the lowest sufficient level:
- No new UI: remove friction, improve defaults, fix eligibility, or clarify existing copy
- Existing surface: adjust hierarchy, timing, placement, or value framing
- Inline addition: add contextual proof, limit visibility, or a quiet upgrade path
- Persistent addition: add a restrained status, usage, or plan affordance
- Interruption: modal, gate, takeover, or notification
A level-five recommendation requires strong evidence of user intent, low frequency, easy dismissal, and a clear user benefit. Reject it otherwise.
5. Apply the taste and trust gate
A recommendation passes only when all answers are yes:
- Does it help the user understand or reach value?
- Does it appear at a moment related to the user's current intent?
- Can it fit the existing component, copy, and interaction system?
- Does it preserve one clear primary action?
- Is it accessible, reversible, and honest?
- Will repeated exposure remain tolerable for frequent users?
- Can success be measured without sacrificing a trust or usability guardrail?
Read emil-design-foundations before finalizing a recommendation that changes visual hierarchy or interaction. Use emil-ui-review only when the user also asks for a code-level craft review.
6. Rank without fake precision
Rank opportunities by:
- Revenue potential
- Confidence in the evidence
- Design and flow fit
- Interruption cost
- Implementation effort
Use High, Medium, or Low. Do not manufacture a numeric score when the inputs are estimates.
Verdict
One sentence on the strongest revenue opportunity and the health of the current flow.
Current flow
Three to six short steps showing where value and monetization occur.
Opportunities
Return at most five rows:
| Priority |
Moment |
Smallest change |
Revenue mechanism |
Interruption |
Evidence |
Evidence MUST cite an observed route, state, event, or file:line. Label unsupported claims as hypotheses.
Test first
For the top recommendation only:
- Hypothesis
- Smallest viable experiment
- Primary revenue metric
- One usability or trust guardrail
Avoid
List up to three tempting ideas that would add interruption, conflict with the current flow, or optimize a vanity metric. Omit this section when there is nothing worth warning against.
1---2name: growth-ux-audit3description: Audit product UI and UX flows for revenue opportunities without disrupting the existing experience. Use when reviewing onboarding, activation, conversion, pricing, checkout, upgrade, expansion, retention, referral, or monetization flows; when asked how a product can increase conversion, revenue, ARPU, retention, or paid adoption with tasteful changes. Read-only: observes the current flow, ranks low-interruption experiments, and protects usability and trust. Triggers on: growth audit, growth engineering, conversion audit, monetization audit, revenue opportunities, improve conversion, increase upgrades, product-led growth, activation, retention, expansion, paywall, upgrade prompt.4---56# Growth UX Audit78<overview>9Audit the product as a growth engineer with design taste. Find the smallest changes that can improve revenue while preserving the product's current interaction model, visual language, and user trust.1011This is a read-only skill. The output is a short, evidence-backed audit, not code or a backlog dump.12</overview>1314<rules>1516- MUST NOT edit source, create files, change analytics, or write to external platforms.17- MUST observe and understand the current flow before suggesting changes.18- MUST tie every recommendation to a revenue mechanism and an observed moment in the flow.19- MUST prefer the least interruptive change likely to work.20- MUST preserve the user's primary task, existing mental model, and established visual language.21- MUST NOT recommend dark patterns, fake urgency, hidden costs, confirmshaming, forced continuity, blocked dismissal, or repeated nagging.22- MUST distinguish observed evidence from hypotheses. Never invent conversion data, user intent, or revenue impact.23- MUST keep the final audit short. Return the top three to five opportunities, not every plausible idea.2425</rules>2627<workflow>2829## 1. Establish the business context3031Determine from the repository, product, analytics, pricing, plans, and existing documentation:3233- Revenue model and paid value34- Target user and lifecycle stage35- Flow being audited36- Current growth goal and primary metric37- Existing experiments, prompts, limits, and upgrade surfaces3839Gather accessible context directly. Ask one focused question only when the revenue model or target flow cannot be inferred safely.4041## 2. Experience the current flow4243When the product is runnable, use the browser and complete the flow as the target user. Inspect the relevant code when it explains state, eligibility, frequency, or event tracking that the interface cannot show.4445Record only what affects the audit:46471. User goal482. First value moment493. Monetization moment504. Existing friction and interruptions515. Exit, recovery, and repeat-use behavior5253Do not judge an isolated screen when the surrounding journey changes its meaning.5455## 3. Find revenue opportunities5657Look across five mechanisms:5859| Mechanism | Question |60| --- | --- |61| Activation | Can users reach meaningful value sooner? |62| Conversion | Is paid value clear when purchase intent is present? |63| Expansion | Does usage reveal a natural reason to upgrade, add seats, or adopt more? |64| Retention | Does the flow reinforce achieved value and make return behavior easier? |65| Referral | Is sharing or collaboration useful enough to create organic acquisition? |6667Ignore ideas with no credible path to revenue, even if they might move clicks.6869## 4. Use the interruption ladder7071Consider changes in this order and stop at the lowest sufficient level:72731. No new UI: remove friction, improve defaults, fix eligibility, or clarify existing copy742. Existing surface: adjust hierarchy, timing, placement, or value framing753. Inline addition: add contextual proof, limit visibility, or a quiet upgrade path764. Persistent addition: add a restrained status, usage, or plan affordance775. Interruption: modal, gate, takeover, or notification7879A level-five recommendation requires strong evidence of user intent, low frequency, easy dismissal, and a clear user benefit. Reject it otherwise.8081## 5. Apply the taste and trust gate8283A recommendation passes only when all answers are yes:8485- Does it help the user understand or reach value?86- Does it appear at a moment related to the user's current intent?87- Can it fit the existing component, copy, and interaction system?88- Does it preserve one clear primary action?89- Is it accessible, reversible, and honest?90- Will repeated exposure remain tolerable for frequent users?91- Can success be measured without sacrificing a trust or usability guardrail?9293Read `emil-design-foundations` before finalizing a recommendation that changes visual hierarchy or interaction. Use `emil-ui-review` only when the user also asks for a code-level craft review.9495## 6. Rank without fake precision9697Rank opportunities by:98991. Revenue potential1002. Confidence in the evidence1013. Design and flow fit1024. Interruption cost1035. Implementation effort104105Use High, Medium, or Low. Do not manufacture a numeric score when the inputs are estimates.106107</workflow>108109<format>110111## Verdict112113One sentence on the strongest revenue opportunity and the health of the current flow.114115## Current flow116117Three to six short steps showing where value and monetization occur.118119## Opportunities120121Return at most five rows:122123| Priority | Moment | Smallest change | Revenue mechanism | Interruption | Evidence |124| --- | --- | --- | --- | --- | --- |125126Evidence MUST cite an observed route, state, event, or `file:line`. Label unsupported claims as hypotheses.127128## Test first129130For the top recommendation only:131132- Hypothesis133- Smallest viable experiment134- Primary revenue metric135- One usability or trust guardrail136137## Avoid138139List up to three tempting ideas that would add interruption, conflict with the current flow, or optimize a vanity metric. Omit this section when there is nothing worth warning against.140141</format>
jal-co