From ux-superpowers
Use when the user asks how to measure product or feature success, define success metrics, pick a north star metric, track KPIs, design analytics events, build an instrumentation plan, decide what telemetry to fire, or figure out "how will we know if this is working for users" — trigger whenever users say things like "how will we measure success", "what KPIs should we track", "design the analytics events for X", "we need a telemetry plan", "what events should we fire", "metrics for the launch of X", or "how do we validate this worked". Always invoke when defining leading indicators, guard-rail health metrics, activation/retention, qualitative feedback plans (NPS, CSAT, in-app surveys), or a decision framework tying metrics to actions; this skill produces an implementable user-outcome measurement plan with event specs, properties, baselines, targets, and response plans. This is strictly for USER-OUTCOME and product analytics — measuring whether users are succeeding with the product. Do NOT trigger for engineering or operational observability such as p95 latency, error-rate dashboards, SLO/SLI definition for infra, APM, log aggregation, Datadog/Prometheus setup, database query tuning, performance optimization, generic "add logging" requests, or bug triage — those are SRE/observability concerns, not product telemetry. Skip when ux-discover is already orchestrating. When a request mixes product metrics and ops metrics, trigger on the product-metric portion only.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ux-superpowers:telemetry-designerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
If you can't measure it, you can't know if you helped the user.
If you can't measure it, you can't know if you helped the user.
Using all prior discovery artifacts, ask:
"If this project is wildly successful 6 months from now, how would you KNOW? What would be different for users?"
Then ask:
"What's the ONE metric that, if it moved in the right direction, would prove this was worth building?"
This becomes the North Star Metric.
Build a layered metric structure:
## Success Metrics
### North Star Metric
- **Metric**: [what you're measuring]
- **Current baseline**: [today's value, or "unknown — need to establish"]
- **Target**: [6-month goal]
- **Why this metric**: [how it connects to user success]
### Health Metrics (guard rails)
| Metric | Purpose | Target | Alert Threshold |
|--------|---------|--------|-----------------|
| [metric] | [what it guards against] | [target] | [when to worry] |
### Input Metrics (leading indicators)
| Metric | Predicts | Measurement Method |
|--------|----------|-------------------|
| [metric] | [what outcome it predicts] | [how to measure] |
For each key moment in the user journey, define what to track:
## Telemetry Plan
### Event: [event_name]
- **Trigger**: When [user action or system event]
- **Properties**:
- [property_name]: [type] — [why we need this]
- **Purpose**: Answers the question: [what question does this data answer?]
- **Privacy**: [PII: yes/no] [Consent required: yes/no]
Not everything is quantitative. Define qualitative feedback channels:
## Qualitative Feedback Plan
| Signal Type | Collection Method | Frequency | Owner |
|-------------|-------------------|-----------|-------|
| User satisfaction | [NPS, CSAT, in-app survey, etc.] | [cadence] | [who reviews] |
| Feature feedback | [feedback widget, support tickets, etc.] | [ongoing] | [who reviews] |
| Usability issues | [session replay, user testing, etc.] | [cadence] | [who reviews] |
For each key metric, define what actions you'd take:
## Metric Response Plan
| Metric | If improving | If flat | If declining |
|--------|-------------|---------|-------------|
| [metric] | [action: scale, invest more] | [action: investigate, iterate] | [action: pivot, diagnose] |
Produce a Telemetry & Metrics section for the UX Discovery Document containing:
npx claudepluginhub adnanmir123/ux-superpowers --plugin ux-superpowersProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.