القائمة
Use when user needs are unclear, assumptions need validation, or the design brief identifies gaps in understanding — plans what to learn, which methods to use, and from whom
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when the user wants to start from a known brand's design language — "use the same design language as Stripe", "make it feel like Linear", "start from Notion's DESIGN.md", "what brands can I borrow from?". Pulls a ready-made DESIGN.md from the open VoltAgent/awesome-design-md library (73+ brand design systems in the standard format), loads it as a STARTING POINT for the project's design layer, then adapts it to the real client. Inspired references, not official brand assets — adapt, don't impersonate
Use as a lightweight on-ramp for first-time or hesitant users who want a quick win before committing to the full pipeline — "can you just take a quick look", "make me a quick X", or a designer new to the terminal who freezes at the full process. Two tiny loops — express critique (one screen, one fast read) and express build (one component, shown immediately) — in plain language, finishing in about two minutes. Always a GATEWAY into the full workflow, never a replacement for it. Offered to first-time users only; returning users go straight to the Build and Review lanes
Use to turn Designpowers' markdown specs into something a designer can actually SEE and manipulate, and to pull existing Figma work back in. Bridges in both directions — push design-lead's visual decisions or built code into real Figma frames (code-to-design), and pull a Figma file in for review or as a design-system source (design-to-code). Falls back to a clickable HTML prototype when Figma isn't available. Invoke at the screenshot checkpoint, at handoff, when reviewing a Figma link, or whenever the user says "show me", "put this in Figma", or "make it real"
Use after a build to evaluate usability against Nielsen's 10 heuristics and run cognitive walkthroughs of every key task. Dispatches the heuristic-evaluator agent in parallel with design-critic and accessibility-reviewer, then feeds findings into the reconciliation protocol. This is the usability lens — "will people actually be able to use this?" — distinct from craft critique and accessibility audit
Use when the user wants to see how they design — "what's my taste", "show me my taste report", "how do I decide", "what are my patterns", or periodically as the personal profile matures. Generates a longitudinal, reflective report from the PERSONAL taste profile (design-memory) — recurring moves, tells, evolution, blind spots — that helps a designer understand their own instincts. Personal layer only: it never reports client-specific signals from any project's DESIGN.md
MUST run before any other Designpowers skill — shows welcome, checks taste profile, and routes to the correct first skill. Triggers on ANY design-related message. No other Designpowers skill may run until the welcome sequence has completed
| name | research-planning |
| description | Use when user needs are unclear, assumptions need validation, or the design brief identifies gaps in understanding — plans what to learn, which methods to use, and from whom |
Research is how we replace assumptions with evidence. This skill structures what you need to learn before committing to a design direction.
Review the design brief and list:
Present this to the user. Assumptions and unknowns become research questions.
Convert gaps into answerable questions. Good research questions are:
Aim for 3-5 research questions. More than that means you need to narrow scope.
Match methods to questions:
| Question Type | Recommended Methods |
|---|---|
| "What do people currently do?" | Journey mapping, diary studies, contextual inquiry |
| "Why do people struggle with X?" | Usability testing, think-aloud protocols |
| "What do people need?" | Interviews, jobs-to-be-done analysis |
| "Which approach works better?" | A/B testing, preference testing, card sorting |
| "How does our offering compare?" | Competitive analysis, heuristic evaluation |
| "Who are we designing for?" | Persona development, ability spectrum mapping |
Every research plan must address:
# Research Plan: [Topic]
## Research Questions
1. [Question]
2. [Question]
3. [Question]
## Methods
| Method | Questions Addressed | Participants | Timeline |
|--------|-------------------|-------------|----------|
| [Method] | Q1, Q2 | [Who and how many] | [When] |
## Inclusion Considerations
[How participant diversity and method accessibility will be ensured]
## Expected Outputs
[What deliverables this research will produce — personas, journey maps, findings report]
## Decision Points
[Which design decisions this research will inform]
Save to: docs/designpowers/research/YYYY-MM-DD-<topic>-plan.md
Present the plan. Confirm scope, methods, and timeline are realistic.
design-discoveryinclusive-personas (when persona development is a research output)design-strategy (research informs strategy)This skill plans research — it does not execute it. Execution happens with real people in the real world. The plan ensures that when research happens, it is structured, inclusive, and actionable.