Windows-App-UX-Design - Prioritäten nach Nutzungsumgebung

Wer beim UX einer Windows-App zuerst danach fragt, ob sie modern aussieht oder ob die Weißräume gut wirken, bringt die Reihenfolge leicht durcheinander.

Auf dem Windows-Desktop entscheidet sich UX nicht allein über das Aussehen.

• Wie weit lässt sich die Bedienung allein mit der Tastatur abschließen?
• Ist die App auf Maus- oder auf Touch-Bedienung ausgelegt?
• Wird sie über Stunden genutzt oder nur gelegentlich für ein paar Minuten?
• Handelt es sich um Monitoring, Dateneingabe oder ein Terminal vor Ort?
• Was geht kaputt, wenn ein Fehler passiert?
• Hält sie Textskalierung, Kontrastthemen und assistiven Technologien stand?

All das zusammen ist UX.

Erschwerend kommt hinzu, dass B2C und B2B unterschiedliche Schwerpunkte haben. Wer daraus jedoch schließt, „B2B heißt einfach Informationen hineinstopfen“ oder „B2C heißt einfach leicht und locker bauen“, läuft fast immer irgendwo gegen die Wand.

Selbst innerhalb von B2B unterscheiden sich die Bedingungen für gutes UX erheblich – etwa zwischen

• Bürotätigkeiten wie Buchhaltungseingaben oder Auftragsverwaltung,
• Terminals vor Ort in Fabriken, Lagern, am Empfang oder an Prüfgeräten,
• Betriebsbildschirmen für 24-Stunden-Überwachung und Wartungsreaktion.

Umgekehrt unterscheiden sich auch innerhalb von B2C

• kleine Utilities für Privatanwender und
• fortgeschrittene Tools wie Bildbearbeitung, Musikproduktion oder Anlageanalyse

völlig in Bezug auf UI-Dichte und Anforderungen an Tastenkürzel.

Auch Microsofts Design-Leitfaden für Windows legt Wert darauf, dass Windows-App-Design intuitiv und barrierefrei ist und über Eingabemethoden und Formfaktoren hinweg konsistent funktioniert.¹²

Dieser Artikel ordnet die UX von Windows-Apps als Entscheidungstabelle nach Einsatzzweck. Ziel ist es, bei Design-Reviews oder in der frühen Phase des Bildschirmentwurfs leichter klären zu können, „was diese App priorisieren sollte“.

Zielgruppe und Voraussetzungen dieses Artikels

In diesem Artikel verwendete Begriffe

1. Zuerst das Fazit

Grob vorweggenommen, sieht es so aus:

• Bei B2C priorisieren Sie zunächst leichte Verständlichkeit beim ersten Kontakt, ein Gefühl von Sicherheit, wenige Einstellungen und einen unkomplizierten Ablauf
• Bei B2B priorisieren Sie zunächst kontinuierliche Effizienz, Vermeidung von Fehlbedienungen, Tastaturunterstützung und ein stabiles Layout
• Bei B2B-Terminals vor Ort haben jedoch Klarheit, große Bedienelemente und kurze Abläufe Vorrang vor Dichte
• Bei B2C-Tools für fortgeschrittene Anwender haben Informationsdichte, Tastenkürzel und Anpassbarkeit Vorrang vor Einfachheit
• Bei Windows-Apps bricht das Design später seltener, wenn UX auch Tastatur, Maus, Touch, Textskalierung, Kontrastthemen und assistive Technologien einbezieht¹³⁴⁵⁶⁷

Was zuerst wirklich entschieden werden muss, ist nicht nur B2C oder B2B. Zunächst sollten diese fünf Punkte konkret formuliert werden.

1. Wer nutzt sie (Anfänger, erfahrene Anwender, gemischt)
2. Wo wird sie genutzt (Schreibtisch, Besprechungsraum, vor Ort, Fabrik, Empfang, im Freien)
3. Womit wird sie bedient (Tastatur, Maus, Touch, Stift, Barcode, assistive Technologien)
4. Wie oft wird sie genutzt (überwiegend beim ersten Mal, gelegentlich, täglich, den ganzen Tag)
5. Was kostet ein Fehler (gering, hoch, gefährlich, prüfungsrelevant)

Sind diese fünf Punkte geklärt, lassen sich die Prioritäten für UI-Dichte, Navigation, Tastenkürzel, Bestätigungsdialoge und Anpassbarkeit deutlich leichter festlegen.

2. B2C/B2B ist ein Einstieg, aber nicht die Antwort

Die Einteilung in B2C und B2B ist als erster Einstiegspunkt praktisch. Allerdings ist es weniger die Art des Käufers als die Art der Nutzung, die stärker bestimmt, was die richtige UX ist.

Betrachtet man das grob entlang zweier Achsen, ergibt sich etwa folgendes Bild.

Mit anderen Worten gilt nicht:

• B2C = immer ein leichtes UI
• B2B = immer ein hochdichtes UI

Auch der Design-Leitfaden für Windows-Apps legt Wert darauf, über Geräte, Eingabearten und Formfaktoren hinweg konsistent nutzbar zu sein, und aus Sicht der Barrierefreiheit wird es als wichtig angesehen, nicht nur eine Behinderung, sondern auch Umgebungseinschränkungen wie helles Tageslicht im Freien, gemeinsam genutzte Räume, ruhige Orte und laute Orte zu berücksichtigen.¹²

Es empfiehlt sich daher, nach der Betrachtung von B2C/B2B zusätzlich entlang der folgenden Achsen zu unterscheiden.

Wird diese Unterscheidung vorab getroffen, verringern sich Diskussionen in Meetings über ein vages „wirkt irgendwie modern“ oder „wirkt irgendwie geschäftsmäßig“ erheblich.

3. Die Entscheidungstabelle nach Einsatzzweck auf einen Blick

Zunächst die in der Praxis am nützlichste Tabelle.

Schon diese Tabelle allein zeigt die grobe Richtung. Besonders wichtig ist, dass selbst bei B2B ein hochdichtes UI für Terminals vor Ort nicht die richtige Antwort ist und dass selbst bei B2C bei Tools für fortgeschrittene Anwender Effizienz wichtiger ist als Leichtigkeit.

Wer es eilig hat, kann an dieser Stelle aufhören. Das folgende Kapitel 4 vertieft jede Zeile dieser Tabelle bis hin zu „warum das so ist“ und „was konkret hingehört“. Es lässt sich so nutzen, dass man die gleichen Schlussfolgerungen wie in der Tabelle nicht noch einmal liest, sondern nur die Entscheidungsgrundlagen, die in der Tabelle keinen Platz hatten.

4. Gestaltungsrichtlinien nach Einsatzzweck

4.1 B2C-Utilities/Apps für Privatanwender

Bei kleinen B2C-Windows-Apps zählt vor allem eines: „sofort nach dem Start nutzbar sein“.

Besonders wichtig sind dabei diese Punkte:

• Der erste Bildschirm macht klar, was die App tut
• Die Hauptfunktionen sind auf ein oder zwei Aktionen reduziert
• Der Leerzustand wirkt nicht unfreundlich
• Riskante Aktionen lassen sich rückgängig machen
• Nicht von Anfang an alle Einstellungen zeigen

Ein häufiger Fehler ist es, alles aufzulisten, was technisch möglich ist. Bei leichten B2C-Tools ist jedoch häufig sofortige Nutzbarkeit wertvoller als Funktionsreichtum.

Auch der Windows-Leitfaden zum Navigationsdesign betont, dass es keine für alle Apps gültige Lösung gibt und zunächst Konsistenz, Einfachheit und Klarheit im Vordergrund stehen. Standardsteuerelemente und übliche Platzierungen machen die Bedienung vorhersehbarer.⁸

Für B2C-Apps reicht daher oft folgende Struktur:

• Bei kleinem Umfang ein einzelner Bildschirm
• Bei parallelen Abschnitten obere Navigation
• Einstellungen schrittweise zeigen
• Die Hauptaktion hell hervorheben, alles Übrige zurückhaltend gestalten

Anders sieht es allerdings aus, wenn eine B2C-App wie Fotobearbeitung, Videoschnitt, Komposition, Anlageanalyse oder Entwicklertools an fortgeschrittene Anwender gerichtet ist. In diesem Fall führt ein Blick auf Erfahrungsgrad und Nutzungsdauer eher zur richtigen Lösung als das Label B2C.

4.2 B2B Bürotätigkeiten/Backoffice

Bei B2B-Apps für Bürotätigkeiten zählt weniger die visuelle Leichtigkeit als vielmehr, dass die Arbeit nicht ins Stocken gerät.

Tägliche Nutzer gewöhnen sich innerhalb weniger Tage an das UI. Danach werden folgende Aspekte entscheidend:

• Wie weit kommt man allein mit der Tastatur?
• Lässt sich leicht zwischen Liste und Detail wechseln?
• Sind wichtige Spalten und Zustände auf einen Blick erkennbar?
• Bleiben Filter und Sortierung erhalten?
• Lassen sich Fehler direkt vor Ort korrigieren?

Auch Microsofts Leitfaden zur Tastatur-Barrierefreiheit betont, dass Apps mit der Tastatur alle Funktionen erreichbar machen sollten, und empfiehlt Tab-Reihenfolge, Fokus, Bedienung mit Enter/Leertaste sowie die Implementierung von Tastenkürzeln.³

Zugriffstasten steigern zudem nicht nur die Barrierefreiheit, sondern auch die Effizienz von Power-Usern, die die Tastatur bevorzugen. Wo sinnvoll, wird empfohlen, Zugriffstasten auch in benutzerdefinierten Steuerelementen zu unterstützen.⁹

Für Dateneingabe ist Liste/Detail eine solide Navigationswahl. Auch der Windows-Navigationsleitfaden weist darauf hin, dass sich Liste/Detail für Fälle eignet, in denen häufig zwischen Elementen gewechselt und dabei Details angezeigt oder aktualisiert werden, etwa bei Posteingängen, Kontaktlisten und Dateneingabe.⁸

Ein naheliegender Aufbau sieht demnach so aus:

• Links die Funktionskategorien
• In der Mitte die Liste
• Rechts oder unten das Detail bzw. die Bearbeitung
• Oben Suche, Filter und die wichtigsten Befehle
• Häufig genutzte Aktionen mit Tastenkürzeln

Umgekehrt sind folgende Muster zu vermeiden:

• Ein Dialog bei jeder einzelnen Aktion
• Zu wenige Spalten, sodass die Liste schwer zu überblicken ist
• Wichtige Aktionen nur über das Kontextmenü erreichbar
• Bedeutung ausschließlich über Symbole vermitteln wollen
• Eine chaotische Tab-Reihenfolge, bei der weder Enter noch Leertaste funktionieren

Auch bei Eingabefehlern gilt: Validierungsfehler, die an ein Feld gebunden sind, sollten im Bildschirm selbst und nicht in einem Dialog erscheinen. Auch der Windows-Leitfaden zu Dialogen empfiehlt, bei kontextgebundenen Validierungsfehlern – etwa bei Passwortfeldern – keinen Dialog, sondern eine Inline-Anzeige zu verwenden.¹⁰

4.3 B2B Monitoring/Betrieb

Bei Monitoring- und Betriebsbildschirmen kommt noch vor „einfach zu bedienen“ das Prinzip: nichts übersehen, nichts falsch machen, nichts anhalten.

Die Prioritäten liegen hier ungefähr so:

• Das Vorhandensein einer Anomalie ist auf einen Blick erkennbar
• Der Schweregrad der Anomalie ist klar
• Nicht nur der aktuelle Wert, sondern auch Veränderungen und der zeitliche Verlauf lassen sich nachvollziehen
• Der Weg zu gefährlichen Aktionen ist nicht zu leichtgängig
• Protokolle, Historie und Ursachenermittlung sind einen Klick entfernt

In dieser Art von Bildschirm steht die Zustandsdarstellung im Zentrum der UX. Zustände sollten möglichst über mehrere Elemente ausgedrückt werden – Farbe + Text + Symbol + Uhrzeit. Wird der Zustand nur über Farbe vermittelt, steigt die Gefahr von Übersehen und Fehlinterpretation, und auch aus Sicht der Barrierefreiheit ist das schwach.¹¹

Bei der Navigation ist bei vielen überwachten Zielen die linke Navigation sinnvoll, das Vertiefen einzelner Ziele erfolgt über Drilldown, Details werden als Protokoll oder Zeitreihe angezeigt. Auch der Windows-Navigationsleitfaden weist darauf hin, dass sich linke Navigation für viele Elemente der obersten Ebene eignet sowie für Strukturen, bei denen nicht ständig zwischen Seiten gewechselt wird.⁸

Auf der Bedienungsseite ist es ebenfalls riskant, einen Befehl nur an einer einzigen Stelle anzubieten. Der Windows-Leitfaden zum Befehlsdesign empfiehlt, Befehle über mehrere Oberflächen – Schaltflächen, Kontextmenüs, Tastenkürzel, Gesten – verfügbar zu machen und alle relevanten Befehle in ein Kontextmenü oder ein CommandBarFlyout aufzunehmen. Wer sich ausschließlich auf per Hover erscheinende Aktionen verlässt, macht sie auf Touch-Geräten und mit assistiven Technologien unbenutzbar.¹²¹³

Bestätigungsdialoge für gefährliche Aktionen sind hier ebenfalls wichtig. Allerdings ist „vorsichtshalber alles bestätigen“ kontraproduktiv. Wirklich bestätigt werden sollten die eher unumkehrbaren Aktionen: Stoppen, Löschen, Umschalten, Sperren, Überschreiben. Wird ein Dialog angezeigt, sollten mindestens diese drei Punkte gelten:

• In der ersten Zeile klar beschreiben, was passiert
• Schaltflächentexte konkret formulieren – Löschen/Stoppen/Sperren statt OK/Ja
• Stets eine sichere Option anbieten

¹⁰

4.4 B2B Terminals vor Ort/Geräte-UI/Kioske

Terminals vor Ort sind innerhalb der Windows-App-UX eine ziemlich andere Spezies.

• Der Nutzer sitzt nicht
• Er trägt möglicherweise Handschuhe
• Nur eine Hand ist frei
• Der Bildschirm wird nicht genau studiert
• Es besteht Zeitdruck
• Genutzt wird an hellen oder lauten Orten

Diese Bedingungen sind ganz normal.

Auch Microsofts Leitfaden zur Barrierefreiheit betont, dass eine gute Windows-App Umgebungseinschränkungen berücksichtigen sollte – nicht nur eine Behinderung, sondern auch Situationen wie grelles Sonnenlicht, gemeinsam genutzte Räume, Lärm, Stille oder das Kochen.²

Beim Touch-Design gibt es außerdem Unterschiede wie:

• Touch kennt kein Hover
• Finger und Hand verdecken (Occlusion) die UI
• Manche Bereiche des Bildschirms sind aufgrund der Handhaltung schwer zu treffen
• Visuelles Feedback ist wichtig

⁴

Für Terminals vor Ort empfiehlt sich daher meist diese Ausrichtung:

• Schaltflächen und Listenelemente ausreichend groß
• Möglichst ein Ziel pro Bildschirm
• Die Reaktion nach einer Aktion deutlich sichtbar machen
• Den Ablauf in Schritte gliedern
• Eingaben möglichst über Auswahl, Scan oder feste Vorgaben statt Freitext
• Zustände klar oben oder mittig im Bildschirm anzeigen

Zu vermeiden sind dagegen:

• Kleine Schrift
• Kleine Trefferbereiche
• Abhängigkeit von Hover-basierten Tooltips
• Tiefe Hierarchien
• Große Informationsmengen auf einem Bildschirm
• Lange Freitexteingaben

Der pauschale Gedanke, „bei B2B ist hohe Dichte besser“, geht in diesem Bereich am häufigsten daneben. Hier gilt eher: Klarheit vor allem anderen – selbst innerhalb von Fachanwendungen.

4.5 Editier-/Analysetools für Experten

Bei Tools für Experten kann „mach es verständlicher“ gegenüber „lass mich nicht innehalten müssen“ verlieren.

Beispiele sind:

• CAD
• Signalanalyse
• Videoschnitt
• Bildverarbeitung
• Musikproduktion
• Entwicklertools
• Datenanalyse
• Audit-/Diagnosetools

Bei dieser Art von App zahlen sich folgende Elemente aus:

• Informationsdichte
• Mehrere Bereiche
• Tabs
• Kontextmenüs
• Tastenkürzel
• Gespeicherte Layouts
• Anpassbare Spalten und Anzeigefelder
• Rückgängig/Wiederholen
• Wiederherstellung des Arbeitszustands

Auch der Windows-Navigationsleitfaden weist darauf hin, dass sich Tabs eignen, wenn mehrere Seiten oder Dokumente geöffnet, geschlossen und neu angeordnet werden sollen.⁸ Und das Windows-Befehlsdesign empfiehlt, Befehle über mehrere UI-Oberflächen hinweg gemeinsam zu nutzen, sodass dieselbe Aktion unabhängig von der Eingabemethode erreichbar ist.¹²

Der übliche Fehler bei dieser Art von Tool besteht darin, aus Freundlichkeit zu Einsteigern alles in tiefen Menüs zu verstecken. Erfahrene Anwender führen dieselbe Aktion jedoch hunderte Male am Tag aus. Für sie zählt weniger die Freundlichkeit in den ersten fünf Minuten als vielmehr, nach 100 Nutzungsstunden nicht erschöpft zu sein.

Für fortgeschrittene Anwender bewährt sich daher folgender Ansatz:

• Häufig genutzte Aktionen nah beieinander
• Hilfsfunktionen etwas weiter entfernt
• Erweiterte Funktionen ordnen statt löschen
• Anzeigelayouts speichern
• Die Tastaturbedienung umfangreich gestalten

4.6 Residente Tools/Tray-Apps

Bei residenten Apps ist es gerade die zurückhaltende Präsenz, die die UX ausmacht.

Bei Apps wie zum Beispiel

• Synchronisationsstatus
• Verbindungsstatus
• Backup
• Umschaltung von Audio/Kamera/Gerät
• VPN/Agent/Launcher
• Benachrichtigungszentrale

steht das Hauptfenster oft nicht im Mittelpunkt.

Priorität haben:

• Schneller Zugriff über das Tray oder ein kleines Menü
• Der aktuelle Zustand ist erkennbar
• Benachrichtigungen nur bei Bedarf
• Benachrichtigungen führen direkt zur nötigen Aktion
• Das Hauptfenster beansprucht nicht zu sehr den Vordergrund

Zu vermeiden:

• Dialoge für Nebensächlichkeiten
• Das Hauptfenster bei jedem Start öffnen
• Nicht sichtbare Hintergrundaktivität
• So viele Benachrichtigungen, dass alle ignoriert werden

Bei dieser Art von App entscheidet eher nicht zu stören über die UX als viele Funktionen zu haben.

5. Die Entscheidungstabelle für die Navigation

Der Windows-Navigationsleitfaden stellt fest, dass es kein einzelnes Navigationsdesign gibt, das für jede App funktioniert, und macht Konsistenz, Einfachheit und Klarheit zu den leitenden Prinzipien. Zusätzlich wird die UI vorhersehbarer, wenn Standardsteuerelemente dort platziert werden, wo Nutzer sie erwarten.⁸

In der Praxis lässt sich mit dieser Tabelle gut arbeiten.

Der Windows-Navigationsleitfaden nennt insbesondere folgende Unterscheidung.⁸

• Obere Navigation: wenn alle Navigationspunkte auf dem Bildschirm sichtbar sein sollen
• Linke Navigation: bei vielen Elementen der obersten Ebene, wenn nicht ständig zwischen Seiten gewechselt wird
• Liste/Detail: bei häufigem Elementwechsel mit Bedarf an Detailanzeige oder -aktualisierung
• Tabs: wenn mehrere Dokumente oder Seiten dynamisch geöffnet und geschlossen werden sollen
• Breadcrumbs: bei tiefer Hierarchie, wenn der Rückweg klar erkennbar sein soll

5.1 Wireframes als reines Grundgerüst

Nur mit Worten lässt sich das Bild schwer greifen, daher folgen vier repräsentative Grundgerüste. Ignorieren Sie die Details und achten Sie nur darauf, was wo platziert ist.

[ Obere Navigation ]  Wenn gleichrangige Seiten alle sichtbar sein sollen
+-------------------------------------------------------------
| AppName        Start | Konvertieren | Verlauf | Einstellungen
+-------------------------------------------------------------
|
|    Hauptinhalt
|    Möglichst ein Ziel pro Bildschirm
|
+-------------------------------------------------------------


[ Linke Navigation ]  Bei vielen Elementen der obersten Ebene
+-------------------------------------------------------------
| AppName                                 Suche [           ]
+-------------------------------------------------------------
| Dashboard       |
| Geräteliste     |    Hauptinhalt
| Alarme          |
| Aufträge        |
| Berichte        |
| Einstellungen   |
+-------------------------------------------------------------


[ Liste/Detail ]  Zwischen Elementen wechseln, Details ansehen und aktualisieren
+-------------------------------------------------------------
| Suche [          ]  Filter: Offen / Alle          [Neu] [Löschen]
+-------------------------------------------------------------
| Liste            |  Detail/Bearbeitung
|  > Beleg 1001    |    Belegnummer   1001
|    Beleg 1002    |    Geschäftspartner  ...
|    Beleg 1003    |    Positionen    ...
|    Beleg 1004    |
|                  |    [ Speichern ]   [ Abbrechen ]
+-------------------------------------------------------------


[ Dashboard + Drilldown ]  Anomalien finden und vertiefen
+-------------------------------------------------------------
| Gesamt   Normal 22   Warnung 3   Fehler 1   Aktualisiert vor 0,5 s
+-------------------------------------------------------------
| 1 Fehler
|   ! Linie B Prüfgerät      Keine Antwort    vor 48 s    [ Detail ]
| 3 Warnungen
|   - Linie A Kamera         Wert veraltet    vor 12 s    [ Detail ]
|   ...
+-------------------------------------------------------------
              |
              |  Klick auf [ Detail ]
              v
+-------------------------------------------------------------
| < Zurück zur Liste     Linie B Prüfgerät / Keine Antwort
+-------------------------------------------------------------
| Aktueller Wert | Zeitreihendiagramm | Ereignisprotokoll | Aktion
+-------------------------------------------------------------

Stellt man die vier nebeneinander, wird die Auswahlachse klar.

• Der Unterschied zwischen oberer und linker Navigation liegt in der Anzahl der Elemente der obersten Ebene. Passt alles nebeneinander in eine Zeile, wählen Sie oben; passt es nicht, wählen Sie links
• Der eigentliche Hauptdarsteller bei Liste/Detail ist nicht die rechte Seite, sondern die Liste links. Reicht der Informationsgehalt der Liste nicht aus, muss das Detail immer wieder neu geöffnet werden
• Beim Dashboard steht die entscheidende Kennzahl „wie viele Anomalien gibt es“ in der ersten Zeile. Geht man in die Tiefe, muss immer ein Rückweg vorhanden sein

Navigation ist letztlich keine „Geschmacksfrage“, sondern spiegelt die Informations- und Arbeitsstruktur wider.

6. Die Entscheidungstabelle für Eingabegeräte und Befehlsdesign

Windows-Apps werden flexibler und benutzerfreundlicher, je mehr Eingabemethoden sie unterstützen. Auch Microsofts Leitfaden empfiehlt, möglichst viele Eingaben zu berücksichtigen: Gesten, Sprache, Touch, Touchpad, Maus und Tastatur.¹⁴

Da die Plattform-Steuerelemente von Windows mehrere Eingabemethoden bis zu einem gewissen Grad selbst abfedern, ist es zudem stark, Standardsteuerelemente einfach zu verwenden.⁴⁸

In eine praxistaugliche Form gebracht, ergibt sich Folgendes:

Rund um die Tastatur sind besonders folgende Punkte wichtig.³⁹

• Alle Funktionen sind allein mit der Tastatur erreichbar
• Die Tab-Reihenfolge weicht nicht stark von der visuellen Reihenfolge ab
• Elemente, die mit Enter/Leertaste bedienbar sein sollten, funktionieren auch tatsächlich so
• Wichtige Funktionen besitzen Tastenkürzel
• Für häufig genutzte Aktionen gibt es Zugriffstasten oder Beschleuniger

Beim Touch gelten folgende Eigenschaften.⁴

• Es gibt kein Hover
• Finger und Hand verdecken die UI
• Trefferbereiche wirken kleiner als sie aussehen
• Visuelles Feedback ist erforderlich
• Eine für direkte Bedienung geeignete UI unterscheidet sich von einer für indirekte Eingabe geeigneten UI

6.1 Nicht „ausreichend groß“, sondern über Zahlen entscheiden

In Design-Reviews wird häufig gestritten, wenn man bei „ausreichend groß“ oder „deutlich genug“ stehen bleibt. Wo Microsofts Leitfaden konkrete Zahlen nennt, verkürzt es die Diskussion erheblich, diese Zahlen direkt als Abnahmekriterium zu verwenden.

Sind die Werte einmal festgelegt, ändert sich auch die Art des Feedbacks im Review. Statt „ist diese Schaltfläche nicht zu klein“ heißt es dann „diese Schaltfläche misst 32 px und erreicht damit nicht den Richtwert von 7,5 mm“ – und die Entscheidung, ob korrigiert wird, fällt direkt vor Ort.

Die Standardsteuerelemente von WinUI sind übrigens standardmäßig so gestaltet, dass sie dieser Zielgröße entsprechen.¹⁵ Umgekehrt bedeutet das: Gefährlich sind allein selbst erstellte Steuerelemente und eigene Zeichenroutinen.

Beim Befehlsdesign lohnt sich ein Blick in den Windows-Leitfaden zu Befehlen. Besonders wichtig ist, Befehle über mehrere UI-Oberflächen verfügbar zu machen.¹²

• Über eine Schaltfläche auslösbar
• Auch im Kontextmenü vorhanden
• Auch per Tastenkürzel aufrufbar
• Bei Bedarf auch per Wisch- oder Gestenbedienung

Und es wird empfohlen, alle relevanten Befehle in Kontextmenüs oder CommandBarFlyouts aufzunehmen. Wer sich auf nur bei Hover sichtbare Aktionen verlässt, gerät auf reinen Touch-Geräten ins Stocken.¹²

7. UX-Punkte, die bei einer Windows-App mindestens erfüllt sein sollten

Ab hier folgen die Mindestanforderungen, die unabhängig vom Einsatzzweck gelten.

7.1 Lässt sich alles mit der Tastatur erledigen?

Auf dem Windows-Desktop ist die Tastatur nicht nur „praktisch, wenn vorhanden“, sondern ein zentrales Eingabemittel.

Auch Microsofts Leitfaden zur Tastatur-Barrierefreiheit betont, dass Tastaturunterstützung nicht nur für Nutzer mit visuellen oder motorischen Einschränkungen wichtig ist, sondern auch für Nutzer, die die Tastatur aus Effizienzgründen wählen.³

Mindestens diese fünf Punkte sollten geprüft werden:

• Ist die Tab-Reihenfolge natürlich?
• Ist der Fokus visuell erkennbar?
• Lässt sich mit Enter/Leertaste bedienen?
• Gibt es Tastenkürzel?
• Lässt sich eine dem Rechtsklick entsprechende Aktion auch über die Tastatur aufrufen?

Unauffällig, aber wenn dieser Punkt zusammenbricht, leidet die B2B-UX erheblich.

7.2 Textskalierung, Kontrastthemen und Barrierefreiheit

Bei Windows-Apps stabilisiert es die UX erheblich, wenn Schriftgröße und Kontrast einfach korrekt mitgeführt werden.

Microsofts Leitfaden empfiehlt für sichtbaren Text ein Kontrastverhältnis von mindestens 4,5:1 und verlangt, dass bei vergrößertem Text auch Steuerelemente und Container mitskaliert und neu angeordnet werden.⁵⁶

Bei Kontrastthemen wird zudem empfohlen:

• Farben nicht fest codieren
• SystemColor-/Brush-Ressourcen verwenden
• Mit den vier Kontrastthemen testen

⁷

Häufige Schwachstellen sind:

• Beschriftungen mit fester Breite
• Schaltflächen mit fester Pixelhöhe
• Design, das Bedeutung ausschließlich über Farbe vermittelt
• Eigene Zeichenroutinen, die dem Thema nicht folgen

Das ist weniger „Barrierefreiheits-Konformität“ als vielmehr das Fundament für eine Windows-UI, die auf Dauer nicht bricht.

7.3 Dialoge nicht überstrapazieren

Dialoge sind praktisch, aber bei zu häufigem Einsatz werden sie zum Feind der Arbeit.

Der Windows-Leitfaden zu Dialogen definiert einen Dialog als modale UI für Fälle, in denen Benachrichtigung, Zustimmung oder eine zusätzliche Eingabe erforderlich ist, und empfiehlt, mindestens eine sichere, nicht destruktive Aktion (Close, Cancel usw.) anzubieten. Zudem sollten Schaltflächentexte konkrete Antworten formulieren.¹⁰

Wichtig ist, nicht alles zu einem Dialog zu machen.

Insbesondere:

• Feldbezogene Eingabefehler
• Formatfehler, die sich direkt korrigieren lassen
• Vorübergehende Hinweise

sollten möglichst als Inline-Anzeige erscheinen.¹⁰

7.4 Wichtige Befehle über mehrere Wege anbieten

Das Windows-Befehlsdesign legt Wert darauf, dass wichtige Befehle über verschiedene Eingabemethoden und UI-Oberflächen aufrufbar sind.¹²¹³

Das zahlt sich auch in der Praxis regelmäßig aus.

Bei „Löschen“ zum Beispiel sorgen mehrere Wege wie

• Symbolleiste
• Kontextmenü
• Entf-Taste
• bei Bedarf Wischgeste

für eine stabile Bedienbarkeit.

Umgekehrt werden Designs wie

• nur bei Hover am rechten Rand sichtbar
• nur per Rechtsklick erreichbar
• über die Tastatur überhaupt nicht erreichbar

plötzlich schwach, sobald sich die Eingabemethode ändert.

7.5 Mit Testwerkzeugen überprüfen

Bei der Barrierefreiheit geht es schneller, mit Werkzeugen nachzusehen, als im Kopf „wird schon passen“ zu denken.

Microsofts Leitfaden zum Testen der Barrierefreiheit stellt Live Inspect, FastPass und Troubleshooting mit Accessibility Insights for Windows vor, und zusätzlich lassen sich mit dem SDK-Tool Inspect UI-Automation-Attribute und die Navigationsstruktur prüfen.¹⁷

Mindestens sollten Sie:

• mit Accessibility Insights grob durchgehen
• mit Inspect Namen, Rolle und Muster der wichtigsten Elemente prüfen
• die Hauptabläufe allein mit der Tastatur durchlaufen
• Textskalierung und Kontrastthemen ausprobieren

Das reduziert spätere Nacharbeit bereits deutlich.

7.6 Wiederherstellbarkeit einbauen

Das ist weniger ein Punkt aus Microsofts Ein-Zeilen-Checkliste als vielmehr etwas, das sich in der Praxis des Windows-Desktops erheblich auszahlt.

UX entscheidet sich nicht nur über „Schaltflächen, die sich gut anfühlen“, sondern darüber, nach einem Missgeschick wieder zurückzufinden.

Zum Beispiel:

• Rückgängig/Wiederholen
• Automatisches Speichern
• Erhalt des Bearbeitungszustands
• Wiederherstellung von Filtern/Sortierung/Spaltenbreiten
• Unterbrechen und Fortsetzen
• Fortschrittsanzeige und Abbruchmöglichkeit bei langen Vorgängen

wirken sich weit stärker auf die UX aus als das reine Erscheinungsbild.

Besonders bei B2B- und Experten-Tools führt der Stress erneuter Eingabe unmittelbar zu schlechter UX.

8. Häufige Gestaltungsfehler

8.1 Annehmen, „B2B heißt hohe Dichte“

Das ist nur zur Hälfte richtig.

Bei täglich genutzten Apps für erfahrene Anwender kann hohe Dichte funktionieren. Bei Terminals vor Ort, Empfangsterminals und Geräte-UIs ist Dichte jedoch eher der Feind.

Ein Blick auf Erfahrungsgrad, Eingabemethode und Nutzungsumgebung statt auf das Label B2B führt seltener in die Irre.

8.2 Bei B2C zu viele Funktionen verstecken

Auch bei Privatanwendern hat Effizienz oberste Priorität, wenn das Tool für erfahrene Nutzer gedacht ist.

Wird alles in Richtung „einfach wirken lassen“ getrimmt, beginnt eine stille Hölle:

• Häufig genutzte Aktionen sind weit entfernt
• Man gräbt sich ständig durch Menüs
• Der Bildschirm wechselt fortwährend

8.3 Auf Hover angewiesene Bedienung bauen

Touch kennt kein Hover. Zudem verträgt sich UI, die nur bei Zeigergeräten erscheint, häufig schlecht mit assistiven Technologien.⁴¹²

Wichtige Aktionen sollten immer sichtbar sein oder zumindest über mehrere Wege erreichbar bleiben.

Vorher: Nur bei Hover über die Zeile erscheinen die Aktionen am rechten Rand
  Beleg 1001   2026-03-18   offen                              <- nichts sichtbar
  Beleg 1002   2026-03-18   offen           [ Bearbeiten ][ Löschen ] <- nur bei Mauszeiger auf der Zeile

Nachher: Immer sichtbar + mehr Wege
  Beleg 1001   2026-03-18   offen           [ Bearbeiten ][ Löschen ]
  Beleg 1002   2026-03-18   offen           [ Bearbeiten ][ Löschen ]
     Rechtsklick  -> Bearbeiten / Löschen
     Tastatur     -> Enter zum Bearbeiten, Entf zum Löschen

8.4 Zustand nur über Farbe vermitteln

Besonders bei Monitoring-Bildschirmen häufig, aber gefährlich: Bedeutung nur über Rot/Gelb/Grün zu vermitteln.

Text, Symbol, Uhrzeit, Anzahl und Beschreibung zusammen verringern sowohl Übersehen als auch Fehlinterpretation.¹¹

8.5 Alle Validierungsfehler als Dialog anzeigen

Bei Anwendungen zur Dateneingabe häufig zu finden. Erscheint bei jeder Eingabe ein Dialog, ist der Arbeitsrhythmus vollständig zerstört.

Fehler, die auf einen Kontext begrenzt sind, wirken natürlicher, wenn sie direkt im Bildschirm angezeigt werden.¹⁰

Vorher: Für jedes Feld ein modaler Dialog
  Postleitzahl  [ 1234        ]        +------------------------------+
  Adresse       [             ]        | Die Postleitzahl hat kein gültiges Format
                                        |                       [ OK ]
                                        +------------------------------

Nachher: Direkt inline an Ort und Stelle
  Postleitzahl  [ 1234        ]
                ! Bitte geben Sie 7 Ziffern ein. Beispiel: 1234567
  Adresse       [             ]

8.6 Mit fest dimensioniertem Layout arbeiten

Bei 100 % Anzeige in der Entwicklungsumgebung mag es sauber aussehen, aber es bricht schnell zusammen bei:

• Textskalierung
• Hoher DPI
• Kontrastthemen
• Lokalisierung

⁶⁷

Vorher: Feste Beschriftungsbreite + feste Schaltflächenhöhe. Bei vergrößertem Text
  [ Lieferter... ][ 2026-03-1  ]      <- Beschriftung wird abgeschnitten, Wert läuft über
  [ Sp ][ Ab ]                          <- Schaltflächentext wird oben und unten abgeschnitten

Nachher: Layout, das sich am Inhalt orientiert
  Liefertermin
  [ 2026-03-18              ]
  [ Speichern ]   [ Abbrechen ]        <- Höhe ergibt sich aus Inhalt + Abstand

Je ausgereifter das Erscheinungsbild wird, desto stärker wird eine feste Größenannahme zum Gift.

8.7 Zu viele eigene Steuerelemente bauen

Die Standardsteuerelemente von Windows besitzen weit mehr Verhalten, als ihr Aussehen vermuten lässt.

Sie kümmern sich um:

• Fokus
• Tastatur
• Themenanpassung
• UI Automation
• Anbindung an assistive Technologien

Wer ohne Grund alles selbst baut, häuft daher UX- und Barrierefreiheits-Schulden an.⁸³

9. Acht Fragen, die vor dem Start zu klären sind

Zum Schluss acht Fragen, die sich gut an den Anfang eines Design-Reviews stellen lassen.

Werden diese acht Fragen vorab beantwortet, ergibt sich von selbst,

• ob die Navigation flacher sein sollte,
• ob Liste + Detail passend ist,
• ob in Tastenkürzel investiert werden sollte,
• wo Dialoge sinnvoll sind,
• wie viel Anpassung erlaubt werden soll.

10. Zusammenfassung

Beim UX-Design von Windows-Apps zählt vor allem, noch vor „sieht es gut aus“ zu klären, ob diese Person an diesem Ort mit dieser Eingabemethode ohne Unterbrechung arbeiten kann.

Grob zusammengefasst:

• B2C priorisiert Verständlichkeit beim ersten Kontakt und ein Sicherheitsgefühl
• B2B Bürotätigkeiten priorisieren kontinuierliche Effizienz und Tastaturunterstützung
• B2B Monitoring priorisiert das Vermeiden übersehener Anomalien und sichere Bedienung
• B2B-Terminals vor Ort priorisieren große Bedienelemente und kurze Abläufe
• Tools für Experten priorisieren Dichte, Tastenkürzel und Anpassbarkeit
• Residente Tools priorisieren, nicht zu stören

Und branchenübergreifend zahlen sich diese sechs Punkte aus:

1. Standardsteuerelemente einfach verwenden
2. Die Hauptaktionen lassen sich mit der Tastatur abschließen
3. Kein Stillstand bei Touch- oder assistiven Technologien
4. Kein Zusammenbrechen bei Textskalierung oder Kontrastthemen
5. Mehrere Wege zu wichtigen Befehlen
6. Ein Weg zurück nach einem Missgeschick

UX ist keine Dekoration, sondern ein Vertrag über die Bedienung. Je besser dieser Vertrag zu Nutzer, Umgebung und Eingabemethode passt, desto unauffälliger – aber verlässlicher – wird eine Windows-App nutzbar.

11. Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Sollten B2B-Fachanwendungen ein informationsdichtes, hochkompaktes UI haben?

Nur zur Hälfte. Bei täglich genutzten Bürotätigkeiten für erfahrene Anwender zahlt sich eine hohe Informationsdichte mit guter Übersicht und vollständiger Tastaturbedienung für die kontinuierliche Effizienz aus. Bei Terminals vor Ort und Geräte-UIs in Fabriken, Lagern oder am Empfang ist Dichte dagegen eher der Feind – hier sollten große Bedienelemente, kurze Abläufe und Klarheit Vorrang haben. Statt auf das Label B2B zu schauen, liegt man mit einem Blick auf Erfahrungsgrad, Eingabemethode und Nutzungsumgebung seltener daneben. Umgekehrt haben auch bei B2C-Anwendungen wie Bildbearbeitung oder Anlageanalyse, die sich an fortgeschrittene Anwender richten, Informationsdichte, Tastenkürzel und Anpassbarkeit Vorrang vor Einfachheit.

Was sollte beim UX-Design einer Windows-App zuerst entschieden werden?

B2C oder B2B allein reicht nicht aus – zunächst sollten fünf Fragen konkret beantwortet werden: Wer nutzt die App (Anfänger, erfahrene Anwender oder gemischt), wo wird sie genutzt (am Schreibtisch, vor Ort, im Freien, am Empfang), womit wird sie bedient (Tastatur, Maus, Touch, Scanner, assistive Technologien), wie oft wird sie genutzt (überwiegend beim ersten Mal, täglich, den ganzen Tag) und was kostet ein Fehler (gering, hoch, gefährlich, prüfungsrelevant). Sind diese fünf Punkte geklärt, lassen sich die Prioritäten für UI-Dichte, Navigation, Tastenkürzel, Bestätigungsdialoge und Anpassbarkeit deutlich leichter festlegen.

Wie wählt man das richtige Navigationsmuster aus?

Es gibt kein einziges Navigationsdesign, das für alle Apps funktioniert – Konsistenz, Einfachheit und Klarheit sind die leitenden Prinzipien. Als Faustregel gilt: obere Navigation eignet sich, wenn alle Navigationspunkte auf dem Bildschirm sichtbar sein sollen; linke Navigation eignet sich bei vielen Elementen der obersten Ebene; Liste/Detail eignet sich für Dateneingabe, bei der häufig zwischen Elementen gewechselt und Details angezeigt oder aktualisiert werden; Tabs eignen sich, wenn mehrere Dokumente dynamisch geöffnet und geschlossen werden sollen; Breadcrumbs eignen sich bei tiefen Hierarchien, in denen man den aktuellen Standort leicht aus den Augen verliert. Navigation ist keine Geschmacksfrage, sondern spiegelt die Informations- und Arbeitsstruktur wider.

Wie weit sollten Bestätigungsdialoge eingesetzt werden?

Wichtig ist, nicht alles zu einem Dialog zu machen. Feldbezogene Eingabefehler und Formatfehler, die sich direkt korrigieren lassen, wirken natürlicher als Inline-Anzeige im Bildschirm statt als Dialog. Wirklich bestätigt werden sollten eher unumkehrbare Vorgänge wie Stoppen, Löschen, Sperren oder Überschreiben. Wird ein Dialog angezeigt, sollten mindestens drei Dinge gelten: In der ersten Zeile klar beschreiben, was passiert; Schaltflächentexte konkret formulieren (z. B. „Löschen“ oder „Stoppen“ statt „OK“/„Ja“); und stets eine sichere, nicht destruktive Schaltfläche anbieten.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.