438 lines
14 KiB
Markdown
438 lines
14 KiB
Markdown
# 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
|
|
|
|
Aktueller Stand:
|
|
|
|
- `U6.1` abgeschlossen
|
|
- `U6.2` abgeschlossen
|
|
- `U6.3` abgeschlossen
|
|
- `U6.4` 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`
|
|
|
|
## 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.
|