1. Kontext: Ihre App ist zu Gast im Haus von ChatGPT
Bevor Sie Buttons zeichnen und Schriften auswählen, sollten Sie eine Realität akzeptieren: Der Nutzer öffnet nicht „Ihre Website“, er befindet sich in ChatGPT. ChatGPT hat bereits seine eigenen:
- Farbschemata,
- Schriften und Größen,
- Abstände und Layouts der Elemente.
Ihr Widget wird innerhalb dieser Umgebung angezeigt, meist in einem iframe. Daraus folgt Wichtiges: Visuell sollte die App wie eine natürliche Fortsetzung der ChatGPT‑Oberfläche wirken – nicht wie ein Banner aus dem Jahr 2008.
Die offiziellen OpenAI‑Guidelines sagen genau das: Systemfarben und ‑schriften nicht brechen, nur maßvolle Markenakzente hinzufügen und die grundlegende Typografie sowie das Raster der Plattform respektieren.
Praktisch bedeutet das drei Dinge.
Erstens: Hintergrund, Basistextfarbe, Standardtypografie – all das sollte von ChatGPT bzw. systemweiten Variablen geerbt werden und nicht nach dem Motto „Ich bin Künstler, ich sehe das so“ gestaltet sein.
Zweitens: Wenn Sie „Ihren eigenen Stil“ möchten, sollte er sich auf Akzente konzentrieren: primäre Buttons, Badges, hervorgehobene Zustände. Aber bitte kein Regenbogenhintergrund und keine benutzerdefinierte Schrift wie Comic Sans – auch wenn Sie es innerlich sehr wollen.
Drittens: Inline‑ und Fullscreen‑Modi derselben App sollten visuell aus einer Welt kommen: gleiche CTA‑Farben, gleiche Kartenradien und ‑abstände, gleiche Typografie. Der Nutzer sollte nicht das Gefühl haben, beim Wechsel von Inline zu Fullscreen in ein anderes Produkt geraten zu sein.
Als Nächstes gehen wir Schicht für Schicht vor: Farben und Themes, Typografie, Abstände und Raster – und dann, wie Tailwind und shadcn/ui helfen, alles zusammenzufügen.
Insight
Die ChatGPT‑Sandbox beschränkt nicht nur die Funktionalität Ihres Widgets, sondern verpasst ihm auch eigene Stile.
Erstens – das ist der HTML‑Header
Original von der Website:
<html lang="ru">
In der Sandbox:
<html lang="en-US" data-theme="light" class="light" style="--safe-area-inset-top: 0px; --safe-area-inset-bottom: 0px; --safe-area-inset-left: 0px; --safe-area-inset-right: 0px;">
Zweitens – das sind native CSS‑Stile, damit Ihr Widget mehr wie ChatGPT aussieht:
<style>
html,body,#root{-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;margin:0;padding:0}
html,body{font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Helvetica Neue,Arial,sans-serif!important}
button,input,textarea,select{font-family:inherit}
html{background-color:#fff}
html.dark{background-color:#212121}
html.mobileSkybridge.dark{background-color:#000}
@supports (font: -apple-system-body){html.mobileSkybridge{font:-apple-system-body}}
</style>
Merken Sie sich das – dann gibt es weniger Überraschungen.
2. Themes und Farben: leben in hellen und dunklen Welten
Helle und dunkle Themes
Die ChatGPT‑Oberfläche unterstützt bereits helle und dunkle Themes. Ihr Widget wird innerhalb eines davon angezeigt, und der Nutzer kann jederzeit zwischen ihnen wechseln. Jegliche hart codierten weißen oder schwarzen Hintergründe sind daher potenzielle Stolperfallen.
Stellen Sie sich ein Widget vor, das weißen Hintergrund und schwarzen Text zeichnet. Im hellen Theme wirkt es erträglich. Im dunklen Theme – wie ein Scheinwerfer ins Gesicht. Umgekehrt sieht schwarzer Hintergrund im hellen Theme auch nicht besser aus. Deshalb empfehlen die offiziellen Richtlinien, keine Farben zu hardcoden, sondern sich auf das Host‑Theme/Variablen zu stützen.
In der Apps‑SDK‑Umgebung bekommen Sie normalerweise ein API oder CSS‑Variablen für das aktuelle Theme. In der Doku tauchen Varianten wie window.openai.theme und die Nutzung der Standard‑CSS‑Variablen von ChatGPT auf. Außerdem gibt es prefers-color-scheme und die dark:‑Utilities in Tailwind.
Die Idee ist in etwa: Ihr Widget sollte sich automatisch an das Theme des Hosts anpassen bei Dingen wie:
- Kartenhintergründe (etwas heller/dunkler als der Basis‑Hintergrund),
- Textfarbe (ausreichender Kontrast),
- Rahmen, Schatten und Hover‑Zustände.
Ein einfaches Wrapper‑Beispiel für ein Theme mit Tailwind:
// components/AppShell.tsx
export function AppShell({ children }: { children: React.ReactNode }) {
return (
<div className="bg-background text-foreground">
{/* bg-background/text-foreground werden durch das Theme überschrieben */}
{children}
</div>
);
}
Dabei sind bg-background und text-foreground keine Standard‑Tailwind‑Klassen, sondern Aliasse auf CSS‑Variablen Ihres Designsystems (z. B. aus shadcn/ui), die ihrerseits an das helle/dunkle ChatGPT‑Theme gebunden sind.
Systemfarben vs. Markenakzente
OpenAI sagt ziemlich klar: Systemfarben von ChatGPT dürfen nicht verändert werden. Basistexte, Standard‑Chatpanels, Hintergrund – all das soll in den Plattformfarben bleiben. Ihr Spielfeld sind Akzente innerhalb des Widgets: CTA‑Buttons (call to action – primäre Aktion), Badges, kleine Elemente.
In der GiftGenius‑Praxis bedeutet das:
- der Hintergrund der Geschenk‑Karte ist nah an der Systemfarbe,
- der Text hat die gewöhnliche Systemfarbe – wie der Chat‑Text,
- die Markenfarbe von GiftGenius wird für den primären Button „Geschenk auswählen“ und vielleicht für einen Rabatt‑Badge genutzt.
Man kann sich das als Tabelle vorstellen:
| Element | Empfehlung | Was vermeiden |
|---|---|---|
| Widget‑Hintergrund | Von ChatGPT erben | Knalligen Markenverlauf setzen |
| Primärtext | Systemfarbe erben | Zu bunt/zu grau bis zur Unleserlichkeit |
| Primärer CTA‑Button | Markenakzentfarbe verwenden | „Regenbogen“ und 5 Farben auf den Button malen |
| Sekundäre Buttons/Links | Nahe an Systemlinks | So auffällig gestalten wie den CTA |
| Schatten/Rahmen | Sanft, minimalistisch | Dicke Neon‑Konturen |
Mini‑Beispiel mit Tailwind für die Primärfarbe:
// styles/globals.css (Ausschnitt)
:root {
--gift-accent: 222 84% 56%; /* hsl */
}
.dark {
--gift-accent: 222 84% 64%; /* etwas heller für Dark */
}
// components/GiftButton.tsx
export function GiftButton({ children }: { children: React.ReactNode }) {
return (
<button className="rounded-md bg-[hsl(var(--gift-accent))] px-4 py-2 text-sm font-medium text-white hover:opacity-90">
{children}
</button>
);
}
Sie verändern nicht den Hintergrund des gesamten Widgets, verwenden Ihre Farbe aber dezent für den primären CTA‑Button.
Kontrast und WCAG ohne Fanatismus
Auch wenn Sie keinen WCAG‑Test ablegen: Es gibt eine einfache Leitlinie – Text muss lesbar sein. Je kleiner die Schrift, desto höher sollte der Kontrast sein. In Accessibility‑Kursen empfiehlt man, den Textkontrast zum Hintergrund nicht unter ~4.5:1 für Fließtext fallen zu lassen. Wir steigen hier nicht tief in die Standards ein: Uns reicht ein praktischer Richtwert – ausreichender Kontrast zwischen Text und Hintergrund.
In der Praxis:
- Keinen hellgrauen Text auf hellgrauem Hintergrund für vermeintliche „Eleganz“ verwenden;
- dunkelgrauen Text auf fast schwarzem Hintergrund im Dark‑Theme vermeiden;
- mindestens einen „Augentest“ machen: Wenn Sie blinzeln müssen, tut es der Nutzer auch.
Vereinbaren Sie mit sich selbst: Jeder sekundäre Text (Labels, Hinweise) bleibt lesbar – nur etwas weniger akzentuiert in Farbe und Größe, aber nicht „völlig geisterhaft“.
3. Typografie: Systemschriften, Hierarchie und etwas gesunder Menschenverstand
Systemschriften statt eigener Schriftfamilie
Die offiziellen Guidelines raten, die Systemschriften der Plattform zu verwenden, etwa SF Pro, Roboto und ihre Pendants, und keinen eigenen Webfont einzuschleusen. Der Grund ist nicht nur Performance, sondern auch, dass Ihre App wie ein natives UI‑Element wirken soll.
In einer Next.js‑App ist es am einfachsten, alles im Widget den Basis‑Systemstack erben zu lassen. In Tailwind ist das meist bereits als font-sans konfiguriert. Wenn Sie es expliziter möchten:
// app/layout.tsx (Ausschnitt)
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="en">
<body className="font-sans antialiased">
{children}
</body>
</html>
);
}
Sie müssen keine drei Familien via Google Fonts einbinden. Für das Lernprojekt GiftGenius sieht eine strenge Systemschrift ordentlicher aus als etwa Lobster.
Größenhierarchie
Uns genügen ein paar Typografiestufen: Blocktitel, Untertitel/Schlüsselparameter, Fließtext und Beschriftung.
Für die Inline‑Karte von GiftGenius können wir z. B. folgende Stufen vereinbaren:
| Rolle | Tailwind‑Klasse | Beispiel |
|---|---|---|
| Kartentitel | |
Geschenkname |
| Schlüsselparameter | |
Preis oder Kategorie |
| Beschreibung | |
Kurze Beschreibung |
| Beschriftung/Kleingedrucktes | |
Versand, Shop |
Mini‑Komponente für eine Karte:
// components/GiftCard.tsx
type GiftCardProps = {
title: string;
price: string;
description: string;
};
export function GiftCard({ title, price, description }: GiftCardProps) {
return (
<div className="rounded-lg border bg-card p-4">
<h3 className="text-base font-semibold">{title}</h3>
<p className="mt-1 text-sm font-medium text-emerald-600">{price}</p>
<p className="mt-2 text-sm text-muted-foreground">{description}</p>
</div>
);
}
Hier gilt:
- kein riesiges H1;
- alle Informationen sind kompakt;
- die Hierarchie ist über Größe und Schriftstärke erkennbar.
Ausrichtung und Zeilenlänge
Ein Chat‑Interface ist meist schmal – besonders im Inline‑Modus. Daher müssen Sie sich nicht mit komplizierter Typografie quälen: Linksbündig und eine Zeilenlänge von 40–60 Zeichen ist gut lesbar.
Nützliche Gewohnheiten:
- lange Texte in Karten nicht zentrieren – das erschwert das Lesen;
- NICHT ALLES IN VERSALIEN SCHREIBEN;
- Basistext nicht kleiner als 14 px machen (in Tailwind ist das text-sm), außer mit sehr gutem Grund.
Im Zweifel gilt: Lesen wird ein müder Mensch in der U‑Bahn, nicht Sie mit einem perfekten 27‑Zoll‑Monitor.
4. Abstände, Dichte und Raster
Wenn Farben und Schriften die „Farben“ sind, dann sind Abstände die Luft. Ohne sie werden selbst die ordentlichsten Karten zur Suppe.
OpenAI betont in den Empfehlungen: Elemente dürfen nicht „verklebt“ sein; Abstände und Radien besser aus dem Designsystem oder UI‑Framework nehmen (Tailwind, shadcn/ui etc.); horizontalen Scroll möglichst minimieren.
Das „Atmen“-Prinzip
Das einfachste Muster: eine einheitliche Abstandsskala verwenden (z. B. Schritt 4 px oder 8 px) und nicht jedes Mal eine neue Größe erfinden. In Tailwind ist das schon eingebaut: p-2, p-3, p-4, gap-3 usw.
Beispiel eines kleinen Rasters für eine Geschenkliste im Inline‑Modus:
// components/GiftListInline.tsx
export function GiftListInline({ children }: { children: React.ReactNode }) {
return (
<div className="flex flex-col gap-3">
{children}
</div>
);
}
Jede Karte ist durch gap-3 getrennt, hat eigene innere p-4 – und schon das genügt, damit die Liste nicht wie ein „Endloslaken“ wirkt.
Spalten: Inline vs. Fullscreen
In den UX‑Dokumenten für die Apps SDK wird empfohlen, im Inline‑Widget bei 1–2 Spalten zu bleiben; im Fullscreen kann man sich bei ausreichender Breite 2–3 Spalten leisten.
Der Grund ist einfach: Im Chat ist die Breite begrenzt, besonders mobil, und zwei Spalten liegen schon an der Grenze der Lesbarkeit. Im Fullscreen bekommen Sie nahezu den ganzen Bildschirm und können Inhalte dichter anordnen.
Grobe Skizze:
flowchart LR
subgraph Inline
A[1 Spalte
schmaler Bildschirm]
B[2 Spalten
auf dem Desktop]
end
subgraph Fullscreen
C[2 Spalten
Standardszenario]
D[3 Spalten
für Grids/Kataloge]
end
Implementierung in Tailwind für GiftGenius:
// components/GiftGrid.tsx
export function GiftGrid({ fullscreen, children }: { fullscreen?: boolean; children: React.ReactNode }) {
const base = fullscreen ? "grid-cols-2 md:grid-cols-3" : "grid-cols-1 sm:grid-cols-2";
return (
<div className={`grid gap-4 ${base}`}>
{children}
</div>
);
}
Im Inline‑Modus geben Sie eine Spalte auf dem Handy und zwei auf breiteren Bildschirmen; im Fullscreen direkt 2–3 Spalten je nach Breite.
Horizontalen Scroll vermeiden
Ein Chat ist seiner Natur nach vertikal. Der Nutzer ist gewohnt, nach unten zu scrollen, nicht zur Seite. Daher:
- Tabellen und Karten so bauen, dass sie in die Containerbreite passen;
- keine festen Breiten wie width: 600px; für Elemente, die in flexiblen Containern leben;
- max-w-full, overflow-x-auto nur als „letzte Rettung“ nutzen, nicht als Default.
Für GiftGenius‑Karten ist w-full praktisch, und das Raster entscheidet, wie viele pro Zeile passen.
5. Responsivität im ChatGPT‑Container
Im normalen Frontend haben Sie die volle Kontrolle über den Viewport. In ChatGPT ist diese Kontrolle begrenzt: Ihr Widget steckt im Chat‑Container mit eigenen Abmessungen und Regeln. Die Apps SDK bietet hilfreiche Brücken: maximale Höhe, Safe‑Area für Display‑Ausschnitte, Gerätetyp usw.
maxHeight und vertikale Einschränkungen
Im Inline‑Modus kann ChatGPT die Widget‑Höhe begrenzen, damit es nicht „den ganzen Bildschirm frisst“. Hooks wie useMaxHeight() lassen Sie wissen, wie viel Platz Sie aktuell ehrlich belegen dürfen, und Sie hängen interne Scrolls dort hin, wo sie nötig sind.
Pseudocode:
// Pseudocode, kein echtes API:
const maxHeight = useMaxHeight();
return (
<div style={{ maxHeight, overflowY: "auto" }}>
<GiftGrid>{/* ... */}</GiftGrid>
</div>
);
So vermeiden Sie, dass das Widget am unteren Bildschirmrand anschlägt und Chat‑Nachrichten „irgendwohin ins Gestern“ rutschen.
safeArea und Mobilgeräte
Auf Mobilgeräten gibt es oben und unten Ausschnitte, Statusleiste, Systempanels. Die Apps SDK erlaubt, die safeArea zu erhalten und Abstände so anzupassen, dass nichts unter die „Notch“ rutscht.
Auf CSS‑Ebene können Sie zusätzliche Paddings hinzufügen:
// Pseudocode
const { top, bottom } = useSafeArea(); // zum Beispiel: gibt { top: 8, bottom: 16 } zurück
return (
<div style={{ paddingTop: top, paddingBottom: bottom }}>
{/* Inhalt */}
</div>
);
Für die Vorlesung ist der Grundsatz wichtiger: Das Widget soll die Höhenbegrenzung und die Safe‑Area respektieren, sonst wird die UX schnell zu „scroll noch dreimal, bis du den Button siehst“.
6. Tailwind und shadcn/ui: Buttons nicht neu erfinden
Reines CSS von Hand für den ganzen UI zu schreiben, ist heute fast Hardcore‑Sport. Im Kontext von ChatGPT‑Apps ist es viel einfacher, eine bewährte Bibliothek zu nehmen und sie an die Anforderungen der Plattform anzupassen. Im Kurs stützen wir uns auf Tailwind und shadcn/ui als Basisstack.
Tailwind als Vokabular für Abstände und Farben
Tailwind liefert einen praktischen Satz Utilities:
- Abstände (p-4, gap-3),
- Größen (text-sm, text-base),
- Farben (text-muted-foreground, bg-card), die in shadcn/ui und ähnlichen Systemen bereits an Theme‑CSS‑Variablen gebunden sind.
Das passt perfekt zu ChatGPTs Anforderungen:
- Sie erfinden keine beliebigen Abstände,
- definieren Textgrößen konsistent,
- brechen Systemfarben nicht, sondern nutzen abgestimmte Tokens.
shadcn/ui als Satz sauberer Komponenten
shadcn/ui (und ähnliche Bibliotheken) bieten fertige Card, Button, Input, Tabs usw., abgestimmt auf das Tailwind‑Theme. Das beschleunigt den Aufbau einer sauberen, minimalistischen Oberfläche deutlich – gerade für GiftGenius‑Karten.
Beispiel GiftCard mit shadcn/ui:
// components/GiftCardShadcn.tsx
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";
import { Button } from "@/components/ui/button";
type GiftCardProps = {
title: string;
price: string;
description: string;
};
export function GiftCardShadcn(props: GiftCardProps) {
return (
<Card>
<CardHeader>
<CardTitle className="text-base">{props.title}</CardTitle>
</CardHeader>
<CardContent className="space-y-2">
<p className="text-sm font-medium text-emerald-600">{props.price}</p>
<p className="text-sm text-muted-foreground">{props.description}</p>
<Button className="mt-2">Geschenk auswählen</Button>
</CardContent>
</Card>
);
}
Wichtig sind hier weniger shadcn selbst als die Prinzipien:
- der Titel ist nicht riesig;
- die Beschreibung ist gut lesbar;
- der Button ist gemäß der gemeinsamen Design‑Systematik gestaltet, nicht „auf eigene Faust“.
Anpassung an ChatGPT
Im realen Projekt können Sie die Palette an den minimalistischen Stil von ChatGPT anpassen: heller Hintergrund, weiche Schatten, dezente Radien. Der Modulplan empfiehlt ausdrücklich, sich auf ein bestehendes Designsystem zu stützen und kein eigenes Universum zu erschaffen.
Ein einfacher Ansatz:
- Basis von shadcn/ui nehmen,
- Systemschrift beibehalten,
- ein bis zwei Markenfarben in den Tokens primary / accent konfigurieren,
- sicherstellen, dass sowohl Inline als auch Fullscreen dieselben Tokens verwenden.
So bekommen Sie einen konsistenten visuellen Kern ohne großen Aufwand.
7. Visuelle Sprache von GiftGenius: alles zusammenführen
Systematisieren wir, was für unser hypothetisches GiftGenius bereits als „visuelle Sprache“ gelten kann.
Erstens: Farbschema. Hintergrund und Text erben von ChatGPT; der Akzent ist dezent, aber sichtbar und wird auf CTA‑Buttons und ggf. Rabatt‑Badges angewendet. Im Dark‑Theme ist dieser Akzent etwas heller, um den Kontrast zu halten.
Zweitens: Typografie. Basis‑Systemschrift, Größen text-sm für Fließtext und text-base für Kartentitel. Kursiv und Versalien selten und nur mit Zweck. Überschriften im Fullscreen‑Assistenten eine Stufe höher – aber immer noch ohne schreiende text-4xl.
Drittens: Abstände und Raster. Im Inline‑Modus ist die Geschenkliste eine oder zwei Spalten mit gap-3/gap-4, jede Karte mit p-4. Im Fullscreen‑Modus 2–3 Spalten, Assistent‑Schritte mit ausreichenden Abständen zwischen Formularen und Buttons. Kein horizontaler Scroll für die wichtigsten Szenarien.
Kleine Skizze für GiftGenius‑Screens:
graph TD A[Inline: Geschenkliste] --> B[GiftCard
Farben/Typografie/CTA] A --> C[GiftGrid 1–2 Spalten] D[Fullscreen: Auswahlassistent] --> E[Schritt 1
Formular] D --> F[Schritt 2
Filter/Bereiche] D --> G[Schritt 3
Bestätigung] B --> H[GiftButton
Markenakzent]
Viertens: Kompatibilität mit dem Host‑Kontext. Alle Elemente verhalten sich anständig beim Umschalten zwischen hellem/dunklem Theme, respektieren maxHeight und verschwinden nicht unter der Safe‑Area. Farben konkurrieren nicht mit ChatGPT, und CTA‑Buttons sehen überall gleich aus, damit der Nutzer aus dem Muskelgedächtnis weiß, wo er drücken muss.
Dieser Satz an Entscheidungen macht Ihre App schon demotauglich – nicht nur für Entwickler, sondern auch für echte Nutzer oder Product‑Manager: Es gibt etwas zu besprechen, jenseits von „hier MCP, dort Agents SDK“.
8. Barrierefreiheit (Accessibility Guidelines, WCAG AA)
Wir haben WCAG bereits kurz erwähnt, als wir in Abschnitt 2.3 über Text‑/Hintergrundkontrast gesprochen haben. Dort interessierte uns ein praktischer Richtwert – die Lesbarkeit nicht zu ruinieren. Jetzt schauen wir etwas breiter: Wie wirkt dasselbe UI für Menschen, die es nicht mit den Augen sehen, und für ChatGPT im Sprachmodus?
WCAG AA ist ein Konformitätsniveau des internationalen Regelwerks WCAG (Web Content Accessibility Guidelines), das beschreibt, wie Websites und Interfaces für Menschen mit unterschiedlichen Einschränkungen in Sehen, Motorik, Kognition usw. zugänglich gemacht werden.
Die Hauptidee von WCAG AA ist, ein Interface von „theoretisch zugänglich“ zu tatsächlich nutzbar zu machen. Dieses Niveau umfasst Dutzende Anforderungen, die die Interaktionsqualität direkt beeinflussen. Darunter – der erwähnte Kontrastschwellenwert von etwa 4.5:1 für Text sowie Anforderungen an die Größe klickbarer Flächen, Fokuszustände, Fehlermeldungen in Formularen usw.
Eine eigene Schicht ist die Unterstützung von Assistive Technologies, einschließlich Screenreader. Das AA‑Niveau fordert korrekte Semantik: Überschriften müssen Überschriften sein, Listen Listen, Buttons Buttons; interaktive Elemente brauchen korrekt zugewiesene Rollen und Textalternativen. So können Nutzer, die mit VoiceOver, TalkBack oder NVDA arbeiten, Struktur und Sinn des Interfaces vollständig erfassen.
Screenreader (Bildschirmleser)
Ein Screenreader (Bildschirmleser) ist ein Programm, das den Bildschirminhalt vorliest und/oder strukturiert, damit Menschen mit Sehbeeinträchtigungen Computer, Smartphones oder Web‑Apps bedienen können.
Ein Screenreader ist nicht einfach „ein Programm, das Text vorliest“. Er ist ein vollständiges Interaktionssystem, das die visuelle Darstellung einer Website oder App in eine zugängliche akustische und strukturierte Navigation verwandelt.
ChatGPT, Screenreader und WCAG AA
Wenn Ihr Widget nach den WCAG‑AA‑Prinzipien ausgezeichnet ist (korrekte Rollen, Überschriften, Beschriftungen von Buttons), ist es nicht nur für Screenreader verständlich, sondern auch für ChatGPT im Sprachmodus. Der Nutzer spricht mit ChatGPT, und das Modell kann sich auf dieselbe semantische Struktur stützen, um „virtuell“ dasselbe zu tun wie ein Mensch: die richtigen UI‑Elemente finden, Buttons drücken, Links folgen usw.
Gemäß den Anforderungen des ChatGPT Store ist die Unterstützung des Standards WCAG AA für jede App verpflichtend. Jedes Widget und jedes Tool sollte maximal hochwertige und detaillierte Beschreibungen besitzen, und das Markup muss den WCAG AA‑Standards entsprechen: korrekte Semantik, lesbare Labels, vorhersehbare Zustände.
Daher ist die Forderung nach WCAG AA keine separate „Feature für Menschen mit besonderen Bedürfnissen“, sondern ein grundlegendes Designprinzip, damit ChatGPT‑Apps vollwertig mit Ihrer Anwendung arbeiten können – auch wenn der Nutzer per Stimme interagiert.
Zu Voice‑UX‑Szenarien, Unterschieden zwischen Sprach‑ und Textdialog und Anforderungen des ChatGPT Store kommen wir noch – in anderen Lektionen dieses Moduls und im Modul zur Veröffentlichung der App. All das steht jedoch auf dem Fundament, das Sie jetzt gesehen haben: Sprachmodus = Multimodalität + Barrierefreiheit (WCAG AA + Screenreader).
9. Typische Fehler im visuellen Design von ChatGPT‑Apps
Fehler Nr. 1: Hart codierte weiße/schwarze Hintergründe und Textfarben.
Ein Entwickler setzt weißen Hintergrund und schwarzen Text, ohne an das Dark‑Theme zu denken. Im hellen Theme geht es noch, im dunklen wird es zum Scheinwerfer und ruiniert die UX. Besser Systemfarben und Host‑Theme nutzen (CSS‑Variablen, prefers-color-scheme oder das Apps‑SDK‑API) und eigene Farben nur für Akzente verwenden.
Fehler Nr. 2: Zu aggressives Branding.
Knalliger Verlaufshintergrund, Custom‑Font, bunte Rahmen. Das Widget wirkt wie ein Promo‑Banner statt als Teil der ChatGPT‑Oberfläche. Die Guidelines verlangen das Gegenteil: minimalistischer, „nativer“ Look mit dezentem Einsatz der Markenfarbe nur bei Schlüsselelementen, z. B. den primären Buttons.
Fehler Nr. 3: Keine Hierarchie in der Typografie.
Alle Texte haben dieselbe Größe/Gewicht – oder umgekehrt: drei Überschriftstufen auf einer kleinen Karte, dazu noch in Versalien. Der Nutzer erkennt nicht, was wichtig ist: Titel, Preis oder Beschreibung. Besser vorab 3–4 Stufen festlegen und konsequent nutzen: Titel, Schlüsselparameter, Fließtext, Beschriftung.
Fehler Nr. 4: Zusammengeklebte Elemente ohne Abstände.
Karten stoßen direkt aneinander, Text klebt am Rand, Buttons direkt am Text. Auf dem Desktop geht es gerade noch, mobil wird es zu visuellem Lärm. Nutzen Sie eine einheitliche Abstandsskala (z. B. die Tailwind‑Klassen p-4, gap-3) und sparen Sie nicht an „Luft“.
Fehler Nr. 5: Versuch, 4–5 Spalten im Inline‑Modus unterzubringen.
Der Entwickler ist gedanklich noch auf einer Shop‑Seite und baut im Chat ein Kachelgitter aus vier schmalen Karten. Auf breitem Screen fragwürdig, mobil unlesbar – horizontaler Scroll kommt dazu. Im Inline‑Widget genügen meist ein bis zwei Spalten; die dritte Spalte dem Fullscreen überlassen.
Fehler Nr. 6: Ignorieren von Höhenlimits und Safe‑Area.
Das Widget rendert eine riesige Liste ohne innere Scrolls und ohne maxHeight zu beachten – Buttons landen „unterhalb des Bildschirms“. Oder Elemente verstecken sich unter dem Display‑Ausschnitt. Nutzen Sie Daten zur maximalen Höhe und Safe‑Area, um Höhe und Abstände korrekt zu verteilen.
Fehler Nr. 7: Inkonsistentes Erscheinungsbild von Buttons und Karten zwischen Inline und Fullscreen.
Im Inline‑Modus ist der Button grün und rund, im Fullscreen blau und eckig. Das Gefühl eines einheitlichen Produkts geht verloren. Basisstile für Buttons und Karten in eine gemeinsame Komponente/ein gemeinsames Theme auslagern und in allen Modi verwenden.
Fehler Nr. 8: „Autoren“-Schrift und dekorative Kapriolen.
Ein schwerer Webfont „weil es schöner ist“ bricht die visuelle Konsistenz mit ChatGPT und kann die Performance beeinträchtigen. Die Plattform empfiehlt Systemschriften und eine dezente Typografie. Wenn Sie sich als Designer ausdrücken möchten – arbeiten Sie lieber an Icons und Microcopy als an einer Schriften‑Revolution.
GO TO FULL VERSION