it-swarm-eu.dev

Wie kommunizieren Sie die Schwere von Designfehlern? Haben Sie standardisierte Methoden, um dies zu tun?

Bei der Behebung und Prüfung von Fehlern im Zusammenhang mit der Benutzerfreundlichkeit stelle ich häufig fest, dass ich auf eine Show zurückgreifen oder die Schmerzen des Benutzers in Bezug auf ein Problem ausführlich und dramatisch beschreiben muss. Ich bin mir zwar sicher, dass ich immer etwas davon tun muss, aber ich wünschte, es gäbe eine standardisiertere Methode, um zu kommunizieren, wie schwerwiegend ein Problem ist/sich anfühlt. Ich habe über Leute bei Mozilla gelesen, die Fehler markieren, mit welchen Heuristiken sie brechen, was ich für eine großartige Idee halte, aber es hilft nicht wirklich bei der Schwere. Hat jemand gute Ideen oder Prozesse da draußen?

Ein Beispiel könnte sein, ein Fehler kann sich für einen Designer anfühlen, oh mein Gott, wir sollten dies niemals in diesem Zustand veröffentlichen, aber für einen Entwickler, der es programmiert hat, mag das Verhalten offensichtlich erscheinen, so dass es überhaupt nicht sehr schwerwiegend erscheint.

8
Becky

User Focus hat einen guten Artikel zum Thema Priorisierung von Usability-Problemen .

Ich stimme dem Gefühl des Eröffnungspostens zu. Wenn Sie in einer technischen Umgebung oder mit einem großen komplexen System arbeiten, ist eine konsistente und verständliche Methodik und Berichterstellung von entscheidender Bedeutung. Ein Teil davon, warum es wichtig ist, ist, ernst genommen zu werden, und der andere Teil ist, gute Kommunikation zu üben und sich sinnvoll in die anderen Teams und Prozesse zu integrieren, mit denen Sie arbeiten.

Wenn Sie wirklich nach Hause fahren, dass etwas wirklich wirklich ein Problem ist und den Benutzern große Schmerzen bereitet, kann es Wunder bewirken, wenn Sie Ihre Berichterstattung durch Videoclips der Interaktion ergänzen.

7
Splog

Nachdem ich einige Jahre mit diesem Problem zu kämpfen hatte und am Ende ein Produkt mit relativ schlechter Benutzerfreundlichkeit entwickelt habe, habe ich dieses Problem auf eine andere Weise gelöst.

Es gibt zwei Ursachen (zumindest dort, wo ich arbeite) für das Problem: 1) "The Business" wird Usability-Probleme niemals planen/priorisieren, da a) sie lieber neue Funktionen/Bugfixes haben und b) sie keine wirkliche Vorstellung davon haben von oder quantifizieren die Kosten für schlechte Benutzerfreundlichkeit (sie sind schließlich Domain-Experten, keine Software-Experten).

2) Die (traditionellen) Entwickler werden Usability-Probleme niemals planen/priorisieren, da sie a) häufig das Ausmaß/die Kosten des Problems nicht erkennen können und b) häufig weniger zuversichtlich in die Front-End-Entwicklung sind und c) ihr Fokus ständig gestohlen wird durch Probleme, die für den Job eines Entwicklers von zentraler Bedeutung sind.

Folglich leidet die Benutzerfreundlichkeit.

Als solches, IMO, benötigen Sie im Wesentlichen einen separaten Entwicklungskanal, um die Benutzerfreundlichkeit zu verbessern. Es ist fast das gleiche wie technische Schulden (die ich auch befürworten würde, werden auf diese Weise "gelöst"). Erstellen Sie einen neuen Entwicklungskanal, unabhängig davon, ob Sie in einer idealen Welt ein paar agile Punkte pro Iteration (oder ein paar Tage pro zweiwöchiger Veröffentlichung) für die Einstellung eines Front-End-Ingenieurs mit eigener Priorität festlegen -Liste. Dieser neue Entwicklungskanal durchläuft ständig und konsequent Usability-Probleme, und Usability-Probleme werden nicht mehr vor Nicht-Usability-Problemen, sondern voreinander priorisiert.

Wenn Sie nun für beide Zielgruppen in meinem ersten Absatz ein paar Tage damit verbringen, einige Forschungszusammenfassungen, Ergebnisse von Fallstudien, Zitate der anerkannten Gurus usw. zu sammeln, sollten Sie in der Lage sein, ein Argument zu entwickeln, das die Menschen überzeugt . Aber wer hat die Zeit, 4 Stunden Forschung und Argumentation zu betreiben, um einen 1-Stunden-Job ausreichend zu priorisieren? Wenn Sie jedoch ein Argument zusammenstellen (unter Berufung auf einige Beispiele für schlechte Benutzerfreundlichkeit in Ihrer App), das nicht die Rechtfertigung der Priorisierung eines einzelnen Problems, sondern die Rechtfertigung eines separaten Entwicklungskanals unterstützt, lohnt sich die Auszahlung plötzlich viel mehr.

Ich bin ein gewöhnlicher C # .Net-Entwickler mit einem zunehmenden Interesse an Benutzerfreundlichkeit. Ich habe ein Argument dafür formuliert, wie wichtig es ist, Usability-Probleme zu untersuchen, bin mit einem Vorschlag zu meinem CTO gegangen, und jetzt widme ich einen Prozentsatz meiner Zeit Usability-Problemen. Mein Team hat einige Kernressourcen für die Entwicklung verloren (wir haben eingestellt, daher war es sowieso ein einfacheres Argument), aber jetzt wird endlich die Benutzerfreundlichkeit überprüft.

Langfristig denke ich, dass es Teil meiner neuen Aufgabe ist, die anderen Entwickler so zu schulen, dass keine Funktionen veröffentlicht werden, die eine schlechte Benutzerfreundlichkeit aufweisen. Verstärken Sie die Effekte sozusagen.

Viel Glück!

7
Mark Gibaud

Ich habe gesehen, dass Visuals, insbesondere Demonstrationen, den größten Einfluss haben.

Dies geschah in einer agilen Umgebung, in der das UX-Team Storys an das Product Backlog übermittelte und sie bei Schätzungsbesprechungen abstimmen ließ.

Visuals funktionierten immer in Bezug auf das Referenzieren von Screenshots, aber das Beste war, das Problem tatsächlich in Aktion zu zeigen und zu beschreiben, warum es ein Problem war.

Wenn Sie sich nicht in einer agilen Umgebung befinden, müssen Sie noch Entwicklungsmeetings abhalten, bei denen Probleme angesprochen werden können. Seien Sie bereit zu zeigen, was kaputt ist, und zu diskutieren, warum Sie es als "kaputt" betrachten.

(Übrigens, für diejenigen, die mit Agile nicht vertraut sind, wenn Sie möchten, dass etwas bearbeitet wird, schreiben Sie es auf und senden Sie es an die große Liste "Woran wir arbeiten müssen". Die Liste wird wöchentlich überprüft und von Development, UX, QA diskutiert , Produktmanagement und wichtige Stakeholder).

1
gef05

Die Standardanzeigen kommen in den Sinn, möglicherweise kombiniert mit einem Farbverlauf von gelb über orange nach rot.

Andere Analogien könnten verwendet werden: Symbol eines Marienkäfers, ein Geschirrtopf, ein Trinkglas, eine Person in verschiedenen Stadien der "Brüchigkeit". Dh: ein Pflaster an einem Teil, ein Riss (oder ein faltiges "Lächeln"), ein Stück abgebrochen (abgebrochen), ... völlig zerbrochen/gequetscht

Seien Sie nur vorsichtig, wenn Sie tierische/menschliche Analogien verwenden, damit diese nicht zu grafisch werden.

1
Marjan Venema

Benutzerfreundlichkeit ist keine Programmierung.

Es wäre irreführend, ein solches schrittweises System zu schaffen.

Wenn Sie wirklich denken, dass etwas so fehlerhaft ist, dass es das System irgendwie kaputt macht (z. B. eine fehlende Schaltfläche, um zum nächsten Schritt zu gelangen), beheben Sie es.

Andernfalls handelt es sich nur um ein Usability-Problem, und es spielt keine Rolle, wie wichtig wir als Praktiker sind, dass sie keine Metriken aufweisen, die nahe daran liegen, wann Code nicht funktioniert.

Wenn beim Programmieren der Gedanke nicht funktioniert, funktioniert die Periode nicht. Damit es funktioniert, müssen Sie es reparieren.

In der Benutzerfreundlichkeit können Sie mit viel mehr davonkommen, bevor das System ausfällt.

0
ThomPete