Wie kann man Benutzer dazu bringen, Fehlermeldungen zu lesen?

Wenn Sie für ein nichttechnisches Publikum programmieren, besteht ein hohes Risiko, dass Benutzer Ihre sorgfältig formulierten und aufschlussreichen Fehlermeldungen nicht lesen, sondern nur frustriert auf die erste verfügbare Schaltfläche klicken.

Daher frage ich mich, welche bewährten Methoden Sie empfehlen können, um Benutzern das Lesen Ihrer Fehlermeldung zu erleichtern, anstatt einfach darauf zu verzichten. Ideen, an die ich denken kann, fallen in folgende Richtung:

• Formatierung natürlich helfen; Vielleicht eine einfache, kurze Nachricht mit einer Schaltfläche "Weitere Informationen", die zu einer längeren, detaillierteren Fehlermeldung führt
• Lassen Sie alle Fehlermeldungen auf einen Abschnitt des Benutzerhandbuchs verweisen (etwas schwer zu erreichen).
• Geben Sie einfach keine Fehlermeldungen aus, sondern lehnen Sie die Ausführung der Aufgabe ab (eine etwas "Apple" -Methode für die Eingabe von Benutzereingaben).

Bearbeiten: Das Publikum, an das ich denke, ist eine ziemlich breite Benutzerbasis, die die Software nicht zu oft verwendet und nicht in Gefangenschaft ist (dh keine interne Software oder enge Community). Eine allgemeinere Form dieser Frage wurde auf slashdot gestellt , daher sollten Sie dort nach Antworten suchen.

Das ist eine ausgezeichnete Frage, die eine +1 von mir verdient. Die Frage ist zwar einfach, deckt jedoch viele Aspekte der Art der Endnutzer ab. Es läuft hier auf eine Reihe von Faktoren hinaus, die Ihnen und der Software selbst und natürlich den Endbenutzern zugute kommen würden.

• Platzieren Sie keine Fehlermeldungen in der Statusleiste - sie werden sie nie lesen, obwohl sie mit Farben usw. aufgepeppt sind. Sie werden sie immer vermissen! Egal wie sehr Sie es auch versuchen werden ... Zu einem Zeitpunkt während des Win 95-UI-Tests vor dem Start führte MS ein Experiment zum Lesen der UI durch ( ed - es sollte beachtet werden, dass die Nachricht explizit im Kontext von angegeben wurde 'Schau unter den Stuhl' ), mit einem 100-Dollar-Schein an der Unterseite des Stuhls, auf dem die Probanden saßen ... niemand entdeckte die Nachricht in der Statusleiste!
• Machen Sie die Nachrichten kurz, verwenden Sie keine einschüchternden Wörter wie "Warnung: Das System ist auf ein Problem gestoßen". Der Endbenutzer wird die Panik-Taste drücken und überreagieren ...
• Egal wie sehr Sie es auch versuchen, verwenden Sie keine Farben, um die Nachricht zu identifizieren ... psychologisch ist es so, als würde man dem Stier eine rote Fahne schwenken!
• Verwenden Sie neutral klingende Wörter, um minimale Reaktionen und Vorgehensweisen zu vermitteln!
• Es ist möglicherweise besser, ein Dialogfeld mit der neutralen Fehlermeldung anzuzeigen und ein Kontrollkästchen einzuschließen, das angibt, ob Sie in Zukunft mehr dieser Fehlermeldungen sehen möchten. Das Letzte, was ein Endbenutzer möchte, ist das Arbeiten In der Mitte der Software, die mit Popup-Nachrichten bombardiert werden soll, werden sie frustriert und von der Anwendung ausgeschaltet! Wenn das Kontrollkästchen aktiviert war, protokollieren Sie es stattdessen in einer Datei ...
• Halten Sie die Endbenutzer über die Fehlermeldungen auf dem Laufenden ... was impliziert ... Schulung und Dokumentation ... jetzt ist dies eine schwierige Frage ... Sie möchten nicht, dass sie glauben, dass dies der Fall sein wird seien 'Probleme' oder 'Pannen' und was in diesem Fall zu tun ist ... sie dürfen nicht wissen, dass es mögliche Fehler geben wird, in der Tat schwierig.
• Haben Sie immer, immer keine Angst, um Feedback zu bitten, wenn das Ereignis eintritt - wie z. B. „Als diese Fehlernummer 1304 auftauchte, wie haben Sie reagiert? Was war Ihre Interpretation? - Der Bonus dabei ist, dass der Endbenutzer Ihnen möglicherweise eine kohärentere Erklärung geben kann als "Fehler 1304, Datenbankobjekt verloren!". Stattdessen kann er möglicherweise sagen: "Ich habe darauf geklickt." und so, dann hat jemand versehentlich das Netzwerkkabel der Maschine gezogen ', dies wird Sie darauf hinweisen, dass Sie sich damit befassen müssen, und kann den Fehler so ändern, dass' Ups, Netzwerkverbindung getrennt 'lautet ... Sie bekommen die Abweichung.
• Wenn Sie ein internationales Publikum ansprechen möchten, sollten Sie die Internationalisierung der Fehlermeldungen berücksichtigen. Deshalb sollten Sie sie neutral halten, da sie dann einfacher zu übersetzen sind und Synonyme, Slang-Wörter usw. vermeiden Die Übersetzung war bedeutungslos - zum Beispiel verkaufte Fiat Ford, die Automobilfirma, ihre Marke Fiat Ford Pinto, bemerkte jedoch, dass in Südamerika keine Verkäufe stattfanden. Es stellte sich heraus, dass Pinto dort ein Slang für „kleinen Penis“ und daher keine Verkäufe war ...
• ( ed ) Dokumentieren Sie die Liste der zu erwartenden Fehlermeldungen in einem separaten Abschnitt der Dokumentation mit dem Titel "Fehlermeldungen" oder "Korrekturmaßnahmen" oder ähnlichem und geben Sie die Fehlernummern in der richtigen Reihenfolge mit ein oder zwei Anweisungen zum weiteren Vorgehen an. ..
• ( ed ) Dank an Victor Hurdugaci für seine Beiträge, halten Sie die Nachrichten höflich, lassen Sie die Endbenutzer sich nicht dumm fühlen. Dies widerspricht der Antwort von Jack Marchetti, wenn die Nutzerbasis international ist ...

Edit: Ein besonderes Dankeschön an Gnibbler, der noch einen weiteren äußerst wichtigen Punkt erwähnt hat!

• Ermöglichen Sie dem Endbenutzer, die Fehlermeldung auszuwählen / zu kopieren, damit er auf Wunsch eine E-Mail an das Help-Support-Team oder das Entwicklungsteam senden kann.

Edit # 2: Mein schlechtes! Hoppla, dank DanM, der das über das Auto erwähnt hat, habe ich den Namen verwechselt , es war Ford Pinto ... mein schlechtes ...

Bearbeiten Nr. 3: Hervorgehoben durch ed , um Zusätze oder Nachträge anzugeben, und anderen für ihre Eingaben gutgeschrieben ...

Edit # 4: Als Antwort auf Kens Kommentar - hier ist meine Einstellung ... Nein, ist es nicht, verwenden Sie neutrale Standard-Windows-Farben ... wählen Sie keine auffälligen Farben! Halten Sie sich an die normale graue Hintergrundfarbe mit schwarzem Text, die eine normale Standard-GUI-Richtlinie in den Microsoft-Spezifikationen ist. Siehe UX-Richtlinien ( ed ).

Wenn Sie zumindest auf auffällige Farben bestehen, berücksichtigen Sie potenzielle farbenblinde Benutzer, dh die Zugänglichkeit, die ein weiterer wichtiger Faktor für Menschen mit Behinderungen ist, bildschirmvergrößerungsfreundliche Fehlermeldungen, Farbenblindheit und diejenigen, die unter Albino leiden kann empfindlich auf auffällige Farben und auch auf Epileptiker reagieren ... die unter bestimmten Farben leiden können, die einen Anfall auslösen könnten ...

Zeigen Sie ihnen die Nachricht. Due Dilligence und alles, aber protokollieren Sie jeden Fehler in einer Datei. Benutzer können sich nicht erinnern, was sie getan haben oder wie die Fehlermeldung Sekunden nach dem Ereignis lautete. Es ist wie bei Augenzeugenberichten von Tätern.

Bieten Sie eine gute Möglichkeit, ihnen das Versenden von E-Mails oder das Hochladen des Protokolls zu ermöglichen, damit Sie sie bei der Lösung des Problems unterstützen können. Wenn es sich um eine Webanwendung handelt: Noch besser, Sie können Informationen über die Situation erhalten, bevor jemand das Problem meldet.

Kurze Antwort: Das kannst du nicht.

Weniger kurze Antwort: Machen Sie sie sichtbar, relevant und kontextbezogen (markieren Sie, was sie durcheinander gebracht haben). Trotzdem kämpfst du einen verlorenen Kampf. Die Leute lesen nicht auf Computerbildschirmen, sie scannen und sie wurden geschult, auf die Schaltflächen zu klicken, bis die Dialogfelder verschwinden.

Wir haben eine einfache, einprägsame Grafik in das Fehlerfeld eingefügt: kein Symbol, keine ziemlich große Bitmap und nichts wie die Standard-Windows-Nachrichtensymbole. Niemand kann sich jemals an den Wortlaut einer Nachrichtenbox erinnern (die meisten lesen ihn nicht einmal, wenn die Box eine "OK" -Taste hat, die sie drücken können), aber die meisten Menschen erinnern sich an das Bild, das sie gesehen haben. So können unsere Support-Mitarbeiter den Kunden fragen: "Haben Sie den Kaffeetrinker gesehen?" oder "hast du den leeren Schreibtisch gesehen?". Zumindest wissen wir so ungefähr, was schief gelaufen ist.

Abhängig von Ihrer Benutzerbasis kann das Schreiben von lustigen / unhöflichen / persönlichen Fehlermeldungen hervorragend funktionieren.

Zum Beispiel habe ich eine Bewerbung geschrieben, mit der unsere HR- Mitarbeiter die Einstellungsdaten der Mitarbeiter besser verfolgen können. [Wir waren eine kleine Firma, sehr entspannt].

Wenn sie falsche Daten eingegeben haben, würde ich schreiben:

Hey dummer Arsch, lerne, wie man ein Datum eingibt!

BEARBEITEN: Natürlich ist eine hilfreichere Nachricht zu sagen: "Bitte geben Sie das Datum als MM / TT / JJJJ ein" oder vielleicht im Code, um herauszufinden, was sie eingegeben haben und ob sie "blahblah" eingegeben haben, um einen Fehler anzuzeigen. Dies war jedoch eine sehr kleine Anwendung für eine HR-Person, die ich persönlich kannte. Daher noch einmal Leute, lesen Sie die erste Zeile dieses Beitrags: Abhängig von Ihrer Benutzerbasis ...

Ich habe kürzlich an einem Projekt des Art Institute gearbeitet, daher richteten sich die Fehlermeldungen an das Publikum, wie zum Beispiel:

Die meiste Kunst vor dem Barock war nicht signiert. Wir sind jedoch jetzt jenseits des Barock, daher müssen alle Felder ausgefüllt werden.

Richten Sie es grundsätzlich auf Ihr Publikum aus, wenn dies möglich ist, und vermeiden Sie Langeweile, da alle überirdischen allgemeinen Fehler wie "Bitte E-Mail eingeben" oder "Bitte gültige E-Mail eingeben".

Warnungen / Popups sind ärgerlich, deshalb drückt jeder den ersten Knopf, den er sieht.

Mach es weniger nervig . Beispiel: Wenn der Benutzer das Datum falsch eingegeben oder einen Text eingegeben hat, in dem Zahlen erwartet werden, wird KEINE Nachricht angezeigt. Markieren Sie einfach das Feld und schreiben Sie eine Nachricht irgendwo darum herum.

Erstellen Sie ein benutzerdefiniertes Meldungsfeld . Verwenden Sie niemals das Standardnachrichtenfeld des Systems. Beispielsweise nerven sich Windows XP-Meldungsfelder. Erstellen Sie ein neues farbiges Meldungsfeld mit einer anderen Hintergrundfarbe als die Standardeinstellung des Systems.

Sehr wichtig: Bestehen Sie nicht darauf . Einige Meldungsfelder verwenden das Dialogfeld "Modal" und bestehen darauf, dass Sie es lesen. Dies ist sehr ärgerlich. Wenn Sie das Meldungsfeld als Warnmeldung anzeigen können, ist es besser, z. B. Stapelüberlaufmeldungen, die ganz oben auf der Seite angezeigt werden und informieren, aber nicht stören.

UPDATE
Machen Sie die Nachricht aussagekräftig und hilfreich . Schreiben Sie beispielsweise nichts wie "Keine Tastatur gefunden, drücken Sie F1, um fortzufahren."

Das beste UI-Design ist, wenn Sie praktisch nie eine Fehlermeldung anzeigen. Die Software sollte sich an den Benutzer anpassen. Bei dieser Art von Design ist eine Fehlermeldung neu und erregt die Aufmerksamkeit des Benutzers. Wenn Sie den Benutzer mit solchen sinnlosen Dialogen überhäufen, trainieren Sie ihn explizit, um Ihre Nachrichten zu ignorieren.

Meiner Meinung und Erfahrung nach sind es die Hauptbenutzer, die keine Fehlermeldungen lesen. Das nicht-technische Publikum, das ich kenne, liest jede Nachricht auf dem Bildschirm am sorgfältigsten und das Problem an dieser Stelle ist meistens: Sie verstehen es nicht.

Dieser Punkt kann die Ursache Ihrer Erfahrung sein, weil sie irgendwann aufhören werden, sie zu lesen, weil "sie es sowieso nicht verstehen", so dass Ihre Aufgabe einfach ist:

Machen Sie die Fehlermeldung so einfach wie möglich und halten Sie den technischen Teil unter der Haube.

Zum Beispiel übertrage ich eine Nachricht wie folgt:

ORA-00237: Snapshot-Vorgang nicht zulässig: Steuerdatei neu erstellt Ursache: Es wurde versucht, cfileMakeAndUseSnapshot mit einer aktuell bereitgestellten Steuerdatei aufzurufen, die mit CREATE CONTROLFILE neu erstellt wurde. Aktion: Mounten Sie eine aktuelle Steuerdatei und wiederholen Sie den Vorgang.

zu so etwas wie:

Dieser Schritt konnte aufgrund momentaner Probleme mit der Datenbank nicht verarbeitet werden. Bitte wenden Sie sich an (Ihren Administrator | den Helpdesk | jeden, der sich an den Entwickler oder Administrator wenden kann, um das Problem zu lösen). Entschuldigung für die Unannehmlichkeiten.

Zeigen Sie den Benutzern, dass die Fehlermeldung eine Bedeutung hat , und geben Sie ihnen auf diese Weise Unterstützung, damit sie sie lesen können. Wenn es sich nur um eine Jargon-Bibel oder eine generische Unsinnsnachricht handelt, werden sie lernen, sie schnell zu verwerfen.

Ich habe gelernt, dass es sehr empfehlenswert ist, einen Fehlerdialog mit Standardaktion zum Senden detaillierter Diagnoseinformationen (z. B. per E-Mail) einzuschließen. Wenn Sie schnell auf diese E-Mails mit wertvollen Informationen oder Problemumgehungen antworten, werden Sie verehrt.

Dies ist auch ein großartiges Lernwerkzeug. In zukünftigen Versionen können Sie bekannte Probleme lösen oder zumindest Informationen zur Problemumgehung bereitstellen. Bis dahin werden Benutzer erfahren, dass diese Nachricht durch X verursacht wird und das Problem durch Y gelöst werden kann - alles nur, weil es ihnen jemand erklärt hat.

Natürlich funktioniert dies nicht in einer großen Anwendung, aber es funktioniert sehr gut in Unternehmensanwendungen mit wenigen hundert Benutzern und in einer schlanken, agilen Umgebung, in der häufig vorzeitige Versionen veröffentlicht werden.

BEARBEITEN:

Da Sie eine breite Benutzerbasis haben, empfehle ich, Software bereitzustellen, die das tut, was Benutzer erwarten / können, z. Zeigen Sie ihnen keine Fehlermeldung an, wenn die Telefonnummer nicht gut formatiert ist. Formatieren Sie sie neu, wenn dies für sie der Fall ist.

Ich persönlich mag Software, die mich nicht zum Nachdenken bringt , und wenn Sie (der Entwickler) gelegentlich nichts tun können, um meine Absicht zu interpretieren, geben Sie eine sehr gut geschriebene (und von tatsächlichen Benutzern überprüfte) Nachricht ab.

Es ist allgemein bekannt, dass Menschen keine Dokumentation lesen (haben Sie Anweisungen hintereinander gelesen , als Sie ein Haushaltsgerät angeschlossen haben?), Sie versuchen einen Weg, schnell Ergebnisse zu erzielen, wenn Sie versagt haben, müssen Sie ihre Aufmerksamkeit auf sich ziehen (z. Deaktivieren Sie die Standardschaltfläche für eine Weile) mit aussagekräftigen und hilfreichen Informationen. Sie kümmern sich nicht um Ihren Softwarefehler, sie möchten jetzt Ergebnisse erzielen.

Mach ihnen Spaß . (Es schien relevant, angesichts der Seite, auf der wir uns befinden :))

Schreiben Sie zunächst Fehlermeldungen, die Benutzer tatsächlich verstehen können. "Fehler: 1023" ist kein gutes Beispiel. Ich denke, es ist besser, den Fehler zu protokollieren, als ihn dem Benutzer mit einem "ausgefallenen" Code anzuzeigen. Wenn die Protokollierung nicht möglich ist, geben Sie den Benutzern die richtige Möglichkeit, die Fehlerdetails an die Supportabteilung zu senden.

Seien Sie auch kurz und klar genug. Geben Sie keine technischen Details an. Zeigen Sie ihnen keine Informationen, die sie nicht verwenden können. Geben Sie nach Möglichkeit eine Problemumgehung für den Fehler an. Wenn Sie keine Standardroute angeben, sollte diese verwendet werden.

Wenn es sich bei Ihrer Anwendung um eine Web-App handelt, ist das Entwerfen benutzerdefinierter Fehlerseiten eine gute Idee. Sie belasten die Benutzer weniger, zum Beispiel SO. Hier finden Sie einige Ideen zum Entwerfen einer guten Fehlerseite: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Eine Sache möchte ich hinzufügen.

Verwenden Sie Verben für Ihre Aktionsschaltflächen, um Ihre Fehlermeldungen anstelle von Ausrufen zu schließen. Verwenden Sie beispielsweise nicht "Ok!" "Schließen" usw.

Ein guter Tipp, den ich gelernt habe, ist, dass Sie ein Dialogfeld wie einen Zeitungsartikel schreiben sollten. Nicht im Größensinn, sondern im Wichtigkeitssinn. Lassen Sie mich erklären.

Sie sollten zuerst die wichtigsten Dinge zum Lesen schreiben und dann detailliertere Informationen bereitstellen.

Mit anderen Worten, das ist nicht gut:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Ändern Sie stattdessen die Reihenfolge:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Auf diese Weise kann der Benutzer so viel lesen, wie er möchte oder stört, und trotzdem eine Vorstellung davon haben, was gefragt wird.

Siehe auch die Benutzerantworten von Slashdot hier .

Wenn Sie dem Benutzer keine einfache Lösung bieten können, müssen Sie dem Benutzer überhaupt keine Fehlermeldung anzeigen. Es macht einfach keinen Sinn, da 90% der Benutzer sich nicht darum kümmern, was darin steht.

Auf der anderen Seite Wenn Sie CAN tatsächlich zeigen den Benutzer eine nützliche Abhilfe, dann einen Weg , um sie zu zwingen , es ist machen die OK - Taste wurde nach 10 Sekunden oder so aktiviert zu lesen. So wie Firefox es macht, wenn Sie versuchen, ein neues Plug-In zu installieren.

Wenn es sich um einen totalen Absturz handelt, von dem Sie sich nicht ordnungsgemäß erholen können, informieren Sie den Benutzer in sehr laienhaften Worten:

" Es tut mir leid, dass wir es vermasselt haben. Wir möchten einige Informationen über diesen Absturz senden. Erlauben Sie uns dies? JA / NEIN. "

Versuchen Sie außerdem, Ihre Fehlermeldungen nicht länger als einen Satz zu machen. Wenn Leute (ich eingeschlossen) einen ganzen Absatz sehen, der über den Fehler spricht, schaltet sich mein Verstand einfach aus.

Bei so viel Social Media und Informationsüberflutung frieren die Gedanken der Menschen ein, wenn sie eine Textwand sehen.

BEARBEITEN:

Jemand hat kürzlich auch vorgeschlagen, Comics zusammen mit der Nachricht zu verwenden, die Sie anzeigen möchten. Zum Beispiel etwas von Dilbert , das der Art des Fehlers nahe kommt, den Sie möglicherweise haben.

Aus meiner Erfahrung: Sie nicht erhalten die Nutzer (vor allem nicht-technischer Art) Fehlermeldungen zu lesen. Egal wie klar und verständlich, fett, rot und blinkend die Nachricht ist, die Sie anzeigen, die meisten Benutzer klicken einfach auf etwas, an das sie nicht gewöhnt sind, selbst wenn es "Möchten Sie wirklich alles löschen?" Ist. Ich habe gesehen, dass Benutzer auf das "Fenster schließen" -Konikon anstatt auf "OK" oder "Abbrechen" geklickt haben, obwohl sie nicht einmal wussten, welche Option sie dabei gewählt haben ...

Wenn Sie Benutzer wirklich zwingen müssen, zu lesen, was Sie anzeigen, würde ich einen JavaScript-Countdown vorschlagen, bis eine Schaltfläche anklickbar ist. Auf diese Weise wird der Benutzer hoffentlich die Wartezeit nutzen, um wirklich zu lesen, was er soll. Seien Sie jedoch vorsichtig: Die meisten Benutzer werden sich darüber noch mehr ärgern :)

Ich mag außerdem Ihre Idee eines "read more" -Links, obwohl ich bezweifle, dass dies die Benutzer mehr interessiert, die die Nachricht auf jeden Fall loswerden wollen ...

Nur zur Veranschaulichung: Es gibt Benutzer, die zwar Fehlermeldungen lesen, aber solche Angst haben, dass sie nichts damit anfangen. Ich hatte einmal einen Support-Anruf, bei dem der Kunde mir eine Fehlermeldung vorlas und mich fragte, was er tun sollte. "Nun, was sind deine Möglichkeiten?", Fragte ich. "Das Fenster hat nur einen 'OK'-Knopf.", Antwortete er. ... mmh, harte :)

Ich zeige den Fehler oft rot an (wenn das Design dies zulässt).

Rot steht für "Alarm" usw., daher wird es häufiger gelesen.

Um Ihre Frage direkt zu beantworten: Lassen Sie Ihre Programmierer Ihre Fehlermeldungen nicht schreiben. Wenn Sie diesen einen Ratschlag befolgen, sparen Sie kumulativ Tausende von Stunden an Angst und Produktivität der Benutzer und Millionen von Dollar an Kosten für den technischen Support.

Das eigentliche Ziel sollte jedoch darin bestehen, Ihre Anwendung so zu gestalten, dass Benutzer keine Fehler machen können. Lassen Sie sie keine Maßnahmen ergreifen, die zu Fehlermassagen führen, und fordern Sie sie zur Sicherung auf. In einem Webformular, in dem alle Felder ausgefüllt werden müssen, aktivieren Sie die Schaltfläche Senden erst, wenn alle Felder gültigen Inhalt enthalten, anstatt eine Fehlermeldung anzuzeigen, wenn Benutzer auf die Schaltfläche Senden klicken. Dies bedeutet mehr Arbeit auf der Rückseite, führt jedoch zu einer besseren Benutzererfahrung.

Das ist natürlich eine ideale Welt. Manchmal sind Programmfehler unvermeidbar. Wenn sie auftreten, müssen Sie klare, vollständige und nützliche Informationen bereitstellen und vor allem das System nicht dem Benutzer aussetzen und die Benutzer nicht für ihre Aktionen verantwortlich machen.

Eine gute Fehlermeldung sollte enthalten:

1. Was ist das Problem und warum es passiert ist.
2. So lösen Sie das Problem.

Eines der schlimmsten Dinge, die Sie tun können, ist einfach, Systemfehlermeldungen an Benutzer weiterzuleiten. Wenn Ihr Java-Programm beispielsweise eine Ausnahme auslöst, übergeben Sie das Programmiergerät nicht einfach an die Benutzeroberfläche und legen Sie es dem Benutzer zur Verfügung. Fangen Sie es ab und lassen Sie sich von Ihrem Benutzerunterstützungsentwickler eine klare Nachricht erstellen, die Sie Ihrem Benutzer präsentieren können.

Ich hatte das Glück, bei meinem letzten Job mit einem Team von Programmierern zusammenzuarbeiten, die nicht daran denken würden, ihre eigenen Fehlermeldungen zu schreiben. Jedes Mal, wenn sie sich in einer Situation befanden, in der eine erforderlich war und das Programm nicht darauf ausgelegt war, dies zu vermeiden (häufig aufgrund begrenzter Ressourcen), kamen sie immer zu mir, erklärten, was sie benötigten, und ließen mich eine Fehlermeldung erstellen war klar und folgte Unternehmensstil. Wenn dies die Standardeinstellung eines jeden Programmierers wäre, wäre die Computerwelt ein weitaus besserer Ort.

Weniger Fehler

Wenn eine Anwendung regelmäßig Erbrochenes auf Sie wirft, werden Sie dagegen immun und Fehler werden zu irritierendem Hintergrund-Muzak. Wenn ein Fehler ein seltenes Ereignis ist, wird er mehr Aufmerksamkeit erregen.

Quosh alles, was keine große Sache ist, wirf all diese Warnungen weg, finde Wege, die Absicht des Benutzers zu verstehen, treffe die Entscheidungen, wo immer es möglich ist. Ich habe einige Apps, die ich auf diese Weise weiter optimiere. Entwickler sehen jeden Fehler als wichtig an, dies gilt jedoch aus Anwendersicht nicht. Achten Sie auf die gemeinsame Antwort der Benutzer auf ein Problem und zu erfassen , dass einsetzen , dass als Ihre Antwort.

Wenn Sie einen Fehler auslösen müssen: kurzer, prägnanter, niedriger Terrorfaktor, keine Ausrufezeichen. Absätze sind fehlgeschlagen .

Es gibt keine Silberkugel, aber Sie müssen sozial konstruieren, um Fehler wichtig zu machen.

Wir sagten den Benutzern, dass ihr Manager kontaktiert wurde (was eine Lüge war). Es funktionierte etwas zu gut und musste entfernt werden.

Das Hinzufügen einer Schaltfläche "Erweitert", die einige weitere technische Details ermöglicht, bietet einen Anreiz, sie für den Teil der Zielgruppe zu lesen, der sich selbst als technisch betrachtet

Ich würde vorschlagen, dass Sie unmittelbar nach dem Fehler Feedback geben (mit der Aussage, dass der Benutzer einen Fehler gemacht hat). (Wenn Sie beispielsweise einen Wert für ein Datumsfeld eingeben, überprüfen Sie den Wert und machen Sie das Eingabefeld visuell anders, wenn es falsch ist.)

Wenn die Seite Fehler enthält (ich beschäftige mich mehr mit Webentwicklung, daher bezeichne ich sie als "Seite", kann aber auch als "Formular" bezeichnet werden), zeigen Sie eine "Fehlerzusammenfassung" an, in der dies erklärt wird waren Fehler und eine Aufzählungsliste, was genau Fehler passiert sind. Wenn jedoch mehr als 5-6 Wörter pro Nachricht vorhanden sind, werden diese nicht gelesen / verstanden.

Wie wäre es, wenn Sie den Schaltflächenstatus festlegen? "Klicken Sie hier, um mit einem Support-Techniker zu sprechen, der Sie bei diesem Problem unterstützt."

Es gibt viele Websites, die die Möglichkeit bieten, mit einer realen Person zu sprechen.

Ich habe einen Kandidaten für die schrecklichste Lösung für Slashdot gelesen:

Wir haben festgestellt, dass die einzige Möglichkeit, Benutzer dazu zu bringen, die Verantwortung für Fehler zu übernehmen, darin besteht, ihnen eine Strafe zu geben, wenn sie den Fehler zum Verschwinden erzwingen. Wenn möglich, wird der Fehler für sie erst dann geschlossen, wenn wir ein Administratorkennwort eingeben, damit er nicht mehr angezeigt wird. Wenn sie neu gestartet werden, um ihn zu entfernen (der Task-Manager ist auf allen Client-PCs deaktiviert), öffnet der Computer den Fehler nicht Anwendung, die 15 Minuten lang abgestürzt ist. Dies hängt natürlich alles von der Art der Benutzer ab, mit denen Sie es zu tun haben, da technisch versierte Benutzer diese Art von System nicht akzeptieren würden, aber nachdem sie buchstäblich JAHRE lang versucht haben, Benutzer dazu zu bringen, die Verantwortung für Abstürze zu übernehmen und sicherzustellen, dass die IT-Abteilung darüber informiert ist Dies sind die einzigen Schritte, die funktioniert haben, um das Problem zu beheben, bevor es zu schwierig wird, es zu verwalten. Jetzt,

"ACHTUNG! ACHTUNG! Wenn Sie keine Fehlermeldung lesen, werden Sie sterben!"

Trotz aller Empfehlungen in der akzeptierten Antwort klickten meine Benutzer weiterhin auf die erste Schaltfläche, die sie finden konnten. Jetzt zeige ich Folgendes:

Der Benutzer muss eine Auswahl treffen, bevor die Schaltfläche OK angezeigt wird

Wenn er die dritte Option auswählt, kann er fortfahren, andernfalls wird die Anwendung beendet.