yourpart3/docs/USABILITY_CONCEPT.md

Bedienbarkeitskonzept

Ziel

Die Bedienbarkeit von YourPart soll systematisch verbessert werden, ohne die vorhandene Funktionsbreite oder den neuen UI-Stand wieder aufzubrechen. Der Fokus liegt auf Orientierung, Vorhersagbarkeit, Aufgabenfluss, Fehlertoleranz und effizienter Nutzung auf Desktop und Mobile.

Das Dokument ist bewusst als Arbeitsgrundlage aufgebaut:

• Was genau verbessert werden soll
• nach welchen Prinzipien entschieden wird
• in welcher Reihenfolge gearbeitet wird
• woran ein Punkt als erledigt gilt

Leitprinzipien

1. Weniger Reibung

• Haeufige Aufgaben muessen mit moeglichst wenig Entscheidungen und moeglichst wenig Klicks erreichbar sein.
• Sekundaere Funktionen duerfen nicht die Kernaufgabe stoeren.

2. Klare Orientierung

• Nutzer muessen jederzeit erkennen:
• wo sie sich befinden
• was hier moeglich ist
• was der naechste sinnvolle Schritt ist

3. Konsistente Interaktion

• Gleiche Interaktionsmuster muessen sich in der gesamten App gleich verhalten.
• Buttons, Dialoge, Tabs, Listen, Formulare und Menues duerfen nicht je Bereich eigene Bedienlogiken entwickeln.

4. Fehlertoleranz statt Bestrafung

• Fehlbedienungen muessen auffangbar sein.
• Kritische Aktionen brauchen klare Rueckmeldung, wo sinnvoll Bestätigung und wenn moeglich Undo oder sichere Rueckwege.

5. Geschwindigkeit fuer geuebte Nutzer

• Power-User sollen die App schnell nutzen koennen.
• Haeufige Wege duerfen nicht durch uebermaessige Zwischenschritte ausgebremst werden.

Nicht-Ziele

• Keine komplette Informationsarchitektur-Neuerfindung in einem Schritt.
• Kein sofortiger Umbau jedes Workflows gleichzeitig.
• Keine reine Accessibility-Checklistenarbeit ohne echten Nutzwert.

Ausgangsprobleme

Aus dem aktuellen Projektstand und den bisherigen Umbauten ergeben sich fuer die Bedienbarkeit vor allem diese Problemklassen:

• Uneinheitliche Bedienmuster zwischen alten und neueren Bereichen
• zu viele tiefe Menues und bereichsspezifische Sonderlogiken
• einige Seiten mit hoher Funktionsdichte, aber schwacher Priorisierung
• Mischformen aus statischen Shell-Bereichen und historischen inneren Scrollkonzepten
• lokale Alt-Dialoge und Formmuster mit uneinheitlicher Rueckmeldung
• Desktop-zentrierte Denkweise in Teilen von Admin, Minigames und Falukant

Zielbild

Am Ende soll die App folgendes Nutzungsgefuehl bieten:

• Shell, Navigation und Dialoge verhalten sich vorhersagbar
• jede Hauptseite zeigt klar eine Primaeraufgabe und erkennbare Sekundaeraufgaben
• Formulare fuehren sauber durch Eingabe, Validierung und Abschluss
• Statusaenderungen und Systemreaktionen sind sichtbar und verstaendlich
• Falukant, Community, Blog und Lernen bleiben fachlich unterschiedlich, aber bedienbar aus einem Guss

Arbeitsbereiche

Bereich A: Navigation und Orientierung

Ziel:

• Nutzer finden schneller zum Ziel und verstehen Menuehierarchien besser.

Arbeitspunkte:

• Hauptnavigation auf tatsaechliche Primaerbereiche pruefen
• Untermenues auf Redundanzen und Leerpfade pruefen
• aktive Position und Kontext pro Bereich klarer machen
• in tiefen Bereichen Rueckwege, Breadcrumb-artige Hinweise oder Bereichstitel konsistent gestalten
• Schnellzugriffe nur dort einsetzen, wo sie echte Beschleunigung bringen

Abnahmekriterien:

• jeder Hauptmenuepunkt hat einen klaren Zweck
• Menuepunkte ohne Untermenue verhalten sich direkt
• tiefe Ansichten haben einen klaren Rueckweg
• Nutzer muessen nicht raten, in welchem Bereich sie sich befinden

Bereich B: Seitenhierarchie und Aufgabenfluss

Ziel:

• jede Seite hat einen erkennbaren Einstieg, eine Hauptaufgabe und einen lesbaren Aufbau

Arbeitspunkte:

• pro View Primaeraktion definieren
• Informationsdichte dort reduzieren, wo gleichrangige Bloecke konkurrieren
• visuelle Prioritaet zwischen Lesen, Auswaehlen, Bearbeiten und Absenden schaerfen
• Tabellen, Listen und Karten jeweils auf ihren eigentlichen Einsatzzweck pruefen

Abnahmekriterien:

• Nutzer erkennen in wenigen Sekunden den Zweck einer Seite
• Hauptaktionen sind oberhalb oder in unmittelbarer Naehe des relevanten Inhalts
• Nebenfunktionen dominieren die Seite nicht mehr

Bereich C: Formulare und Eingaben

Ziel:

• Formulare sollen verstaendlich, fehlertolerant und effizient sein

Arbeitspunkte:

• Labels, Hilfetexte, Pflichtfelder und Fehlermeldungen vereinheitlichen
• Validierung naeher an den Eingabepunkt bringen
• unklare Zustandswechsel vermeiden
• Speichern, Abbrechen und gefaehrliche Aktionen konsistent platzieren
• Checkboxen, Radios und Selects auf Lesbarkeit und Trefferflaechen pruefen

Abnahmekriterien:

• jeder Eingabefehler ist erkennbar und nachvollziehbar
• Speichern fuehlt sich in allen Bereichen gleich an
• keine Form wirkt wie ein historischer Sonderfall

Bereich D: Dialoge, Feedback und Systemstatus

Ziel:

• Systemreaktionen muessen sichtbar, verstaendlich und nicht stoerend sein

Arbeitspunkte:

• Dialogarten unterscheiden:
• bestaetigend
• informierend
• bearbeitend
• kritisch
• Messagebox/Dialog-Rueckmeldungen vereinheitlichen
• Ladezustaende, Erfolg, Fehler und Leere Zustaende standardisieren
• offene Dialoge und Fensterleiste auf Priorisierung pruefen

Abnahmekriterien:

• Nutzer verstehen, was gerade passiert ist oder noch passiert
• kritische Aktionen sind klar markiert
• Modale Interaktionen blockieren nur, wenn es wirklich noetig ist

Bereich E: Mobile und kleine Viewports

Ziel:

• zentrale Aufgaben muessen auch auf kleineren Screens robust funktionieren

Arbeitspunkte:

• Shell mit Header, Navigation, Content und Footer auf reale Nutzungsszenarien pruefen
• Tabellen und breite Steuermasken auf mobile Alternativen oder horizontale Strategien prüfen
• Touch-Ziele und Abstaende angleichen
• Hover-abhaengige Muster fuer Touch absichern

Abnahmekriterien:

• Kernaufgaben sind auf Tablet und Smartphone ohne Layoutbruch nutzbar
• keine kritische Funktion ist nur via Hover oder Pixel-Präzision erreichbar

Bereich F: Komplexe Produktbereiche

Ziel:

• Falukant, Vokabeltrainer, Minigames und Admin sollen fachlich komplex bleiben, aber leichter steuerbar werden

Arbeitspunkte:

• Falukant:
• Schnellzugriffsleiste, Tab-Struktur, Statusfeedback und Arbeitsablaeufe priorisieren
• Vokabeltrainer:
• Lernpfad, Bearbeitung, Suche, Uebung und Fortschritt klarer trennen
• Minigames:
• Einstieg, Pause, Statusanzeige und Kampagnenfluss vereinfachen
• Admin:
• Such-, Editier- und Bestaetigungsfluesse entlasten

Abnahmekriterien:

• komplexe Bereiche sind ohne Einlernen nicht sofort trivial, aber deutlich besser fuehrend
• wiederkehrende Aktionen sind schneller und sicherer bedienbar

Methodik

1. Bedienbarkeits-Audit

Pro Hauptbereich wird ein kurzer Audit gemacht:

• Primaeraufgabe der Seite
• haeufigste Nutzeraktion
• groesste Reibung
• groesstes Fehlerrisiko
• mobile Schwachstelle

Empfohlene Cluster:

• Shell und Navigation
• Home und Einstieg
• Community/Social
• Blog
• Vokabeltrainer
• Falukant
• Admin
• Minigames
• Dialoge/Formulare

2. Aufgabenorientierte Review-Szenarien

Die App wird nicht nur nach Komponenten, sondern nach Aufgaben geprueft:

• registrieren und einloggen
• Profil/Freunde finden
• Forumsthema finden und beantworten
• Vokabelsprache erstellen, abonnieren, lernen
• Falukant-Status pruefen und Folgeaktion ausfuehren
• Admin-Nutzer suchen und aendern
• Match3 starten, pausieren, neu starten

3. Fix-Kategorien

Alle Probleme werden in vier Kategorien eingeordnet:

• P1: blockiert oder verwirrt Kernnutzung deutlich
• P2: verlangsamt Nutzung oder erzeugt Fehlbedienung
• P3: stoert Konsistenz oder Lesbarkeit
• P4: Feinschliff ohne unmittelbaren Schaden

Umsetzungsphasen

Phase U1: Audit und Problemkatalog

Ergebnis:

• kompakte Liste realer Bedienprobleme pro Hauptbereich
• priorisiert nach P1 bis P4

Arbeit:

• 1 Durchgang Desktop
• 1 Durchgang kleiner Viewport
• 1 Durchgang fuer Tastatur-/Dialognutzung

Aktueller Stand:

• abgeschlossen
• Audit dokumentiert in docs/USABILITY_AUDIT_U1.md
• priorisierte Folgephase: U2 Shell, Navigation und Feedback

Phase U2: Shell, Navigation, Feedback

Ergebnis:

• globale Bedienmuster sind konsistent

Arbeit:

• Navigation
• Rueckwege
• Fokuslogik
• Dialog-/Feedbacksystem
• Lade- und Leerezustaende

Aktueller Stand:

• abgeschlossen
• Shell-Kontextbereich mit Bereichstitel und Rueckweg umgesetzt
• Navigation um klareren Seitenkontext ergaenzt
• zentrales Feedback-API eingefuehrt
• Standard-Feedbackdialoge visuell und technisch vereinheitlicht
• Kernfluesse aus Auth und Settings auf das neue Feedbackmuster umgestellt

Phase U3: Formulare und Abschlussfluesse

Ergebnis:

• Eingaben, Speichern, Validierung und Rueckmeldung sind vereinheitlicht

Arbeit:

• Auth
• Settings
• Admin
• Falukant-Formulare
• Vokabel-Bearbeitungsfluesse

Aktueller Stand:

• abgeschlossen
• gemeinsames Formularmuster fuer Hinweise, Fehler und Action-Row eingefuehrt
• Dialogbuttons respektieren Disabled-Zustaende
• Auth-Dialoge, Account-Settings, zentrale Admin-/Falukant-Formulare und Vokabel-Bearbeitungsfluesse auf sichtbarere Validierung und konsistentere Abschlusslogik umgestellt

Phase U4: Komplexe Fachbereiche

Ergebnis:

• Falukant, Vokabeltrainer, Minigames und Admin sind auf Nutzbarkeit statt nur Funktion geprüft

Arbeit:

• Arbeitsablaeufe entlasten
• Primaeraktionen schaerfen
• Informationslast reduzieren

Aktueller Stand:

• abgeschlossen
• Vokabeltrainer als Aufgabenhub mit getrennten Bereichen fuer eigene und abonnierte Sprachen
• Falukant-Uebersicht um Routinekarten, verdichtete Kennzahlen und schnellere Folgeaktionen erweitert
• Match3-Spiel um Ziel-/Statusleiste fuer den naechsten sinnvollen Schritt ergaenzt
• Match3-Admin um klaren 3-Schritt-Arbeitsfluss, Formzusammenfassung und sicherere Speicherlogik erweitert

Phase U5: Mobile und Endabnahme

Ergebnis:

• Kernaufgaben sind auf Standard-Viewports belastbar

Arbeit:

• letzte Layoutkorrekturen
• Touch und Fokus
• Abschlussreview entlang echter Nutzerszenarien

Aktueller Stand:

• abgeschlossen
• Hauptnavigation auf kleinen Viewports zu einer verlässlich aufklappbaren Mobilnavigation mit Touch-gerechten Zielgroessen umgebaut
• Header und Footer auf kleine Breiten mit stabileren Status- und Linkblöcken angepasst
• Dialoge fuer kleine Viewports auf sichere Maximalgroessen und mobile Button-Stacks begrenzt
• breite Tabellen auf kleinen Screens per horizontalem Scroll-Fallback abgesichert
• globale Touch-Ziele fuer Buttons leicht vergroessert und letzte Shell-Kanten geglaettet

Phase U6: Vereinfachung und Restentruempelung

Ergebnis:

• die letzten spuerbaren Bedienhuerden aus Altmustern, Scrolllogik und funktionslastigen Ansichten werden systematisch entfernt

Arbeit:

• verbliebene alert-/confirm-Fluesse auf das zentrale Feedbacksystem umstellen
• verschachtelte Scrollcontainer in Falukant, Admin und Minigames entfernen oder entkoppeln
• tabellenlastige Kernansichten auf klarere Aufgabenreihenfolge pruefen
• Debug-/Altinteraktionen aus grossen Kernviews reduzieren, wenn sie Bedienbarkeit oder Folgepflege stoeren
• Direktwege, Rueckspruenge und Fokusverhalten in den haeufigsten Hauptpfaden nachziehen

Aktueller Stand:

• U6.1 abgeschlossen
• U6.2 abgeschlossen
• U6.3 abgeschlossen
• U6.4 abgeschlossen
• U6.5 abgeschlossen
• aus der Review nach U5 als eigener Nachlauf identifiziert
• Fokus bewusst nicht mehr auf Redesign, sondern auf Reibungsabbau in realen Nutzungswegen
• priorisierte Teilpakete:
• U6.1 Feedback vereinheitlichen
• U6.2 Scroll- und Layoutfallen entfernen
• U6.3 Tabellen- und Arbeitsflaechen vereinfachen
• U6.4 Interaktionsaltlasten reduzieren
• U6.5 Direktwege und Ruecklogik polieren

Konkreter Arbeitskatalog

1. Shell und Navigation

• Menuepunkte auf Nutzungsprioritaet sortieren
• Untermenues auf direkte Zielerreichung pruefen
• Bereichskontext pro Seite konsistent machen
• globale Ruecksprunglogik definieren

2. Dialog- und Feedbacksystem

• Dialogtypen definieren und dokumentieren
• Standard fuer Erfolg, Fehler, Warnung, Leere, Laden festlegen
• Inline-Feedback vor modalem Feedback bevorzugen, wenn kein harter Block noetig ist

3. Formsystem

• ein gemeinsames Muster fuer Label, Hilfetext, Fehlermeldung, Pflichtfeld
• ein gemeinsames Muster fuer Save/Cancel/Delete
• ein gemeinsames Muster fuer Tabellenfilter und Suchformulare

4. Bereichsreviews

• Social/Friends/Search/Forum entlang echter Aufgaben pruefen
• Vokabeltrainer entlang des Lernpfads pruefen
• Falukant entlang taeglicher Routinen pruefen
• Admin entlang Such-/Editier-Routinen pruefen
• Minigames entlang Einstieg/Pause/Neustart pruefen

5. Mobile Review

• Header/Nav/Footer mit realen Hoehen pruefen
• breite Inhalte auf kleine Screens pruefen
• Dialoge und Tabellen fuer Touch pruefen

6. Vereinfachungsreview

• Restbestände an alert, confirm und lokalen Sonderdialogen abbauen
• komplexe Tabellenbereiche in Aufgabenfolge statt nur Datenanzeige gliedern
• verschachtelte Scrollbereiche konsequent entfernen
• Debug-/Sonderlogik in Kerninteraktionen auf Bedienrelevanz pruefen

Definition of Done

Das Bedienbarkeitsprojekt gilt als abgeschlossen, wenn:

• fuer alle Hauptbereiche ein Audit stattgefunden hat
• P1- und P2-Probleme aus dem Audit abgearbeitet sind
• Navigation, Formulare, Dialoge und Feedback nach gemeinsamen Regeln funktionieren
• Kernaufgaben auf Desktop und kleinem Viewport ohne strukturelle Reibung moeglich sind
• verbleibende Altinteraktionen in Kernpfaden keine zusaetzliche Bedienlogik mehr erzwingen
• Restpunkte nur noch P3/P4-Feinschliff sind

Empfohlene Reihenfolge

1. Audit ueber Kernaufgaben
2. Shell/Navigation/Feedback
3. Formulare und Abschlusslogik
4. Falukant, Vokabeltrainer, Admin, Minigames
5. Mobile Endabnahme
6. Vereinfachungsnachlauf ueber Feedback, Scrolllogik und tabellenlastige Restbereiche

Naechster konkreter Schritt

Der naechste sinnvolle Umsetzungsschritt ist U6.1 Feedback vereinheitlichen: alle verbliebenen alert-/confirm-Fluesse in Kernpfaden auf das zentrale Feedback- und Bestätigungssystem ziehen und dabei zugleich die groebsten Altinteraktionen in Falukant, Kalender, Vokabeln und Admin bereinigen.