Fehlerbehandlung und UX-Erklärungen

1) Warum es wichtig ist

• erklärt, was passiert ist und was als nächstes zu tun ist,
• speichert die eingegebenen Daten und verhindert den Verlust des Fortschritts,
• gibt eine sichere Wiederholung oder einen alternativen Weg,
• bleibt verfügbar (SR/Tastatur) und gibt nicht zu viel preis.

2) Fehlertypologie (für Schnittstelle)

1. Datenvalidierung (4xx Client): leere/falsche Felder, Format, Länge, Regelkonflikt.
2. Geschäftsregeln: Limits, Geo-Limits, KYC/KYB, Takes, nicht verfügbare Slots.
3. Rechte/Permissionen: Rolle, Zugang zur Ressource, Altersgrenzen.
4. Netzwerk/Server: Timeout, offline, 5xx, Überlast, Rate Limit.
5. Konflikte/Zustand: 409/412 (Daten geändert), Rennen, Blockaden.
6. Fehlende Ressource: 404/410, gelöscht/verschoben.
7. Zahlung und Risiko: Ablehnung durch Bank/PSP, Betrugsbekämpfung, Grenzen für verantwortungsvolles Spielen.

3) Kanäle und Darstellungsebene

Regel: Verstecken Sie nicht das kritische in toast/hover. Wo der Nutzer hinschaut, ist auch die Botschaft.

4) Copywriting von Fehlern

Struktur: Ursache → Wirkung → Wirkung.
Der Ton: ehrlich, neutral, schuldfrei.
Besonderheiten: Feld/Bedingung angeben, Codes und Stacks vermeiden.
Aktionsschaltfläche: „Wiederholen“, „Karte ändern“, „Filter zurücksetzen“, „Chat öffnen“.
Sensible Daten: nicht anzeigen (PAN-Maskierung, persönliche Attribute).

Beispiele

Gut: "Die Zahlung ist fehlgeschlagen: Die Bank hat die Transaktion abgelehnt. Versuchen Sie es auf eine andere Weise oder wiederholen Sie es später".
Schlecht: "Fehler 500. Etwas ist schiefgelaufen".
Gut: "Die Tageskostengrenze ist erreicht. Setzen Sie ein neues Limit oder versuchen Sie es morgen".
Gut: "Die Datei ist zu groß (max. 25 MB). Komprimieren oder laden Sie mehrere Dateien hoch".

5) Verhalten und Fokus (A11y)

Der Fehler wird in den Fokuskontext ausgegeben: Wir setzen den Fokus auf das erste fehlerhafte Feld.
Lebende Regionen: 'role =' status'(polite) für info, 'role =' alert'(assertive) für critical.
Sichtbar': Fokus-sichtbar', Kontrast ≥ AA, Farbalternativen (Icon/Text).
Die Nachricht wird über 'aria-describedby' an das Feld gebunden.

html
<label for = "pwd "> Password </label>
<input id="pwd" name="password" aria-describedby="pwd-err" aria-invalid="true">
<p id = "pwd-err" role = "alert"> Minimum 8 characters </p>

6) Retrays, Backoff und Idempotenz

Eine Wiederholung wird vorgeschlagen, wenn eine Erfolgschance besteht (Netzwerkfehler, 5xx, Rate Limit).
Exponentieller Backoff 1-2-4-8 s, Versuchsbegrenzung, verständlicher „Wiederholen“ -Button.
Kritische Transaktionen (Wetten/Zahlungen): Der obligatorische Idempotency-Key schließt → Duplikate aus.
Pullbacks optimistischer Updates - klare visuelle Rückkehr + Erklärung.

js async function retry(fn, attempts=3){
let wait=1000; for(let i=0; i<attempts; i++){
try{ return await fn(); }catch(e){ if(i===attempts-1) throw e; await new Promise(r=>setTimeout(r,wait)); wait=2; }
}
}

7) Offline, Timeouts und Teilinhalte

Offline: Wir zeigen das Banner „Keine Verbindung“, den Zugriff auf den Cache (nur lesen), die Synchronisationswarteschlange.
Timeouts: UI-Timeouts (3-5s) → Status „Warten auf Bestätigung“... mit sicherer Wiederholung/Annullierung.
Teilerfolg: Wir bewahren, was gelungen ist; Beschriften Sie „nicht synchronisiert“.

8) Konflikte und Wettbewerb

409/412: Daten sind veraltet. „Aktualisieren“ vorschlagen und diff anzeigen (was sich geändert hat).
Sperren: Wir informieren Sie, wer den Block hält, und wie lange die Schaltfläche „Zugriff anfordern“.

9) UI-Mustervorlagen

html
<div class="banner banner--error" role="alert">
<strong> Connection failed. </strong> Shows cached data.
<button class =" btn btn--ghost" id = "retry "> Retry </button>
</div>

html
<div role="alertdialog" aria-labelledby="err-title" aria-describedby="err-desc">
<h2 id = "err-title "> Session expired </h2>
<p id = "err-desc "> Sign in again to continue. </p>
<button class = "btn "> Sign in </button>
<button class =" btn btn--ghost"> Home </button>
</div>

tsx function Fallback({ id, onRetry }: { id: string; onRetry: ()=>void }) {
return (
<div role="alert" className="banner banner--error">
<strong> We couldn't load the page. </strong>
<div> Try again. Код: <code>{id}</code> <button onClick={()=>navigator. clipboard. writeText (id)}> Copy </button> </div>
<button onClick = {onRetry}> Retry </button>
</div>
);
}

10) Fehler-Token (Design-System)

json
{
"error": {
"tones": { "danger": "#", "warning": "#", "info": "#" },
"aria": { "polite": true, "assertive": true },
"timing": { "toastMs": 3500, "retryBackoffMs": [1000,2000,4000] },
"layout": { "fieldGap": 8, "bannerIcon": 20 }
}
}

css
.banner--error { background: var(--bg-danger); color: var(--on-danger); padding: 12px 16px; border-radius: 12px; }
.field-error { color: var(--role-danger); margin-top: 6px; font-size:.875rem; }

11) Sicherheit und Privatsphäre

Wir geben keine Stack-Traces, interne IDs, DB-Pfade aus.
Wir maskieren sensible Werte (Karten, Dokumente).
Nachrichten sollten den Angreifer nicht auffordern (z. B. dass ein Konto existiert).
Zur Unterstützung - Korrelations-ID anstelle von Details.

json
{"level":"error","event":"payment_fail","correlation_id":"c-8f1...","user_id":"u-","route":"/pay","psp_code":"DO_NOT_EXPOSE_TO_USER"}

12) Metriken und Kontrolle

INP und Long Tasks-Anteil zum Zeitpunkt des Fehlers (der Fehler darf die UI nicht „aufhängen“).
Retry-Erfolgsrate, Fehler pro 1000 Aktionen, Zeit bis zur Wiederherstellung.
CTR auf „Hilfe/Chat“, Prozentsatz der zurückgelassenen Formulare.
Heatmaps: Wo Feld-Fehler am häufigsten auftreten.

13) QS-Checkliste

Fassbarkeit

• Fokus auf das erste fehlerhafte Feld; 'aria-describedby '/' aria-invalid' werden angezeigt.
• Kritische Meldungen - 'role =' alert'; Der Kontrast ≥ AA.

Verhalten

• Formulardaten gehen bei einem Fehler nicht verloren.
• Es gibt ein klares' Retry 'und einen korrekten Backoff.
• Offline-Modus/Cache arbeiten; Banner sehen.

Copywriting

• Ursache → Wirkung; ohne Fachjargon und Vorwürfe.
• Die Texte sind lokalisiert und brechen das Raster nicht.

Sicherheit

• Kein Durchsickern von PII/Geheimnissen; Wir zeigen nur sichere Codes/IDs.
• Idempotenz ist für kritische Operationen aktiviert.

14) Besonderheiten von iGaming

• UI erfasst sofort „busy“; bei Verzögerung> 3 s - „Wir warten auf Bestätigung“....
• Mit Fail: ehrlicher Status („der Markt hat geschlossen“, „das Verhältnis hat sich geändert“) + sicherer 'Retry'.
• Ein idempotenter Schlüssel, um eine doppelte Wette auszuschließen.

• Wir unterscheiden zwischen „Bank/PSP-Ausfall“ und „Server-Ausfall“. Für die erste - „Wählen Sie einen anderen Weg“, für die zweite - „Retry“.
• Transparente KYC/AML-Schritte; Links "Warum ist es notwendig? ».

• Der Ton ist fürsorglich, ohne Druck. „Limit erreicht - Pause oder Limit aktualisieren“.
• Keine Blitze/Neon; Kontrast AAA, Verfügbarkeit bei SR.

• Erklären Sie die Einschränkungen klar und schlagen Sie „Regeln/Support“ vor.

15) Anti-Muster

„Etwas ist schiefgelaufen“ ohne Handlung und Kontext.
Zurücksetzen des Formulars nach einem Fehler.
Verstecken Sie die kritische in den toast für 3 Sekunden.
Nur Farbe ohne Text/Icon.
Endlose Rückzüge ohne Stornierungsmöglichkeit.
Interne Codes/Stack-Traces anzeigen.

16) Dokumentation im Konstruktionssystem

Компоненты: `FieldError`, `FormError`, `PageBanner`, `AlertDialog`, `ErrorBoundary`.
Ton/Kontrast/Timing-Token, a11y-Presets und ARIA-Beispiele.
Typical Scripting Map (Validierung, Netzwerk, Rechte, Zahlungen) mit Textvorlagen.
„Do/Don't“: reale Vorher/Nachher-Bildschirme mit Bounce/Success-Metriken.

Kurze Zusammenfassung

Machen Sie Fehler verständlich und überschaubar: Sprechen Sie die menschliche Sprache, speichern Sie die eingegebenen Daten, bieten Sie eine sichere Wiederholung und Alternativen, respektieren Sie Verfügbarkeit und Privatsphäre. Dann behalten auch Notsituationen das Vertrauen und unterbrechen nicht den Weg des Nutzers - gerade in kritischen Wett- und Zahlungsszenarien.