# Product Design > Use for user-centered product discovery, UX, product requirements, AI/ML experiences, design systems, and hypothesis validation. Own the path from user outcome and evidence to an experience and measurable product change; use business-product-consulting for strategy, operating-model, or executive tradeoff decisions. - Skill: `bejeweledme/product-design` (Agent Skill, multi-file: 16 files) - Install (CLI): `npx skillmds@latest add bejeweledme/product-design` - Raw SKILL.md: https://api.skillmd.com/api/skills/bejeweledme/product-design/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: BejeweledMe (https://skillmd.com/u/bejeweledme) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/bejeweledme/product-design --- # Product Design Use this skill to design or review products end to end. Treat product design as the connection between customer outcomes, business results, discovery evidence, usability, feasibility, viability, UI/UX quality, AI trust, design systems, metrics, release safety, and maintenance. ## Core Rule For an unresolved product decision, connect the user, context, desired outcome, opportunity, evidence, assumptions, risks and success measures before selecting an experience. Reuse supplied context and accepted decisions. For a bounded implementation or edit, address only unknowns that could materially change the requested work; do not require fresh discovery, alternatives, an OKR or a document merely to proceed. Apply quality, guardrails, fallback, ownership and maintenance requirements relevant to the actual change. ## Hierarchy And Handoffs This skill owns the product and experience path: user problem, discovery evidence, opportunity, candidate experience, requirements, usability, validation, and product measurement. Start here when the central uncertainty is what to build, for whom, or how the experience should behave. Use `$business-product-consulting` when the primary decision is a business case, portfolio or market choice, operating model, organization/ownership, executive recommendation, or a comparison of strategic alternatives. It may consume this skill's evidence but does not replace user research or UX design. Involve the appropriate frontend, backend, system, ML, LLM or mobile owner early when technical options or constraints affect discovery. That owner also leads implementation architecture once the product decision is sufficiently clear. Early engineering input and ongoing product/design support during delivery preserve shared understanding; an implementation choice does not itself validate the user problem. For browser UI, give `$web-frontend-engineering` the acceptance journey, supported devices and input modes, visible and operable states, focus behavior, and failure criteria from `references/08-ui-ux-product-quality.md`; it owns rendering and loading implementation, while this skill owns acceptable user behavior. ## Reference Routing Read only the references needed for the current task. - Always start with `references/00-index.md` for broad product design work or to choose a route. - For shared vocabulary, read `references/01-terminology.md`. - For empowered teams, product roles and authority, cross-team coherence, commitments, and value/usability/feasibility/viability risks, read `references/02-product-operating-model.md`. - For product discovery, opportunity-solution trees, outcome -> opportunities -> solutions -> assumptions, and discovery anti-patterns, read `references/03-discovery-and-opportunity-solution-trees.md`. - For interview planning, research questions, story-based interviews, prototype sessions, user evidence, and shared learning, read `references/04-user-research-and-interviewing.md`. - For assumption tests, evidence and prototype selection, AI/UI validation, learning artifacts versus release readiness, and readiness to build, read `references/05-validation-and-assumption-tests.md`. - For AI/ML product UX, AI-vs-non-AI decisions, data needs, explainability, automation, model errors, and feedback loops, read `references/06-ai-ml-product-ux.md`. - For calibrated trust, confidence, user control, correction, undo, fallback, granular feedback, and global controls, read `references/07-calibrated-trust-and-human-control.md`. - For UI/UX product quality, states, accessibility extensions, instrumentation, design system fit, and implementation quality, read `references/08-ui-ux-product-quality.md`. - For design systems as product infrastructure, design tokens, components, docs, users, ownership, and AI support, read `references/09-design-systems-as-product.md`. - For design system governance, contribution, adoption, buy-in, documentation, automation, and metrics, read `references/10-design-system-governance-adoption-metrics.md`. - For business outcomes, product metrics, guardrails, leading/lagging indicators, AI metrics, and design system metrics, read `references/11-business-outcomes-and-product-metrics.md`. - For concrete review and design checklists, read `references/12-agent-product-design-checklists.md`. - For red flags and failure modes, read `references/13-anti-patterns.md`. ## Workflow Use the route and output fields relevant to the request. These lists guide substantial design work; they do not require reopening settled decisions or producing every artifact for a bounded change. 1. Classify the request: - New product or feature: read `00`, `01`, `02`, `03`, `05`, `11`, then topic files. - Product discovery: read `03`, `04`, `05`, `11`, `13`. - User research plan: read `04`, then `03`, `05`, and `11` if the research drives prioritization. - AI/ML product or assistant UX: read `06`, `07`, `05`, `08`, `11`, `13`. - UI/UX acceptance review: read `08`, then `07` for AI flows, `09` for design-system fit, and `12` for checklists. Route browser state/rendering implementation to `$web-frontend-engineering`. - Design system work: read `09`, `10`, `11`, `13`. - Metrics, validation, or launch readiness: read `05`, `11`, `12`, and topic files for the relevant surface. - Fact-checking or source-sensitive work: use supplied sources or primary current sources before making strong claims; label any remaining inference explicitly. 2. Identify blocking unknowns. Ask only when missing information changes the decision; otherwise state assumptions. 3. Separate outcome, opportunity, solution, and assumptions. 4. Assess material value, usability, feasibility and viability uncertainty using available evidence; pursue additional inquiry where it can change the decision. Make residual risks explicit when a commitment is needed under uncertainty. 5. Produce practical recommendations with validation, metrics, guardrails, fallback, ownership, and maintenance. 6. Mark any recommendation not grounded in the references as `external extension`. ## Output For New Product Or Feature Design Include: - User, context, and job/problem. - Business problem and desired outcome. - Current evidence and source quality. - Opportunities and selected target opportunity. - Candidate solutions, including simpler non-AI/non-custom alternatives when relevant. - Critical assumptions and validation plan. - Value, usability, feasibility, and viability risks. - UI/UX requirements, states, accessibility, instrumentation, and design-system fit. - AI capabilities, limits, feedback, correction, fallback, and controls when AI is involved. - Product metrics, business metrics, guardrails, and thresholds. - Rollout, support, monitoring, ownership, maintenance, and future-change plan. ## Output For Product Or UX Review Lead with risks and missing decisions: - Outcome and user-context gaps. - Unsupported opportunities or solution-first thinking. - Weak or missing value/usability/feasibility/viability validation. - AI trust, uncertainty, correction, or fallback gaps. - UI state, accessibility, instrumentation, and implementation gaps. - Design-system governance, adoption, or component-fit risks. - Metric and business-impact gaps. - Concrete fixes, experiments, and questions to unblock the work. ## Output For AI/ML Product UX Prioritize: 1. Decide whether AI is needed and compare non-AI baselines. 2. Define user benefit, data needs, model-quality risks, and error costs. 3. Design expectations: capabilities, limits, uncertainty, explanations. 4. Preserve control: dismiss, correct, edit, undo, retry, manual path. 5. Plan feedback loops, tuning, monitoring, behavior-change communication, and fallback. 6. Connect model metrics to user and business outcomes. ## Output For Design Systems Include: - System users and repeated product needs. - Current artifacts: design, code, tokens, docs, examples, tests. - Governance model and decision rights. - Contribution path and quality gates. - Adoption blockers and migration plan. - Metrics across adoption, quality, speed, consistency, community, and business impact. - Documentation, release notes, versioning, deprecation, support, and ownership. ## Quality Bar - Do not equate output with outcome. - Do not call a need an opportunity until it is backed by customer evidence or clearly marked as an assumption. - When choosing a solution for an unresolved opportunity, compare alternatives and assess critical assumptions; reuse prior decisions and evidence for a specified change. - Do not add AI without proving unique AI value and designing uncertainty, correction, fallback, and control. - Do not call a UI product-ready without non-happy-path states, accessibility basics, instrumentation, error handling, and ownership. - Do not call a design system mature because it has a UI kit or component package; require adoption, governance, docs, release process, and metrics. - Do not overclaim source coverage. Rosenfeld notes are based only on public pages/samples, and zeroheight survey data must keep its sample limitations.