UX-Checkliste für Desktopanwendungen

Hinweis

Dieses Designhandbuch wurde für Windows 7 erstellt und wurde für neuere Versionen von Windows nicht aktualisiert. Ein Großteil der Anleitungen gilt immer noch grundsätzlich, aber die Präsentation und Beispiele spiegeln nicht unsere aktuelle Designanleitung wider.

Im Folgenden finden Sie eine Sammlung einiger wichtiger Richtlinien im UX-Leitfaden. Sie können dies als Checkliste verwenden, um sicherzustellen, dass diese wichtigen Elemente in der Benutzeroberfläche Ihres Programms richtig sind.

Windows

  • Unterstützt die effektive Windows-Mindestauflösung von 800 x 600 Pixeln. Unterstützen Sie für kritische Benutzeroberflächen (UIs), die im abgesicherten Modus funktionieren müssen, eine effektive Auflösung von 640 x 480 Pixeln. Achten Sie darauf, den von der Taskleiste verwendeten Platz zu berücksichtigen, indem Sie 48 vertikale relative Pixel für Fenster reservieren, die mit der Taskleiste angezeigt werden.
  • Optimieren Sie größenveränderbare Fensterlayouts für eine effektive Auflösung von 1024 x 768 Pixeln. Passen Sie die Größe dieser Fenster für niedrigere Bildschirmauflösungen automatisch an, wobei die Funktion erhalten bleibt.
  • Testen Sie Ihre Fenster unbedingt im Modus 96 dpi (bei 800 x 600 Pixeln), 120 dpi (bei 1024 x 768 Pixeln) und 144 dpi (bei 1200 x 900 Pixeln). Suchen Sie nach Layoutproblemen, wie z. B. dem Abschneiden von Steuerelementen, Text und Fenstern sowie dem Strecken von Symbolen und Bitmaps.
  • Optimieren Sie für Programme mit Touch- und mobilen Nutzungsszenarien auf 120 dpi. Bildschirme mit hoher DPI-Auflösung sind derzeit bei Touch- und Mobil-PCs weit verbreitet.
  • Handelt es sich bei einem Fenster um ein eigenes Fenster, wird es zunächst „zentriert“ über dem eigenen Fenster angezeigt. Nie darunter. Bei der nächsten Anzeige empfiehlt es sich, das Dialogfeld an seiner letzten Position (relativ zum Besitzerfenster) anzuzeigen, wenn dies wahrscheinlich praktischer ist.
  • Wenn ein Fenster kontextbezogen ist, zeigen Sie es immer in der Nähe des Objekts an, von dem aus es gestartet wurde. Platzieren Sie es jedoch außerhalb des Weges (am besten nach unten und rechts versetzt), damit das Objekt nicht durch das Fenster verdeckt wird.

Layout

  • Passen Sie die Größe von Steuerelementen und Bereichen innerhalb eines Fensters an ihren typischen Inhalt an. Vermeiden Sie abgeschnittenen Text und die damit verbundenen Auslassungspunkte. Benutzer sollten nie mit einem Fenster interagieren müssen, um dessen typischen Inhalt anzuzeigen. Größenanpassung und Scrollen sollten bei ungewöhnlich großen Inhalten vorbehalten sein. Überprüfen Sie insbesondere Folgendes:
    • Größe von Steuerelementen. Passen Sie die Größe der Steuerelemente ihrem typischen Inhalt an und machen Sie die Steuerelemente bei Bedarf breiter, höher oder mehrzeilig. Größensteuerelemente zum Beseitigen oder Reduzieren des Bildlaufs in Fenstern mit viel verfügbarem Platz. Darüber hinaus sollten Beschriftungen oder Text in Fenstern mit viel freiem Platz niemals abgeschnitten werden. Um den Text leichter lesbar zu machen, sollten Sie die Zeilenbreite jedoch auf 65 Zeichen begrenzen.
    • Spaltenbreiten. Stellen Sie sicher, dass die Spalten der Listenansicht eine geeignete Standard-, Mindest- und Maximalgröße haben. Wählen Sie für Listenansichten Standardspaltenbreiten, die nicht zu abgeschnittenem Text führen, insbesondere wenn in der Listenansicht Platz vorhanden ist.
    • Layout-Balance. Das Layout eines Fensters sollte ungefähr ausgewogen wirken. Wenn das Layout zu linkslastig erscheint, können Sie die Steuerelemente breiter machen und einige Steuerelemente weiter nach rechts verschieben.
    • Layoutgröße ändern. Wenn die Größe eines Fensters veränderbar ist und Daten abgeschnitten werden, achten Sie darauf, dass bei größeren Fenstergrößen mehr Daten angezeigt werden. Wenn Daten abgekürzt werden, erwarten Benutzer, dass durch das Ändern der Fenstergröße mehr Informationen angezeigt werden.
  • Legen Sie eine Mindestfenstergröße fest, wenn es eine Größe gibt, unterhalb derer der Inhalt nicht mehr nutzbar ist. Legen Sie für skalierbare Steuerelemente die Mindestgröße skalierbarer Elemente auf ihre kleinsten funktionalen Größen fest, z. B. die minimale funktionale Spaltenbreite in Listenansichten.

Text

  • Verwenden Sie nach Möglichkeit normale, umgangssprachliche Begriffe. Konzentrieren Sie sich auf die Benutzerziele, nicht auf Technologie. Dies ist besonders effektiv, wenn Sie ein komplexes technisches Konzept oder eine komplexe Aktion erläutern. Stellen Sie sich vor, Sie schauen dem Benutzer über die Schulter und erklären ihm, wie er die Aufgabe erledigt.
  • Seien Sie höflich, unterstützend und ermutigend. Der Benutzer sollte sich niemals herablassend behandelt, beschuldigt oder eingeschüchtert fühlen.
  • Entfernen Sie redundanten Text. Achten Sie auf redundanten Text in Fenstertiteln, Hauptanweisungen, ergänzenden Anweisungen, Inhaltsbereichen, Befehlsverknüpfungen und Festlegen-Schaltflächen. Lassen Sie in der Regel den vollständigen Text in den Hauptanweisungen und interaktiven Steuerelementen und entfernen Sie Redundanzen an den anderen Stellen.
  • Verwenden Sie für Titel die Großschreibung im Titelstil und für alle anderen UI-Elemente die Großschreibung im Satzstil. Dies ist für den Windows-Ton besser geeignet.
    • Ausnahme: Bei älteren Anwendungen können Sie für Befehlsschaltflächen, Menüs und Spaltenüberschriften die Großschreibung im Stil von Titeln verwenden, wenn dies erforderlich ist, um eine Vermischung der Großbuchstaben zu vermeiden.
  • Bei Namen von Merkmalen und Technologien sollten Sie bei der Großschreibung zurückhaltend sein. In der Regel sollten nur Hauptkomponenten großgeschrieben werden (mit Groß-/Kleinschreibung im Titelformat).
  • Achten Sie bei Namen von Funktionen und Technologien auf die Großschreibung. Wenn der Name mehr als einmal auf einem Bildschirm der Benutzeroberfläche erscheint, sollte er immer auf dieselbe Weise erscheinen. Ebenso sollte der Name auf allen Bildschirmen der Benutzeroberfläche des Programms einheitlich dargestellt werden.
  • Schreiben Sie die Namen allgemeiner Elemente der Benutzeroberfläche, wie Symbolleiste, Menü, Bildlaufleiste, Schaltfläche und Symbol, nicht groß.
    • Ausnahmen: Adressleiste, Verknüpfungsleiste, Menüband.
  • Verwenden Sie nicht alle Großbuchstaben für die Tastaturtasten. Befolgen Sie stattdessen die von Standardtastaturen verwendete Großschreibung bzw. die Kleinschreibung, wenn die Taste auf der Tastatur nicht beschriftet ist.
  • Ellipsen bedeuten Unvollständigkeit. Verwenden Sie Ellipsen in Benutzeroberflächentexten wie folgt:
    • Befehle. Geben Sie an, dass für einen Befehl zusätzliche Informationen erforderlich sind. Verwenden Sie keine Ellipsen, wenn durch eine Aktion ein weiteres Fenster angezeigt wird – nur wenn zusätzliche Informationen erforderlich sind. Befehle, deren implizites Verb darin besteht, ein anderes Fenster anzuzeigen, haben keine Auslassungspunkte, z. B. „Erweitert“, „Hilfe“, „Optionen“, „Eigenschaften“ oder „Einstellungen“.
    • Daten. Gibt an, dass der Text abgeschnitten ist.
    • Bezeichnungen Gibt an, dass eine Aufgabe in Bearbeitung ist (z. B. „Wird gesucht ... “).

Tipp: Abgeschnittener Text in einem Fenster oder auf einer Seite mit ungenutztem Platz weist auf ein schlechtes Layout oder eine zu kleine Standardfenstergröße hin. Bemühen Sie sich um Layouts und Standard-Fenstergrößen, die die Menge an abgeschnittenem Text eliminieren oder reduzieren. Weitere Informationen finden Sie unter Layout.

  • Verwenden Sie keinen blauen Text, der kein Link ist, da Benutzer möglicherweise davon ausgehen, dass es sich um einen Link handelt. Verwenden Sie Fettdruck oder einen Grauton, wo Sie sonst farbigen Text verwenden würden.
  • Verwenden Sie Fettdruck sparsam, um die Aufmerksamkeit auf Text zu lenken, den die Benutzer*innen lesen müssen.
  • Verwenden Sie die Hauptanweisung, um kurz und bündig zu erklären, was die Benutzer*innen in einem bestimmten Fenster oder auf einer bestimmten Seite tun sollen. Gute Hauptanweisungen vermitteln das Ziel des Benutzers und konzentrieren sich nicht nur auf die Bedienung der Benutzeroberfläche.
  • Drücken Sie die Hauptanweisung in Form einer zwingenden Anweisung oder einer konkreten Frage aus.
  • Setzen Sie am Ende von Steuerelementbeschriftungen oder Hauptanweisungen keine Punkte.
  • Verwenden Sie ein Leerzeichen zwischen Sätzen. Nicht zwei.

Steuerelemente

  • Allgemein
    • Bezeichnen Sie jedes Steuerelement oder jede Gruppe von Steuerelementen. Ausnahmen:
      • Textfelder und Dropdownlisten können mit Aufforderungen beschriftet werden.
      • Untergeordnete Steuerelemente verwenden die Bezeichnung des zugehörigen Steuerelements. Steuerelemente für Drehungen sind immer untergeordnete Steuerelemente.
    • Wählen Sie für alle Steuerelemente standardmäßig den sichersten Wert (um den Verlust von Daten oder Systemzugriff zu verhindern) aus. Wenn Sicherheit kein wichtiger Faktor ist, wählen Sie die wahrscheinlichsten oder praktischsten Werte aus.
    • Bevorzugen Sie eingeschränkte Steuerelemente. Verwenden Sie wenn möglich eingeschränkte Steuerelemente wie Listen und Schieberegler anstelle von uneingeschränkten Steuerelementen wie Textfeldern, um den Bedarf an Texteingaben zu reduzieren.
    • Überdenken Sie deaktivierte Steuerelemente. Deaktivierte Steuerelemente können schwierig zu verwenden sein, da Benutzer buchstäblich herausfinden müssen, warum sie deaktiviert sind. Deaktivieren Sie ein Steuerelement, wenn Benutzer dessen Anwendung erwarten. Dann können sie leicht ableiten, warum das Steuerelement deaktiviert ist. Entfernen Sie das Steuerelement, wenn es für Benutzer keine Möglichkeit gibt, es zu aktivieren, oder wenn sie nicht damit rechnen, dass es angewendet wird. Oder lassen Sie es aktiviert, geben Sie jedoch eine Fehlermeldung aus, wenn es falsch verwendet wird.
      • Tipp: Wenn Sie nicht sicher sind, ob Sie ein Steuerelement deaktivieren oder eine Fehlermeldung ausgeben sollen, verfassen Sie zunächst die Fehlermeldung, die Sie ausgeben möchten. Wenn die Fehlermeldung hilfreiche Informationen enthält, die die Zielbenutzer wahrscheinlich nicht schnell erschließen, lassen Sie das Steuerelement aktiviert und geben Sie den Fehler an. Deaktivieren Sie andernfalls das Steuerelement.
  • Befehlsschaltflächen
    • Bevorzugen Sie spezifische Bezeichnungen gegenüber generischen Bezeichnungen. Im Idealfall sollten Benutzer*innen keinen weiteren Text lesen müssen, um die Bezeichnung zu verstehen. Benutzer*innen lesen viel eher Befehlsschaltflächenbezeichnungen als statischen Text.
      • Ausnahme: Benennen Sie die Schaltfläche „Abbrechen“ nicht um, wenn die Bedeutung von „Abbrechen“ eindeutig ist. Benutzer sollten nicht alle Schaltflächen lesen müssen, um festzustellen, welche Schaltfläche eine Aktion abbricht. Benennen Sie „Abbrechen“ jedoch um, wenn unklar ist, welche Aktion abgebrochen wird, etwa wenn mehrere Aktionen ausstehen.
    • Verwenden Sie beim Stellen einer Frage Beschriftungen, die zur Frage passen. Geben Sie beispielsweise auf eine Ja-Nein-Frage die Antworten „Ja“ und „Nein“.
    • Verwenden Sie keine „Übernehmen“-Schaltflächen in Dialogfeldern, bei denen es sich nicht um Eigenschaftenblätter oder Systemsteuerungselemente handelt. Die Schaltfläche „Übernehmen“ bedeutet, dass die ausstehenden Änderungen angewendet werden sollen, ohne das Fenster zu schließen. So können Benutzer*innen die vorgenommenen Änderungen bewerten, bevor sie das Fenster schließen. Dies ist allerdings nur bei Eigenschaftenblättern und Elementen der Systemsteuerung erforderlich.
    • Beschriften Sie eine Schaltfläche mit „Abbrechen“, wenn durch das Abbrechen die Umgebung in ihren vorherigen Zustand zurückversetzt wird (ohne dass Nebeneffekte entstehen). Andernfalls beschriften Sie die Schaltfläche mit „Schließen“ (wenn der Vorgang abgeschlossen ist) oder „Stopp“ (wenn der Vorgang ausgeführt wird), um anzugeben, dass der aktuell geänderte Zustand erhalten bleibt.
  • Befehlslinks
    • Präsentieren Sie Befehlslinks immer in einer Gruppe von zwei oder mehr. Logischerweise gibt es keinen Grund, eine Frage zu stellen, auf die es nur eine Antwort gibt.
    • Stellen Sie eine explizite Schaltfläche „Abbrechen“ bereit. Verwenden Sie hierfür keinen Befehlslink. Häufig stellen Benutzer fest, dass sie eine Aufgabe nicht ausführen möchten. Die Verwendung eines Befehlslinks zum Abbrechen würde erfordern, dass Benutzer alle Befehlslinks sorgfältig lesen, um festzustellen, welcher zum Abbrechen führt. Über eine explizite Schaltfläche „Abbrechen“ können Benutzer eine Aufgabe effizient abbrechen.
    • Wenn bei der Bereitstellung einer expliziten Schaltfläche „Abbrechen“ nur ein einziger Befehlslink übrig bleibt, stellen Sie sowohl einen Befehlslink zum Abbrechen als auch eine Schaltfläche „Abbrechen“ bereit. Dadurch wird deutlich, dass die Benutzer eine Wahl haben. Formulieren Sie diesen Befehlslink in Bezug darauf, wie er sich von der ersten Antwort unterscheidet, statt einfach nur „Abbrechen“ oder eine Variation davon zu verwenden.
  • Kontrollkästchen „Dieses <Element> nicht mehr anzeigen“
    • Mit einer Option vom Typ „Dieses <Element> nicht mehr anzeigen“ können Benutzer*innen die wiederholte Anzeige eines Dialogfelds unterdrücken. Diese Option sollte allerdings nur verwendet werden, wenn es keine bessere Alternative gibt. Es ist besser, das Dialogfeld immer anzuzeigen, wenn Benutzer*innen es wirklich benötigen, oder es andernfalls einfach zu entfernen.
    • Ersetzen Sie <item> durch das jeweilige Element. Beispiel: „Diese Erinnerung nicht mehr anzeigen“. Wenn Sie sich ganz allgemein auf ein Dialogfeld beziehen, verwenden Sie „Diese Meldung nicht mehr anzeigen“.
    • Machen Sie deutlich, wenn Benutzereingaben als zukünftige Standardwerte verwendet werden. Fügen Sie hierzu unter der Option den folgenden Satz hinzu: „Ihre Auswahl wird in Zukunft als Standard verwendet.“
    • Aktivieren Sie die Option nicht standardmäßig. Wenn das Dialogfeld wirklich nur einmal angezeigt werden soll, tun Sie dies ohne Nachfrage. Verwenden Sie diese Option nicht als Ausrede, um Benutzer zu verärgern – achten Sie darauf, dass das Standardverhalten nicht störend ist.
    • Wenn Benutzer*innen die Option auswählen und auf „Abbrechen“ klicken, wird diese Option wirksam. Diese Einstellung ist eine Metaoption. Sie entspricht also nicht dem Standardverhalten von Abbruchvorgängen, die ja so ausgeführt werden, dass keine Nebenwirkung zurückbleibt. Beachten Sie, dass Benutzer*innen, die nicht möchten, dass das Dialogfeld erneut angezeigt wird, es wahrscheinlich auch abbrechen möchten.
  • Links
    • Weisen Sie keineZugriffstaste zu. Der Zugriff auf Links erfolgt über die Tabulatortaste.
    • Fügen Sie dem Linktext nicht „Klicken“ oder „Hier klicken“ hinzu. Dies ist nicht erforderlich, da ein Link ein Anklicken erfordert.
  • QuickInfos
    • Verwenden Sie QuickInfos, um Bezeichnungen für nicht bezeichnete Steuerelemente bereitzustellen. Aus Gründen der Konsistenz müssen Sie beschrifteten Steuerelementen keine QuickInfos bereitstellen.
    • Wenn dies hilfreich ist, können QuickInfos auch weitere Details zu beschrifteten Symbolleistenschaltflächen bereitstellen. Es ist nicht erforderlich, einfach nur zu wiederholen oder wortreich auszudrücken, was bereits auf dem Etikett steht.
    • Vermeiden Sie es, das Objekt abzudecken, das der Benutzer anzeigen oder mit dem er interagieren möchte. Platzieren Sie die Spitze immer an der Seite des Objekts, auch wenn dies einen Abstand zwischen Zeiger und Spitze erfordert. Eine gewisse Trennung stellt kein Problem dar, solange die Beziehung zwischen dem Objekt und seiner Spitze klar ist.
      • Ausnahme: QuickInfos für vollständige Namen, die in Listen und Strukturen verwendet werden.
    • Vermeiden Sie bei Elementsammlungen, das nächste Objekt zu verdecken, das der Benutzer wahrscheinlich sehen oder mit dem er interagieren wird. Vermeiden Sie bei horizontal angeordneten Artikeln die Platzierung von Hinweisen auf der rechten Seite und bei vertikal angeordneten Artikeln die Platzierung von Hinweisen unterhalb.
  • Schrittweise Offenlegung
    • Verwenden Sie die Schaltflächen „Mehr“/„Weniger“ für die schrittweise Offenlegung, um erweiterte oder selten verwendete Optionen, Befehle und Details auszublenden, die Benutzer normalerweise nicht benötigen. Blenden Sie häufig verwendete Elemente nicht aus, da Benutzer sie möglicherweise nicht finden. Stellen Sie aber sicher, dass alles Verborgene Wert hat.
    • Wenn auf der Oberfläche immer bestimmte Optionen, Befehle oder Details angezeigt werden, verwenden Sie die folgenden Beschriftungspaare:
      • Mehr/weniger Optionen. Verwenden Sie es für Optionen oder eine Mischung aus Optionen, Befehlen und Details.
      • Mehr/weniger Befehle. Wird nur für Befehle verwendet.
      • Mehr/weniger Details. Nur zu Informationszwecken verwenden.
      • Mehr/weniger <Objektname>. Wird für andere Objekttypen verwendet, z. B. Ordner.
    • Andernfalls:
      • Optionen anzeigen/ausblenden. Verwenden Sie es für Optionen oder eine Mischung aus Optionen, Befehlen und Details.
      • Befehle anzeigen/ausblenden. Wird nur für Befehle verwendet.
      • Details anzeigen/ausblenden. Nur zu Informationszwecken verwenden.
      • Anzeigen/Ausblenden <Objektnamen>. Wird für andere Objekttypen verwendet, z. B. Ordner.
  • Fortschrittsbalken
    • Verwenden Sie bestimmte Statusindikatoren für Vorgänge, die einen begrenzten Zeitraum erfordern, auch wenn diese Zeit nicht genau vorhergesagt werden kann. Unbestimmte Statusanzeigen zeigen an, dass Fortschritte erzielt werden, bieten aber keine weiteren Informationen. Wählen Sie keine unbestimmte Statusanzeige nur aufgrund der möglichen fehlenden Genauigkeit.
    • Geben Sie eine Schätzung der verbleibenden Zeit ab, sofern Sie dazu eine genaue Angabe machen können. Genaue Schätzungen der verbleibenden Zeit sind nützlich, Schätzungen, die weit daneben liegen oder stark schwanken, sind jedoch nicht hilfreich. Möglicherweise müssen Sie einige Verarbeitungsvorgänge durchführen, bevor Sie genaue Schätzungen abgeben können. Wenn ja, zeigen Sie in dieser Anfangsphase keine möglicherweise ungenauen Schätzungen an.
    • Starten Sie den Status nicht neu. Eine Statusanzeige verliert ihren Wert, wenn sie neu gestartet wird (beispielsweise weil ein Schritt im Vorgang abgeschlossen wird), da Benutzer nicht wissen können, wann der Vorgang abgeschlossen sein wird. Lassen Sie stattdessen alle Schritte des Vorgangs einen Teil des Fortschritts teilen, und lassen Sie eine Statusanzeige einmal bis zum Abschluss anzeigen.
    • Geben Sie nützliche Fortschrittsdetails an. Stellen Sie zusätzliche Fortschrittsinformationen bereit, aber nur, wenn Benutzer etwas damit anfangen können. Stellen Sie sicher, dass der Text lange genug angezeigt wird, damit Benutzer ihn lesen können.
    • Kombinieren Sie eine Statusanzeige nicht mit einem Zeiger für „Beschäftigt“. Verwenden Sie das eine oder das andere, aber nicht beides gleichzeitig.
  • Aufforderungen
    • Verwenden Sie einen Hinweis, wenn der Bildschirmplatz so knapp bemessen ist, dass die Verwendung einer Bezeichnung oder Anweisung unpraktisch ist, z. B. auf einer Symbolleiste.
    • Die Eingabeaufforderung dient in erster Linie dazu, den Zweck des Textfelds oder Kombinationsfelds auf kompakte Weise zu identifizieren. Es dürfen keine wichtigen Informationen sein, die der Benutzer bei der Verwendung des Steuerelements sehen muss.
    • Der Eingabetext darf nicht mit echtem Text verwechselt werden. Gehen Sie dazu folgendermaßen vor:
      • Zeichnen Sie den Eingabeaufforderungstext kursiv grau und den tatsächlichen Eingabetext in Roman Schwarz.
      • Der Eingabeaufforderungstext sollte nicht editierbar sein und verschwinden, sobald Benutzer in das Textfeld klicken oder mit der Tabulatortaste hineingehen.
        • Ausnahme: Wenn das Textfeld den Standardeingabefokus hat, wird die Eingabeaufforderung angezeigt und wird ausgeblendet, sobald der Benutzer mit der Eingabe beginnt.
    • Verwenden Sie keine abschließenden Satzzeichen oder Auslassungspunkte.
  • Benachrichtigungen
    • Verwenden Sie Benachrichtigungen für Ereignisse, die nichts mit der aktuellen Benutzeraktivität zu tun haben, keine sofortige Benutzeraktion erfordern und die Benutzer problemlos ignorieren können.
    • Nutzen Sie Benachrichtigungen nicht aus:
      • Verwenden Sie Benachrichtigungen nur, wenn sie erforderlich sind. Wenn Sie eine Benachrichtigung anzeigen, unterbrechen Sie möglicherweise Benutzer oder stören sie sogar. Stellen Sie sicher, dass Unterbrechungen gerechtfertigt sind.
      • Verwenden Sie Benachrichtigungen für nicht kritische Ereignisse oder Situationen, die keine sofortige Benutzeraktion erfordern. Verwenden Sie für kritische Ereignisse oder Situationen, die eine sofortige Benutzeraktion erfordern, ein alternatives UI-Element (z. B. ein modales Dialogfeld).
      • Verwenden Sie keine Benachrichtigungen für Featureanzeigen!

Tastatur

  • Weisen Sie dem Steuerelement den anfänglichen Eingabefokus zu, mit dem Benutzer am wahrscheinlichsten zuerst interagieren, wobei es sich häufig um das erste interaktive Steuerelement handelt. Wenn das erste interaktive Steuerelement keine gute Wahl ist, sollten Sie eine Änderung des Fensterlayouts in Betracht ziehen.
  • Weisen Sie allen interaktiven Steuerelementen, einschließlich schreibgeschützten Bearbeitungsfeldern, Tabulatorstopps zu. Ausnahmen:
    • Gruppieren Sie Sätze zusammengehöriger Steuerelemente, die sich wie ein einzelnes Steuerelement verhalten, z. B. Optionsfelder. Solche Gruppen haben einen einzelnen Tabulatorstopp.
    • Gruppen ordnungsgemäß einschließen, sodass die Pfeiltasten sowohl vorwärts als auch rückwärts innerhalb der Gruppe blättern und innerhalb der Gruppe bleiben.
  • Die Reihenfolge der Registerkarten sollte von links nach rechts und von oben nach unten verlaufen. Generell sollte die Reihenfolge der Registerkarten der Lesereihenfolge entsprechen Machen Sie ggf. Ausnahmen für häufig verwendete Steuerelemente, indem Sie diese früher in der Tabulatorreihenfolge platzieren. Die Tabulatortaste sollte alle Tabulatorstopps in beide Richtungen ohne Unterbrechung durchlaufen. Innerhalb einer Gruppe sollte die Tabulatorreihenfolge ausnahmslos sequenziell sein.
  • Innerhalb eines Tabulatorstopps sollte die Pfeiltastenreihenfolge ausnahmslos von links nach rechts und von oben nach unten verlaufen.. Die Pfeiltasten sollten alle Elemente in beide Richtungen durchlaufen, ohne zu stoppen.
  • Präsentieren Sie die Commit-Buttons in der folgenden Reihenfolge:
    • OK/[Ausführen]/Ja
    • [Nicht ausführen]/Nein
    • Abbrechen
    • „Anwenden“ (sofern vorhanden)

wobei [Tun Sie es] und [Tun Sie es nicht] spezifische Antworten auf die Hauptanweisung sind.

  • Verwechseln Sie Zugriffstasten nicht mit Tastenkombinationen. Obwohl sowohl Zugriffstasten als auch Tastenkombinationen per Tastatur auf die Benutzeroberfläche zugreifen können, dienen sie unterschiedlichen Zwecken und haben unterschiedliche Richtlinien.
  • Weisen Sie nach Möglichkeit allen interaktiven Steuerelementen oder deren Bezeichnungen eindeutige Zugriffstasten zu.Schreibgeschützte Textfelder sind interaktive Steuerelemente (da Benutzer darin scrollen und Text kopieren können) und profitieren deshalb von Zugriffstasten. Folgenden Elementen dürfen keine Zugriffstasten zugewiesen werden:
    • Schaltflächen „OK“, „Abbrechen“ und „Schließen“. Für diese Elemente werden EINGABETASTE und ESC-TASTE als Zugriffstasten verwendet. Steuerelementen, die „OK“ oder „Abbrechen“ bedeuten, aber eine andere Bezeichnung haben, sollte dagegen immer eine Zugriffstaste zugewiesen werden.
  • Weisen Sie den am häufigsten verwendeten Befehlen Tastenkombinationen zu. Für selten verwendete Programme und Funktionen sind keine Tastenkombinationen erforderlich, da Benutzer stattdessen Zugriffstasten verwenden können.
  • Erstellen Sie keine Tastenkombination als einzige Möglichkeit zum Ausführen einer Aufgabe. Benutzer sollten auch die Maus oder die Tastatur mit TAB, Pfeil und Zugriffstasten verwenden können.
  • Weisen Sie bekannten Tastenkombinationen keine andere Bedeutung zu. Da sie auswendig gelernt werden, sind inkonsistente Bedeutungen für bekannte Tastenkombinationen frustrierend und fehleranfällig.
  • Versuchen Sie nicht, systemweite Programmtastenkombinationen zuzuweisen. Die Tastenkombinationen Ihres Programms haben nur dann eine Wirkung, wenn Ihr Programm den Eingabefokus hat.

Maus

  • Benutzer sollten nie auf ein Objekt klicken müssen, um festzustellen, ob es anklickbar ist. Benutzer müssen in der Lage sein, die Klickbarkeit ausschließlich durch visuelle Inspektion zu bestimmen.
    • Die primäre Benutzeroberfläche (z. B. Commit-Schaltflächen) muss eine statische Klickmöglichkeit bieten. Benutzer sollten nicht mit der Maus darüberfahren müssen, um die primäre Benutzeroberfläche zu entdecken.
    • Sekundäre UI (z. B. sekundäre Befehle oder Steuerelemente zur schrittweisen Anzeige) können beim Mouseover deren Klickangebot anzeigen.
    • Textverknüpfungslinks sollten Linktext statisch vorschlagen und dann beim Mouseover deren Klickangebot (Unterstreichung oder andere Präsentationsänderungen) mit dem Mauszeiger anzeigen.
    • Grafiklinks zeigen beim Mouseover nur einen Handzeiger an.
  • Verwenden Sie den Handzeiger (oder „Linkauswahl“) nur für Text- und Grafiklinks. Andernfalls müssten Benutzer auf Objekte klicken, um festzustellen, ob es sich um Links handelt.

Dialogfelder

  • Modale Dialogfelder erfordern eine Interaktion. Verwenden Sie sie daher für Dinge, auf die Benutzer reagieren müssen, bevor Sie mit ihrer Aufgabe fortfahren. Stellen Sie sicher, dass die Unterbrechung gerechtfertigt ist, z. B. bei kritischen oder seltenen einmaligen Aufgaben, die abgeschlossen werden müssen. Andernfalls sollten Sie auch nicht modale Alternativen in Betracht ziehen.
  • nicht modale Dialogfelder erfordern keine Interaktion. Verwenden Sie sie daher, wenn Benutzer zwischen einem Dialogfeld und dem Eigentümerfenster wechseln müssen. Sie eignen sich am besten für häufige, sich wiederholende oder laufende Aufgaben. Allerdings sind Menübänder, Symbolleisten und Palettenfenster oft bessere Alternativen.

Eigenschaftenblätter

  • Stellen Sie sicher, dass die Eigenschaften erforderlich sind. Überladen Sie Ihre Eigenschaftenseiten nicht mit unnötigen Eigenschaften, um schwierige Entwurfsentscheidungen zu vermeiden.
  • Präsentieren Sie Eigenschaften im Hinblick auf Benutzerziele statt auf Technologie. Nur weil eine Eigenschaft eine bestimmte Technologie konfiguriert, heißt das nicht, dass Sie die Eigenschaft im Hinblick auf diese Technologie präsentieren müssen.
    • Wenn Sie Einstellungen in Bezug auf die Technologie präsentieren müssen (vielleicht weil Ihre Benutzer den Namen der Technologie wiedererkennen), fügen Sie eine kurze Beschreibung des Benutzernutzens bei.
  • Verwenden Sie bestimmte, aussagekräftige Registerkartenbeschriftungen. Vermeiden Sie allgemeine Registerkartenbeschriftungen, die für jede beliebige Registerkarte gelten könnten, wie etwa „Allgemein“, „Erweitert“ oder „Einstellungen“.
  • Vermeiden Sie allgemeine Seiten. Sie benötigen nicht die Seite „Allgemein“. Verwenden Sie die Seite „Allgemein“ nur in folgenden Fällen:
    • Die Eigenschaften gelten für mehrere Aufgaben und sind für die meisten Benutzer aussagekräftig. Platzieren Sie spezialisierte oder erweiterte Eigenschaften nicht auf einer allgemeinen Seite. Sie können sie jedoch über eine Befehlsschaltfläche auf der allgemeinen Seite zugänglich machen.
    • Die Eigenschaften passen nicht zu einer spezifischeren Kategorie. Wenn sie das tun, verwenden Sie stattdessen diesen Namen für die Seite.
  • Vermeiden Sie erweiterte Seiten. Verwenden Sie eine erweiterte Seite nur in folgenden Fällen:
    • Die Eigenschaften gelten für ungewöhnliche Aufgaben und sind in erster Linie für fortgeschrittene Benutzer aussagekräftig.
    • Die Eigenschaften passen nicht zu einer spezifischeren Kategorie. Falls sie es tun, verwenden Sie stattdessen diesen Namen für die Seite.
  • Verwenden Sie keine Registerkarten, wenn ein Eigenschaftenfenster nur über eine einzelne Registerkarte verfügt und nicht erweiterbar ist. Verwenden Sie stattdessen ein normales Dialogfeld mit „OK“, „Abbrechen“ und einer optionalen Schaltfläche „Übernehmen“. Erweiterbare Eigenschaftenfenster (die von Drittanbietern erweitert werden können) müssen jedoch Registerkarten verwenden.

Zauberer

  • Erwägen Sie zunächst einfache Alternativen wie Dialogfelder, Aufgabenbereiche oder einzelne Seiten. Assistenten stellen eine schwere Benutzeroberfläche dar und eignen sich am besten für Aufgaben mit mehreren Schritten, die selten ausgeführt werden. Sie müssen keine Assistenten verwenden – Sie können in jeder Benutzeroberfläche hilfreiche Informationen und Hilfe bereitstellen.
  • Verwenden Sie „Weiter“ nur, wenn Sie unverbindlich zur nächsten Seite gelangen. Der Wechsel zur nächsten Seite wird als Verpflichtung betrachtet, wenn der Effekt nicht durch Klicken auf „Zurück“ oder „Abbrechen“ rückgängig gemacht werden kann.
  • Verwenden Sie „Zurück“ nur, um Fehler zu korrigieren. Abgesehen von der Korrektur von Fehlern sollten Benutzer nicht auf „Zurück“ klicken müssen, um bei einer Aufgabe fortzufahren.
  • Wenn Benutzer eine Aufgabe ausführen, verwenden Sie eine „Commit“-Schaltfläche, die eine bestimmte Antwort auf die Hauptanweisung darstellt (z. B. „Drucken“, „Verbinden“ oder „Starten“). Verwenden Sie zum Übernehmen einer Aufgabe keine allgemeinen Bezeichnungen wie „Weiter“ (was keine Verpflichtung impliziert) oder „Fertig“ (was nicht spezifisch ist). Die Beschriftungen dieser Commit-Schaltflächen sollten für sich genommen Sinn ergeben. Beginnen Sie die Beschriftung von Commit-Schaltflächen immer mit einem Verb. Ausnahmen:
    • Verwenden Sie „Fertig stellen“, wenn die spezifischen Antworten noch allgemeiner Natur sind, z. B. „Speichern“, „Auswählen“, „Auswählen“ oder „Abrufen“.
    • Verwenden Sie „Fertig“, um eine bestimmte Einstellung oder eine Sammlung von Einstellungen zu ändern.
  • Verwenden Sie Befehlslinks nur für Auswahlmöglichkeiten, nicht für Verpflichtungen. Spezielle Commit-Schaltflächen zeigen die Verpflichtung weitaus besser an als Befehlslinks in einem Assistenten.
  • Wenn Sie Befehlslinks verwenden, verbergen Sie die Schaltfläche „Weiter“, lassen Sie die Schaltfläche „Abbrechen“ jedoch bestehen.
  • Verwenden Sie „Schließen“ für Nachverfolgungs- und Abschlussseiten. Verwenden Sie nicht „Abbrechen“, da durch das Schließen des Fensters keine an dieser Stelle vorgenommenen Änderungen oder Aktionen verworfen werden. Verwenden Sie nicht „Fertig“, da es sich nicht um ein imperatives Verb handelt.
  • Verwenden Sie „Assistent“ nicht in Assistentennamen. Verwenden Sie beispielsweise „Mit einem Netzwerk verbinden“ statt „Netzwerk-Setup-Assistent“. Es ist jedoch zulässig, Assistenten als Assistenten zu bezeichnen. Beispiel: „Wenn Sie zum ersten Mal ein Netzwerk einrichten, können Sie Hilfe vom Assistenten „Mit einem Netzwerk verbinden“ erhalten.“
  • Behalten Sie die Benutzerauswahl durch die Navigation bei. Wenn der Benutzer beispielsweise Änderungen vornimmt und auf „Zurück“ und dann auf „Weiter“ klickt, sollten diese Änderungen beibehalten werden. Benutzer gehen nicht davon aus, dass sie Änderungen erneut eingeben müssen, es sei denn, sie entscheiden sich ausdrücklich, sie zu löschen.

Seiten des Assistenten

  • Konzentrieren Sie sich auf effiziente Entscheidungsfindung. Verringern Sie die Anzahl der Seiten, um sich auf wesentliche Dinge zu konzentrieren. Konsolidieren Sie verwandte Seiten, und entfernen Sie optionale Seiten aus dem Hauptfluss. Wenn Benutzer während des gesamten Vorgangs des Assistenten immer auf „Weiter“ klicken müssen, mag das zunächst eine gute Erfahrung sein. Wenn die Benutzer die Standardeinstellungen jedoch nie ändern müssen, sind die Seiten wahrscheinlich unnötig.
  • Verwenden Sie keine Willkommensseiten. Gestalten Sie die erste Seite nach Möglichkeit funktional. Verwenden Sie eine optionale Seite „Erste Schritte“ nur in folgenden Fällen:
    • Der Assistent verfügt über Voraussetzungen, die zum erfolgreichen Abschluss des Assistenten erforderlich sind.
    • Benutzer verstehen den Zweck des Assistenten möglicherweise nicht auf der ersten Auswahlseite und es besteht kein Raum für weitere Erklärungen.
    • Die Hauptanweisung für die Seiten „Erste Schritte“ lautet „Bevor Sie beginnen:“.
  • Optimieren Sie auf Seiten, auf denen Benutzer Entscheidungen treffen müssen, für die wahrscheinlichsten Fälle. Auf solchen Seiten sollten tatsächliche Auswahlmöglichkeiten und nicht nur Anweisungen präsentiert werden.
    • Wenn Sie keine Seite „Erste Schritte“ verwenden, erläutern Sie den Zweck des Assistenten oben auf der ersten Seite mit Auswahlmöglichkeiten.
  • Verwenden Sie Commit-Seiten, um deutlich zu machen, wann Benutzer sich der Aufgabe verpflichten. Normalerweise ist die Seite „Commit“ die letzte Seite mit Auswahlmöglichkeiten, und die Schaltfläche „Weiter“ wird neu beschriftet, um anzuzeigen, dass die Aufgabe committet wird.
    • Verwenden Sie keine Zusammenfassungsseiten, die lediglich die vorherigen Auswahlen des Benutzers zusammenfassen, es sei denn, die Aufgabe ist riskant (Sicherheitsrisiken oder Zeit- bzw. Geldverlust) oder es besteht eine gute Chance, dass Benutzer ihre Auswahl nicht verstehen und sie überprüfen müssen.
  • Verwenden Sie keine Glückwunschseiten, die nichts anderes tun, als den Assistenten zu beenden. Wenn die Ergebnisse des Assistenten für Benutzer klar ersichtlich sind, schließen Sie den Assistenten einfach mit der Schaltfläche zum endgültigen Übernehmen.
    • Verwenden Sie Nachverfolgungsseiten, wenn verwandte Aufgaben vorhanden sind, die Benutzer wahrscheinlich als Folgeaufgaben ausführen. Vermeiden Sie bekannte Folgeaufgaben wie „Senden Sie eine E-Mail-Nachricht.“
    • Verwenden Sie Abschlussseiten nur, wenn die Ergebnisse nicht sichtbar sind und es keine bessere Möglichkeit gibt, Feedback zur Aufgabenerledigung zu geben.
    • Assistenten mit Fortschrittsseiten müssen eine Abschluss- oder Folgeseite verwenden, um den Abschluss der Aufgabe anzuzeigen. Schließen Sie bei Aufgaben mit langer Ausführungsdauer den Assistenten auf der Seite „Commit“ und geben Sie Feedback über die Benachrichtigungen.

Fehlermeldungen

  • Geben Sie keine Fehlermeldungen aus, wenn es unwahrscheinlich ist, dass Benutzer aufgrund der Meldung eine Aktion ausführen oder ihr Verhalten ändern. Wenn die Benutzer keine Aktion ausführen können oder das Problem nicht erheblich ist, unterdrücken Sie die Fehlermeldung.
  • Schlagen Sie, wenn möglich, eine Lösung vor, damit Benutzer das Problem beheben können. Stellen Sie jedoch sicher, dass die vorgeschlagene Lösung das Problem wahrscheinlich löst. Verschwenden Sie nicht die Zeit der Benutzer, indem Sie mögliche, aber unwahrscheinliche Lösungen vorschlagen.
  • Spezifisch sein. Vermeiden Sie vage Formulierungen wie „Syntaxfehler“ und „unzulässige Operation“. Geben Sie die genauen Namen, Standorte und Werte der beteiligten Objekte an.
  • Verwenden Sie keine Formulierungen, die dem Benutzer die Schuld geben oder einen Benutzerfehler implizieren. Vermeiden Sie die Verwendung von „Sie“ und „Ihre“ in der Formulierung. Während die aktive Form im Allgemeinen vorzuziehen ist, sollten Sie die passive Form verwenden, wenn der Benutzer das Subjekt ist und sich bei Verwendung der aktiven Form für den Fehler verantwortlich fühlen könnte.
  • Verwenden Sie „OK“ nicht für Fehlermeldungen. Benutzer zeigen keine Fehler als „OK“ an. Wenn die Fehlermeldung keine direkte Aktion enthält, verwenden Sie stattdessen „Schließen“.
  • Verwenden Sie nicht die folgenden Wörter:
    • Fehler (stattdessen Problem verwenden)
    • Fehlgeschlagen (verwenden Sie stattdessen „konnte nicht“)
    • Illegal, ungültig, schlecht (verwenden Sie stattdessen „falsch“ oder „ungültig“)
    • Abbrechen, eliminieren (stattdessen Beenden verwenden)
    • Katastrophal, fatal (stattdessen schwerwiegend verwenden)

Diese Begriffe sind unnötig und stehen im Widerspruch zum ermutigenden Ton von Windows. Stattdessen kommuniziert ein Fehlersymbol, wenn es richtig verwendet wird, ausreichend, dass ein Problem vorliegt.

  • Begleiten Sie keine Fehlermeldungen mit Soundeffekten. Dies ist störend und unnötig.

Warnmeldungen

  • Warnungen beschreiben einen Zustand, der in Zukunft ein Problem verursachen könnte. Warnungen sind keine Fehler oder Fragen. Formulieren Sie Routinefragen daher nicht als Warnungen.
  • Geben Sie keine Warnmeldungen aus, wenn es unwahrscheinlich ist, dass Benutzer aufgrund der Meldung eine Aktion ausführen oder ihr Verhalten ändern. Wenn der Benutzer keine Aktion ausführen kann oder der Zustand nicht signifikant ist, unterdrücken Sie die Warnmeldung.

Bestätigungen

  • Verwenden Sie keine unnötigen Bestätigungen. Verwenden Sie Bestätigungen nur in folgenden Fällen:
    • Es gibt einen klaren Grund, nicht fortzufahren, und es besteht eine gewisse Wahrscheinlichkeit, dass Benutzer dies manchmal nicht tun.
    • Die Aktion hat erhebliche Folgen oder kann nicht einfach rückgängig gemacht werden.
    • Die Aktion hat Folgen, die Benutzer möglicherweise nicht kennen.
    • Wenn Sie mit der Aktion fortfahren, müssen Benutzer eine Auswahl treffen, die nicht über einen geeigneten Standardwert verfügt.
    • Angesichts des aktuellen Kontexts haben Benutzer wahrscheinlich eine Fehleraktion ausgeführt.
  • Formulieren Sie Bestätigungen als Ja- oder Nein-Fragen und geben Sie Ja- oder Nein-Antworten. Im Gegensatz zu anderen Dialogfeldtypen sollen Bestätigungen Benutzer davon abhalten, schnelle Entscheidungen zu treffen. Wenn Benutzer nicht in ihre Antwort überlegt haben, hat eine Bestätigung keinen Wert.

Symbole

  • Alle Symbole sollten denSymbolrichtlinien im Aero-Stil entsprechen. Ersetzen Sie alle Symbole im Windows XP-Stil.
  • Wählen Sie Standardsymbole basierend auf ihrem Nachrichtentyp und nicht dem Schweregrad des zugrunde liegenden Problems aus:
    • Fehler. Einen Fehler oder ein Problem, der/das aufgetreten ist.
    • Warnung. Eine Bedingung, die in der Zukunft ein Problem verursachen kann.
    • Information Nützliche Informationen.

Wenn ein Problem verschiedene Nachrichtentypen kombiniert, konzentrieren Sie sich auf den wichtigsten Aspekt, auf den Benutzer reagieren müssen.

  • Symbole müssen immer mit der Hauptanweisung oder einem anderen entsprechenden Text übereinstimmen.
  • Bei nicht kritischen Problemen mit der Benutzereingabe werden keine Fehlersymbole benötigt. Für direkte Fehler sind jedoch Symbole erforderlich, da solche kontextbezogenen Rückmeldungen sonst zu leicht übersehen werden könnten.
  • Verwenden Sie keine Warnsymbole, um nicht kritische Fehler „abzumildern“. Fehler sind keine Warnungen; wenden Sie stattdessen die Richtlinien für Fehlersymbole an.
  • Verwenden Sie in Fragedialogen Warnsymbole nur für Fragen mit schwerwiegenden Konsequenzen. Verwenden Sie bei Routinefragen keine Warnsymbole.

Hilfe

  • Link zu bestimmten, relevanten Hilfethemen. Verlinken Sie nicht auf die Startseite der Hilfe, das Inhaltsverzeichnis, eine Liste mit Suchergebnissen oder eine Seite, die lediglich auf andere Seiten verweist. Vermeiden Sie die Verlinkung auf Seiten, die als große Liste häufig gestellter Fragen strukturiert sind, denn dadurch werden die Benutzer gezwungen, nach der Frage zu suchen, die dem angeklickten Link entspricht. Verlinken Sie nicht auf bestimmte Hilfethemen, die für die vorliegende Aufgabe nicht relevant und hilfreich sind. Verlinken Sie niemals auf leere Seiten.
  • Platzieren Sie aus Gründen der Einheitlichkeit nicht in jedem Fenster oder auf jeder Seite Hilfe-Links. Das Bereitstellen eines Hilfe-Links an einer Stelle bedeutet nicht, dass Sie ihn überall bereitstellen müssen.
  • Wenn möglich, verknüpft die Phrase „Hilfe“ den Text in Bezug auf die Hauptfrage, die durch den Hilfeinhalt beantwortet wird. Verwenden Sie nicht den Ausdruck "Weitere Informationen" oder "Hilfe zu diesem Thema erhalten".
  • Verwenden Sie den gesamten Hilfe-Link für den Linktext, nicht nur für die Schlüsselwörter.
  • Verwenden Sie vollständige Sätze.
  • Verwenden Sie keine abschließenden Satzzeichen oder Auslassungspunkte, außer bei Fragezeichen.
  • Wenn der Hilfeinhalt online ist, machen Sie dies im Linktext klar. Dadurch wird das Ergebnis der Links vorhersehbar.
  • Last updated on