Checkliste für gutes UI UX Design

Regeln

• Die Bedienphilosophie muss innerhalb eines Projektes immer durchgängig sein. Innerhalb des Projektes darf nicht gewechselt werden.
• Wenn mehrere Menschen in einem Projekt arbeiten, müssen Abstimmungen zum UI und zur UX getroffen werden.
• Denke immer aus der Sicht der Nutzer und nie aus der Sicht der Programmierer. Nur weil Daten in der Datenbank zusammenstehen, müssen sie noch lange nicht im User Interface zusammenstehen. Löse dich vom Datenbankdenken.

Hierarchien

• Hierarchien bedeuten, dass du durch Größe, Farbe und Design Elemente im Nutzerinterface nach Wichtigkeit und Relevanz einordnest.
• Durch klare hierarchische Struktur machst du die Software intuitiv bedienbar.
• Zeige den Nutzern durch Größe, Farbe und Nähe immer den Standard Pfad.

Beispiele

• Niemals Speichern und Abbrechen in der gleichen Farbe
• Es gibt in der Regel nur einen Standard Pfad
• Die primäre Aktion zum Beispiel Speichern ist am größten und am auffälligsten
• Die sekundäre Aktion zum Beispiel Abbrechen ist deutlich unauffälliger
• Aktionen die wir nicht möchten zum Beispiel Benutzerkonto löschen sind nochmals mehrere Stufen unauffälliger zum Beispiel nur noch grauer Link und kein Button

Farben

• Farben haben Bedeutung. Grün steht für alles gut, Gelb für Warnung, Rot für Fehler.
• Wenn eine CI Farbe bereits eine klare Bedeutung trägt, achte darauf, dass diese Bedeutung im Interface konsistent bleibt.

Gruppen

• Gruppiere so viel wie möglich. Gruppierung bringt Übersicht
• Gruppiere Formularfelder, die zusammengehören
• Richte Gruppen an anderen Elementen aus. Ziel ist es, dass nur wenige horizontale Linien im Layout entstehen

Größen

• Beachte die natürliche Größe von Elementen.
• PLZ ist kürzer als Ort, Hausnummer ist kürzer als Straße.

Beispiel für Adress Eingabe

 XXXXXX XXXXXX Vorname Nachname
 XXXXXXXX XXXX Straße Hausnummer
 XXXX XXXXXXXX PLZ Ort

Weglassen und Ausblenden

• Zeige den Nutzern keine Felder oder Daten, die für sie nicht relevant sind (Bsp. ID-Feld).
• Diese Felder können über Checkboxen oder Links ein und ausgeblendet werden.

Listings und Tabellen

• Der Sinn von Tabellen ist es, dass sich ein Nutzer aus vielen Daten den gewünschten Datensatz auswählt um ihn zu bearbeiten oder anzuschauen.

• Unterstütze diesen Zweck indem du genau die Daten präsentierst, die für eine schnelle Übersicht benötigt werden.

• Eine Tabellenzelle sollte höchstens drei Aktions Buttons enthalten

• Wenn mehr Aktionen nötig sind, nutze ein Dropdown Menü

Selectbox

• Selectboxen mit über zwanzig Einträgen sind nur selten nutzerfreundlich.
• Denke über eine Selectbox mit Suche nach oder gruppiere Einträge mit <optgroup>.

Feedback

• Gib den Nutzern immer Feedback. Jede Aktion wird quittiert
• Im Standard nutzen wir Toast Nachrichten für Erfolg und Fehler
• Tritt ein Fehler auf, wird er unmittelbar am betroffenen Element angezeigt
• Eine Fehler Zusammenfassung an zentraler Stelle kann ein gutes Zusatz Element sein, ersetzt aber niemals die Fehlermeldung am Element
• Alle Buttons die eine Aktion mit Laufzeit auslösen zum Beispiel alle API Calls benötigen einen Loading Spinner zum Beispiel ein Font Awesome Icon mit Spin
• Wenn eine Nutzer Aktion eine E Mail an andere auslöst, kommuniziere das deutlich
  • Entweder in der Beschriftung der Schaltfläche zum Beispiel Speichern und E Mail an Name senden
  • Oder mit einem Hilfetext direkt beim Speichern Button

Bearbeiten von Ressourcen

Wir unterscheiden drei Arten

Eigene Seite

➕ Sehr flexibel
➕ Klare Navigation
➖ Kein direkter Bezug zum Ausgangselement
➖ Schnelle Wechsel zwischen Ressourcen sind nicht möglich

Modal

➕ Schnell und klein
➕ Direkter Bezug zum Eltern Element
➖ Keine Verschachtelung möglich

Inline Bearbeitung

➖ UI kann komplex wirken
➖ Unklarer Flow wann werden Daten gespeichert

Überlege genau welche Art im konkreten Fall sinnvoll ist.
Auch die Bearbeitungsart bleibt im Projekt durchgängig.

Es ist möglich die eigene Seite und Modals parallel zu nutzen jedoch immer klar definiert und durchgängig.

Beispiel Flow

• Im Listing führt der Klick immer auf eine eigene Seite
• Beim Bearbeiten der Ressource werden Unterressourcen im Modal bearbeitet

Achtung Wenn du Modals nutzen möchtest, kannst du kein Modal im Modal verwenden.
Besitzt eine Ressource Unterressourcen, ist ein Modal kritisch. Die Unterressource müsste dann inline bearbeitbar sein.
Prüfe bereits in der Konzeption alle Eventualitäten, damit du Modals im gesamten Projekt konsistent nutzen kannst.