UX/UI/CX Market Intelligence

Purpose

Use this skill to turn credible market and experience evidence into a small, prioritized, testable improvement backlog. Treat UX as task and decision quality, UI as the visible interaction layer, and CX as the end-to-end relationship across discovery, evaluation, conversion, onboarding, use, support, renewal, and advocacy.

Always distinguish an observation, an interpretation, a recommendation, and a verified outcome. Market research can identify patterns and hypotheses; it cannot prove that copying a competitor will improve the target product.

Non-Negotiable Controls

Do not publish, deploy, alter production code, change pricing, send outreach, collect user data, submit forms, or make external commitments through this skill without a separate explicit approval.

Do not infer user intent or satisfaction from weak proxy data alone. Do not fabricate market size, conversion, accessibility conformance, customer sentiment, benchmark, or competitor capability claims. Attribute every external factual claim to a dated source URL, and label inaccessible, third-party, or anecdotal evidence accordingly.

Collect only data necessary for the question. Do not place credentials, personal data, raw session recordings, support transcripts, private analytics exports, customer lists, or internal operational details in public files. Keep research evidence and proposed changes in a private, version-controlled location.

For an ARM property with the knowledge registry, use permanent registry IDs for durable records. Link the research brief or recommendation to its evidence IDs. Do not turn public pages, search snippets, or AI-discovery files into the source of truth.

Begin Every Engagement

1. Define the property, audience, journey segment, target task, business outcome, constraints, and decision owner. Ask only for missing information that changes the research plan.
2. Establish a baseline before recommending a redesign. Capture the current path, visible friction, key task steps, accessibility risks, content clarity, performance signals available to the team, and existing success measures.
3. Choose evidence sources using the hierarchy in references/evidence-and-metrics.md. Read that reference before collecting market data or calculating a priority score.
4. Write the question as a falsifiable hypothesis. Example: “Clarifying the first-page value proposition may increase qualified next-step completion for first-time visitors,” not “The landing page needs a modern design.”
5. State data gaps, confidence limits, and whether a recommendation needs validation with real target users before implementation.

Research Cycle

1. Baseline the Current Experience

Map the user journey as an ordered path: entry point, user goal, action, interface response, decision required, probable friction, recovery route, and measurement signal. Inspect desktop and narrow-screen behavior when relevant. Include keyboard, focus, contrast, semantics, labels, motion, error handling, and content comprehension in the audit.

Record observations as reproducible facts: page URL or route, timestamp, viewport or device context, task attempted, observed behavior, and supporting source. Avoid aesthetic verdicts without a user, task, accessibility, or business rationale.

2. Gather Market and Customer Evidence

Use three to six relevant comparators. Select them by audience, job-to-be-done, journey stage, market model, maturity, or interaction pattern—not solely by brand prestige. Examine the comparable task rather than broadly copying page layouts.

Use public sources lawfully and transparently. Prefer official product pages, release notes, documented help journeys, public pricing, public app listings, reputable research, accessibility standards, and direct observations. Use owned analytics, search queries, support themes, and user research only when they are provided or the team has authorized access. Strip personal data from findings.

For every source, capture: the question it informs, source URL or internal locator, access date, evidence tier, relevant observation, limitation, and confidence. Separate a competitor’s visible behavior from assumptions about its performance or strategy.

3. Synthesize Opportunities

Group evidence by journey failure rather than by design preference. Typical groups include value comprehension, information scent, trust, navigation, form completion, task success, recovery from error, onboarding, accessibility, speed, support handoff, and retention.

Use the market-research brief template in templates/market-research-brief.md. Create one improvement card per discrete change hypothesis using templates/improvement-experiment-card.md. A card must identify its evidence, target user/task, expected benefit, scope, risks, measurement plan, and required approval.

4. Prioritize Without False Precision

Score each proposal using the following ordinal factors, each with a short written rationale:

Use the scores to sort discussion, not to replace judgment. Favor high-impact, strongly evidenced, low-risk, reversible experiments. Escalate any proposal involving legal terms, pricing, authentication, payments, sensitive data, algorithms that affect people, or public claims for specialist and accountable-owner review.

5. Validate Before Scaling

For a low-risk change, define a bounded test: audience, route, hypothesis, success metric, guardrail metric, observation period, sample or exposure limit, rollback trigger, and reviewer. When controlled experimentation is unavailable, validate with moderated task testing, accessibility testing, staged release, or structured qualitative feedback.

Do not claim improvement until the predetermined evidence shows it. Record null, negative, and mixed results as carefully as positive results. If a change is approved and implemented, run functional, responsive, keyboard, screen-reader-aware, and content checks appropriate to the scope before release.

6. Close the Learning Loop

Write a concise decision record: what was proposed, which evidence supported it, who approved it, what changed, how it was evaluated, the result, and the next action. Mark the evidence freshness date. Retire or re-test recommendations when the market, product, audience, or evidence materially changes.

Recurring Operation

Continuous improvement means a repeating evidence-and-review loop, not unattended changes. Begin a recurring program with a cadence decision using templates/cadence-decision.md.

For a light program, conduct a time-boxed recurring review that watches the target journey, a small comparator set, standards updates, known feedback themes, and previously defined metrics. Produce a reviewable brief and a proposed backlog only. This is appropriate when analysis needs judgment and frequency is modest.

For a larger or growing program, create a managed research workspace that stores source dates, evidence, hypotheses, decisions, metrics, owners, and review status. Use automated collection only for permitted, deterministic, public or owned data sources. Make the system create drafts and alerts, never automatic design changes or external actions. Present at least two operating options—one lightweight and one durable—with cost, setup, data access, and review tradeoffs before configuring automation.

Required Deliverables

Deliver a concise brief containing the baseline, research question, source table, observations, evidence limitations, ranked opportunity cards, proposed validation plan, and decisions requested. Include citations for external claims. Keep screenshots, raw notes, and personally sensitive material private; attach or reference only the minimum necessary evidence.

Use this closing structure:

Reference and Template Use

Read references/evidence-and-metrics.md before research collection, metric selection, or market-data interpretation. Use templates/market-research-brief.md for each review, templates/improvement-experiment-card.md for each proposal, and templates/cadence-decision.md before establishing a recurring operation.