Prompts for design system practitioners - building, scaling, and governing systems that the rest of the org will actually use. Use them in a planning sprint, an audit, or a maturity review.
Find what's broken before scaling.
Audit our current design system: [PASTE high-level state]. Org size: [PASTE]. Consumers: [PASTE]. Output: 1) the components that get reused well, 2) the components that get forked, 3) the gaps consumers patch around, 4) the token system maturity, 5) the docs gap. End with the 3 priorities for the next quarter and the 1 thing to stop doing.
Tokens that scale to multiple brands and themes.
Design token architecture for [PRODUCT or COMPANY]. Themes: [PASTE]. Brands: [PASTE]. Output: 1) the layered model (raw / semantic / component), 2) the naming convention, 3) the brand and theme overlay strategy, 4) the contribution rule for adding a token, 5) the deprecation flow. End with the 1 token category most teams over-engineer.
Define a component end-to-end before building.
Spec the [COMPONENT NAME] component for our design system. Use cases: [PASTE]. Output: 1) the anatomy and slots, 2) the props / variants, 3) the states (default, hover, focus, active, disabled, error, loading), 4) the accessibility requirements (semantic role, keyboard, screen-reader), 5) the responsive behavior. End with the misuses to document explicitly.
Names that survive contact with reality.
Name this component: [DESCRIBE FUNCTION]. Output: 3 candidate names. For each: 1) the search-ability, 2) the discoverability for new consumers, 3) the conflict risk with existing components, 4) the cross-platform consistency, 5) the long-term scalability. End with the winner and the 1 name I should reject and why.
Let the system scale beyond the core team.
Design a contribution model for our design system. Core team size: [PASTE]. Contributor pool: [PASTE]. Output: 1) the contribution types (proposal, fix, new component), 2) the workflow for each, 3) the gating criteria, 4) the maintainer review SLA, 5) the recognition mechanism. End with the failure mode to watch for.
Phase out without breaking the world.
Deprecate [COMPONENT] in favor of [REPLACEMENT]. Output: 1) the deprecation announcement message, 2) the timeline (warning → soft removal → hard removal), 3) the migration guide structure, 4) the codemod or auto-fix opportunity, 5) the rollback plan. End with the 1 stakeholder that will push back hardest and the response.
Docs people actually use.
Design the documentation structure for our system. Audiences: [PASTE]. Output: 1) the top-level sections, 2) the per-component page structure (overview, anatomy, props, examples, accessibility, do/don't, code), 3) the search-ability, 4) the staying-fresh mechanism, 5) the contribution-friendliness. End with the 1 section every system underinvests in.
Decision rights and escalation.
Define governance for our design system. Org structure: [PASTE]. Output: 1) the decision rights matrix (who decides tokens, components, breaking changes), 2) the regular cadence (sync, review, retros), 3) the escalation path for conflicts, 4) the public roadmap commitment, 5) the metrics worth reporting. End with the rule for breaking your own rule.
Files and components that scale.
Organize our Figma library. Current state: [PASTE]. Output: 1) the file split rationale (single mega-file vs splits), 2) the page organization within files, 3) the component naming convention with separators, 4) the variant property structure, 5) the publishing and versioning rule. End with the 1 thing that breaks fastest at scale.
Get adoption past the first 10 users.
Launch our design system internally. Audience: [PASTE]. Current status: [PASTE]. Output: 1) the launch message, 2) the office-hours plan for the first 2 weeks, 3) the first-product migration target, 4) the success stories to capture, 5) the friction to expect and pre-empt. End with the 1 thing not to promise.
SemVer or branded versions or rolling release.
Design the versioning strategy for our system. Consumers: [PASTE]. Release cadence: [PASTE]. Output: 1) the version scheme (semver, calver, rolling), 2) the breaking change protocol, 3) the changelog format, 4) the consumer migration support window, 5) the LTS rule if any. End with the most common mistake at our scale.
What's required of every component.
Define an accessibility baseline for every component in our system. Output: 1) the WCAG level we commit to, 2) the keyboard-navigation requirements, 3) the screen-reader testing protocol, 4) the contrast minimums for tokens, 5) the documentation requirement. End with the 1 accessibility shortcut teams take that we must forbid.
Prove the system's value.
Define success metrics for our design system. Goals: [PASTE]. Output: 1) the adoption metric (and how to instrument it), 2) the time-to-ship metric for consumers, 3) the consistency metric, 4) the consumer-satisfaction metric, 5) the cost-of-design-debt avoided. End with the 1 metric I shouldn't optimize for.
Where design and code meet cleanly.
Define the design-engineering interface for our system. Stack: [PASTE]. Output: 1) the source of truth (design tool, code, both), 2) the token sync pipeline, 3) the component parity checks, 4) the variant naming alignment, 5) the breaking-change communication. End with the friction point that costs both teams the most time.
Honest snapshot of where we are.
Assess design system maturity for our team. Current state: [PASTE]. Output: 1) the maturity level (foundational, established, scaled, autonomous), 2) the biggest gap to next level, 3) the 3 investments worth making this quarter, 4) the 1 investment to defer, 5) the team-size and skill-mix recommendation. End with the 1 fragility to address first.
Instale o aprimorador de prompts de IA grátis para Chrome e veja a diferença na hora.
5 prompts grátis por dia. Sem cartão. Funciona em 11 ferramentas de IA.
Instalar grátis — Corrigir meu próximo prompt