dragoon0x/everything-design-taste

prototyping-strategy

Prototyping fidelity decisions, tools selection, prototype testing, and interactive prototype design.

First seen Jul 18, 2026

Installation

$ npx skills add dragoon0x/everything-design-taste --skill prototyping-strategy

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from dragoon0x/everything-design-taste · top by installs.

npx skills add dragoon0x/everything-design-taste

Browse all from dragoon0x/everything-design-taste

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 11
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 1,382 B
  • docs SUMMARY.md 129 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 2 installs

SKILL.md

Prototyping Strategy

Fidelity Spectrum

Fidelity Tool Best For Time
Paper Paper + pen Early concepts, team brainstorming Minutes
Lo-fi wireframe Balsamiq, Whimsical Structure validation, flow testing Hours
Mid-fi Figma wireframes Usability testing, stakeholder alignment Days
Hi-fi Figma, Framer Final design validation, development spec Days-weeks
Code HTML/CSS, React Production-ready, complex interactions Weeks

When to Use Each

  • Paper: When you need to explore 10+ ideas quickly
  • Lo-fi: When testing navigation and flow (not visual design)
  • Mid-fi: When testing usability before investing in visual design
  • Hi-fi: When testing visual design, brand response, and polish
  • Code: When testing complex interactions, animations, or real data

Prototype Testing Rules

  1. Match fidelity to the question you're testing
  2. Use real content (not lorem ipsum)
  3. Build only the paths you're testing (not the whole app)
  4. Let users find their own way (don't guide them)
  5. Prototype the error states and edge cases too