CP Registry

Wissensbasis

Designer

Aufgaben-orientierte Wissensbasis für Designer in der Digital-Unit. Token-Praxis, Handoff, Brand-Override — für alle Kundenprojekte.

12 Aufgaben in dieser Wissensbasis
  1. Design-Rolle im 9-Phasen-Wasserfall
  2. Farben auf Tokens mappen
  3. Abstände auf Token-Skala snappen
  4. Schriftskala für alle Breakpoints
  5. Variante oder Token — binäre Entscheidung
  6. Brand-Update ohne Component-Fork
  7. Light und Dark ohne Doppelarbeit
  8. Figma-Handoff-Checkliste einhalten
  9. States und Focus-Ring liefern
  10. Mockups mit echten deutschen Begriffen
  11. Kontrast und Touch-Target in Figma prüfen
  12. Mockup sauber einreichen
wichtig

Design-Rolle im 9-Phasen-Wasserfall

Wer die Phase-Grenzen nicht kennt, doppelt Termine, blockiert Frontend oder kassiert Rueckweisungen beim Launch.

Problem: Design ist bei uns im Wasserfall fest verortet — Phase 1 (Konzept), Phase 2 (Mockups), Phase 3 (Abstimmung mit FE). Wer außerhalb dieser Fenster liefert, wirft den Zeitplan für alle anderen Disziplinen um.

Mockups außerhalb von Phase 2 bedeuten: Frontend muss Zeitplanung neu aufsetzen, Backend wartet, Vorlauf brennt.

  1. Phase 1 zuhören

    In der Konzeptionsphase sammelst du visuelle Anker und offene Gestaltungsfragen — Marc-Andre und Hendrik treffen die Weichenstellungen, deine Notizen fuettern Phase 2.

  2. Phase 2 liefern

    Mockups entstehen jetzt — gemeinsam mit Lina (Motion-States) und Hendrik (Screen-Entscheidungen). Kein Mockup ohne Briefing aus Phase 1.

  3. Phase 3 abstimmen

    Du klärst innerhalb eines Tages mit Marc-Andre: Token-Kompatibilität, lange Strings, Touch-Targets. Erst nach Freigabe ist das Mockup final.

  4. Phase 7 erreichbar bleiben

    In der TYPO3-Übernahme bist du nicht aktiv — aber erreichbar. Unklarheiten kommen als Rueckfrage, nie als stille Annahme des Backends.

  5. Routing über Awork

    Alle Anfragen laufen über Renana in Awork. Direkt-Pings an Devs umgehen die Planung und sind für das Team unsichtbar.

Beispiel

Klima-Werk Pillar-Page

Hendrik in Phase 1 dabei, Lina baut in Phase 2 die Card-Variante mit Motion-States, Marc-Andre prüft in Phase 3 Token-Mappings. Phase 4 startet am nächsten Tag ohne Rueckfrage.

Gegenbeispiel

OePNV-Tagesticket-Card

Designer überspringt Phase 3. Brandon baut drei Tage. QS findet Token-Inkompatibilitäten — Neustart, Vorlauf weg.

Weiter: 9-Phasen-Workflow · Design-Intro

Vertiefung

Unsere Astro-Templates sind Style-Guide und Vorlage. Das Backend übersetzt sie 1:1 in Fluid-Templates für TYPO3 — kein Headless-System. Du designst für einen Style-Guide, der das Backend bedient. Konsequenz: Tokens sind verbindlich, weil Backend sie als CSS-Variablen übernimmt. Inline-Werte landen nicht im Fluid-Template.

kritisch

Farben auf Tokens mappen

Wer Farben aus dem Hex-Picker nimmt statt von Tokens, laehmt jeden Brand-Update und zwingt Frontend zu OKLCH-Schätzungen.

Problem: Farben mit Hex-Pickern zu wählen und nicht auf Tokens zu mappen, zwingt Frontend bei jeder Farbe zur Nachfrage — oder zur OKLCH-Eigenberechnung, die daneben liegt.

Inkonsistenz im Build, Brand-Updates später unmoglich, jeder Handoff produziert eine Rueckfrage-Schleife.

  1. Token prüfen

    Oeffne die Token-Liste (/design/tokens) und prüfe, ob die Farbe schon existiert (z.B. --color-brand-primary, --color-brand-surface).

  2. Vorhandenes nutzen

    Wenn ja: nimm den Token — auch wenn er 5 % daneben liegt. Marc-Andre bestätigt im Pre-Review, ob das ok ist.

  3. Neu anlegen

    Wenn kein Token passt: lege ihn in Figma als Variable mit OKLCH-Notation an und kennzeichne ihn mit "neu — Marc-Andre Pre-Review & Token-Anlage".

  4. Handoff sauber

    Jedes Farbfeld im Handoff trägt den Token-Namen, nicht den Hex-Wert. Bei Brand-Override: ausschließlich Tokens, keine Inline-Farben.

Beispiel

Förderhöhen-Vergleichs-Card

Lina prüft --color-success (OKLCH 65% 0.13 145) — passt. Im Handoff steht "Background: var(--color-success-soft)". Frontend baut ohne Nachfrage.

Gegenbeispiel

E-Ladesäulen-Karte

Designer wählt #2D7FF9 per Color-Picker. Frontend mappt auf --color-brand-primary (OKLCH 55% 0.18 245) — sichtbar anders. Diskrepanz fällt erst im Pre-Launch auf.

Weiter: Tokens · Theme-Generator

Vertiefung

Wir notieren Farben in OKLCH (Lightness, Chroma, Hue). Vorteil: Lightness ist wahrnehmungs-linear, du kannst Light/Dark-Varianten durch reine L-Änderung ableiten. Hex ist im Handoff als Referenz erlaubt, aber das verbindliche Format ist OKLCH.

wichtig

Abstände auf Token-Skala snappen

Jeder Pixel neben der Skala kostet Frontend Messzeit und produziert eine Rueckfrage.

Problem: 23px hier, 19px dort, 27px woanders — Frontend muss jedes Spacing einzeln nachmessen, in den nächsten Token snappen und dich fragen, ob das so ok ist.

Stunden Verlust pro Mockup, plus das Ergebnis weicht trotzdem von deiner Intention ab.

  1. Skala kennen

    Snap alle Spacings auf: 4, 8, 12, 16, 24, 32, 48, 64 px (spacing-xs bis spacing-3xl). Kein Wert außerhalb der Skala.

  2. Auto-Layout erzwingen

    In Figma: Auto-Layout mit Spacing-Variablen, kein freies Padding.

  3. Snappen, nicht rechtfertigen

    Wenn 23px besser aussieht als 24px — snap auf 24. Ein neues Token brauchst du in 99 % der Fälle nicht.

  4. Handoff prüfen

    Spacing-Werte als Token-Namen (spacing-md), nie als Pixel. Vor Abgabe: scroll durch den Frame, nicht-runde Werte sind verdächtig.

Beispiel

Förder-Antrags-Card

Hendrik baut Auto-Layout mit Padding spacing-md (16px), Gap spacing-sm (8px). Handoff: jeder Wert ein Token. Frontend übernimmt 1:1.

Gegenbeispiel

OePNV-Störungsmeldungs-Card

14px, 19px, 23px Padding gemischt. Frontend snapped selbst, fragt für jeden Mismatch zurück — 4 Stunden für eine Card.

Weiter: Tokens

Vertiefung

Die 4px-Skala ist nicht frei waehlbar. Sie ist Ergebnis der Component-Library-Hygiene: jedes neue Token erhöht die Komplexität linear. Wenn du wirklich ein neues Spacing brauchst, hol Marc-Andre dazu — es wandert in die Token-Liste, nicht in einen einzelnen Mockup.

wichtig

Schriftskala für alle Breakpoints

Was auf 1440px gross und luftig wirkt, bricht auf 320px ohne clamp() in fünf Zeilen.

Problem: Mockup auf 1440px sieht gut aus. Auf 320px bricht die H1 in fünf Zeilen, der Body wird unleserlich, Karten überlappen. Frontend "fixt" das spontan und trifft nicht deine Intention.

Iterationsschleifen in QS, weil Mobile-Verhalten nie abgestimmt wurde.

  1. Fluide Tokens nutzen

    Nutze die fluide Skala aus den Tokens (font-size-h1 … font-size-body) — sie skaliert via clamp() über den Viewport, kein Breakpoint-Sprung.

  2. Zwei Breakpoints mockuppen

    Pflicht: 1440px (Desktop) UND 320px (Mobile). Gleiche Schrift-Tokens, nicht zwei separate Skalen.

  3. Line-height dokumentieren

    Line-height pro Token separat dokumentieren (1.2 für Headlines, 1.5-1.6 für Body) — nie als Pixel.

  4. Zeilenlänge prüfen

    Maximale Body-Zeilenlänge: 60-75 Zeichen. Deutsche Worte sind lang — eher Richtung 60 planen.

Beispiel

Förderprogramm-Pillar-Page

Marc-Andre setzt H1 auf --font-size-h1 (clamp 1.875rem-2.5rem). Auf 320px lesbar (zwei Zeilen), auf 1440px wirkungsvoll. Kein Frontend-Eingriff nötig.

Gegenbeispiel

Mobilitätstag-Eventseite

H1 mit fester Größe 48px. Auf 320px bricht "Mobilitätstag" in vier Zeilen. Frontend reduziert auf 28px — drei Iterationen, weil der Designer das nicht wollte.

Weiter: Tokens

Vertiefung

Unsere Schrift-Tokens nutzen clamp(min, preferred, max). Zwischen Smartphone und Desktop skaliert die Schrift kontinuierlich — keine Breakpoint-Sprünge. Du musst nichts berechnen, du nutzt das Token.

kritisch

Variante oder Token — binäre Entscheidung

Die falsche Antwort auf diese Frage kostet Frontend Tage Arbeit in die falsche Richtung.

Problem: Du sollst einen "roten Notfall-Button" liefern. Ist das eine neue Component-Variante (Code-Änderung) oder reicht ein Token-Override? Wer das nicht klärt, laesst Frontend raten.

Frontend baut die falsche Richtung — entweder ein unnötig neuer Component, oder Token-Override der keine State-Logik hat.

  1. Frage 1: nur Optik?

    Aenderst du nur Farbe, Spacing oder Schrift? Dann Token-Override — kein neuer Code nötig.

  2. Frage 2: Struktur oder States?

    Aenderst du Layout, Struktur, States oder fuegst Sub-Elemente hinzu? Dann neue Variante — das ist Code.

  3. Frage 3: nur Verhalten?

    Aenderst du nur Verhalten (z.B. Button mit Icon vs. ohne)? Meistens Variant-Prop, kein neuer Component.

  4. Im Zweifel: Marc-Andre vorher

    Frag vor dem Mockup, nicht nach dem Mockup. Im Handoff explizit markieren: "Token-Override" oder "neue Variante".

Beispiel

Notfall-Button OePNV

Gleiche Form, gleiches Padding, andere Farbe — Token-Override: --color-brand-primary im Brand-Override-CSS auf Notfall-Rot. Kein Component-Fork.

Gegenbeispiel

Förder-Card mit Status-Badge

Card mit zusätzlichem Antragsstatus-Badge oben rechts und Progressbar unten. Das ist KEINE Token-Sache — neue Variante "Card with Status". Per Token gelöst hat Frontend keine Chance.

Weiter: Tokens

Vertiefung

Jede neue Variante kostet langfristig: Tests, Dokumentation, Pflege. Wenn drei Mockups drei Varianten verlangen, frag dich, ob die drei Probleme in einer Variante mit Props lebbar sind. Frontend hilft bei der Abwägung — wenn du es vor dem Final-Mockup ansprichst.

wichtig

Brand-Update ohne Component-Fork

Wer für ein Sub-Brand Components in Figma dupliziert, zwingt Frontend zum Code-Fork — und jeden Bugfix zweimal.

Problem: Wenn du für ein neues Sub-Projekt Components in Figma duplizierst (statt Variable-Modes), muss Frontend sie im Code forken — und jede Component-Änderung muss zweimal gepflegt werden.

Drei Monate später: ein Bugfix muss zweimal gemerged werden. Brand-Divergenz schleicht sich ein.

  1. Brand-Override anlegen

    Erstelle ein Brand-Override-Dokument (CSS-Datei brand-<projekt>.css) — Inhalt: nur Token-Ueberschreibungen, kein Component-Code.

  2. Figma Variable-Modes

    In Figma: Variable-Modes für Brand (Default, Klima-Werk, Mobil-NRW). Kein Component-Duplikat.

  3. Nur Delta liefern

    Im Handoff: nur die Token-Liste, die anders ist. Marc-Andre prüft Kontraste mit den neuen Tokens.

  4. Test: drei Brands, ein Component

    Frontend zieht das Brand-CSS via data-theme-Attribut. Gleicher Component, drei Brands, kein Code-Fork.

Beispiel

Klima-Werk + Mobil-NRW

Beide teilen dieselbe Förder-Card-Component. Brand-Override setzt nur --color-brand-primary und --color-brand-accent. Frontend hat eine Component, zwei CSS-Dateien.

Gegenbeispiel

Förder-Card-MobilNRW

Designer dupliziert Förder-Card in Figma als "Förder-Card-MobilNRW" mit minimal anderen Farben. Frontend forked den Component. Bugfix muss später zweimal gemerged werden.

Weiter: Theme-Generator · Tokens

Vertiefung

Brand = identitätsstiftende Farben/Logo/Typo. Theme = strukturelle Variante. Mode = Light/Dark. Diese drei Achsen sind unabhängig und werden über Tokens kombiniert. Wenn dein Mockup eine Achse verschiebt, weisst du, welcher Pfad: Brand-Override, Theme-Änderung (Phase 1) oder Light/Dark.

wissenswert

Light und Dark ohne Doppelarbeit

Zwei getrennte Mockups verdoppeln nicht nur die Arbeit — sie produzieren Inkonsistenzen, die sich bei Brand-Updates raachen.

Problem: Wenn du beide Modes als getrennte Mockups baust, verdoppelt sich die Arbeit und Inkonsistenzen schleichen sich ein. Wenn du nur Light baust, erfindet Frontend Dark.

Beim nächsten Brand-Update weichen Light und Dark voneinander ab, weil sie nie Token-synchron waren.

  1. Semantische Tokens

    Nutze semantische Tokens (--color-brand-surface, --color-brand-foreground, --color-brand-muted) statt rohe Farb-Tokens.

  2. Variable-Mode Dark

    Lege in Figma einen Variable-Mode "Dark" an, der nur die Token-Werte umdreht — gleiche Components, gleiche Strukturen.

  3. Kein reines Schwarz

    Im Dark-Mode nie #000 — das erzeugt Halation. Stattdessen oklch(15% 0.01 260) oder ähnlich.

  4. Beide Modes prüfen

    WCAG-AA-Kontraste in Light und Dark prüfen. Im Handoff: ein Mockup, Mode-Switch zeigen — nicht zwei Frames.

Beispiel

OePNV-Tagesticket-Card

Nutzt --color-brand-surface als Background. Light: oklch(98% 0.005 260). Dark: oklch(18% 0.01 260). Gleicher Component, ein Token-Switch — kein neues Mockup.

Gegenbeispiel

Förder-Card Hex-Mode

Designer baut Light und Dark als zwei separate Frames mit Hex-Werten. Beim Brand-Update: drei Token-Drift-Stellen, Dark hat sich von Light-Logik entfernt.

Weiter: Dark/Light · Tokens

Vertiefung

"color-blue-500" ist ein roher Token. "color-brand-primary" ist semantisch. Im Dark-Mode kann "color-brand-primary" zu einem helleren Blau werden, ohne dass dein Mockup etwas davon merkt. Wer in Figma direkt "color-blue-500" nutzt, verliert diese Mode-Fähigkeit.

kritisch

Figma-Handoff-Checkliste einhalten

Ein Handoff ohne Checkliste produziert garantiert Rueckfrage-Pingpong oder stille Fehl-Implementierung.

Problem: Frontend bekommt einen Figma-Frame und muss raten: welche Component, neue Variante oder Token-Override, welche Tokens, wie verhält sich das bei langem Text.

Rueckfragen-Pingpong oder freie Erfindung von States, Mobile-Verhalten und Textvarianten — alles in QS korrigiert.

  1. Prüfpunkt 1: Component-Name

    Name passend zur CP-Registry angeben (z.B. Card, Button, Förder-Card falls neu).

  2. Prüfpunkt 2: Token-Bezug

    Pro Element: Farb-Token, Spacing-Token, Schrift-Token. Kein Hex, kein Pixel ohne Token-Name.

  3. Prüfpunkt 3: States als Frames

    Hover, Focus, Active, Disabled als eigene Frames nebeneinander — nicht als Notizen am Rand.

  4. Prüfpunkt 4: Mobile + Stress-Text

    Mobile-Variante bei min. 320px. Laengster realer deutscher Begriff im Mockup, kein Lorem.

  5. Prüfpunkt 5: Markierung

    "Wiederverwendete Component" / "neue Variante" / "Token-Override" — Frontend braucht das explizit. Cross-Link zu CP-Registry bei existierenden Components.

Beispiel

Förderhöhen-Vergleichs-Card

Lina liefert alle vier States, 320px-Variante, "Energieeffizienz-Förderprogramm-Antrag" als Stress-Wort, Tokens auf jedem Element, Markierung "neue Variante: Card with Compare". Brandon baut ohne Rueckfrage in zwei Tagen.

Gegenbeispiel

E-Ladesäulen-Karte (nur Default)

Nur Default-State, keine Mobile-Variante, Lorem-Text. Brandon erfindet Hover (falscher Hue), erfindet Mobile (falsches Layout). Drei Iterationen in QS.

Weiter: Figma-Workflow

Vertiefung

Figma Dev-Mode zeigt Spec-Werte — nutze ihn. Erganeze aber die Punkte, die er nicht von selbst weiß: Component-Name in CP-Registry, Markierung neu/wiederverwendet, Stress-Strings. Dev-Mode allein reicht nicht.

kritisch

States und Focus-Ring liefern

Wer nur den Default-State liefert, zwingt Frontend zur Erfindung — und verstosst gegen die BFSG-Pflicht für sichtbares Focus.

Problem: Mockup zeigt Default-State. Frontend muss Hover, Focus und Active selbst erfinden und trifft nicht deine Intention. Focus-Ring weglassen ist eine gesetzliche BFSG-Verletzung.

In QS fallen State-Fehler auf, drei Iterationen — und bei BFSG-Prüfung ist kein Tastatur-Focus vorhanden.

  1. Vier States Pflicht

    Pro interaktivem Element: Default, Hover, Focus, Active. Bei Buttons zusätzlich Disabled.

  2. States als Frames

    States als eigene Frames in Figma, nebeneinander, klar beschriftet — nicht als Notiz.

  3. Token pro State

    Token-Bezug pro State (Hover = --color-brand-primary-hover, ein Lightness-Schritt heller; Focus = --color-focus als 2px Outline).

  4. Focus-Ring nie entfernen

    Focus-Ring ist BFSG-Pflicht. Kein outline: none ohne sichtbaren Replacement. Auch wenn er im Mockup stört — er bleibt.

Beispiel

Förder-Antrag-Button

Lina liefert vier Frames: Default, Hover (+5% L), Focus (2px solid --color-focus), Active (-5% L). Frontend baut korrekt in 30 Minuten.

Gegenbeispiel

OePNV-Buchen-Button

Nur Default geliefert. Brandon erfindet Hover als "dunkler" — trifft anderen Hue. Lina korrigiert in QS.

Weiter: Design-Intro

Vertiefung

BFSG schreibt sichtbares Tastatur-Focus vor. Im Mockup immer mit Focus-State liefern. Ein 2px Outline mit Brand-Farbe-Kontrast reicht meistens. Den Focus-Ring zu "für den Designer entfernen" ist verboten — auch wenn er störend wirkt.

wissenswert

Mockups mit echten deutschen Begriffen

Englisches Lorem ist 30 % kuerzer als deutsche Wirklichkeit — Förder-Mockups brechen garantiert.

Problem: Du baust mit "Subsidies", der echte Begriff ist "Förderprogramm" oder "Energieeffizienz-Förderprogramm-Antrag". Das Mockup sieht gut aus, der Build bricht.

Frontend fixt Mobile-Zeilenbrüche spontan ohne deine Intention. Neue Iteration, weil das Ergebnis nicht passt.

  1. Nie Lorem

    Echte deutsche Begriffe — und zwar die laengsten realistischen, nicht die schönsten.

  2. Stress-Frame pflicht

    Pro Mockup mindestens ein Frame mit "Stress-Text": laengstes Wort, laengster Satz.

  3. 320px prüfen

    Bricht die Headline in 4+ Zeilen? Bricht das Button-Label? Wenn ja, Layout anpassen bevor Handoff.

  4. Handoff-Hinweis

    Laengstes Wort als Test-Hinweis im Handoff dokumentieren, damit Frontend weiß, womit es testen soll.

Beispiel

"Energieeffizienz-Förderprogramm-Antragsformular"

Hendrik testet mit diesem Stress-Wort. Card bricht auf 320px — er macht das Title-Label zweizeilig. Frontend übernimmt ohne Rueckfrage.

Gegenbeispiel

OePNV-Störungsmeldungs-Card

"Lorem ipsum dolor" im Mockup. In Realität: "Vorübergehende Streckenstillegung wegen Bauarbeiten an der Oberleitung im Bereich Hauptbahnhof bis voraussichtlich 18.07." Card sprengt das Layout.

Weiter: Glossar

Vertiefung

CSS hyphens: auto mit lang="de" auf dem HTML-Tag bricht lange Worte sauber. Frontend setzt das default auf Body-Text. Du musst es im Mockup nicht zeichnen — aber wissen, dass es passiert.

kritisch

Kontrast und Touch-Target in Figma prüfen

Kontrast- oder Touch-Maengel, die erst in QS auffallen, kosten Tage statt Minuten — und sind BFSG-Pflicht.

Problem: Wenn Kontraste oder Touch-Targets erst in QS auffallen, ist das Mockup schon final und Frontend hat schon gebaut.

Redesign-Kosten statt Korrektur in Figma. BFSG-Verstoß wenn unbehoben: juristisches Risiko für den Kunden.

  1. Kontrast prüfen

    WCAG-AA: 4.5:1 für Body, 3:1 für Headlines/große Schrift. Figma-Plugin nutzen (Stark, Able oder "Contrast").

  2. Touch-Target prüfen

    Min. 44x44px (WCAG 2.2). Prüfe mit Spacing-Overlay in Figma.

  3. Beide Modes

    Kontraste in Light und Dark prüfen — beide müssen AA erreichen. Brand-Override-Theme separat prüfen, weil Tokens den Kontrast ändern.

  4. Handoff dokumentieren

    Kontrast-Werte im Handoff explizit angeben (z.B. "Body auf Surface: 5.2:1 — AA"). Marc-Andre gibt frei.

Beispiel

Förder-Antrag-Button

Hendrik prüft: Text auf Primary = 6.1:1 (AA+), Touch-Target 48x48px, Focus-Ring im Dark-Mode 4.8:1 (AA). Im Handoff steht das explizit. Marc-Andre gibt frei.

Gegenbeispiel

OePNV-Filter-Pill

Hellgraue Schrift auf hellem Background — sieht dezent aus, liegt bei 2.8:1. In QS erkannt, Designer muss neu nachfärben, Frontend baut um.

Weiter: Glossar (WCAG, BFSG)

Vertiefung

BFSG verlangt WCAG 2.2 AA für öffentliche Web-Anwendungen. Das schließt Touch-Targets (44x44), Focus-Visibility und Drag-Alternativen ein. Du designst nicht für einen Standard, sondern für eine gesetzliche Pflicht — Verstöße können Bussgelder produzieren.

wichtig

Mockup sauber einreichen

Ein Mockup ohne Selbst-Pre-Review und Awork-Ticket produziert eine Woche Klärungsaufwand statt eines Tages Review.

Problem: Du reichst ein Mockup ein, eine Woche später kommen 12 Kommentare zurück — weil Checkliste-Punkte fehlten, die du haettest selbst prüfen können.

Phase 3 dauert dreimal so lang wie geplant. Phase 4 startet versetzt, Vorlauf brennt weg.

  1. Selbst-Pre-Review

    Gehe alle Punkte der vorigen Aufgaben durch: Tokens, States, Mobile, Stress-Text, Kontraste. Wenn ein Punkt fehlt, nicht einreichen.

  2. Awork-Ticket

    Renana ein Ticket setzen ("Designfreigabe Phase 3 — Mockup <name>") mit Figma-Link. Kein Direkt-Ping auf Teams ohne Ticket.

  3. Delta-Liste im Ticket

    Im Ticket: Liste der NEUEN Components, Varianten und Tokens. Was wiederverwendet wurde, kommt nicht ins Ticket.

  4. Iteration sauber versionieren

    Bei Änderungs-Wünschen: neue Iteration mit Versions-Tag in Figma (v2-postReview), Ticket aktualisiert. Nicht im Chat diskutieren.

Beispiel

Förderprogramm-Pillar-Page

Lina reicht mit Awork-Ticket ein: "1 neue Variante: Card with Compare; 0 neue Tokens; Brand: Klima-Werk-Default." Marc-Andre: 30-Minuten-Review, 2 Anmerkungen. Lina fixt am selben Tag. Phase 3 in 1.5 Tagen.

Gegenbeispiel

Teams-Ping ohne Ticket

Figma-Link via Teams ohne Ticket, ohne Liste, gemischte Versionen im selben Frame. Marc-Andre weiß nicht, was final ist. 3 Tage Klärung, kein Review möglich.

Weiter: Spielregeln (Awork) · Zusammenarbeit (Phase 3)

Vertiefung

Awork ist das verbindliche Routing — alle Tickets über Renana. Teams ist informell. Versionierung in Figma: nutze Branches oder explizite Versions-Tags. Niemals den Default-Frame überschreiben, ohne dass die alte Version greifbar bleibt.

Weiter im Material: 9-Phasen-Workflow · Zusammenarbeit · Glossar