Product Design Workflow¶

Dokumentation für Unternehmensprozesse und externe Reviews¶

Version: 1.1 Stand: Februar 2026 Autor: VisiTrans Engineering

Inhaltsverzeichnis¶

Executive Summary
Workflow-Übersicht
Die 7 Phasen im Detail
Die Iterationsschleife
State Management
Orchestrator und Agenten
Skills und Commands
Quality Gates
Handoff zum Development Workflow
Best Practices
Glossar

1. Executive Summary¶

Was ist der Product Design Workflow?¶

Der Product Design Workflow ist ein strukturierter, KI-gestützter Prozess, der den gesamten Weg von der initialen Produktidee bis zur Übergabe an die Entwicklung abdeckt. Er ist Teil einer Two-Workflow-Architektur:

Workflow	Zielgruppe	Output
Product Design (`/pd-*`)	Product Manager, Designer	PRD, Prototype, specs
Knowledge Work (`/kw-*`)	Alle	Dokumentation, Guides, Analysen
Development (`/0-6`)	Entwickler	Funktionierende Software

Kernprinzipien¶

Iterativ, nicht linear: Der Workflow unterstützt Rücksprünge zu früheren Phasen, wenn neue Erkenntnisse dies erfordern.
State-basiert: Ein zentrales State-File (.design-state.yaml) trackt den Fortschritt, Artefakt-Versionen und Entscheidungshistorie.
Quality Gates: Jede Phase hat definierte Qualitätskriterien, die erfüllt sein müssen, bevor zur nächsten Phase übergegangen wird.
95% Code-Wiederverwendung: Prototypen werden so erstellt, dass 95% des Codes direkt in die Entwicklung übernommen werden können.
Lückenlose Dokumentation: Alle Entscheidungen werden dokumentiert und sind im Handoff-Paket für die Entwicklung verfügbar.

2. Workflow-Übersicht¶

Linearer Ablauf¶

┌─────────────────────────────────────────────────────────────────────────────┐
│                      PRODUCT DESIGN WORKFLOW                                 │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                              │
│   /vt-c-pd-0-start      Übersicht & Projektsetup                                 │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-1-research   User Research (Interviews, Personas, Analyse)            │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-2-prd        PRD erstellen (12-Sektionen-Template)                    │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-3-prototype  Prototyp generieren (VisiTrans Corporate Design)         │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-4-validate   Usability Testing und Iteration                          │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-5-specs   specs erstellen (Feature Briefs für Entwicklung)      │
│       │                                                                      │
│       ▼                                                                      │
│   /vt-c-pd-6-handoff    Übergabe an Development vorbereiten                      │
│       │                                                                      │
│       ╰──────────────────────────────────────────────────────────────────╮  │
│                                                                          │  │
│   ┌──────────────────────────────────────────────────────────────────────┼──┤
│   │                    DEVELOPMENT WORKFLOW                              │  │
│   │                                                                      ▼  │
│   │   /vt-c-0-start → /vt-c-1-bootstrap → /vt-c-2-plan → /vt-c-3-build → /vt-c-4-review → ...       │
│   └─────────────────────────────────────────────────────────────────────────┤
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

Mit Iterationsschleifen¶

                                    ITERATIVE DESIGN LOOP

   ┌─────────────────────────────────────────────────────────────────────────┐
   │                                                                         │
   │                    ┌──────────────────────────────┐                     │
   │                    │        00-Inbox/             │                     │
   │                    │  (Neue Inputs, Feedback)     │                     │
   │                    └──────────────┬───────────────┘                     │
   │                                   │                                     │
   │                                   ▼                                     │
   │                         /vt-c-pd-inbox-scan                                  │
   │                         (Erkennt neue Items)                            │
   │                                   │                                     │
   │                                   ▼                                     │
   │                       /vt-c-pd-analyze-changes                               │
   │                       (Analysiert Auswirkungen)                         │
   │                                   │                                     │
   │                                   ▼                                     │
   │                       /vt-c-pd-route-decision                                │
   │                       (Entscheidet Rücksprung)                          │
   │                                   │                                     │
   │         ┌─────────────────────────┴─────────────────────────┐           │
   │         │                         │                         │           │
   │         ▼                         ▼                         ▼           │
   │   ┌──────────┐             ┌──────────┐             ┌──────────┐        │
   │   │  pd-1    │             │  pd-2    │             │  pd-3    │        │
   │   │ research │             │   prd    │             │prototype │        │
   │   └────┬─────┘             └────┬─────┘             └────┬─────┘        │
   │        │                        │                        │              │
   │        ▼                        ▼                        ▼              │
   │   ┌──────────┐             ┌──────────┐             ┌──────────┐        │
   │   │  pd-2    │────────────▶│  pd-3    │────────────▶│  pd-4    │        │
   │   │   prd    │             │prototype │             │ validate │        │
   │   └──────────┘             └──────────┘             └────┬─────┘        │
   │                                                          │              │
   │                                   ┌──────────────────────┘              │
   │                                   │                                     │
   │                                   ▼                                     │
   │                            ┌──────────┐                                 │
   │                            │  pd-5    │                                 │
   │                            │specs  │                                 │
   │                            └────┬─────┘                                 │
   │                                 │                                       │
   │                                 ▼                                       │
   │                            ┌──────────┐                                 │
   │                            │  pd-6    │                                 │
   │                            │ handoff  │──────────▶ Development          │
   │                            └──────────┘                                 │
   │                                                                         │
   └─────────────────────────────────────────────────────────────────────────┘

3. Die 7 Phasen im Detail¶

Phase 0: Start (`/vt-c-pd-0-start`)¶

Zweck: Workflow-Übersicht und Projektsetup

Aktivitäten: - OneDrive-Projektordner aus Vorlage erstellen - .design-state.yaml initialisieren - Projektstruktur validieren - Vorhandene Artefakte prüfen

Projektstruktur:

OneDrive/[Projekt]/
├── 00-Inbox/                    # Eingehende Materialien
├── 01-Projektmanagement/        # Projektmanagement-Dokumente
├── 02-Knowledge/
│   ├── 02-Zielgruppen-Personas/ # User Personas
│   └── 04-Dokumente/            # Research Findings
├── 03-PRD/
│   ├── PRD.md                   # Product Requirements Document
│   └── PID.md                   # Project Implementation Document
├── 04-prototyp/                 # Prototyp (Git Repository)
├── 05-specs/                 # Feature Briefs für Entwicklung
│   ├── spec-0-project-setup.md
│   └── spec-N-[feature].md
├── 06-Handoff/                  # Übergabepaket
└── 98-Vorlagen/                 # Templates

Output: - Initialisierte Projektstruktur - Design State File (.design-state.yaml) - Klarer nächster Schritt

Quality Gate: - [ ] Projektordner existiert mit Standardstruktur - [ ] .design-state.yaml initialisiert - [ ] Nächste Phase bestimmt

Phase 1: Research (`/vt-c-pd-1-research`)¶

Zweck: User Research durchführen und Personas erstellen

Aktivitäten: - Interview-Skripte erstellen (Agent: interview-script-writer) - User Interviews durchführen (extern) - Transkripte analysieren (Agent: interview-analyzer) - Personas definieren - Key Findings dokumentieren

Verwendete Agenten: | Agent | Aufgabe | |-------|---------| | interview-script-writer | Erstellt semi-strukturierte Interviewleitfäden | | interview-analyzer | Extrahiert Insights aus Transkripten |

Output: - Interview-Skripte in 02-Knowledge/04-Dokumente/ - Persona-Definitionen in 02-Knowledge/02-Zielgruppen-Personas/ - Findings-Dokumentation

Quality Gate: - [ ] Mindestens 5 Interviews durchgeführt - [ ] Personas definiert mit Zitaten - [ ] Key Findings dokumentiert

Phase 2: PRD (`/vt-c-pd-2-prd`)¶

Zweck: Product Requirements Document erstellen

Aktivitäten: - PID.md lesen (falls vorhanden) für Tech-Constraints - Anforderungen sammeln durch geführte Fragen - PRD.md mit 12-Sektionen-Template generieren - Zu User Research verlinken

Die 12 PRD-Sektionen:

#	Sektion	Inhalt
1	Projekt-Übersicht	Titel, Ziele, Timeline
2	Problemstellung & Kontext	Problem, Zielgruppe, Dringlichkeit
3	Lösungsvision	Lösung, User Journeys, KPIs
4	Features (High-Level)	Feature-Tabelle mit Prototyp + FB-Link
5	Scope & Abgrenzung	In/Out of Scope, Trade-offs
6	System-Integrationen	Integrationen, Abhängigkeiten
7	Data Models & Schema	Entitäten, Beziehungen
8	NFRs	Performance, Security, Testing
9	Implementierungsplanung	Pakete, Abhängigkeiten
10	Risiken & offene Fragen	Risiken, Unsicherheiten
11	Anhänge & Referenzen	Design, Research, Kontakte
12	Stakeholder Review & Freigabe	Sign-off

Output: - 03-PRD/PRD.md (vollständiges PRD) - 03-PRD/PID.md (Tech Stack Reference) - Feature-Liste mit Platzhaltern für Prototyp und FB-Link

Quality Gate: - [ ] Alle 12 Sektionen vollständig - [ ] Sektion 4 Feature-Tabelle hat alle Features - [ ] Stakeholder Sign-off erhalten (Sektion 12)

Phase 3: Prototype (`/vt-c-pd-3-prototype`)¶

Zweck: Funktionalen Prototyp erstellen

Aktivitäten: - Git Repository in 04-prototyp/ erstellen - VisiTrans Corporate Design anwenden - Angular Standalone Komponenten generieren - Mock-Daten erstellen - Responsive Layouts implementieren - Deployment für Sharing

VisiTrans Corporate Design Tokens:

/* Farben */
--vt-black: #1F1F1F;
--vt-orange: #FF6600;
--vt-white: #FFFFFF;
--vt-magenta: #E6007E;  /* Action Color */

/* Graustufen */
--vt-gray-90: #2D2D2D;
--vt-gray-70: #5C5C5C;
--vt-gray-50: #8A8A8A;
--vt-gray-30: #B8B8B8;
--vt-gray-10: #E6E6E6;

/* Typografie */
--vt-font-family: 'Inter', sans-serif;

Verwendete Agenten: | Agent | Aufgabe | |-------|---------| | design-implementation-reviewer | Prüft Prototyp gegen Design-Vorgaben |

Output: - 04-prototyp/ Git Repository - Deployable Angular Prototype - PrimeNG Preset mit VisiTrans Tokens - Mock-Daten Fixtures - Live Preview URL

Quality Gate: - [ ] VisiTrans CD Tokens angewendet - [ ] Alle PRD-Features haben Screens - [ ] Responsive Layouts funktionieren - [ ] Deployed und erreichbar

Phase 4: Validate (`/vt-c-pd-4-validate`)¶

Zweck: Usability Testing und Validierung

Aktivitäten: - Testplan erstellen (Agent: usability-test-designer) - Task-Szenarien definieren - Moderator-Skript generieren - Usability Tests durchführen (extern) - Ergebnisse analysieren - Verbesserungen priorisieren - Bei Bedarf Prototyp aktualisieren

Verwendete Agenten: | Agent | Aufgabe | |-------|---------| | usability-test-designer | Erstellt Testpläne und Szenarien |

Output: - Usability Test Plan in 02-Knowledge/04-Dokumente/ - Task-Szenarien - Moderator-Skript - Usability Findings Report - Priorisierte Issue-Liste

Quality Gate: - [ ] Mindestens 5 Usability Tests durchgeführt - [ ] Task Completion Rate ≥ 80% - [ ] Kritische Issues behoben

Automatische Iteration bei Nicht-Bestehen: - Task Completion Rate < 80% → Return zu pd-3-prototype

Phase 5: specs (`/vt-c-pd-5-specs`)¶

Zweck: PRD in implementierungsgroße Feature Briefs aufteilen

Aktivitäten: - PRD Feature Scope analysieren - Abhängigkeiten identifizieren - spec-0 (Project Setup) generieren - spec-N für jedes Feature generieren - PRD Feature-Tabelle FB-Link Spalte aktualisieren

specs Struktur (SpecKit-kompatibel):

# spec-N: [Feature Name]

## Metadata
parent_prd: ../03-PRD/PRD.md
prototype: ../04-prototyp/[feature-folder]/
dependencies: [spec-0-project-setup]
status: draft | approved | implemented
priority: P0 | P1 | P2

## Feature: [Feature Name]
[Kurzbeschreibung]

## User Stories
### Story 1: [Name]
**As a** [persona]
**I want to** [action]
**So that** [benefit]

## Acceptance Criteria
### Funktionale Anforderungen
- [ ] Kriterium 1
- [ ] Kriterium 2

### Nicht-funktionale Anforderungen
- [ ] Performance: [requirement]
- [ ] Security: [requirement]

## Technical Specifications
### Data Model
[From PID constraints]

### API Endpoints
| Method | Endpoint | Description |
|--------|----------|-------------|
| GET | /api/[resource] | [description] |

## Prototype Reference
Location: ../04-prototyp/[feature-folder]/

## Dependencies
### Depends On
- spec-0: Project Setup

### Blocks
- specs-[Y]: [Feature]

Output: - 05-specs/spec-0-project-setup.md - 05-specs/spec-N-[feature].md für jedes Feature - Aktualisierte PRD Feature-Tabelle mit FB-Links

Quality Gate: - [ ] Alle PRD Features haben entsprechende specs - [ ] Acceptance Criteria für jedes specs definiert - [ ] SpecKit-kompatibles Format (YAML Frontmatter) - [ ] Abhängigkeiten zwischen specs gemappt

Phase 6: Handoff (`/vt-c-pd-6-handoff`)¶

Zweck: Übergabepaket für Entwicklung vorbereiten

Voraussetzungen: - Alle vorherigen Quality Gates bestanden - Keine pending Items in Inbox

Aktivitäten: - 06-Handoff/ Verzeichnisstruktur erstellen - README.md mit Quick Links generieren - Handoff-Checklist erstellen - Meeting-Agenda generieren - Development Guide erstellen - Design Journey dokumentieren - Package-Vollständigkeit prüfen

Handoff-Paket Struktur:

06-Handoff/
├── README.md                    # Übergabe-Übersicht
├── handoff-checklist.md         # Verifikations-Checklist
├── meeting-agenda.md            # 60-Minuten Meeting-Agenda
├── development-guide.md         # Quick Start für Entwickler
├── design-journey.md            # Iterationshistorie und Entscheidungen
└── links/
    ├── prd.md                   # Link zu ../03-PRD/PRD.md
    ├── pid.md                   # Link zu ../03-PRD/PID.md
    ├── prototype.md             # Link zu ../04-prototyp/
    └── specs/                # Links zu ../05-specs/*.md

Design Journey Dokument:

Das design-journey.md dokumentiert: - Iterationshistorie (Zeitstrahl aller Iterationen) - Key Decisions (aus .design-state.yaml) - Usability Findings Summary - Eingearbeitetes Stakeholder Feedback - Bekannte Limitierungen - Offene Fragen für Development

Output: - Vollständiges Übergabepaket in 06-Handoff/ - Dokumentierte Design Journey - Geplantes Handoff Meeting

Quality Gate: - [ ] Alle vorherigen Quality Gates bestanden - [ ] Handoff-Paket erstellt - [ ] Meeting-Agenda vorbereitet - [ ] Team-Zugriff erteilt - [ ] Handoff Meeting durchgeführt

4. Die Iterationsschleife¶

Übersicht¶

Der Product Design Workflow ist iterativ, nicht linear. Neue Informationen können jederzeit eintreffen und erfordern möglicherweise einen Rücksprung zu einer früheren Phase.

New Input → /vt-c-pd-inbox-scan → /vt-c-pd-analyze-changes → /vt-c-pd-route-decision
                                                         │
              ┌─────────────────────────────────────────┘
              ▼
    Return to appropriate phase (pd-1 through pd-5)

Die drei Iterationsschleifen-Skills¶

1. `/vt-c-pd-inbox-scan` - Erkennung¶

Zweck: Projekt-Inbox auf neue Items überwachen

Funktionsweise: 1. Lädt Design State aus .design-state.yaml 2. Scannt 00-Inbox/ Ordner nach neuen Dateien seit letztem Scan 3. Klassifiziert Items nach Typ und Dringlichkeit 4. Aktualisiert State File mit pending Items

Item-Klassifizierung:

Muster	Typ	Dringlichkeit
`usability`, `test-result`	usability_test	HIGH
`stakeholder`, `feedback`	stakeholder_feedback	MEDIUM
`competitor`, `market`	market_intel	LOW
`technical`, `feasibility`	tech_constraint	HIGH
`interview`, `transcript`	user_research	MEDIUM
`requirement`, `scope`	scope_change	HIGH

Empfehlung basierend auf Dringlichkeit: - HIGH: Sofort /vt-c-pd-analyze-changes ausführen - MEDIUM: Vor Phasenwechsel verarbeiten - LOW: Im nächsten Iterationsbatch verarbeiten

2. `/vt-c-pd-analyze-changes` - Analyse¶

Zweck: Auswirkungen neuer Informationen analysieren

Funktionsweise: 1. Lädt pending Items aus State 2. Liest und analysiert jedes Dokument 3. Extrahiert Key Information und Severity 4. Mappt auf Impact Matrix 5. Aggregiert Impacts bei mehreren Items 6. Generiert Impact Report mit Optionen

Impact Matrix:

Change Type	PRD Impact	Prototype Impact	specs Impact	Typische Rücksprung-Phase
User Research Findings	HIGH	MEDIUM	MEDIUM	pd-1-research
Stakeholder Feedback (Scope)	HIGH	HIGH	HIGH	pd-2-prd
Stakeholder Feedback (UI)	LOW	HIGH	LOW	pd-3-prototype
Usability Test (kritisch)	LOW	HIGH	LOW	pd-3-prototype
Usability Test (minor)	NONE	MEDIUM	NONE	pd-4-validate (continue)
Technical Feasibility	HIGH	HIGH	HIGH	pd-2-prd
Market/Competitive	MEDIUM	LOW	LOW	pd-1-research

Aggregationsregel: Bei mehreren Items gewinnt die früheste betroffene Phase.

3. `/vt-c-pd-route-decision` - Entscheidung¶

Zweck: Routing-Entscheidung ausführen und State aktualisieren

Optionen: 1. [EMPFOHLEN] Return zu empfohlener Phase - Vollständiger Iterationszyklus - Artifacts werden für Revision markiert

Return zu alternativer Phase
Subset der Issues adressieren
Trade-off dokumentieren
Parallel Tracks
Track A: Quick Fixes → pd-6-handoff
Track B: Größere Änderungen → separate Iteration
Erhöht Komplexität
Continue
Items zu Backlog verschieben
Als bekannte Limitierungen dokumentieren
Weiter zur nächsten Phase

State Update bei Rücksprung:

current_state:
  phase: "{target_phase}"
  status: "in_progress"
  iteration: {n+1}  # Iteration wird inkrementiert

quality_gates:
  {target_phase}:
    passed: false  # Gate wird zurückgesetzt
  {subsequent_phases}:
    passed: false  # Alle nachfolgenden Gates zurücksetzen

artifacts:
  prd:
    version: "{increment if affected}"
    status: "revision_needed"

Automatische Iterations-Trigger¶

Trigger	Erkennungsmethode	Standard-Aktion
Neue Inbox Items	`/vt-c-pd-inbox-scan`	Workflow pausieren, Impact analysieren
Usability Test Failure	pd-4-validate Quality Gate	Return zu pd-3-prototype
PRD Approval Rejection	pd-2-prd Quality Gate	In pd-2-prd bleiben
Prototype CD Violation	pd-3-prototype Validation	In pd-3-prototype bleiben
specs Rejection	pd-5-specs Review	Return zu pd-2 oder pd-3
Stakeholder Scope Change	Inbox Item Type	Return zu pd-2-prd

Inbox-Routing nach Verarbeitung¶

Nachdem Items den vollständigen Iterationszyklus (/vt-c-pd-inbox-scan → /vt-c-pd-analyze-changes → /vt-c-pd-route-decision → Phase-Ausführung) durchlaufen haben, werden sie beim nächsten /vt-c-pd-inbox-scan automatisch aus 00-Inbox/ in Zielordner verschoben:

Dateityp	Zielordner	Grund
Meeting-Transkripte, Input-Dokumente, technische Docs, externe Reports	`02-Knowledge/04-Dokumente/`	Referenzmaterial
Items ohne verwertbaren Inhalt	`00-Inbox/99-alt/`	Archiv

Voraussetzungen für Routing: - Item ist als analyzed: true im State markiert - Item ist noch nicht als processed: true markiert - Datei existiert noch am gespeicherten Pfad

Dieses Muster folgt dem gleichen Prinzip wie /vt-c-inbox-qualify in der Toolkit-Intake-Pipeline: verarbeitete Dateien werden verschoben, nie gelöscht.

Täglicher PM Workflow¶

# Start des Tages - auf neue Inputs prüfen
/vt-c-pd-inbox-scan
# (routet automatisch bereits verarbeitete Items)

# Falls neue Items gefunden
/vt-c-pd-analyze-changes
/vt-c-pd-route-decision

# Mit gerouteter Phase fortfahren
/pd-{N}-{skill}

5. State Management¶

Die `.design-state.yaml` Datei¶

Das State File ist das zentrale Tracking-Element des Workflows. Es wird im Projektstammverzeichnis gespeichert.

Struktur:

# .design-state.yaml - Product Design Workflow State
version: "1.0"
project_name: "[Projektname]"
created_at: "2026-01-28T10:00:00"
last_updated: "2026-01-28T14:30:00"

# Aktuelle Workflow-Position
current_state:
  phase: "pd-4-validate"   # Aktive Phase
  status: "in_progress"    # in_progress | blocked | completed
  iteration: 3             # Aktuelle Iterationsnummer
  started_at: "2026-01-28T12:00:00"

# Artefakt-Versionen (Hash + Timestamp)
artifacts:
  prd:
    path: "03-PRD/PRD.md"
    version: "2.1"
    hash: "abc123def456"
    last_modified: "2026-01-28T11:30:00"
    status: "approved"
  prototype:
    path: "04-prototyp/"
    version: "1.3"
    hash: "xyz789ghi012"
    last_modified: "2026-01-28T12:15:00"
    status: "deployed"
    deploy_url: "https://preview.example.com/project-v1.3"
  specs:
    path: "05-specs/"
    version: "1.0"
    count: 5
    status: "draft"
    files:
      - "spec-0-project-setup.md"
      - "spec-1-feature-a.md"
      - "spec-2-feature-b.md"

# Inbox Monitoring
inbox:
  last_scan: "2026-01-28T14:00:00"
  pending_items:
    - file: "00-Inbox/usability-test-results.pdf"
      detected_at: "2026-01-28T13:45:00"
      type: "usability_test"
      urgency: "HIGH"
      analyzed: false
    - file: "00-Inbox/2026-01-25 stakeholder-feedback.md"
      detected_at: "2026-01-25T10:00:00"
      type: "stakeholder_feedback"
      urgency: "MEDIUM"
      analyzed: true
      processed: true
      routed_to: "02-Knowledge/04-Dokumente/"
      routed_at: "2026-01-28T14:05:00"

# Quality Gates Status
quality_gates:
  pd-0-start:
    passed: true
    passed_at: "2026-01-28T08:00:00"
  pd-1-research:
    passed: true
    passed_at: "2026-01-28T09:00:00"
    criteria:
      personas_defined: true
      interviews_completed: 5
  pd-2-prd:
    passed: true
    passed_at: "2026-01-28T10:30:00"
    criteria:
      all_sections_complete: true
      stakeholder_review: true
  pd-3-prototype:
    passed: true
    passed_at: "2026-01-28T11:00:00"
    criteria:
      cd_compliant: true
      deployed: true
  pd-4-validate:
    passed: false
    criteria:
      task_completion_rate: 0.65  # Target: 0.80

# Iterationshistorie
iterations:
  - number: 1
    started: "2026-01-28T08:00:00"
    ended: "2026-01-28T10:00:00"
    phases_completed: ["pd-0", "pd-1", "pd-2"]
    trigger: "initial"
  - number: 2
    started: "2026-01-28T10:00:00"
    ended: "2026-01-28T12:00:00"
    phases_completed: ["pd-3", "pd-4"]
    trigger: "normal_progression"
  - number: 3
    started: "2026-01-28T12:00:00"
    ended: null  # Aktuelle Iteration
    trigger: "usability_test_failure"
    trigger_details:
      source: "pd-4-validate"
      issue: "Task completion rate below threshold"
      decision: "Return to pd-3-prototype"

# Entscheidungsprotokoll
decisions:
  - timestamp: "2026-01-28T12:00:00"
    phase: "pd-4-validate"
    type: "iteration_triggered"
    reason: "Low task completion rate in usability testing"
    action: "Return to pd-3-prototype"
    impact: "Prototype v1.2 → v1.3"

State File Lifecycle¶

Initialisierung (/vt-c-pd-0-start)
Wird aus Template erstellt
Projekt-Name und Timestamp gesetzt
Erste Iteration gestartet
Update bei Phasenwechsel
Phase wird aktualisiert
Quality Gate wird als passed markiert
Timestamp wird aktualisiert
Update bei Iteration
Iteration wird inkrementiert
Betroffene Quality Gates werden zurückgesetzt
Entscheidung wird protokolliert
Artifacts werden für Revision markiert
Inbox-Item Routing (/vt-c-pd-inbox-scan Step 6)
Items mit analyzed: true werden in Zielordner verschoben
Felder processed: true, routed_to, routed_at werden gesetzt
State wird nach jedem einzelnen Move aktualisiert (Crash-Sicherheit)
Git-Projekte nutzen git mv, OneDrive-Projekte nutzen mv
Abschluss (/vt-c-pd-6-handoff)
Status wird auf "completed" gesetzt
Alle Quality Gates müssen passed sein
Design Journey wird aus State generiert

6. Orchestrator und Agenten¶

Product Design Orchestrator¶

Datei: agents/orchestrators/product-design-orchestrator.md

Zweck: Koordiniert den gesamten Product Design Workflow

Verantwortlichkeiten: - Lädt institutionelles Wissen vor jeder Phase - Stellt sicher, dass Templates konsistent angewendet werden - Trackt Fortschritt durch Phasen - Validiert Handoff-Bereitschaft - Managt Iterationsschleifen

Verwendung: Der Orchestrator wird automatisch aktiv, wenn /pd-* Commands ausgeführt werden.

Sub-Agenten¶

Agent	Zweck	Verwendet in Phase
`interview-script-writer`	Erstellt Interview-Leitfäden	pd-1-research
`interview-analyzer`	Extrahiert Insights aus Transkripten	pd-1-research
`usability-test-designer`	Erstellt Testpläne und Szenarien	pd-4-validate
`design-implementation-reviewer`	Validiert Prototyp gegen Design	pd-3-prototype
`spec-flow-analyzer`	Mappt User Flows, findet Lücken	pd-5-specs

Shared Agents (mit Knowledge Work)¶

Diese Agenten sind in beiden Workflows verfügbar: - interview-script-writer - Auch für Stakeholder-Interviews - interview-analyzer - Auch für allgemeine Research-Analyse - usability-test-designer - Auch für Dokumenten-Usability

7. Skills und Commands¶

Phasen-Skills¶

Command	Skill	Zweck
`/vt-c-pd-0-start`	pd-0-start	Workflow-Übersicht, Projektsetup
`/vt-c-pd-1-research`	pd-1-research	User Research Orchestrierung
`/vt-c-pd-2-prd`	pd-2-prd	PRD-Erstellung
`/vt-c-pd-3-prototype`	pd-3-prototype	Prototyp-Generierung
`/vt-c-pd-4-validate`	pd-4-validate	Usability Testing
`/vt-c-pd-5-specs`	pd-5-specs	specs-Generierung
`/vt-c-pd-6-handoff`	pd-6-handoff	Development Handoff

Iterationsschleifen-Skills¶

Command	Skill	Zweck
`/vt-c-pd-inbox-scan`	pd-inbox-scan	Inbox auf neue Items überwachen
`/vt-c-pd-analyze-changes`	pd-analyze-changes	Impact-Analyse durchführen
`/vt-c-pd-route-decision`	pd-route-decision	Routing-Entscheidung ausführen

Unterstützende Skills¶

Skill	Zweck
`visitrans-design-system`	VisiTrans CD Compliance
`kw-user-test`	User Research Suite

8. Quality Gates¶

Übersicht aller Quality Gates¶

Phase	Quality Gate	Schwellenwert
pd-0-start	Projektordner erstellt	Required
pd-0-start	State File initialisiert	Required
pd-1-research	Interviews durchgeführt	≥ 5
pd-1-research	Personas definiert	Required
pd-2-prd	Alle 12 Sektionen vollständig	Required
pd-2-prd	Stakeholder Sign-off	Required
pd-3-prototype	CD Compliance	100%
pd-3-prototype	Alle Features haben Screens	Required
pd-3-prototype	Deployed	Required
pd-4-validate	Task Completion Rate	≥ 80%
pd-4-validate	Kritische Issues behoben	Required
pd-5-specs	Feature Coverage	100%
pd-5-specs	SpecKit-kompatibles Format	Required
pd-6-handoff	Alle vorherigen Gates passed	Required
pd-6-handoff	Handoff-Paket erstellt	Required
pd-6-handoff	Dev Acknowledgement	Required

Quality Gate Enforcement¶

Gates werden automatisch im State File getrackt
Nicht bestandene Gates blockieren den Phasenwechsel
Bei Nicht-Bestehen wird automatisch Iteration getriggert
Gate-Status wird bei Iteration zurückgesetzt

9. Handoff zum Development Workflow¶

Handoff-Paket Inhalte¶

Dokumentation: | Item | Quelle | Ziel | Zweck | |------|--------|------|-------| | PRD.md | 03-PRD/ | docs/prd/ | Vollständige Anforderungen | | PID.md | 03-PRD/ | docs/prd/ | Tech Stack Constraints | | spec-0 | 05-specs/ | docs/specs/ | Projekt-Setup Requirements | | spec-N | 05-specs/ | docs/specs/ | Feature Briefs | | User Research | 02-Knowledge/ | docs/research/ | Findings, Personas | | Design Journey | 06-Handoff/ | docs/ | Iterationshistorie |

Code: | Item | Quelle | Wiederverwendung | |------|--------|------------------| | Angular Components | 04-prototyp/src/app/shared/components/ | 95% | | PrimeNG Preset | 04-prototyp/src/app/core/theme/vt-preset.ts | 100% | | Design Tokens | 04-prototyp/src/styles/ | 100% | | Mock Data | 04-prototyp/src/mocks/ | 0% (durch APIs ersetzt) |

Development Workflow Integration¶

Nach dem Handoff führt das Development Team aus:

Projekt-Setup (spec-0):
```
/vt-c-0-start → /vt-c-1-bootstrap
```

Feature-Implementierung (spec-1 bis N):

cp spec-N.md specs/[N]-feature/spec.md
/vt-c-2-plan → /vt-c-3-build → /vt-c-4-review → /vt-c-5-finalize

Erfolgsmetriken¶

Metrik	Ziel
Fragen pro specs	< 5 Klärungen
Code-Wiederverwendung	> 90% Prototype-Komponenten
Erstes Feature	Shipped innerhalb 1 Sprint
Design-Treue	95% Match zum Prototyp

10. Best Practices¶

Für Product Manager¶

Täglich Inbox scannen
Starten Sie jeden Tag mit /vt-c-pd-inbox-scan
Verarbeiten Sie HIGH-Priority Items sofort
Quality Gates ernst nehmen
Nicht überspringen, auch wenn es Zeit kostet
Gates sind Investitionen in Qualität
Entscheidungen dokumentieren
Nutzen Sie das State File aktiv
Dokumentieren Sie das "Warum" hinter Entscheidungen
Prototypen als Code behandeln
Sauberer Code im Prototyp = weniger Arbeit für Dev
95% Wiederverwendung ist das Ziel

Für Usability Tests¶

Mindestens 5 Tests für statistisch relevante Ergebnisse
80% Task Completion Rate als Mindeststandard
Kritische Issues sofort beheben, nicht deferren
Findings dokumentieren für Design Journey

Für Handoff¶

Handoff Meeting planen (60 Minuten)
PM verfügbar in ersten 2 Wochen für intensive Unterstützung
Slack-Kanal für tägliche Fragen einrichten
Wöchentlicher Sync für Status und Blocker

11. Glossar¶

Begriff	Definition
PRD	Product Requirements Document - Vollständige Produktanforderungen
PID	Project Implementation Document - Technische Constraints und Stack
specs	Feature Brief - Implementierungsgroße Spezifikation, SpecKit-kompatibel
SpecKit	Tool für Spec-getriebene Entwicklung, liest specs
Quality Gate	Kriterien, die erfüllt sein müssen, bevor Phase gewechselt wird
Iteration	Ein Durchlauf durch (Teil-)Phasen des Workflows
Design State	`.design-state.yaml` - Zentrales Tracking-File
Inbox	`00-Inbox/` - Eingangsordner für neue Informationen
VisiTrans CD	Corporate Design System von VisiTrans
Handoff	Übergabe von Product Design an Development

Anhang A: Dateistruktur¶

~/.claude/plugins/company-claude-toolkit/plugins/core-standards/
├── skills/
│   ├── pd-0-start/SKILL.md
│   ├── pd-1-research/SKILL.md
│   ├── pd-2-prd/SKILL.md
│   ├── pd-3-prototype/SKILL.md
│   ├── pd-4-validate/SKILL.md
│   ├── pd-5-specs/SKILL.md
│   ├── pd-6-handoff/SKILL.md
│   ├── pd-inbox-scan/
│   │   ├── SKILL.md
│   │   └── references/impact-matrix.md
│   ├── pd-analyze-changes/SKILL.md
│   └── pd-route-decision/SKILL.md
├── commands/
│   ├── pd-0-start.md
│   ├── pd-1-research.md
│   ├── pd-2-prd.md
│   ├── pd-3-prototype.md
│   ├── pd-4-validate.md
│   ├── pd-5-specs.md
│   ├── pd-6-handoff.md
│   ├── pd-inbox-scan.md
│   ├── pd-analyze-changes.md
│   └── pd-route-decision.md
├── agents/
│   ├── orchestrators/product-design-orchestrator.md
│   └── research/
│       ├── interview-script-writer.md
│       ├── interview-analyzer.md
│       └── usability-test-designer.md
├── templates/
│   └── .design-state-template.yaml
└── docs/
    └── PRODUCT-DESIGN-WORKFLOW.md  ← Diese Datei

Anhang B: Quick Reference Card¶

┌─────────────────────────────────────────────────────────────────┐
│               PRODUCT DESIGN WORKFLOW - QUICK REFERENCE          │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  PHASEN:                                                         │
│  /vt-c-pd-0-start      → Setup & Übersicht                           │
│  /vt-c-pd-1-research   → User Research & Personas                    │
│  /vt-c-pd-2-prd        → PRD erstellen (12 Sektionen)                │
│  /vt-c-pd-3-prototype  → Prototyp (VisiTrans CD)                     │
│  /vt-c-pd-4-validate   → Usability Testing (≥80%)                    │
│  /vt-c-pd-5-specs   → Feature Briefs                              │
│  /vt-c-pd-6-handoff    → Übergabe an Dev                             │
│                                                                  │
│  ITERATION:                                                      │
│  /vt-c-pd-inbox-scan       → Neue Items erkennen                     │
│  /vt-c-pd-analyze-changes  → Impact analysieren                      │
│  /vt-c-pd-route-decision   → Rücksprung-Phase wählen                 │
│                                                                  │
│  STATE FILE: .design-state.yaml                                  │
│  INBOX: 00-Inbox/                                                │
│                                                                  │
│  DAILY: /vt-c-pd-inbox-scan → /vt-c-pd-analyze-changes → /pd-route-dec.   │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Dokumentation erstellt: Januar 2026 VisiTrans Engineering Team