Fehlermeldungen in Windows 7

Fehlermeldungen in Windows 7 benachrichtigen Benutzer über Probleme, die bereits aufgetreten sind. Im Gegensatz dazu benachrichtigen Warnmeldungen Benutzer über Bedingungen, die in Zukunft Probleme verursachen können. Fehlermeldungen können mithilfe modaler Dialogfelder, direkte Nachrichten, Benachrichtigungen oder Sprechblasen angezeigt werden.

kann nicht umbenannt werden.

Eine typische modale Fehlermeldung.

Effektive Fehlermeldungen informieren Benutzer darüber, dass ein Problem aufgetreten ist, erklären, warum es passiert ist, und stellen eine Lösung bereit, damit Benutzer das Problem beheben können. Benutzer sollten entweder eine Aktion ausführen oder ihr Verhalten als Ergebnis einer Fehlermeldung ändern.

Gut geschriebene, hilfreiche Fehlermeldungen sind für eine qualitativ hochwertige Benutzererfahrung von entscheidender Bedeutung. Schlecht geschriebene Fehlermeldungen führen zu geringer Produktzufriedenheit und sind eine führende Ursache für vermeidbare technische Supportkosten. Unnötige Fehlermeldungen unterbrechen den Benutzerfluss.

Hinweis: Richtlinien für Dialogfelder, Warnmeldungen, Bestätigungen, Standardsymbole, Benachrichtigungenund Layout- werden in separaten Artikeln vorgestellt.

Ist dies die richtige Benutzeroberfläche?

Berücksichtigen Sie die folgenden Fragen, um sich zu entscheiden:

• Stellt die Benutzeroberfläche ein Problem dar, das bereits aufgetreten ist? Wenn nicht, ist die Nachricht kein Fehler. Wenn der Benutzer über eine Bedingung benachrichtigt wird, die in Zukunft zu einem Problem führen kann, verwenden Sie eine Warnmeldung.
• Kann das Problem verhindert werden, ohne Verwirrung zu verursachen? Wenn ja, verhindern Sie stattdessen das Problem. Verwenden Sie beispielsweise Steuerelemente, die auf gültige Werte beschränkt sind, anstatt nicht eingeschränkte Steuerelemente zu verwenden, die Fehlermeldungen erfordern können. Außerdem würde das Deaktivieren von Steuerelementen beim Klicken zu einem Fehler führen, sofern offensichtlich, warum das Steuerelement deaktiviert ist.
• Kann das Problem automatisch behoben werden? Behandeln Sie in diesem Fall das Problem, und unterdrücken Sie die Fehlermeldung.
• Werden Benutzer wahrscheinlich eine Aktion ausführen oder ihr Verhalten als Ergebnis der Nachricht ändern? Ist dies nicht der Grund, den Benutzer zu unterbrechen, ist es besser, den Fehler zu unterdrücken.
• Ist das Problem relevant, wenn Benutzer aktiv andere Programme verwenden? Wenn ja, sollten Sie das Problem mithilfe eines Infobereichssymbolsanzeigen.
• Hängt das Problem nicht mit der aktuellen Benutzeraktivität zusammen, erfordert es keine sofortige Benutzeraktion und kann benutzerfrei ignoriert werden? Verwenden Sie in diesem Beispiel stattdessen eine Aktionsfehlerbenachrichtigung.
• Betrifft das Problem den Status einer Hintergrundaufgabe innerhalb eines primären Fensters? Wenn ja, sollten Sie das Problem mithilfe einer Statusleistenanzeigen.
• Sind die IT-Experten der primären Zielbenutzer? Wenn ja, erwägen Sie die Verwendung eines alternativen Feedbackmechanismus, z. B. Protokolldatei Einträgen oder E-Mail-Benachrichtigungen. IT-Experten bevorzugen protokolldateien dringend für nicht kritische Informationen.

Designkonzepte

Die Merkmale schlechter Fehlermeldungen

Es sollte keine Überraschung sein, dass es viele lästige, nicht hilfreiche und schlecht geschriebene Fehlermeldungen gibt. Und da Fehlermeldungen häufig mithilfe modaler Dialogfelder angezeigt werden, unterbrechen sie die aktuelle Aktivität des Benutzers und fordern, dass sie bestätigt werden müssen, bevor der Benutzer fortfahren kann.

Ein Teil des Problems besteht darin, dass es so viele Möglichkeiten gibt, es falsch zu tun. Betrachten Sie diese Beispiele aus der Fehlermeldungshalle der Schande:

unnötige Fehlermeldungen

Falsch:

In diesem Beispiel von Windows XP kann es sich um die schlechteste Fehlermeldung handeln. Es weist darauf hin, dass ein Programm nicht gestartet werden konnte, da Sich Windows selbst im Prozess des Herunterfahrens befindet. Es gibt nichts, was der Benutzer tun kann, oder möchte sogar tun, um dies zu tun (der Benutzer hat sich entschieden, Windows herunterzufahren, schließlich). Und durch anzeigen dieser Fehlermeldung verhindert Windows, dass sich selbst heruntergefahren wird!

Das Problem: Die Fehlermeldung selbst ist das Problem. Abgesehen davon, dass die Fehlermeldung geschlossen wird, gibt es nichts, was Benutzer tun müssen.

Führende Ursache: Melden aller Fehlerfälle, unabhängig von den Zielen oder Standpunkten der Benutzer.

Empfohlene Alternative: Melden Sie keine Fehler, die benutzern nicht wichtig sind.

Fehlermeldungen "Erfolg"

Falsch:

Diese Fehlermeldung hat dazu geführt, dass der Benutzer windows nicht unmittelbar nach dem Entfernen des Programms neu starten möchte. Die Programmentfernung war aus Sicht des Benutzers erfolgreich.

Das Problem: Es gibt keinen Fehler aus der Sicht des Benutzers. Abgesehen davon, dass die Fehlermeldung geschlossen wird, gibt es nichts, was Benutzer tun müssen.

Führende Ursache: Die Aufgabe wurde erfolgreich aus sicht des Benutzers abgeschlossen, ist jedoch aus Sicht des Deinstallationsprogramms fehlgeschlagen.

Empfohlene Alternative: Melden Sie keine Fehler für Bedingungen, die Benutzer als akzeptabel betrachten.

Vollständig nutzlose Fehlermeldungen

Falsch:

Benutzer erfahren, dass ein Fehler aufgetreten ist, aber sie haben keine Vorstellung davon, was der Fehler war oder was zu tun ist. Und nein, es ist nicht OK!

Das Problem: Die Fehlermeldung gibt kein bestimmtes Problem, und es gibt nichts, was Benutzer tun können.

Führende Ursache: Wahrscheinlich hat das Programm eine schlechte Fehlerbehandlung.

Empfohlene Alternative: Entwerfen einer guten Fehlerbehandlung in das Programm.

Unverständliche Fehlermeldungen

Falsch:

In diesem Beispiel ist die Problemausweisung klar, aber die ergänzende Erklärung ist völlig baffling.

Das Problem: Die Problemausweisung oder Lösung ist unverständlich.

Führende Ursache: Erläutern des Problems aus der Sicht des Codes anstelle der Benutzer.

Empfohlene Alternative: Fehlermeldungstext schreiben, den Ihre Zielbenutzer leicht verstehen können. Stellen Sie Lösungen bereit, die Benutzer tatsächlich ausführen können. Entwerfen Sie die Fehlermeldung Ihres Programms nicht, wenn Programmierer Fehlermeldungen vor Ort verfassen.

Fehlermeldungen, die übertragen

Falsch:

In diesem Beispiel versucht die Fehlermeldung offenbar, jeden Problembehandlungsschritt zu erläutern.

Das Problem: Zu viele Informationen.

Führende Ursache: Zu viele Details geben oder versuchen, einen komplizierten Problembehandlungsprozess in einer Fehlermeldung zu erklären.

Empfohlene Alternative: Vermeiden Sie unnötige Details. Vermeiden Sie außerdem Problembehandlungen. Wenn eine Problembehandlung erforderlich ist, konzentrieren Sie sich auf die wahrscheinlichsten Lösungen, und erläutern Sie den Rest, indem Sie mit dem entsprechenden Thema in der Hilfe verknüpfen.

unnötig harte Fehlermeldungen

Falsch:

nicht gefunden werden.

Die Unfähigkeit des Programms, ein Objekt zu finden, klingt kaum katastrophal. Und wenn es katastrophal ist, warum ist die Antwort ok?

Das Problem: Der Ton des Programms ist unnötig hart oder dramatisch.

Führende Ursache: Das Problem liegt an einem Fehler, der aus sicht des Programms katastrophal erscheint.

Empfohlene Alternative: Wählen Sie die Sprache sorgfältig basierend auf dem Standpunkt des Benutzers aus.

Fehlermeldungen, die Benutzern

Falsch:

Warum fühlen sich Benutzer wie ein Krimineller?

Das Problem: Die Fehlermeldung wird so formuliert, dass der Benutzer einen Fehler vorwirft.

Führende Ursache: Unsensitive Ausdrücke, die sich auf das Verhalten des Benutzers anstatt auf das Problem konzentrieren.

Empfohlene Alternative: Konzentrieren Sie sich auf das Problem, nicht auf die Benutzeraktion, die zu dem Problem führte, indem Sie die passive Stimme bei Bedarf verwenden.

silly Fehlermeldungen

Falsch:

In diesem Beispiel ist die Problemausweisung ziemlich ironisch, und es werden keine Lösungen bereitgestellt.

Das Problem: Fehlermeldungsanweisungen, die dumm oder nicht sequitors sind.

Führende Ursache: Erstellen von Fehlermeldungen ohne Beachtung ihres Kontexts.

Empfohlene Alternative: Lassen Sie Ihre Fehlermeldungen von einem Autor erstellt und überprüft. Berücksichtigen Sie beim Überprüfen der Fehler den Kontext und den Zustand des Benutzers.

Fehlermeldungen des Programmierers

Falsch:

In diesem Beispiel gibt die Fehlermeldung an, dass ein Fehler im Programm vorliegt. Diese Fehlermeldung hat nur für den Programmierer Bedeutung.

Das Problem: Nachrichten, die den Entwicklern des Programms helfen sollen, Fehler zu finden, bleiben in der Version des Programms erhalten. Diese Fehlermeldungen haben keine Bedeutung oder keinen Wert für Benutzer.

Führende Ursache: Programmierer, die normale UI verwenden, um Nachrichten an sich selbst zu senden.

Empfohlene Alternative: Entwickler müssen alle diese Meldungen bedingt kompilieren, damit sie automatisch aus der Releaseversion eines Produkts entfernt werden. Verschwenden Sie keine Zeit, um Fehler wie diese verständlich für Benutzer zu machen, da ihre einzige Zielgruppe die Programmierer ist.

Fehlermeldungen

Falsch:

In diesem Beispiel sind viele häufige Präsentationsfehler aufgetreten.

Das Problem: Alle Details in der Fehlermeldungspräsentation falsch abrufen.

Führende Ursache: Nicht wissen und die Richtlinien für Fehlermeldungen anwenden. Verwenden Sie keine Autoren und Editoren, um die Fehlermeldungen zu erstellen und zu überprüfen.

Die Art der Fehlerbehandlung ist so, dass viele dieser Fehler sehr einfach zu machen sind. Es ist beunruhigend zu erkennen, dass die meisten Fehlermeldungen für den Hall of Shame nominiert werden konnten.

Die Merkmale guter Fehlermeldungen

Im Gegensatz zu den vorherigen schlechten Beispielen haben gute Fehlermeldungen Folgendes:

• Ein Problem. Gibt an, dass ein Problem aufgetreten ist.
• Eine Ursache. Erläutert, warum das Problem aufgetreten ist.
• Eine Lösung. Stellt eine Lösung bereit, damit Benutzer das Problem beheben können.

Darüber hinaus werden gute Fehlermeldungen so dargestellt, dass:

• Einschlägig. Die Meldung stellt ein Problem dar, das benutzer interessieren.
• Verklagbar. Benutzer sollten entweder eine Aktion ausführen oder ihr Verhalten als Ergebnis der Nachricht ändern.
• Benutzerzentriert. Die Nachricht beschreibt das Problem in Bezug auf Zielbenutzeraktionen oder -ziele, nicht in Bezug auf das, was der Code unglücklich ist.
• Kurz. Die Nachricht ist so kurz wie möglich, aber nicht kürzer.
• Klar. Die Nachricht verwendet einfache Sprache, damit die Zielbenutzer Probleme und Lösungen leicht verstehen können.
• Spezifisch. In der Meldung wird das Problem mit einer bestimmten Sprache beschrieben, wobei bestimmte Namen, Speicherorte und Werte der beteiligten Objekte zurückgegeben werden.
• Höflich. Benutzer sollten nicht schuld sein oder sich dumm fühlen.
• Selten. Selten angezeigt. Häufig angezeigte Fehlermeldungen sind ein Zeichen für ein schlechtes Design.

Wenn Sie ihre Fehlerbehandlungserfahrung so gestalten, dass sie diese Merkmale aufweisen, können Sie die Fehlermeldungen Ihres Programms aus der Fehlermeldungshalle der Schande heraushalten.

Vermeiden unnötiger Fehlermeldungen

Häufig ist die beste Fehlermeldung keine Fehlermeldung. Viele Fehler können durch ein besseres Design vermieden werden, und es gibt häufig bessere Alternativen zu Fehlermeldungen. Normalerweise ist es besser, einen Fehler zu verhindern, als einen zu melden.

Die offensichtlichsten Fehlermeldungen, die vermieden werden sollen, sind solche, die nicht handlungsfähig sind. Wenn Benutzer die Nachricht wahrscheinlich schließen, ohne etwas zu tun oder zu ändern, lassen Sie die Fehlermeldung aus.

Einige Fehlermeldungen können beseitigt werden, da sie aus Sicht des Benutzers keine Probleme haben. Angenommen, der Benutzer hat versucht, eine Datei zu löschen, die bereits gelöscht wird. Dies kann zwar ein unerwarteter Fall aus der Sicht des Codes sein, aber Benutzer betrachten diesen Fehler nicht, da ihr gewünschtes Ergebnis erreicht wird.

Falsch:

gelöscht werden.

Diese Fehlermeldung sollte beseitigt werden, da die Aktion aus Sicht des Benutzers erfolgreich war.

Angenommen, der Benutzer bricht eine Aufgabe explizit ab. Aus Sicht des Benutzers ist die folgende Bedingung kein Fehler.

Falsch:

kann nicht abgeschlossen werden.

Diese Fehlermeldung sollte ebenfalls beseitigt werden, da die Aktion aus Sicht des Benutzers erfolgreich war.

Manchmal können Fehlermeldungen beseitigt werden, indem sie sich auf die Ziele der Benutzer anstatt auf die Technologie konzentrieren. In diesem Fall überdenken Sie, was ein Fehler wirklich ist. Ist das Problem mit den Zielen des Benutzers oder mit der Fähigkeit Ihres Programms, sie zu erfüllen? Wenn die Aktion des Benutzers in der realen Welt sinnvoll ist, sollte es auch in der Software sinnvoll sein.

Angenommen, innerhalb eines E-Commerce-Programms versucht ein Benutzer, ein Produkt mithilfe der Suche zu finden, aber die Literalsuchabfrage hat keine Übereinstimmungen, und das gewünschte Produkt ist nicht mehr vorrätig. Technisch gesehen ist dies ein Fehler, aber anstatt eine Fehlermeldung zu geben, könnte das Programm:

• Suchen Sie weiterhin nach Produkten, die der Abfrage am ehesten entsprechen.
• Wenn die Suche offensichtliche Fehler aufweist, empfehlen Sie automatisch eine korrigierte Abfrage.
• Behandeln Sie häufig auftretende Probleme wie Rechtschreibfehler, alternative Schreibweisen und nicht übereinstimmende Pluralisierungs- und Verbfälle automatisch.
• Geben Sie an, wann das Produkt in Lager ist.

Solange die Anforderung des Benutzers angemessen ist, sollte ein gut gestaltetes E-Commerce-Programm angemessene Ergebnisse zurückgeben, keine Fehler.

Eine weitere großartige Möglichkeit, Fehlermeldungen zu vermeiden, besteht darin, Probleme an erster Stelle zu vermeiden. Sie können Fehler verhindern, indem Sie:

• Verwenden von eingeschränkten Steuerelementen. Verwenden Sie Steuerelemente, die auf gültige Werte beschränkt sind. Steuerelemente wie Listen, Schieberegler, Kontrollkästchen, Optionsfelder und Datums- und Uhrzeitauswahl sind auf gültige Werte beschränkt, während Textfelder häufig keine Fehlermeldungen erfordern. Sie können textfelder jedoch so einschränken, dass nur bestimmte Zeichen akzeptiert werden und eine maximale Anzahl von Zeichen akzeptiert wird.
• Verwenden von eingeschränkten Interaktionen. Bei Ziehvorgängen können Benutzer nur auf gültige Ziele ablegen.
• Verwenden von deaktivierten Steuerelementen und Menüelementen Deaktivieren Sie Steuerelemente und Menüelemente, wenn Benutzer leicht ableiten können, warum das Steuerelement oder Menüelement deaktiviert ist.
• Bereitstellen guter Standardwerte. Benutzer sind weniger wahrscheinlich eingabefehler, wenn sie die Standardwerte akzeptieren können. Selbst wenn Benutzer den Wert ändern möchten, informiert der Standardwert die Benutzer über das erwartete Eingabeformat.
• Machen Sie dinge einfach funktionieren. Benutzer sind weniger wahrscheinlich, Fehler zu machen, wenn die Aufgaben nicht erforderlich sind oder automatisch für sie ausgeführt werden. Oder wenn Benutzer kleine Fehler machen, aber ihre Absicht klar ist, wird das Problem automatisch behoben. Sie können z. B. kleinere Formatierungsprobleme automatisch beheben.

Bereitstellen erforderlicher Fehlermeldungen

Manchmal müssen Sie wirklich eine Fehlermeldung angeben. Benutzer machen Fehler, Netzwerke und Geräte funktionieren nicht mehr, Objekte können nicht gefunden oder geändert werden, Aufgaben können nicht abgeschlossen werden, und Programme weisen Fehler auf. Im Idealfall würden diese Probleme weniger häufig auftreten, wir können unsere Software entwerfen, um viele Arten von Benutzerfehlern zu verhindern, aber es ist nicht realistisch, all diese Probleme zu verhindern. Und wenn eines dieser Probleme auftritt, erhält eine hilfreiche Fehlermeldung die Benutzer schnell wieder auf ihre Füße.

Ein allgemeiner Glaube ist, dass Fehlermeldungen die schlechteste Benutzererfahrung sind und zu allen Kosten vermieden werden sollten, aber es ist genauer zu sagen, dass Die Benutzerverwechslung die schlechteste Erfahrung ist und zu allen Kosten vermieden werden sollte. Manchmal ist diese Kosten eine hilfreiche Fehlermeldung.

Erwägen Sie deaktivierte Steuerelemente. Meistens ist es offensichtlich, warum ein Steuerelement deaktiviert ist, sodass das Deaktivieren des Steuerelements eine hervorragende Möglichkeit ist, eine Fehlermeldung zu vermeiden. Was geschieht jedoch, wenn der Grund für die Deaktivierung eines Steuerelements nicht offensichtlich ist? Der Benutzer kann nicht fortfahren, und es gibt kein Feedback, um das Problem zu ermitteln. Jetzt bleibt der Benutzer hängen und muss entweder das Problem ableiten oder technischen Support erhalten. In solchen Fällen ist es viel besser, das Steuerelement aktiviert zu lassen und stattdessen eine hilfreiche Fehlermeldung zu geben.

Falsch:

Warum ist die Schaltfläche "Weiter" hier deaktiviert? Besser, sie aktiviert zu lassen und Benutzerverwechslungen zu vermeiden, indem Sie eine hilfreiche Fehlermeldung geben.

Wenn Sie nicht sicher sind, ob Sie eine Fehlermeldung geben sollten, erstellen Sie zunächst die Fehlermeldung, die Sie möglicherweise geben möchten. Wenn Benutzer wahrscheinlich eine Aktion ausführen oder ihr Verhalten als Ergebnis ändern möchten, geben Sie die Fehlermeldung an. Wenn Benutzer die Nachricht dagegen wahrscheinlich schließen, ohne etwas zu tun oder zu ändern, lassen Sie die Fehlermeldung aus.

Entwerfen für eine gute Fehlerbehandlung

Während das Erstellen eines guten Fehlermeldungstexts schwierig sein kann, ist es manchmal unmöglich, ohne dass eine gute Unterstützung für die Fehlerbehandlung aus dem Programm besteht. Beachten Sie diese Fehlermeldung:

Falsch:

Wahrscheinlich ist das Problem wirklich unbekannt, da die Fehlerbehandlungsunterstützung des Programms fehlt.

Es ist zwar möglich, dass dies eine sehr schlecht geschriebene Fehlermeldung ist, aber es spiegelt wahrscheinlicher den Mangel an guter Fehlerbehandlung durch den zugrunde liegenden Code wider, es gibt keine spezifischen Informationen über das Problem.

Um bestimmte, aktionenfähige, benutzerzentrierte Fehlermeldungen zu erstellen, muss der Fehlerbehandlungscode Ihres Programms spezifische, allgemeine Fehlerinformationen bereitstellen:

• Jedem Problem sollte ein eindeutiger Fehlercode zugewiesen sein.
• Wenn ein Problem mehrere Ursachen hat, sollte das Programm nach Möglichkeit die spezifische Ursache ermitteln.
• Wenn das Problem Parameter enthält, müssen die Parameter beibehalten werden.
• Low-Level-Probleme müssen auf ausreichend hoher Ebene behandelt werden, damit die Fehlermeldung aus Sicht des Benutzers dargestellt werden kann.

Gute Fehlermeldungen sind nicht nur ein UI-Problem, sie sind ein Softwaredesignproblem. Eine gute Fehlermeldung ist nicht etwas, das später nicht angeheftet werden kann.

Problembehandlung (und wie sie vermieden werden)

Problembehandlungsergebnisse, wenn ein Problem mit mehreren verschiedenen Ursachen mit einer einzelnen Fehlermeldung gemeldet wird.

Falsch:

Richtig:

Problembehandlungsergebnisse, wenn mehrere Probleme mit einer einzelnen Fehlermeldung gemeldet werden.

Im folgenden Beispiel konnte ein Element nicht verschoben werden, weil es bereits verschoben oder gelöscht wurde oder der Zugriff verweigert wurde. Wenn das Programm die Ursache leicht ermitteln kann, warum die Belastung für den Benutzer, um die spezifische Ursache zu bestimmen?

Falsch:

Nun, was ist es? Jetzt muss der Benutzer Eine Problembehandlung durchführen.

Das Programm kann ermitteln, ob der Zugriff verweigert wurde, daher sollte dieses Problem mit einer bestimmten Fehlermeldung gemeldet werden.

Richtig:

Bei einer bestimmten Ursache ist keine Problembehandlung erforderlich.

Verwenden Sie Nachrichten mit mehreren Ursachen nur, wenn die spezifische Ursache nicht bestimmt werden kann. In diesem Beispiel wäre es für das Programm schwierig zu ermitteln, ob das Element verschoben oder gelöscht wurde. Daher kann hier eine einzelne Fehlermeldung mit mehreren Ursachen verwendet werden. Es ist jedoch unwahrscheinlich, dass Benutzer sich um dies kümmern, wenn sie beispielsweise keine gelöschte Datei verschieben konnten. Aus diesen Gründen ist die Fehlermeldung nicht einmal erforderlich.

Behandeln unbekannter Fehler

In einigen Fällen werden Sie das Problem, die Ursache oder die Lösung nicht wirklich kennen. Wenn es unweisen wäre, den Fehler zu unterdrücken, ist es besser, sich vor dem Mangel an Informationen zu befinden, als Probleme, Ursachen oder Lösungen zu präsentieren, die möglicherweise nicht richtig sind.

Wenn Ihr Programm beispielsweise eine unbehandelte Ausnahme aufweist, ist die folgende Fehlermeldung geeignet:

Wenn Sie einen unbekannten Fehler nicht unterdrücken können, ist es besser, sich vorab über den Mangel an Informationen zu informieren.

Geben Sie andererseits spezifische, umsetzbare Informationen an, wenn sie wahrscheinlich die meiste Zeit hilfreich sein werden.

Diese Fehlermeldung eignet sich für einen unbekannten Fehler, wenn die Netzwerkkonnektivität in der Regel das Problem darstellt.

Bestimmen des entsprechenden Nachrichtentyps

Einige Probleme können je nach Betonung und Ausdruck als Fehler, Warnung oder Informationen dargestellt werden. Angenommen, eine Webseite kann ein nicht signiertes ActiveX-Steuerelement basierend auf der aktuellen Windows Internet Explorer-Konfiguration nicht laden:

• Fehler. "Diese Seite kann kein nicht signiertes ActiveX-Steuerelement laden." (Als vorhandenes Problem formuliert.)
• Warnung. "Diese Seite verhält sich möglicherweise nicht wie erwartet, da Windows Internet Explorer nicht für das Laden nicht signierter ActiveX-Steuerelemente konfiguriert ist." oder "Zulassen, dass diese Seite ein nicht signiertes ActiveX-Steuerelement installiert? Dies aus nicht vertrauenswürdigen Quellen kann Ihren Computer beschädigen." (Beide als Bedingungen bezeichnet, die zu zukünftigen Problemen führen können.)
• Information. "Sie haben Windows Internet Explorer so konfiguriert, dass nicht signierte ActiveX-Steuerelemente blockiert werden." (Als Faktenaussage formuliert.)

Um den geeigneten Nachrichtentyp zu ermitteln, konzentrieren Sie sich auf den wichtigsten Aspekt des Problems, den Benutzer kennen oder darauf reagieren müssen. Wenn ein Problem in der Regel verhindert, dass der Benutzer fortfahren kann, sollten Sie ihn als Fehler anzeigen. wenn der Benutzer fortfahren kann, geben Sie ihn als Warnung an. Erstellen Sie die Hauptanweisung oder anderen entsprechenden Text basierend auf diesem Fokus, und wählen Sie dann ein Symbol (Standard- oder anderweitig) aus, das dem Text entspricht. Der Hauptanweisungstext und symbole sollten immer übereinstimmen.

Fehlermeldung

Die meisten Fehlermeldungen in Windows-Programmen werden mithilfe modaler Dialogfelder (wie in den meisten Beispielen in diesem Artikel dargestellt), es gibt jedoch weitere Optionen:

• Direktes Anmelden
• Ballone
• Benachrichtigungen
• Symbole für den Infobereich
• Statusleisten
• Protokolldateien (für Fehler, die an IT-Experten gerichtet sind)

Das Platzieren von Fehlermeldungen in modale Dialogfelder hat den Vorteil, dass der Benutzer sofort auf die Aufmerksamkeit und Bestätigung aufmerksam wird. Dies ist jedoch auch der Hauptnachteil, wenn diese Aufmerksamkeit nicht notwendig ist.

Müssen Sie die Benutzer wirklich unterbrechen, damit sie auf die Schaltfläche "Schließen" klicken können? Falls nicht, erwägen Sie Alternativen zur Verwendung eines modalen Dialogfelds.

Modale Dialogfelder sind eine gute Wahl, wenn der Benutzer das Problem sofort erkennen muss, bevor er fortsetzt, aber oft eine schlechte Wahl sonst. Im Allgemeinen sollten Sie lieber die leichteste Präsentation verwenden, die die Arbeit gut macht.

Vermeiden der Überkommunikation von

Im Allgemeinen lesen Benutzer nicht, sie scannen. Je mehr Text vorhanden ist, desto schwieriger ist es, den Text zu scannen, und die wahrscheinlicheren Benutzer lesen den Text überhaupt nicht. Daher ist es wichtig, den Text auf seine Grundlagen zu reduzieren und bei Bedarf progressive Offenlegungs- und Hilfelinks zu verwenden, um zusätzliche Informationen bereitzustellen.

Es gibt viele extreme Beispiele, aber sehen wir uns ein typisches Beispiel an. Das folgende Beispiel weist die meisten Attribute einer guten Fehlermeldung auf, aber sein Text ist nicht prägnant und erfordert motivationsfrei zu lesen.

Falsch:

Dieses Beispiel ist eine gute Fehlermeldung, aber sie übergibt.

Was sagen all diesen Text wirklich? Ungefähr wie folgt:

Richtig:

Diese Fehlermeldung hat im Wesentlichen die gleichen Informationen, ist aber viel präziser.

Mithilfe der Hilfe zum Bereitstellen der Details weist diese Fehlermeldung eine invertierte Pyramidenformatvorlage der Präsentation auf.

Weitere Richtlinien und Beispiele für die Überkommunikation finden Sie unter Text der Benutzeroberfläche.

Wenn Sie nur acht Dinge

1. Entwerfen Sie Ihr Programm für die Fehlerbehandlung.
2. Geben Sie keine unnötigen Fehlermeldungen an.
3. Vermeiden Sie Benutzerverwechslungen, indem Sie erforderliche Fehlermeldungen senden.
4. Stellen Sie sicher, dass die Fehlermeldung ein Problem, eine Ursache und lösung gibt.
5. Stellen Sie sicher, dass die Fehlermeldung relevant, umsetzbar, kurz, klar, spezifisch, höflich und selten ist.
6. Entwerfen Sie Fehlermeldungen aus der Sicht des Benutzers, nicht die Sicht des Programms.
7. Vermeiden Sie, dass der Benutzer bei der Problembehandlung eine andere Fehlermeldung für jede erkennbare Ursache verwendet.
8. Verwenden Sie die leichteste Präsentationsmethode, die die Arbeit gut macht.

Verwendungsmuster

Fehlermeldungen weisen mehrere Verwendungsmuster auf:

Etikett	Wert
Systemprobleme Das Betriebssystem, das Hardwaregerät, das Netzwerk oder das Programm ist fehlgeschlagen oder ist nicht in dem Zustand vorhanden, der zum Ausführen einer Aufgabe erforderlich ist.	Viele Systemprobleme können vom Benutzer gelöst werden: Geräteprobleme können gelöst werden, indem das Gerät eingeschaltet, das Gerät erneut verbunden und Medien eingefügt werden. Netzwerkprobleme können gelöst werden, indem sie die physische Netzwerkverbindung überprüfen und Netzwerkdiagnose und -reparaturausführen. Programmprobleme können gelöst werden, indem Programmoptionen geändert oder das Programm neu gestartet wird. In diesem Beispiel kann das Programm keine Kamera finden, um eine Benutzeraufgabe auszuführen. In diesem Beispiel muss ein Feature, das zum Ausführen einer Aufgabe erforderlich ist, aktiviert sein.
Dateiprobleme Eine datei oder ein Ordner, die für eine vom Benutzer initiierte Aufgabe nicht gefunden wurde, wird bereits verwendet oder hat nicht das erwartete Format.	gelöscht werden. In diesem Beispiel kann die Datei oder der Ordner nicht gelöscht werden, da sie nicht gefunden wurde. wiedergegeben werden. In diesem Beispiel unterstützt das Programm das angegebene Dateiformat nicht.
Sicherheitsprobleme Der Benutzer verfügt nicht über die Berechtigung für den Zugriff auf eine Ressource oder über ausreichende Berechtigungen zum Ausführen einer vom Benutzer initiierten Aufgabe.	In diesem Beispiel verfügt der Benutzer nicht über die Berechtigung für den Zugriff auf eine Ressource. In diesem Beispiel verfügt der Benutzer nicht über die Berechtigung, eine Aufgabe auszuführen.
Aufgabenprobleme Es gibt ein bestimmtes Problem beim Ausführen einer vom Benutzer initiierten Aufgabe (außer einem System, datei nicht gefunden, Dateiformat oder Sicherheitsproblem).	eingefügt werden In diesem Beispiel können die Zwischenablagedaten nicht in Paint eingefügt werden. installiert werden In diesem Beispiel kann der Benutzer kein Softwareupgrade installieren.
Benutzereingabeprobleme Der Benutzer hat einen Wert eingegeben, der falsch ist oder mit anderen Benutzereingaben inkonsistent ist.	In diesem Beispiel hat der Benutzer einen falschen Zeitwert eingegeben. In diesem Beispiel weist die Benutzereingabe nicht das richtige Format auf.

Leitlinien

Präsentation

• Verwenden Sie Aufgabendialogfelds, wenn dies geeignet ist, um ein einheitliches Aussehen und Layout zu erzielen. Aufgabendialoge erfordern Windows Vista oder höher, sodass sie nicht für frühere Versionen von Windows geeignet sind. Wenn Sie ein Meldungsfeld verwenden müssen, trennen Sie die Hauptanweisung von der ergänzenden Anweisung durch zwei Zeilenumbrüche.

Fehler bei der Benutzereingabe

• , wenn möglich, verhindern oder reduzieren Sie Benutzereingabefehler durch:
  • Verwenden von Steuerelementen, die auf gültige Werte beschränkt sind.
  • Das Deaktivieren von Steuerelementen und Menüelementen beim Klicken würde zu Einem Fehler führen, solange offensichtlich, warum das Steuerelement oder Menüelement deaktiviert ist.
  • Bereitstellen guter Standardwerte.

Falsch:

In diesem Beispiel wird ein nicht eingeschränktes Textfeld für eingeschränkte Eingaben verwendet. Verwenden Sie stattdessen einen Schieberegler.

• Moduslose Fehlerbehandlung (direkte Fehler oder Sprechblasen) für kontextbezogene Benutzereingabeprobleme.
• Verwenden Von Sprechblasen für nicht kritische Benutzereingabeprobleme, die während eines Textfelds oder unmittelbar nach einem Textfeld erkannt wurden, verliert der Fokus.Sprechblasen benötigen keinen verfügbaren Bildschirmbereich oder das dynamische Layout, das zum Anzeigen von direkten Nachrichten erforderlich ist. Zeigt jeweils nur eine einzelne Sprechblase an. Da das Problem nicht kritisch ist, ist kein Fehlersymbol erforderlich. Sprechblasen gehen beim Klicken, beim Beheben des Problems oder nach einem Timeout weg.

In diesem Beispiel zeigt eine Sprechblase ein Eingabeproblem an, während sie sich noch im Steuerelement befinden.

• Verwenden Sie direkte Fehler für die verzögerte Fehlererkennung, in der Regel Fehler, die durch Klicken auf eine Commit-Schaltfläche gefunden wurden. (Verwenden Sie nicht direkte Fehler für Einstellungen, die sofort zugesichert werden.) Es können mehrere direkte Fehler gleichzeitig vorhanden sein. Verwenden Sie normaler Text und ein 16 x 16 Pixel-Fehlersymbol, und platzieren Sie sie nach Möglichkeit direkt neben dem Problem. Direkte Fehler werden nicht entfernt, es sei denn, der Benutzer hat einen Commit ausgeführt, und es werden keine anderen Fehler gefunden.

In diesem Beispiel wird ein In-Situ-Fehler für einen Fehler verwendet, der durch Klicken auf die Commit-Schaltfläche gefunden wurde.

• Verwenden Sie die modale Fehlerbehandlung (Aufgabendialogfelder oder Meldungsfelder) für alle anderen Probleme, einschließlich Fehlern, die mehrere Steuerelemente umfassen oder nicht kontextbezogene oder nicht-Eingabefehler sind, die durch Klicken auf eine Commit-Schaltfläche gefunden werden.
• Wenn ein Benutzereingabeproblem gemeldet wird, legen Sie den Eingabefokus auf das erste Steuerelement mit den falschen Daten fest. Scrollen Sie bei Bedarf in der Ansicht des Steuerelements. Wenn es sich bei dem Steuerelement um ein Textfeld handelt, markieren Sie den gesamten Inhalt. Es sollte immer offensichtlich sein, auf was sich die Fehlermeldung bezieht.
• Löschen Sie keine falschen Eingaben. Lassen Sie es stattdessen so, dass der Benutzer das Problem sehen und beheben kann, ohne zu beginnen.
  • Ausnahme: Ungültiges Kennwort und PIN-Textfelder löschen, da Benutzer die maskierte Eingabe nicht effektiv korrigieren können.

Fehlerbehebung

• Vermeiden Sie das Erstellen von Problemen mit der Problembehandlung. Verlassen Sie sich nicht auf eine einzelne Fehlermeldung, um ein Problem mit verschiedenen erkannten Ursachen zu melden.
• Verwenden Sie eine andere Fehlermeldung (in der Regel eine andere ergänzende Anweisung) für jede erkennbare Ursache. Wenn eine Datei z. B. aus mehreren Gründen nicht geöffnet werden kann, geben Sie aus jedem Grund eine separate ergänzende Anweisung an.
• Verwenden Sie eine Nachricht mit mehreren Ursachen nur, wenn die spezifische Ursache nicht bestimmt werden kann. Stellen Sie in diesem Fall die Lösungen dar, um das Problem zu beheben. Auf diese Weise können Benutzer das Problem effizienter lösen.

Ikonen

• Modale Fehlermeldungsdialoge enthalten keine Titelleistensymbole. Titelleistensymbole werden als visueller Unterschied zwischen primären und sekundären Fenstern verwendet.

• Verwenden Sie ein Fehlersymbol. Ausnahmen:

  • Wenn es sich bei dem Fehler um ein Benutzereingabeproblem handelt, das mithilfe eines modalen Dialogfelds oder einer Sprechblase angezeigt wird, verwenden Sie kein Symbol. Dies ist gegen den ermutigenden Ton von Windows. Direkte Fehlermeldungen sollten jedoch ein kleines Fehlersymbol (16 x 16 Pixel) verwenden, um sie eindeutig als Fehlermeldungen zu identifizieren.

    

    

    In diesen Beispielen benötigen Benutzereingabeprobleme keine Fehlersymbole.

    

    In diesem Beispiel benötigt eine direkte Fehlermeldung ein kleines Fehlersymbol, um sie eindeutig als Fehlermeldung zu identifizieren.

• Wenn das Problem für ein Feature mit einem Symbol (und kein Benutzereingabeproblem) besteht, können Sie das Featuresymbol mit einer Fehlerüberlagerung verwenden. Wenn Sie dies tun, verwenden Sie auch den Featurenamen als Betreff des Fehlers.

  

  In diesem Beispiel weist das Featuresymbol eine Fehlerüberlagerung auf, und das Feature ist gegenstand des Fehlers.

• Verwenden Sie keine Warnsymbole für Fehler. Dies geschieht oft, damit die Präsentation weniger schwerwiegend wirkt. Fehler sind keine Warnungen.

  Falsch:

  

  In diesem Beispiel wird ein Warnsymbol fälschlicherweise verwendet, um den Fehler weniger schwerwiegend zu machen.

Weitere Richtlinien und Beispiele finden Sie unter Standardsymbole.

Progressive Offenlegung

• Verwenden Sie eine Schaltfläche zum Einblenden/Ausblenden von Details, um erweiterte oder detaillierte Informationen in einer Fehlermeldung auszublenden. Dadurch wird die Fehlermeldung für die typische Verwendung vereinfacht. Blenden Sie die benötigten Informationen nicht aus, da Benutzer sie möglicherweise nicht finden.

In diesem Beispiel hilft die Progressive Offenlegungsschaltfläche Benutzern, einen Drilldown zu detaillierteren Informationen zu erstellen, wenn sie dies wünschen, oder vereinfachen Sie die Benutzeroberfläche, wenn sie nicht.

• Verwenden Sie "Details einblenden/ausblenden", es sei denn, es gibt wirklich mehr Details. Verwenden Sie nicht nur die vorhandenen Informationen in einem ausführlicheren Format.
• Verwenden Sie keine Details ein-/ausblenden, um Hilfeinformationen anzuzeigen. Verwenden Sie stattdessen Hilfelinks.

Bezeichnungsrichtlinien finden Sie unter Progressive Offenlegungssteuerelemente.

Diese Meldung nicht erneut anzeigen

• Wenn eine Fehlermeldung diese Option benötigt, sollten Sie den Fehler und dessen Häufigkeit überdenken. Wenn es alle Merkmale eines guten Fehlers (relevant, handlungsfähig und selten) aufweist, sollte es nicht sinnvoll sein, dies zu unterdrücken.

Weitere Richtlinien finden Sie unter Dialogfelder.

Standardwerte

• Wählen Sie die sicherste, am wenigsten destruktive oder sicherste Antwort als Standard aus. Wenn Sicherheit kein Faktor ist, wählen Sie den wahrscheinlichsten oder praktischsten Befehl aus.

Hilfe

• Entwerfen Sie Fehlermeldungen, um die Notwendigkeit von Hilfe zu vermeiden. Normalerweise sollten Benutzer keinen externen Text lesen müssen, um das Problem zu verstehen und zu lösen, es sei denn, die Lösung erfordert mehrere Schritte.
• Stellen Sie sicher, dass der Hilfeinhalt relevant und hilfreich ist. Es sollte nicht eine ausführliche Restatement der Fehlermeldung sein, sondern sollte nützliche Informationen enthalten, die über den Umfang der Fehlermeldung hinausgehen, z. B. Möglichkeiten, das Problem in Zukunft zu vermeiden. Stellen Sie keinen Hilfelink bereit, nur weil sie möglich sind.
• Verwenden Sie spezifische, präzise, relevante Hilfelinks, um auf Hilfeinhalte zuzugreifen. Verwenden Sie für diesen Zweck keine Befehlsschaltflächen oder progressive Offenlegung.
• Bei Fehlermeldungen, die Sie nicht spezifisch und umsetzbar machen können, sollten Sie Links zu Onlinehilfeinhalten bereitstellen. Auf diese Weise können Sie Benutzern zusätzliche Informationen bereitstellen, die Sie nach der Veröffentlichung des Programms aktualisieren können.

Weitere Richtlinien finden Sie unter Hilfe.

Fehlercodes

• Bei Fehlermeldungen, die Sie nicht spezifisch und umsetzbar machen können oder die von der Hilfe profitieren, sollten Sie auch Fehlercodes bereitstellen. Benutzer verwenden diese Fehlercodes häufig, um im Internet nach zusätzlichen Informationen zu suchen.
• Geben Sie immer eine Textbeschreibung des Problems und der Lösung an. Hängen Sie nicht nur vom Fehlercode für diesen Zweck ab.

Falsch:

In diesem Beispiel wird ein Fehlercode als Ersatz für einen Lösungstext verwendet.

• Weisen Sie für jede andere Ursache einen eindeutigen Fehlercode zu. Dadurch wird die Problembehandlung vermieden.
• Wählen Sie Fehlercodes aus, die im Internet leicht durchsuchbar sind. Wenn Sie 32-Bit-Codes verwenden, verwenden Sie eine Hexadezimaldarstellung mit führenden "0x"- und Großbuchstaben.

Richtig:

1234

0xC0001234

Falsch:

-1

-67113524

• Verwenden Sie "Details ein-/ausblenden", um Fehlercodes anzuzeigen. Ausdruck als Fehlercode: <error code>.

nicht initialisiert.

In diesem Beispiel wird ein Fehlercode verwendet, um eine Fehlermeldung zu ergänzen, die von weiteren Informationen profitieren kann.

Ton

• Begleiten Sie keine Fehlermeldungen mit einem Soundeffekt oder Signalton. Dies ist störend und unnötig.
  • Ausnahme: Soundeffekt "Kritischer Stopp wiedergeben", wenn das Problem für den Betrieb des Computers von entscheidender Bedeutung ist, und der Benutzer muss sofortige Maßnahmen ergreifen, um schwerwiegende Konsequenzen zu vermeiden.

Text

allgemeine

• Entfernen Sie redundanten Text. Suchen Sie in Titeln, Hauptanweisungen, ergänzenden Anweisungen, Befehlslinks und Commit-Schaltflächen. Behalten Sie im Allgemeinen Volltext in Anweisungen und interaktiven Steuerelementen bei, und entfernen Sie alle Redundanzen an den anderen Stellen.
• Verwenden Sie benutzerzentrierte Erläuterungen. Beschreiben Sie das Problem in Bezug auf Benutzeraktionen oder Ziele, nicht in Bezug auf das, was die Software unglücklich ist. Verwenden Sie die Sprache, die die Zielbenutzer verstehen und verwenden. Vermeiden Sie technischen Jargon.

Falsch:

Richtig:

In diesen Beispielen spricht die richtige Version die Sprache des Benutzers, während die falsche Version übermäßig technisch ist.

• Verwenden Sie nicht die folgenden Wörter:
  • Fehler, Fehler (stattdessen Problem verwenden)
  • Fehler beim Ausführen (Verwenden nicht möglich)
  • Ungültig, ungültig, ungültig (stattdessen falsch verwenden)
  • Abbrechen, beenden, beenden (stattdessen Beenden verwenden)
  • Katastrophal, tödlich (stattdessen ernsthaften Gebrauch)

Diese Begriffe sind unnötig und entgegen dem ermutigenden Ton von Windows. Wenn ordnungsgemäßverwendet wird, teilt das Fehlersymbol ausreichend mit, dass ein Problem vorliegt.

Falsch:

Richtig:

Im falschen Beispiel sind die Begriffe "katastrophal" und "Fehler" unnötig.

• Verwenden Sie keine Ausdrücke, die dem Benutzer die Schuld geben oder einen Benutzerfehler impliziert. Vermeiden Sie es, Sie und Ihre Ausdrücke zu verwenden. Während die aktive Stimme im Allgemeinen bevorzugt wird, verwenden Sie die passive Stimme, wenn der Benutzer das Thema ist, und fühlen Sie sich möglicherweise für den Fehler verantwortlich, wenn die aktive Stimme verwendet wurde.

Falsch:

Richtig:

Das falsche Beispiel weist dem Benutzer die Schuld mithilfe der aktiven Stimme zu.

• Seien Sie spezifisch. Vermeiden Sie vage Formulierungen, z. B. Syntaxfehler und unzulässige Vorgänge. Geben Sie bestimmte Namen, Speicherorte und Werte der beteiligten Objekte an.

Falsch:

Die Datei wurde nicht gefunden.

Der Datenträger ist voll.

Wert außerhalb des Bereichs.

Das Zeichen ist ungültig.

Das Gerät ist nicht verfügbar.

Diese Probleme wären mit bestimmten Namen, Speicherorten und Werten viel einfacher zu lösen.

• Geben Sie möglicherweise unwahrscheinliche Probleme, Ursachen oder Lösungen nicht an, um spezifisch zu sein. Stellen Sie kein Problem, eine Ursache oder Lösung bereit, es sei denn, es ist wahrscheinlich richtig. Beispielsweise ist es besser, einen unbekannten Fehler zu sagen, als etwas, das wahrscheinlich ungenau ist.
• Vermeiden Sie das Wort "bitte", außer in Situationen, in denen der Benutzer aufgefordert wird, etwas unannelich (z. B. Warten) zu tun, oder die Software ist schuld an der Situation.

Richtig:

Warten Sie, während Windows die Dateien auf Ihren Computer kopiert.

• Verwenden Sie das Wort "leider" nur in Fehlermeldungen, die zu schwerwiegenden Problemen für den Benutzer führen (z. B. Datenverlust oder Unfähigkeit, den Computer zu verwenden). Entschuldigen Sie sich nicht, wenn das Problem während des normalen Funktionierens des Programms aufgetreten ist (z. B. wenn der Benutzer warten muss, bis eine Netzwerkverbindung gefunden wurde).

Richtig:

Leider hat Fabrikam Backup ein nicht behebbares Problem erkannt und wurde heruntergefahren, um Dateien auf Ihrem Computer zu schützen.

• Verweisen Sie auf Produkte, die ihre Kurznamen verwenden. Verwenden Sie keine vollständigen Produktnamen oder Markensymbole. Fügen Sie den Firmennamen nicht ein, es sei denn, Benutzer ordnen den Firmennamen dem Produkt zu. Fügen Sie keine Programmversionsnummern ein.

Falsch:

Richtig:

Im falschen Beispiel werden vollständige Produktnamen und Markensymbole verwendet.

• Verwenden Sie doppelte Anführungszeichen um Objektnamen. Dadurch wird die Analyse des Texts erleichtert und potenziell peinliche Aussagen vermieden.
  • Ausnahme: Vollqualifizierte Dateipfade, URLs und Domänennamen müssen sich nicht in doppelten Anführungszeichen befinden.

Richtig:

In diesem Beispiel wäre die Fehlermeldung verwirrend, wenn sich der Objektname nicht in Anführungszeichen befand.

• Vermeiden Sie den Beginn von Sätzen mit Objektnamen. Dies ist oft schwierig zu analysieren.
• Verwenden Sie keine Ausrufezeichen oder Wörter mit allen Großbuchstaben. Ausrufezeichen und Großbuchstaben machen das Gefühl, dass Sie beim Benutzer schreien.

Weitere Richtlinien und Beispiele finden Sie unter Style and Tone.

Titel

• Verwenden Sie den Titel, um den Befehl oder das Feature zu identifizieren, von dem der Fehler stammt. Ausnahmen:
  • Wenn ein Fehler von vielen verschiedenen Befehlen angezeigt wird, sollten Sie stattdessen den Programmnamen verwenden.
  • Wenn dieser Titel redundant oder verwirrend mit der Hauptanweisung wäre, verwenden Sie stattdessen den Programmnamen.
• Verwenden Sie den Titel nicht, um das Problem zu erläutern oder zusammenzufassen, das der Zweck der Hauptanweisung ist.

Falsch:

In diesem Beispiel wird der Titel fälschlicherweise verwendet, um das Problem zu erläutern.

• Verwenden Sie die Groß-/Kleinschreibung im Titelformat, ohne die Interpunktion zu beenden.

Hauptanweisungen

• Verwenden Sie die Hauptanweisung, um das Problem in klarer, einfacher, bestimmter Sprache zu beschreiben.
• Seien Sie prägnant, verwenden Sie nur einen einzigen, vollständigen Satz. Analysieren Sie die Hauptanweisung auf die wesentlichen Informationen. Sie können den Betreff implizit lassen, wenn es sich um Ihr Programm oder den Benutzer handelt. Schließen Sie den Grund für das Problem ein, wenn Sie dies präzise tun können. Wenn Sie etwas mehr erklären müssen, verwenden Sie eine ergänzende Anweisung.

Falsch:

installiert werden

In diesem Beispiel wird die gesamte Fehlermeldung in die Hauptanweisung gesetzt, sodass sie schwer zu lesen ist.

• Geben Sie ihren Namen, wenn Objekte beteiligt sind.
• Vermeiden Sie das Einfügen vollständiger Dateipfade und URLs in die Hauptanweisung. Verwenden Sie stattdessen einen kurzen Namen (z. B. den Dateinamen), und setzen Sie den vollständigen Namen (z. B. den Dateipfad) in die ergänzende Anweisung. Sie können jedoch einen einzigen vollständigen Dateipfad oder eine url in die Hauptanweisung einfügen, wenn die Fehlermeldung andernfalls keine zusätzliche Anweisung benötigt.

In diesem Beispiel befindet sich nur der Dateiname in der Hauptanweisung. Der vollständige Pfad befindet sich in der ergänzenden Anweisung.

• Geben Sie überhaupt nicht den vollständigen Dateipfad und die vollständige URL an, wenn sie aus dem Kontext offensichtlich ist.

In diesem Beispiel wird vom Benutzer eine Datei aus dem Windows-Explorer umbenannt. In diesem Fall ist der vollständige Dateipfad nicht erforderlich, da er aus dem Kontext offensichtlich ist.

• Verwenden Sie nach Möglichkeit präsente Zehner.
• Verwenden Sie großgeschriebene Sätze.
• Schließen Sie keine letzten Punkte ein, wenn es sich bei der Anweisung um eine Anweisung handelt. Wenn die Anweisung eine Frage ist, fügen Sie ein endgültiges Fragezeichen ein.

Hauptanweisungsvorlagen

Obwohl es keine strengen Regeln für ausdrücke gibt, versuchen Sie, die folgenden Hauptanweisungsvorlagen nach Möglichkeit zu verwenden:

• [Optionaler Antragstellername] kann nicht [Aktion ausführen]
• [optionaler Antragstellername] kann keine [Aktion ausführen] weil [Grund]
• [optionaler Antragstellername] kann [Aktion] nicht auf "[Objektname]" ausführen.
• [optionaler Antragstellername] kann [Aktion] nicht auf "[Objektname]" ausführen, weil [Grund]
• [Ressource] ist nicht ausreichend, um [Aktion auszuführen]
• [Antragstellername] weist keinen [Objektnamen] auf, der für [Zweck] erforderlich ist.
• [Gerät oder Einstellung] ist deaktiviert, sodass [unerwünschte Ergebnisse]
• [Gerät oder Einstellung] ist nicht [verfügbar | gefunden | aktiviert | aktiviert]
• "[Objektname]" ist zurzeit nicht verfügbar.
• Der Benutzername oder das Kennwort ist falsch.
• Sie sind nicht berechtigt, auf "[Objektname]" zuzugreifen.
• Sie haben keine Berechtigung zum [Ausführen einer Aktion]
• [Programmname] hat ein ernstes Problem erlebt und muss sofort schließen

Nehmen Sie natürlich nach Bedarf Änderungen vor, damit die Hauptanweisung grammatikalisch korrekt ist und den wichtigsten Anweisungsrichtlinien entspricht.

Ergänzende Anweisungen

• Verwenden Sie die ergänzende Anweisung, um:
  • Geben Sie weitere Details zum Problem an.
  • Erklären Sie die Ursache des Problems.
  • Führen Sie die Schritte auf, die der Benutzer ausführen kann, um das Problem zu beheben.
  • Stellen Sie Maßnahmen bereit, um zu verhindern, dass das Problem erneut auftritt.
• Wenn möglich, schlagen Sie eine praktische, hilfreiche Lösung vor, damit Benutzer das Problem beheben können. Stellen Sie jedoch sicher, dass die vorgeschlagene Lösung das Problem wahrscheinlich lösen wird. Verschwenden Sie die Zeit der Benutzer nicht, indem Sie mögliche, aber ununwahrscheinliche Lösungen vorschlagen.

Falsch:

In diesem Beispiel ist das Problem und seine empfohlene Lösung möglich, aber sie sind sehr unwahrscheinlich.

• Wenn das Problem ein falscher Wert ist, den der Benutzer eingegeben hat, verwenden Sie die ergänzende Anweisung, um die richtigen Werte zu erläutern. Benutzer sollten diese Informationen nicht aus einer anderen Quelle ermitteln müssen.
• Stellen Sie keine Lösung bereit, wenn sie trivial aus der Problemausweisung abgeleitet werden kann.

In diesem Beispiel ist keine ergänzende Anweisung erforderlich; die Lösung kann von der Problemerklärung trivial abgeleitet werden.

• Wenn die Lösung mehrere Schritte enthält, geben Sie die Schritte in der Reihenfolge an, in der sie abgeschlossen werden sollen. Vermeiden Sie jedoch mehrstufige Lösungen, da Benutzer Schwierigkeiten haben, sich mehr als zwei oder drei einfache Schritte zu merken. Wenn weitere Schritte erforderlich sind, lesen Sie das entsprechende Hilfethema.
• Halten Sie ergänzende Anweisungen prägnant. Geben Sie nur an, was Benutzer wissen müssen. Lassen Sie unnötige Details aus. Ziel für maximal drei Sätze mittlerer Länge.
• Um Fehler zu vermeiden, während Benutzer Anweisungen ausführen, platzieren Sie die Ergebnisse vor der Aktion.

Richtig:

Klicken Sie auf 'OK', um Windows neu zu starten.

Falsch:

Klicken Sie auf 'OK', um Windows neu zu starten.

Im falschen Beispiel ist es wahrscheinlicher, dass Benutzer versehentlich auf "OK" klicken.

• Empfehlen Sie nicht, sich an einen Administrator zu wenden, es sei denn, dies gehört zu den wahrscheinlichsten Lösungen für das Problem. Reservieren Sie solche Lösungen für Probleme, die wirklich nur von einem Administrator gelöst werden können.

Falsch:

In diesem Beispiel liegt wahrscheinlich das Problem bei der Netzwerkverbindung des Benutzers, daher lohnt es sich nicht, sich an einen Administrator zu wenden.

• Empfehlen Sie nicht, sich an den technischen Support zu wenden. Die Möglichkeit, sich an den technischen Support zu wenden, um ein Problem zu lösen, ist immer verfügbar und muss nicht über Fehlermeldungen heraufgestuft werden. Konzentrieren Sie sich stattdessen auf das Schreiben hilfreicher Fehlermeldungen, damit Benutzer Probleme lösen können, ohne sich an den technischen Support zu wenden.

Falsch:

In diesem Beispiel empfiehlt die Fehlermeldung fälschlicherweise die Kontaktaufnahme mit dem technischen Support.

• Verwenden Sie vollständige Sätze, Groß-/Kleinschreibung im Satzformat und endende Interpunktion.

Schaltflächen "Commit ausführen"

• Wenn die Fehlermeldung Befehlsschaltflächen oder Befehlslinks bereitstellt, die das Problem lösen, befolgen Sie die entsprechenden Richtlinien in Dialogfeldern.
• Wenn das Programm aufgrund des Fehlers beendet werden muss, geben Sie eine Exit-Programmschaltfläche an. Um Verwirrung zu vermeiden, verwenden Sie "Schließen" für diesen Zweck nicht.
• Stellen Sie andernfalls eine Schaltfläche "Schließen" bereit. Verwenden Sie "OK" nicht für Fehlermeldungen, da diese Formulierung impliziert, dass Probleme ok sind.
  • Ausnahme: Ok verwenden, wenn ihr Fehlerberichterstattungsmechanismus feste Bezeichnungen aufweist (wie bei der MessageBox-API).)

Dokumentation

Beim Verweisen auf Fehler:

• Verweisen Sie auf Fehler anhand ihrer Hauptanweisung. Wenn die Hauptanweisung lang oder detailliert ist, fassen Sie sie zusammen.
• Bei Bedarf verweisen Sie möglicherweise auf ein Dialogfeld mit fehlermeldungen als Meldung. Eine Fehlermeldung wird nur in der Programmierung und anderen technischen Dokumentationen angezeigt.
• Formatieren Sie den Text nach Möglichkeit fett. Platzieren Sie den Text andernfalls nur dann in Anführungszeichen, wenn dies erforderlich ist, um Verwirrung zu vermeiden.

Beispiel: Wenn Sie eine Es ist kein CD-Datenträger im Laufwerk Meldung vorhanden, fügen Sie einen neuen CD-Datenträger in das Laufwerk ein, und versuchen Sie es erneut.