MCP HubMCP Hub
스킬 목록으로 돌아가기

review-web-design

pjt222
업데이트됨 2 days ago
6 조회
17
2
17
GitHub에서 보기
디자인design

정보

이 스킬은 레이아웃, 타이포그래피, 색상 사용, 간격, 반응형 동작, 브랜드 일관성 및 시각적 계층 구조를 평가하여 웹 디자인 품질을 검토합니다. 디자인 원칙에 대한 평가와 개선 권장 사항을 제공합니다. 개발 전 디자인 목업을 검토하거나, 구현된 웹사이트를 평가할 때, 또는 디자인 검토 회의 중에 사용하세요.

빠른 설치

Claude Code

추천
기본
npx skills add pjt222/agent-almanac -a claude-code
플러그인 명령대체
/plugin add https://github.com/pjt222/agent-almanac
Git 클론대체
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/review-web-design

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서


name: review-web-design description: > Bewertet Webdesign auf Layoutqualitaet, Typografie, Farbverwendung, Abstaende, Responsive-Verhalten, Markenkonsistenz und visuelle Hierarchie. Umfasst die Bewertung von Gestaltungsprinzipien und Verbesserungsempfehlungen. Verwenden beim Review eines Design-Mockups vor der Entwicklung, bei der Einschaetzung einer implementierten Website auf Designqualitaet, beim Feedback waehrend einer Design-Review-Sitzung, bei der Bewertung der Markenkonsistenz oder beim Pruefen des Responsive-Verhaltens ueber Breakpoints. locale: de source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Grep Glob WebFetch metadata: author: Philipp Thoss version: "1.0" domain: review complexity: intermediate language: multi tags: web-design, layout, typography, colour, responsive, visual-hierarchy, branding

Webdesign reviewen

Ein Webdesign auf visuelle Qualitaet, Konsistenz und Effektivitaet auf verschiedenen Geraeten bewerten.

Wann verwenden

  • Review eines Design-Mockups oder Prototyps vor der Entwicklung
  • Einschaetzung einer implementierten Website oder Webanwendung auf Designqualitaet
  • Feedback zum visuellen Design waehrend einer Design-Review-Sitzung
  • Bewertung der Markenkonsistenz ueber mehrere Seiten oder Abschnitte
  • Pruefen des Responsive-Design-Verhaltens ueber Breakpoints

Eingaben

  • Erforderlich: Zu reviewendes Design (URL, Mockup-Dateien, Screenshots oder Quellcode)
  • Optional: Markenrichtlinien oder Design-System-Dokumentation
  • Optional: Beschreibung der Zielgruppe
  • Optional: Referenzdesigns oder Konkurrenzbeispiele
  • Optional: Spezifische Problembereiche

Vorgehensweise

Schritt 1: Visuelle Hierarchie bewerten

Visuelle Hierarchie fuehrt das Auge des Nutzers durch Inhalte nach Wichtigkeit.

  • Klarer Blickfang: Gibt es auf jeder Seite/jedem Bildschirm einen offensichtlichen Einstiegspunkt?
  • Ueberschriften-Hierarchie: Folgen Ueberschriften logisch absteigend (H1 → H2 → H3)?
  • Groesskkontrast: Sind wichtige Elemente groesser als unterstuetzende Elemente?
  • Farbkontrast: Sind CTAs und wichtige Aktionen visuell hervorgehoben?
  • Weissraum: Trennt der Abstand logische Gruppen effektiv?
  • Lesefluss: Folgt das Layout einem natuerlichen Lesemuster (F-Muster, Z-Muster)?
## Visuelle-Hierarchie-Bewertung
| Seite/Abschnitt | Blickfang | Hierarchie klar? | Probleme |
|-------------|-------------|-----------------|--------|
| Startseite | Hero-Abschnitt CTA | Ja | Sekundaerer CTA konkurriert mit primaarem |
| Produktseite | Produktbild | Groesstenteils | Preis nicht prominent genug |
| Kontaktformular | Absenden-Button | Nein | Formulartitel gleich gross wie Fliesstext |

Erwartet: Jede wesentliche Seite/jeder Abschnitt auf klare visuelle Hierarchie bewertet. Bei Fehler: Wenn Mockups nicht verfuegbar sind, anhand von Live-Code mit Browser-Entwicklertools bewerten.

Schritt 2: Typografie bewerten

  • Schriftauswahl: Sind Schriften fuer Marke und Inhaltstyp geeignet?
  • Schriftpaarung: Ergaenzen sich Ueberschriften- und Fliesstext-Schriften (max. 2-3 Familien)?
  • Typo-Skala: Gibt es eine konsistente Skala (z. B. 1,25 Major Second, 1,333 Perfect Fourth)?
  • Zeilenhoehe: Fliesstext hat 1,4–1,6 Zeilenhoehe; Ueberschriften haben 1,1–1,3
  • Zeilenlaenge: Fliesstextzeilenlaenge betraegt 45–75 Zeichen (optimal ~66)
  • Schriftstaerke: Staerkevariationen werden konsistent zur Anzeige von Hierarchie verwendet
  • Schriftgroesse: Basis-Schriftgroesse betraegt mindestens 16px fuer Fliesstext
/* Beispiel gut strukturierte Typoskala (Verhaeltnis 1,25) */
:root {
  --text-xs: 0.64rem;    /* 10.24px */
  --text-sm: 0.8rem;     /* 12.8px */
  --text-base: 1rem;     /* 16px */
  --text-lg: 1.25rem;    /* 20px */
  --text-xl: 1.563rem;   /* 25px */
  --text-2xl: 1.953rem;  /* 31.25px */
  --text-3xl: 2.441rem;  /* 39.06px */
}

Erwartet: Typografie auf Konsistenz, Lesbarkeit und Hierarchie bewertet. Bei Fehler: Wenn das Design mehr als 3 Schriftfamilien verwendet, Konsolidierung empfehlen.

Schritt 3: Farbverwendung reviewen

  • Palettenkohaerenz: Ist die Farbpalette bewusst und begrenzt (typischerweise 3-5 Farben + Neutraltoeone)?
  • Markenausrichtung: Stimmen Farben mit den Markenrichtlinien ueberein?
  • Kontrastverhaeltnisse: Text erfuellt WCAG AA (4,5:1 fuer normalen Text, 3:1 fuer grossen Text)
  • Semantische Farbe: Werden Farben konsistent fuer Bedeutungen verwendet (Rot=Fehler, Gruen=Erfolg)?
  • Farbenblindheit: Wird Information nicht ausschliesslich durch Farbe uebermittelt?
  • Dunkel-/Hellmodus: Wenn unterstuetzt, behalten beide Modi Lesbarkeit und Markenkonsistenz bei
## Farbbewertung
| Verwendung | Farbe | Kontrastverhaeltnis | WCAG AA | Anmerkungen |
|-------|--------|----------------|---------|-------|
| Fliesstext auf Weiss | #333333 | 12,6:1 | Bestanden | Gut |
| Linktext auf Weiss | #2563eb | 5,2:1 | Bestanden | Gut |
| Gedaempfter Text auf Hellgrau | #9ca3af auf #f3f4f6 | 2,1:1 | NICHT BESTANDEN | Kontrast erhoehen |
| CTA-Schaltflaeche Text | #ffffff auf #22c55e | 3,1:1 | NICHT BESTANDEN fuer kleinen Text | Dunkleres Gruen oder groesseren Text verwenden |

Erwartet: Farbpalette auf Kohaerenz, Zugaenglichkeit und semantische Konsistenz reviewt. Bei Fehler: Kontrastpruef-Tool (WebAIM) fuer exakte Verhaeltnisse verwenden.

Schritt 4: Layout und Abstaende bewerten

  • Rastersystem: Wird ein konsistentes Raster verwendet (12-Spalten, Auto-Layout oder benutzerdefiniert)?
  • Abstandsskala: Sind Abstaende systematisch (4px/8px Basis oder Tailwind-aehnliche Skala)?
  • Ausrichtung: Sind Elemente am Raster ausgerichtet (keine "fast ausgerichteten" Elemente)?
  • Dichte: Ist die Informationsdichte fuer den Inhaltstyp angemessen (datenlastig vs. Marketing)?
  • Weissraum: Wird Weissraum bewusst zum Gruppieren und Trennen eingesetzt?
  • Konsistenz: Sind aehnliche Abschnitte identisch beabstandet?

Abstandsaudit:

## Abstands-Konsistenz-Prüfung
| Elementpaar | Erwarteter Abstand | Tatsaechlicher Abstand | Konsistent? |
|-------------|-------------|------------|-------------|
| Abschnittstitel bis Inhalt | 24px | 24px | Ja |
| Karte zu Karte | 16px | 16px/24px | Nein — inkonsistent |
| Formular-Label bis Eingabe | 8px | 4px/8px/12px | Nein — variiert |

Erwartet: Layout verwendet ein systematisches Raster und eine Abstandsskala konsistent. Bei Fehler: Wenn Abstaende inkonsistent sind, Einfuehrung einer Abstandsskala empfehlen (z. B. Tailwinds space-*).

Schritt 5: Responsive Design bewerten

Ueber wichtige Breakpoints testen:

BreakpointBreiteRepraesentiert
Mobil375pxiPhone SE / kleine Smartphones
Mobil L428pxiPhone 14 / grosse Smartphones
Tablet768pxiPad Hochformat
Desktop1280pxStandard-Laptop
Breit1536px+Desktop-Monitor

An jedem Breakpoint pruefen:

  • Layout-Anpassung: Fliesst das Layout angemessen um (gestapelt auf Mobil, nebeneinander auf Desktop)?
  • Touch-Ziele: Sind interaktive Elemente auf Mobil mindestens 44x44px gross?
  • Textlesbarkeit: Ist die Schriftgroesse fuer den Viewport geeignet?
  • Bildskalierung: Skalieren Bilder ohne Verzerrung oder Ueberlauf?
  • Navigation: Ist die mobile Navigation zugaenglich (Hamburger-Menu, Bottom-Nav usw.)?
  • Kein horizontales Scrollen: Inhalte ueberlaufen den Viewport nicht horizontal
## Responsive-Review
| Breakpoint | Layout | Touch-Ziele | Text | Bilder | Navigation | Probleme |
|-----------|--------|---------------|------|--------|------------|--------|
| 375px | OK | OK | OK | Ueberlauf im Hero | Hamburger | Hero-Bild wird abgeschnitten |
| 768px | OK | OK | OK | OK | Hamburger | Keine |
| 1280px | OK | N/A | OK | OK | Volle Navigation | Keine |
| 1536px | OK | N/A | Zeilenlaenge zu gross | OK | Volle Navigation | max-width zum Inhalt hinzufuegen |

Erwartet: Design an allen wichtigen Breakpoints getestet mit dokumentierten Problemen. Bei Fehler: Wenn Responsive-Testing-Tools nicht verfuegbar sind, CSS-Media-Queries auf Abdeckung ueberpruefen.

Schritt 6: Markenkonsistenz pruefen

  • Logo-Verwendung: Logo korrekt dargestellt (Groesse, Abstand, Schutzzone)
  • Farbgenauigkeit: Markenfarben stimmen mit Vorgaben ueberein (Hex-Werte, nicht "nah genug")
  • Typografie-Uebereinstimmung: Schriften entsprechen den Markenrichtlinien
  • Ton/Stimme: UI-Texte passen zur Markenpersoenlichkeit
  • Ikonografie: Icons stammen aus einem konsistenten Set (Stil, Staerke, Raster)
  • Fotografie-Stil: Bilder entsprechen den Markenrichtlinien (falls zutreffend)

Erwartet: Markenelemente gegen Richtlinien verifiziert mit spezifisch vermerkten Abweichungen. Bei Fehler: Wenn keine Markenrichtlinien vorhanden sind, dies als Empfehlung vermerken und stattdessen interne Konsistenz bewerten.

Schritt 7: Den Design-Review verfassen

## Webdesign-Review

### Gesamteindruck
[2-3 Saetze: Gesamtqualitaet, staerkste und schwaechste Aspekte]

### Visuelle Hierarchie: [Bewertung/5]
[Wichtigste Befunde mit spezifischen Referenzen]

### Typografie: [Bewertung/5]
[Wichtigste Befunde mit spezifischen Referenzen]

### Farbe: [Bewertung/5]
[Wichtigste Befunde mit spezifischen Referenzen]

### Layout & Abstaende: [Bewertung/5]
[Wichtigste Befunde mit spezifischen Referenzen]

### Responsive Design: [Bewertung/5]
[Wichtigste Befunde mit spezifischen Referenzen]

### Markenkonsistenz: [Bewertung/5]
[Wichtigste Befunde mit spezifischen Referenzen]

### Prioritaere Verbesserungen
1. [Wirkungsvollste Aenderung — spezifisch und umsetzbar]
2. [Zweite Prioritaet]
3. [Dritte Prioritaet]

### Positive Anmerkungen
1. [Was gut funktioniert und erhalten werden sollte]

Erwartet: Review liefert spezifisches, visuell referenziertes Feedback mit priorisierten Verbesserungen. Bei Fehler: Wenn Bewertungen beliebig erscheinen, stattdessen ein einfacheres Bestanden/Bedenken/Nicht-bestanden-System verwenden.

Validierung

  • Visuelle Hierarchie fuer alle wesentlichen Seiten/Abschnitte bewertet
  • Typografie auf Lesbarkeit, Konsistenz und Skala geprueft
  • Farbkontrast gegen WCAG-AA-Mindestwerte verifiziert
  • Layout und Abstaende auf Rasterkonsistenz geprueft
  • Responsive Design an mindestens 3 Breakpoints getestet
  • Markenkonsistenz gegen Richtlinien verifiziert (oder interne Konsistenz bewertet)
  • Feedback ist spezifisch mit visuellen Referenzen (Seite, Abschnitt, Element)

Haeufige Stolperfallen

  • Subjektiv ohne Begruendung: "Ich mag die Farbe nicht" ist nicht umsetzbar. Erklaeren warum (Kontrast, Markendiskrepanz, Zugaenglichkeit).
  • Zugaenglichkeit ignorieren: Visuelles Design-Review muss WCAG-Kontrastpruefungen enthalten. Schoene Designs, die Nutzer ausschliessen, sind keine guten Designs.
  • Nur Mockups reviewen: Responsive-Verhalten, Hover-Zustaende und Uebergaenge testen — nicht nur statische Layouts.
  • Loesungen vorschreiben: Das Problem beschreiben ("Text ist auf diesem Hintergrund schwer lesbar") statt eine bestimmte Loesung vorzuschreiben ("Verwende #333").
  • Kontext vergessen: Eine Banken-App und eine Gaming-Site haben unterschiedliche Designstandards. Gegen den angemessenen Kontext reviewen.

Verwandte Skills

  • review-ux-ui — Usability-, Interaktionsmuster- und Zugaenglichkeitsreview (ergaenzend zum visuellen Design)
  • setup-tailwind-typescript — Tailwind CSS Implementierung fuer Design-Systeme
  • scaffold-nextjs-app — Next.js-Anwendungs-Scaffolding

GitHub 저장소

pjt222/agent-almanac
경로: i18n/de/skills/review-web-design
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

연관 스킬

executing-plans

디자인

executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.

스킬 보기

requesting-code-review

디자인

이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.

스킬 보기

connect-mcp-server

디자인

이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.

스킬 보기

web-cli-teleport

디자인

이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.

스킬 보기