القائمة
Use when designing UI, creating wireframes, running user research, defining information architecture, or reviewing design decisions — regardless of tool (Figma, Sketch, etc.)
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when implementing any feature or bugfix, before writing implementation code
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Use when you have a spec or requirements for a multi-step task, before touching code
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
| name | ux-designer |
| description | Use when designing UI, creating wireframes, running user research, defining information architecture, or reviewing design decisions — regardless of tool (Figma, Sketch, etc.) |
Philosophy: Design is problem solving, not decoration. Good UX is invisible — users accomplish their goal without noticing the interface. The best design eliminates decisions the user shouldn't have to make.
| What | Why it matters |
|---|---|
| Platform? iOS / Android / Web / Desktop | Each has distinct patterns and constraints |
| Stage? Early exploration / Detailed design / Polish | Changes fidelity needed |
| User research available? | Can't design for a user you haven't talked to |
| Design system exists? | Whether to extend or create from scratch |
Hick's Law: Decision time = log2(N choices)
→ More options = slower decisions = more friction
→ Max 5–7 items in navigation; fewer primary actions per screen
Fitts' Law: Time to tap = a + b × log2(distance/size + 1)
→ Bigger targets = faster taps
→ Primary CTA: minimum 44×44pt (iOS) / 48×48dp (Android) / 44×44px (web)
→ Place common actions closer to thumb (bottom of screen on mobile)
Every screen needs exactly:
If a screen has 3+ things competing for attention → redesign.
| ❌ NEVER DO | Why | ✅ DO INSTEAD |
|---|---|---|
| Design in isolation without user feedback | Solving assumed problems | User interviews before wireframing |
| 5+ items in primary navigation | Cognitive overload, users freeze | 4–5 items max; progressive disclosure for the rest |
| Decorative animations only | Distraction without purpose | Animations that communicate state change or guide attention |
| Red for non-error states | Deep-wired association: red = danger | Reserve red for errors/destructive actions only |
| Long onboarding before value | Users leave before experiencing product | Show value first, teach later |
| Placeholder text as labels | Disappears on input, user forgets context | Floating labels or static labels above inputs |
| Custom gestures with no affordance | Undiscoverable | Teach novel gestures with a coach mark on first encounter |
| Text type | Minimum contrast ratio |
|---|---|
| Normal text (< 18pt) | 4.5:1 |
| Large text (≥ 18pt or bold 14pt) | 3:1 |
| UI components, icons | 3:1 |
| Decorative, disabled | No requirement |
Check with: WebAIM Contrast Checker · Figma Contrast plugin · Stark
When designing a new screen:
When reviewing existing design:
Must fix:
Should fix:
mobile-developer — for mobile interaction constraints and platform conventionsfrontend-developer — for web accessibility and component designconversion-optimizer — for conversion-focused landing page designproduct-manager — for JTBD alignment before starting designFigma (design + prototyping) · FigJam (whiteboarding) · Maze / Useberry (usability testing) · Stark (accessibility) · Mobbin (UI reference/inspiration) · Lottie (animations)