Entwurf. Dieser Bereich ist als Entwurf gekennzeichnet. Markenkern und Rahmen sind bereits CEO-freigegeben; die hier beschriebenen Regeln sind in lirai-www als Astro-Komponenten bereits umgesetzt. Der Status dieses Dokuments selbst bleibt bis zur finalen Bestätigung Entwurf.

Eigenständiger Bereich des Corporate Design Manuals für den Webauftritt (Marketing-Startseite, Funktionsseiten, Blog, Dokumentationsserver, künftige Landingpages). Anders als technische Dokumente oder Unternehmenskommunikation (siehe §0) ist die Webseite für die meisten Interessent:innen der erste Kontaktpunkt — sie muss die Positionierung von LirAI unmittelbar erlebbar machen, nicht nur behaupten.

Markenkern für die Webseite (CEO-Freigabe, LIR-2886):

1. Sicher und professionell nach deutschem Sicherheitsstandard — Verlässlichkeit, Datenschutz, Hosting in Deutschland, nachvollziehbare Verarbeitung. Das Vertrauen zeigt sich gestalterisch über Klarheit, Ruhe und Transparenz — nicht über Sicherheits-Symbolik oder Alarmsprache.
2. Einfach und maximal unterstützend in der Belegbearbeitung — der Nutzen soll ohne Erklärung erfassbar sein. Die Seite selbst ist der Beweis: Wenn die Webseite einfach zu bedienen ist, wirkt auch das Produkt einfach.

Gestalterische Kernaufgabe (LIR-2886): Diese beiden Pole stehen in einem Spannungsverhältnis — Seriosität tendiert zu Dichte und Zurückhaltung, Einfachheit zu Leichtigkeit und Reduktion. Die in diesem Dokument getroffenen Entscheidungen (insbesondere §4–§7) lösen dieses Spannungsfeld zugunsten von Reduktion mit klaren Vertrauensankern auf: wenige, gezielt platzierte Vertrauenselemente (§10) statt flächendeckender Sicherheits-Rhetorik.

0. Geltungsbereich und Abgrenzung

Dieser Bereich ergänzt die bestehenden CD-Dokumente und dupliziert keines:

Reichweite (beantwortet die in LIR-2886 offene Grundsatzfrage): Dieser Bereich gilt für den gesamten Webauftritt in lirai-www — Marketing-Startseite, Funktionsseiten, /blog, /docs (Dokumentationsserver, siehe LIR-2868-Entscheidung), Rechtstexte und künftige Landingpages. Alle liegen im selben Astro-Projekt (siehe §2) und teilen sich damit sinnvollerweise eine gemeinsame gestalterische Basis statt formatgebundener Sonderregeln.

1. Zuständigkeit und Freigabeweg

Konflikte zwischen Gestaltung und technischer Umsetzbarkeit eskaliert GUIDeveloper an MarketingLead; ungeklärte Grundsatzfragen (z. B. Plattformwechsel wie in §2) eskaliert MarketingLead an CEO. Die in LIR-2886 offen gelassene Frage „Wer gibt gestalterische Entscheidungen frei, solange der Marketingverantwortliche nicht besetzt ist“ erledigt sich durch die Besetzung dieser Rolle — MarketingLead gibt ab sofort direkt frei.

2. Plattform und Umsetzungsvorgaben — Astro statt WordPress/Elementor

LIR-2886 sah als offene Grundsatzfrage „Umfang: Reines Regelwerk oder Regelwerk plus umgesetzte Elementor-Vorlagen“ vor und nannte als Umsetzungsvorgabe „Anwendung in WordPress/Elementor“. Diese Prämisse ist überholt: Per Kommentar vom 2026-07-26 auf LIR-2895 wurde bestätigt, dass der Webauftritt künftig Astro-nativ umgesetzt wird (Referenz: astro.lirai.dev) — konsistent mit der bereits getroffenen CEO-Entscheidung zur Blog-Plattform (LIR-2891: Astro Content Collection in lirai-www statt WordPress) und zur Dokumentationsserver-Integration (LIR-2868: /docs in lirai-www).

Konsequenz für dieses Dokument: Die hier definierten Gestaltungsregeln (§4–§10) sind medienneutral formuliert und bleiben durch den Plattformwechsel unverändert gültig — sie gelten für jedes Trägermedium. Nur der ursprünglich vorgesehene Begriff „Elementor-Vorlagen“ ist gegenstandslos:

• Kein WordPress/Elementor-Zugang wird für dieses Dokument benötigt oder vorausgesetzt.
• Die technische Umsetzung als wiederverwendbare Astro-Komponenten und globale Styles (Layout-Komponente, Farb-/Typografie-Tokens, Buttons/Formulare/Karten/Hinweisboxen als Komponenten) ist Aufgabe von GUIDeveloper im Scope lirai-www — analog zur bereits etablierten Aufgabenteilung bei Blog und Dokumentationsserver. MarketingLead liefert die Spezifikation (dieses Dokument), nicht den Code — Software-Implementierung liegt außerhalb der MarketingLead-Zuständigkeit.
• Ein Folgeticket an GUIDeveloper zur Komponenten-Umsetzung wird mit diesem Ticket verknüpft angelegt (siehe Kommentar auf LIR-2895).

3. Gestaltungsraster

MarketingLead-Vorgabe (keine Code-Quelle vorhanden — lirai-www liegt außerhalb dieses Repos, siehe Hinweis in §14):

Weißraum: Abstand zwischen Sektionen mindestens 64 px (Desktop) / 40 px (mobil) — Reduktion (siehe Markenkern-Auflösung oben) heißt hier: lieber eine Aussage pro Sektion mit Luft drumherum als mehrere dicht gedrängte.

Responsives Verhalten: Einspaltig unterhalb Tablet-Breakpoint für alle Inhalte; Mehrspalten- Grids (z. B. Feature-Karten) brechen auf 2 Spalten (Tablet) bzw. 1 Spalte (mobil) um, nie horizontales Scrollen für Fließtext-Inhalte.

4. Typografie im Web

Erbt die Schriftfamilie aus cd-styleguide.md §8 (--font-sans: „Inter Variable“, „Inter“, system-ui, sans-serif) — im Web-Kontext ohne die dortige PDF-Einschränkung auf Helvetica (Font-Embedding ist im Browser kein Thema, „Inter Variable“ kann nativ per @font-face/Google Fonts/self-hosted eingebunden werden).

Größenhierarchie (MarketingLead-Vorgabe, rem-Basis 16 px):

Zeilenlängen: 60–75 Zeichen pro Zeile für Fließtext (entspricht der 720-px-Spalte in §3 bei 16 px Grundschrift) — auch auf großen Monitoren nicht breiter, sonst sinkt die Lesbarkeit. Zeilenhöhe: 1,5 für Fließtext, 1,2 für Überschriften.

Mobile Lesbarkeit: Keine Fließtextgröße unter 16 px (iOS-Zoom-Vermeidung bei Formularfeldern ist ein zusätzlicher technischer Grund, den GUIDeveloper bei Formularfeld-Schriftgrößen beachten sollte).

5. Farbanwendung

Übernimmt die Palette aus cd-styleguide.md §7 vollständig — keine neuen Markenfarben für die Webseite:

Flächen-/Text-/Akzent-Verhältnis (löst die in LIR-2886 genannte Kernaufgabe): Grundflächen überwiegend Weiß/Navy hell (Ruhe, Seriosität), Teal ausschließlich für Interaktions-/Handlungselemente (Buttons, Links) — dadurch bleibt die Seite ruhig, aber Handlungsmöglichkeiten sind eindeutig erkennbar. Faustregel: max. 10 % der sichtbaren Fläche einer Sektion in Akzentfarbe.

Kontrastregeln: Alle Text-/Hintergrund-Kombinationen müssen WCAG-AA-Kontrast erreichen (≥ 4,5:1 Fließtext, ≥ 3:1 Großtext/UI-Komponenten) — siehe §11. Die Produkt-UI-Akzentfarbe --color-brand: #3d5afe (Indigo, aus apps/web/src/styles.css) wird nicht auf der Webseite verwendet, aus demselben bereits in cd-styleguide.md §7 dokumentierten Grund (bewusste Trennung Marken-Teal vs. Produkt-UI-Blau — eine Vereinheitlichung wäre CTO/PO-Entscheidung).

6. Komponenten

Entscheidung Primär-Button-Textfarbe (Rev. 2, LIR-2917): Bei der Umsetzung (LIR-2914) stellte sich heraus, dass „weiße Schrift“ aus Rev. 1 den in §10 verbindlich geforderten WCAG-AA-Kontrast verfehlt: Weiß auf Teal misst nur ~2,53:1 (gefordert ≥ 4,5:1 für Fließtext/Button-Label). Navy auf Teal misst ~6,72:1 und besteht komfortabel. Da §10 den Kontrast als verbindlich und nicht verhandelbar markiert, während die Teal-Fläche selbst aus der bestehenden Markenpalette (cd-styleguide.md §7, kein neuer Farbton) stammt, ist Navy-Schrift die korrekte Auflösung — nicht eine Ausnahme, sondern eine Korrektur eines Fehlers in Rev. 1. Die Tabelle oben ist entsprechend aktualisiert; kein neuer, dunklerer Teal-Ton wird eingeführt (das bliebe eine mögliche Alternative, ist aber gegenüber der schlichten Textfarben-Korrektur unnötiger Palettenaufwand).

Entscheidung CTA-Band-Hintergrund (Rev. 2, LIR-2917): Für vollflächige CTA-Sektionen (in Rev. 1 nicht explizit geregelt) gilt ab sofort verbindlich: Navy-Hintergrund, weiße Schrift, Teal-Button als einziger Akzent — wie in der Umsetzung von LIR-2914 etabliert und oben in die Komponententabelle aufgenommen. Dieses Muster ist die Referenz für alle künftigen vollflächigen CTA-Sektionen, nicht nur ein Einzelfall-Workaround.

Entscheidung Eselsohr-Karten-Detail (Rev. 3, LIR-3328/LIR-3368): Aus dem Konzept „Alleinstellungsmerkmale Webseite“ (LIR-3328 §4.2, Owner-Freigabe 2026-07-31) übernommen: das umgeknickte Dokument-Eck aus dem bereits freigegebenen Logo-Icon (design/branding/README.md) als wiederkehrendes UI-Komponenten-Detail bei Feature- und Preiskarten, anstelle des reinen abgerundeten Rechtecks. Kein neuer Markenwert — nur eine technische Umsetzung eines bereits im Icon vorhandenen Formmotivs als CSS-Klasse (.card-dogear, siehe global.css). Bewusst nur auf Feature-/Preiskarten begrenzt, nicht auf alle Karten-artigen Flächen (Hinweisbox, pricing-individual-note) übertragen, um die Reduktions-Vorgabe (Markenkern, siehe Einleitung) nicht zu unterlaufen.

7. Bildsprache und Icons

• Produktabbildungen: Ausschließlich echte, aktuelle Screenshots (kein gestelltes Stockmaterial mit Personen) — konsistent mit dem Vertrauens-Markenkern; ein Screenshot, der nicht dem aktuellen Produktstand entspricht, schadet mehr als keiner.

• Illustrationen: Zurückhaltend einsetzbar für abstrakte Konzepte (z. B. Datenfluss, Sicherheit), in Navy/Teal/Neutraltönen — keine bunten Stockillustrationen, die dem restlichen Farbsystem widersprechen.

• Icons: Strichstärke-konsistentes Icon-Set (Outline-Stil, keine gemischten Stile), Navy oder Teal, nie mehrfarbig/verspielt.

• Wo bewusst auf Bilder verzichtet wird: Rechtstexte (Impressum, Datenschutz, AGB) und Formularseiten (Kontakt, Anmeldung) bleiben bildfrei — hier zählt Klarheit und schnelle Abarbeitung, kein Illustrationsschmuck.

• Wellen-Trennlinie (Rev. 3, LIR-3328 §4.2/LIR-3368): ein abstrahiertes Wellenform-Motiv (WaveDivider-Komponente) als Sektionstrenner statt gerader Linie, sparsam zwischen Kern- sektionen der Startseite — kein Gesicht, kein Maskottchen. Bewusst getrennt vom Doku-Welle- Maskottchen (public/mascot/), das grundsätzlich App-Assistenten-Einstiegspunkten vorbehalten bleibt (siehe design/branding/README.md) — keine Vermischung der beiden Zeichen. WaveDivider bleibt in jedem Fall gesichtslos, auch nach der folgenden begrenzten Ausnahme.

• Begrenzte Ausnahme für die Webseite (Rev. 4, LIR-3917 §7a / Umsetzung LIR-3933, Marketing- Lead-Entscheidung 2026-08-06): die obige Exklusivität wird für genau zwei Einsatzformen aufgehoben, beide über eine eigene, mehrfach referenzierte Komponente umgesetzt statt Bild-für-Bild inline dupliziert:

  1. Signatur-Plakette (SignaturePlakette.astro): eine kleine runde Plakette (weißer Kreis, Navy-Stroke, Schatten) am Rand echter Produkt-Screenshots, max. 1× pro Seite — Wiedererkennungs-Anker, kein eigenständiges Bildmotiv, aria-hidden, kein eigener Alt-Text.
  2. Posen-Set in der Erklär-Sektion „So einfach geht’s“: die bestehende Feature-Card- Komponente/Styles (§6, .feature-card in global.css) — der Icon-Slot akzeptiert wahlweise ein Outline-Icon oder eine Maskottchen-Pose-SVG (public/mascot/doku-welle-<pose>.svg); kein vierter Kartentyp, keine eigenständige .step-CSS.

  Verbindliche Bedingung: beide Einsatzformen müssen visuell eindeutig nicht-interaktiv/ dekorativ bleiben — kein Button-/CTA-Styling, nicht klickbar, kein Hover-Zustand, der einen Assistenten-Einstieg suggeriert. Das schützt die eigentliche Schutzfunktion der bisherigen Exklusivität: das Maskottchen bleibt als klickbares Signal ausschließlich den echten App-Assistenten-Einstiegspunkten vorbehalten. Keine weiteren Placements (z. B. /produkt/) ohne erneute Rücksprache mit dem Marketing Lead.

• Dritte Ausnahme — Hero-Wasserzeichen-Motiv (Rev. 5, LIR-3938 Variante B / Umsetzung LIR-3940, Marketing-Lead-Entscheidung 2026-08-06): das bestehende, rein dekorative Hero-Wasserzeichen der Startseite (.hero-watermark, zentriert, 5 % Deckkraft, aria-hidden, kein Alt-Text) zeigt statt des Logo-Icons (/brand/icon.png) die gesichtslose Doku-Welle- Variante public/mascot/doku-welle-ohne-gesicht.svg. Kein neues Bildmotiv im Sinn dieses Paragrafen (weiterhin ein einzelnes, sparsam eingesetztes Zeichen, keine Sprechblase, kein Text) und keine Kollision mit der Assistenten-Exklusivität, da das Motiv bewusst ohne Gesicht und ohne jede Interaktivität bleibt — reine Fortführung der bestehenden Wasserzeichen-Rolle mit getauschtem Motiv, keine neue Einsatzform.

• Vierte Ausnahme — Hero-Maskottchen mit Sprechblase (Rev. 6, LIR-3938 Variante A, Owner-Direktauftrag 06.08.2026 / Marketing-Lead-CD-Entscheidung 06.08.2026): Auf ausdrücklichen Owner-Auftrag ersetzt in der Startseiten-Hero-Sektion ein aktives Maskottchen-Motiv mit Sprechblase das bisherige Wasserzeichen (Rev. 5) an derselben Position. Diese Ausnahme hebt für diesen einen Einsatz die bisherige Bedingung „nicht-interaktiv, kein eigenständiges Bildmotiv“ auf — das Maskottchen wird hier bewusst zum bedeutungstragenden, aber weiterhin rein illustrativen Element, klar abgegrenzt vom echten App-Assistenten-Einstieg durch folgende verbindliche Bedingungen:

  1. Motiv: vorhandene Pose public/mascot/doku-welle-erfolg.svg (kein neues Assets-Commissioning) statt der gesichtslosen Wasserzeichen-Variante aus Rev. 5.
  2. Sprechblasenform: klassische Cartoon-Sprechblase mit kleinem dreieckigem Schwänzchen zum Maskottchen hin — ausdrücklich nicht die im Produkt für Chat-Nachrichten verwendete Form (rounded-2xl mit einseitig eckiger Ecke rounded-br-md/rounded-bl-md, siehe apps/web/src/components/ai_pane.tsx). Eigene, andersartige Kontur macht die Illustration auf den ersten Blick von echten Chat-Bubbles unterscheidbar.
  3. Farbgebung: weißer Grund, Navy-Hairline-Rahmen (analog Hinweisbox/Karte, §6) — nicht die fixe Teal-Signaturfarbe des Assistenten-Icons (#7fdbcf/#1fb6a6, assistant_mark.tsx). Der Maskottchen-Körper behält seine reguläre Markenfarbgebung.
  4. Keine Interaktivität: kein <button>, kein cursor:pointer, kein Hover-/Fokus-Zustand, kein Klick-Handler, kein Tab-Stop — rein statische Illustration. Der Sprechblasentext ist echter HTML-Text (nicht nur Bild-Alt-Text, da jetzt bedeutungstragend), semantisch als normaler Fließtext markiert statt aria-hidden.
  5. Text: „Ich bin Lira – ich helfe dir, deine Belege sicher und transparent zu verwalten.“ (Marketing-Lead-Formulierung nach Markenkern/Editorial-Guideline-Tonalität, §8/§9 dieses Dokuments — sachlich, ohne Buzzword-Overload, wie vom Owner gefordert).
  6. Geltungsbereich: ausschließlich Startseiten-Hero, ersetzt dort Rev. 5 vollständig; keine Übertragung auf weitere Seiten ohne erneute Rücksprache mit dem Marketing Lead (Fortführung der bestehenden Placement-Governance-Klausel aus Rev. 4).

  Diese sechs Bedingungen sind der Marketing-Lead-Ersatz für die in Rev. 4 geforderte Nicht-Interaktivität und sichern weiterhin, dass Website-Besucher:innen die Illustration nicht mit einem echten, klickbaren Assistenten-Einstieg verwechseln — der Owner-Auftrag wird damit umgesetzt, ohne die Schutzfunktion der bisherigen Exklusivitätsregel komplett aufzugeben.

8. Sprache und Microcopy

Tonalität folgt vollständig editorial-guideline.md — dieser Abschnitt dupliziert keine Sprachregeln, sondern übersetzt sie in Web-UI-Kontexte:

• Buttons/CTAs: Handlungsorientiert, konkret („Rechnung hochladen“ statt „Weiter“ oder „Los“).
• Formular-Fehlermeldungen: Neutral bis lösungsorientiert, keine Fehler-/Versagensrhetorik — „Bitte gültige E-Mail-Adresse eingeben“ statt „Fehler: Ungültige Eingabe!“.
• Status-/Ladehinweise: Sachlich, kein künstlicher Enthusiasmus („Rechnung wird verarbeitet …“ statt „Fast geschafft! 🎉“).
• Leere Zustände (Empty States): Erklären, was als Nächstes zu tun ist, nicht nur, dass nichts da ist.

9. Vertrauenselemente

Löst die Anforderung „Wie werden Aussagen zu Hosting, Datenschutz und Verarbeitung dargestellt, ohne überladen zu wirken“ (LIR-2886):

• Ein kompakter Vertrauensblock, nicht verteilt über die ganze Seite: i. d. R. im Footer (Hosting-Standort Deutschland, Datenschutz-Link, ggf. Zertifizierungs-Badges) plus optional ein einzeiliger Hinweis im Hero-Bereich der Startseite.
• Keine Sicherheits-Symbolik-Inflation (Schlösser, Schilde, Häkchen-Listen mit Sicherheitsbegriffen) — Vertrauen entsteht laut Markenkern über Klarheit und Transparenz, nicht über Symbolik. Ein textlicher, präziser Hinweis („Hosting ausschließlich in Deutschland, DSGVO-konforme Verarbeitung“) wiegt mehr als drei Icons.
• Zertifizierungs-/Siegel-Badges: Nur tatsächlich vorhandene, geprüfte Zertifikate einbinden — keine generischen „Sicher“-Badges ohne Substanz dahinter (Rechtsrisiko, siehe Legal-Zuständigkeit in §1).

10. Barrierefreiheit

• Kontrast: WCAG 2.1 AA verbindlich (siehe §5) — bei jeder neuen Farbkombination vor Rollout prüfen (z. B. mit einem Kontrast-Checker), nicht erst bei Beschwerden nachbessern.
• Fokusdarstellung: Sichtbarer Fokusring (2 px, Navy) auf allen interaktiven Elementen — outline: none ohne Ersatz ist nicht zulässig.
• Tastaturbedienung: Alle Buttons, Links und Formularfelder per Tab erreichbar und per Enter/ Space auslösbar; logische Tab-Reihenfolge, keine Tastaturfallen (z. B. in Modals).
• Formularlabel: Immer als echtes <label>-Element, nie nur Placeholder (siehe §7 Tabelle).
• Alt-Texte: Für alle Produktabbildungen und Illustrationen mit Informationsgehalt Pflicht; rein dekorative Grafiken erhalten leeres alt="".

11. Seitentypen

12. Reichweite — Blog und Dokumentationsserver

Bestätigt und konkretisiert die Reichweite aus §0: Blog (LIR-2891) und Dokumentationsserver (LIR-2868) sind beide bereits als Teil von lirai-www entschieden — dieses Dokument ist damit für beide die gestalterische Grundlage. Kein separates CD-Dokument pro Unterbereich nötig; seitentypspezifische Struktur bleibt in den jeweiligen Fachdokumenten (§11 Tabelle) geregelt.

13. Konsistenzprüfung

14. Offene Punkte

1. Keine Code-Quelle für Grid/Breakpoints (§3) — lirai-www liegt in einem separaten Repo ohne Agent-Zugriff aus diesem Projekt; die Werte in §3–§4 sind MarketingLead-Vorgaben, keine Ist-Stand-Ableitung aus Code. GUIDeveloper prüft bei Umsetzung auf technische Machbarkeit und meldet Abweichungsbedarf zurück.
2. Astro-Komponenten-Umsetzung (§2) — eigenes Folgeticket an GUIDeveloper, siehe Verweis in §2 und Kommentar auf LIR-2895.
3. Zertifizierungs-Badges (§9) — aktuell keine bekannt vorhanden; Klärung ob/welche existieren liegt bei CEO/Legal, kein MarketingLead-Blocker für diese Revision.
4. Automatisierte Kontrastprüfung (§10) — kein CI-Schritt spezifiziert; analoge Empfehlung wie cd-manual-technische-dokumente.md §17.1 (Interims-Vorschlag, Umsetzung bei GUIDeveloper/TR).

15. Freigabestatus

• MarketingLead (Erstellung — vollständiges Regelwerk): abgeschlossen mit dieser Revision.
• CEO (Markenkern und Rahmen): bereits freigegeben mit LIR-2886; keine erneute strategische Freigabe für dieses Regelwerk-Dokument selbst vorgesehen, da LIR-2886 die Erstellung direkt an MarketingLead delegiert hat.
• GUIDeveloper (technische Umsetzbarkeit Astro): ausständig — Folgeticket wird verknüpft, siehe §2.

Änderungshistorie