Sind By-Design-Bugs ein schlechtes Zeichen?

Ist es ein schlechtes Zeichen, wenn Benutzer Fehlerberichte für beabsichtigte Dinge einreichen?

Bedeutet dies in der Regel, dass die Anwendung verwirrend oder unklar ist, oder sollte ich sie nur auf einen einmaligen Benutzerfehler hinweisen, sofern nichts anderes angegeben ist?

(Ich habe eigentlich keine derartigen Berichte. Dies ist eine rein hypothetische Frage, ob das Vorhandensein von "Bugs" durch das Design eine schlechte Sache ist oder nicht.)

Ist es ein schlechtes Zeichen? Ich denke, es ist eine Warnung, die es wert ist, untersucht zu werden, aber ich denke auch, dass sie passieren wird.

Wenn Leute irgendeine Art von Feedback an mich senden, versuche ich, es in drei Gruppen zu filtern:

• Bugs
• Funktionsanfragen
• Fehlkommunikation

Bugs

Fehler treten auf, wenn etwas offensichtlich nicht so funktioniert, wie Sie es erwarten, oder wie der Benutzer es erwartet. Es fragte mich nach meinem Namen, ich gab "Scott" ein, drückte die Eingabetaste und sagte: "Hi Joe!"

Funktionsanfragen

Dies ist wie "Ich weiß, wir haben noch nie darüber gesprochen, aber kann das Programm anhand meiner Mausgesten feststellen, dass ich Linkshänder bin und die OK-Taste auf die linke Seite des Bildschirms bewegen?" In diesem Fall entspricht das aktuelle Verhalten sowohl Ihren Erwartungen als auch den Erwartungen des Benutzers , der jedoch die Erwartung ändern möchte.

Fehlkommunikation

In diesem Fall würden Sie ein Ergebnis von einem Szenario erwarten, der Benutzer erwartet jedoch ein anderes Ergebnis. Manchmal wird dies zu einer Feature-Anfrage, wenn sie ihre Erwartungen nicht mitgeteilt haben, dies aber glaubten. Manchmal wird dies zu einem Fehler, wenn sich herausstellt, dass Ihre Erwartungen falsch sind.

Oft haben Sie jedoch Kenntnisse, die der Benutzer nicht hat. Was wäre, wenn sie sagten: "Auf diesem Bildschirm kann ich zweimal einen Datensatz mit demselben Vor- und Nachnamen für mich selbst hinzufügen! Das ist offensichtlich ein Fehler!" Ihre Antwort könnte lauten: "Es gibt viele Menschen auf der Welt mit dem gleichen Vor- und Nachnamen, daher muss diese Kombination nicht eindeutig sein. Wir haben eine Bereinigungsaufgabe, die nachts ausgeführt wird und einen Bericht über mögliche Duplikate per E-Mail an sendet Kundendienst, wenn er glaubt, ein Duplikat mit einem ähnlichen Namen und einer ähnlichen Adresse zu finden, und bittet ihn, es manuell zu überprüfen. "

Sie sollten also jeden Fehlerbericht lesen, aber die meisten komplexen Systeme werden Fehlerberichte haben, die eigentlich nur Funktionsanforderungen oder möglicherweise eine falsche Kommunikation der Anforderungen darstellen. Das Unverständnis über die zugrunde liegende Komplexität der realen Welt ist wahrscheinlich die Hauptursache für diese Probleme.

Dies wurde in früheren Antworten bisher nicht angesprochen, daher möchte ich hinzufügen, dass dies auch ein Zeichen für eine ignorante Nutzerbasis sein könnte. Ich verwende das Wort "unwissend" nicht abfällig oder herablassend, nur um auszudrücken, dass sie in ihrem Bereich oder in Bezug auf die Komplexität der Software selbst keine ausreichenden Kenntnisse oder Kenntnisse haben.

Die meisten Benutzer sind sich nicht bewusst, wie kompliziert Software sein muss, um bestimmte Anforderungen zu erfüllen. Etwas mit dem Effekt von 80% des Aufwands geht in nur 20% der Funktionalität (Rand- und Ausnahmefälle).

Sie verstehen manchmal nicht, warum sich die Software von Natur aus auf bestimmte Weise verhalten muss, um eine Vielzahl von Fehlern oder Datenverfälschungen usw. zu verhindern.

Dies ist kein Grund zur Sorge, da dies durch klare und präzise Dokumentation und Kommunikation verbessert wird.

Wenn Sie einen Benutzer haben, der ein Experte auf seinem Gebiet ist, könnten Sie ein schwerwiegendes Problem haben. Stellen Sie sich vor, ein Buchhalter, der Ihre Software per Design findet, folgt nicht den allgemeinen Buchhaltungsverfahren oder einem Ingenieur, der feststellt, dass Sie eine falsche Formel haben. Dies sollte nicht zu schwer zu erforschen sein, um festzustellen, ob sie korrekt sind. Neugestaltung und Behebung bei Bedarf schnell.

Eine Meinung zu einem bestimmten UI-Feature oder einem Feld, von dem sie denken, dass es ein Währungssymbol oder eine andere Formatierung haben sollte, sollte berücksichtigt werden, zumindest bis Sie mehr Feedback erhalten. Die Recherche könnte etwas schwieriger sein.

Nach meiner Erfahrung führen Bugs dazu, dass Ihre Anwendungsfälle nicht zu Ihren tatsächlichen Benutzern passen. Lesen Sie, wie Sie echte Benutzer für Ihre Anwendungsfälle verwenden (nur die Angabe von Namen und einer Miniaturbeschreibung wirkt sich positiv auf die Qualität der Anwendungsfälle aus.)

Wenn bekannte Betriebssystemhersteller sagen, dass dieses Verhalten beabsichtigt ist, hatten sie im Allgemeinen eine einfache Implementierung oder einen wirtschaftlichen Vorteil im Sinn. Wenn Sie es nicht sind, versuchen Sie, die tatsächlichen Fähigkeiten und die Beziehung Ihrer Benutzer zu Ihrer Software herauszufinden. Verwenden sie es den ganzen Tag? Zum Spass ? Einmal in der Woche, weil es die TPS-Formulare ersetzt?

Die Benutzeroberfläche sollte dem Prinzip des geringsten Erstaunens folgen. Wiederholte Fehlerberichte zu einer Funktion, die wie geplant funktioniert, weisen darauf hin, dass dieses Prinzip nicht korrekt eingehalten wurde.

Es gibt zwei Arten von Fehlern: Die Funktionalität entspricht nicht den Absichten des Programmierers, oder die Funktionalität entspricht nicht den Anforderungen. Programmierer tendieren dazu, sich auf die ersteren zu konzentrieren, was den letzteren schadet. Einfach ausgedrückt, wenn Ihre Benutzer viele "by-design Bugs" melden, entsprechen Ihre Anforderungen nicht Ihren Vorstellungen.

Nicht unbedingt. Es kann sein, dass sich der gemeldete Fehler in einer Verwendung der Software befindet, die gerade außerhalb des ursprünglich definierten Bereichs liegt. Betrachten Sie eine Software, die für A, B und C entwickelt wurde (für ein einfaches Beispiel, zeichnen Sie Linien, Dreiecke und Rechtecke). Wenn D ein logischer nächster Schritt ist (z. B. Fünfecke), kann der Benutzer davon ausgehen, dass dies auch getan werden sollte, und dass dies nicht der Fall ist, ist ein Fehler. Wenn dies jedoch außerhalb des ursprünglichen Bereichs liegt, handelt es sich nicht um einen Fehler. Es könnte stattdessen ein Versehen (Fehler) im Design oder ein grauer Bereich in den Spezifikationen oder ein anderer Satz von Annahmen sein, die vom Entwickler und vom Benutzer gemacht werden.

(Bearbeiten - hat meinen Kommentar zu der Antwort gemäß dem Vorschlag von @Marjan Venema hinzugefügt.

Ich glaube, es ist ein schlechtes Zeichen, hauptsächlich aufgrund der Tatsache, dass das Design nicht generisch ist und die Benutzeranforderungen nicht vollständig verstanden / analysiert werden.

Ich sehe zwei Kategorien von Design, - Design durch Zufall. - Design mit Absicht.

Design aus Versehen führt häufig zu solchen Problemen und kann nicht aufrechterhalten werden.

Ich möchte die Antwort von maple_shaft über die "Ignoranz" der Benutzer ergänzen. Sie müssen auch bedenken, dass 90% der Benutzer sich nur um ihre eigenen Erfahrungen und die Art und Weise der Nutzung des Systems kümmern . Sie interessieren sich nicht für andere Benutzer, warum sollten sie? Es ist unsere Aufgabe als Designer / Entwickler, die Beiträge aller Arten von Anwendern zu berücksichtigen und für jeden etwas zu schaffen, das so gut wie möglich passt. Meistens kann man nicht für jeden eine optimale Lösung finden.

Aber natürlich müssen Sie das Feedback Ihrer Benutzer lesen und auswerten! Sie sind schließlich diejenigen, die Ihre Schöpfung benutzen!

Die Benutzer, die die Fehleranfragen einreichten, wurden im Allgemeinen nicht zu dem Entwurf konsultiert, sodass es nicht verwunderlich ist, dass sie Dinge als Fehler ansehen, die absichtliche Entwurfsentscheidungen waren. Für einen Benutzer ist alles, was nicht wie erwartet funktioniert, ein Fehler.

Ich habe festgestellt, dass das Problem oft ein Anzeichen dafür ist, dass der BA oder der PM nur Anforderungen von Managern und nicht von tatsächlichen Benutzern hat. Die Erwartungen der Manager an das System unterscheiden sich häufig erheblich von den tatsächlichen Anforderungen der Dateneingabeberechtigten. Mir wurde beigebracht, Daten direkt von den tatsächlichen Benutzern zu sammeln, aber die meisten BAs, auf die ich in letzter Zeit gestoßen bin, sprechen nur mit Managern (und im Allgemeinen relativ hohen Managern).