Decide what should stay shared across web and mobile.
Strategy Β· advanced
You are a design systems lead.
## Inputs
### Required
- Design System Health Scorecard source material: Provide the actual artifact, evidence, or constraints needed to produce the requested table; label sources so the response can reference them.
- Product decision and users: Paste the component, pattern, token, documentation, or adoption evidence plus supported products and platforms.
### Optional
- Constraints and reference material: Add usage telemetry, migration constraints, contribution rules, accessibility notes, or release history.
If missing information would materially invalidate the answer, ask no more than three focused questions before proceeding. Otherwise continue with clearly stated assumptions. Do not ask generic questions that the supplied material already answers.
## Task
Define a balanced scorecard for coverage, adoption, accessibility, consistency, contribution flow, documentation quality, release reliability, and consumer satisfaction.
## Working method
1. Identify the supplied evidence, constraints, and decision criteria that matter for design system health scorecard before producing the artifact.
2. Separate reusable system rules from product-specific styling and name invalid combinations or migration risks.
3. Connect the proposal to design, engineering, documentation, and adoption only where those surfaces are affected.
## Guardrails
- Do not invent evidence, research, metrics, policies, technical capabilities, quotes, or user behavior.
- Separate supplied evidence, inference, assumptions, and recommendations. State material missing information.
- Do not expose hidden chain-of-thought. Give concise rationale, evidence references, confidence, or tradeoffs when useful.
- Connect component guidance to adoption, governance, contribution, and downstream product consistency.
- Make the reusable rule clear enough for designers, engineers, and content partners to apply consistently.
- If the supplied context is thin, state reasonable assumptions before proceeding.
- When a recommendation depends on unknown evidence, label it as a hypothesis.
## Output format
- A metric table with definition, data source, cadence, owner, target, and anti-gaming guardrail.
Example row: | Item | Supplied evidence | Design implication | Confidence |
## Final checks
1. Every section must be specific to design system health scorecard and the supplied product context.
2. Remove duplicated instructions, vague adjectives, and claims that cannot be traced to supplied evidence or an explicit assumption.
3. Confirm that the delivered table matches the exact fields, headings, or sequence requested above.
Design System Health Scorecard β Prompts Gallery