„So schlimm ist es doch gar nicht!“
Diesen Satz habt ihr schon oft gehört, wenn es um die Usability einer Anwendung ging? Mein Beileid – ich kenne solche Sätze auch.
Bei uns im Unternehmen haben wir schon viele Usability- und Softwareentwicklungs-Projekte gemeistert. Doch es ist nicht immer leicht, vor allem wenn der Kunde der Meinung ist, dass die offensichtlich schlechte Usability seiner Anwendung gar nicht so schlimm sei. Tatsächlich kommen mir immer wieder Argumente – oder nennen wir es besser Ausreden – zu Ohren, die eine schlechte Usability rechtfertigen sollen.
Meine zehn Highlights möchte ich mit euch teilen.
1. Die Konkurrenz hat Feature XY auch, deshalb brauchen wir es unbedingt.
Im ersten Moment könnte man meinen, dass es ja gar nicht so unklug ist, sich an der Konkurrenz zu orientieren. Was aber, wenn dieses Feature überhaupt keinen Mehrwert bietet und nur aufgrund einer “Featureitis” entwickelt wurde? Dann solltet ihr nicht den gleichen Fehler begehen. Vielleicht spricht die Konkurrenz eine ganz andere Nutzergruppe an und das Feature ist für sie daher wirklich wichtig, während es für eure Anwendung überflüssig ist. Verzichtet darum nie auf eine ordentliche Nutzungskontextanalyse oder die Erstellung von Personas. So könnt ihr im Vorfeld feststellen, wer eure Nutzer wirklich sind und welche Features sie brauchen.
2. Das machen wir nachher schön, erstmal "Feature First".
Auch diese Aussage habe ich schon oft gehört. Der Kunde möchte sein Produkt, gerade wenn er unter Zeitdruck steht, fristgerecht auf den Markt bringen. Die vollständige Feature-Entwicklung steht also in seinen Augen an erster Stelle. Ob das Produkt schlecht bedienbar ist und somit viele Nutzer abschrecken könnte, sieht er nicht.
Dabei sollte das Thema Usability niemals erst am Ende der Entwicklung eine Rolle spielen. Usability-Aktivitäten sollten vielmehr von Anfang an mit eingeplant und umgesetzt werden, um bereits mit Beginn des Projektes ein nutzerfreundliches Produkt in den Mittelpunkt der Entwicklung zu stellen. Werden Verbesserungen und Änderungen erst ganz zum Schluss umgesetzt, sind diese oftmals viel aufwändiger und teurer umzusetzen, als wenn sie kontinuierlich und iterativ eingepflegt werden.
Wobei wir bereits beim nächsten Argument wären.
3. Für Usability Engineering fehlt uns das Budget.
Denn was dem Kunden oftmals gar nicht bewusst ist, ist, dass er durch Usability Engineering sogar Kosten einsparen kann. In unserem Blogbeitrag “6 gute Gründe für Usability Engineering“ berichten wir unter anderem genau über diese Möglichkeit. Keine unnötigen Entwicklungskosten, geringere Komplexität, Reduzierung der Folgekosten durch Usability Engineering sind hierbei nur einige gute Gründe für mögliche Einsparungen. Diese können laut einer Studie sogar bis zu 60 % der Gesamtkosten ausmachen.
4. Jetzt einen Test aufzubauen, dauert viel zu lange.
Nicht jeder Usability-Test dauert lange. Es geht auch mit vergleichsweise wenig Vorbereitungs- und Durchführungsaufwand, z.B. in Form eines Usability-Speed-Testings. Viele Kunden sind im Vorfeld oftmals skeptisch, da sie noch keine Erfahrung mit dem Themenfeld gemacht haben. Sie erwarten aufwändige Vorbereitungen und riesige Datenberge, die kostspielig ausgewertet werden müssen. Will man die zeitlichen Kosten gering halten, dann eignen sich kurze Usability-Tests, die den aktuellen Entwicklungsstand testen. Es muss dementsprechend keine fertige Software vorliegen oder erst ein komplexer Prototyp erstellt werden. Es wird das getestet, was gerade da ist, und die Ergebnisse fließen in die weitere Entwicklung mit ein.
5. Als Product Owner weiß ich genau, was meine Kunden brauchen und wollen, dafür brauche ich keinen Usability-Test.
Der Product Owner, also in der Regel der Auftraggeber, der die fachliche Sicht vertritt, weiß seiner Meinung nach natürlich am besten, was die Nutzer wollen – schließlich stellt er die Anforderungen und beurteilt die spätere Umsetzung seiner Wünsche im Hinblick auf Funktionalität und Qualität. Doch woher weiß der PO so genau, was die Nutzer wollen? Natürlich kennt er das Produkt besonders gut und spricht oft mit vielen Stakeholdern, um weitere Informationen zu sammeln. Diese Stakeholder sind aber in den wenigsten Fällen auch die direkten Nutzer des Produkts, um die es ja eigentlich gehen sollte. Umso wichtiger ist es, dass diese befragt werden und sie das Produkt frühzeitig testen können, damit am Ende keine bösen Überraschungen drohen. So kann das Produkt letztendlich nicht nur durch Funktionalität und Qualität, sondern auch durch gute Gebrauchstauglichkeit überzeugen.
6. Wir kommen nicht an unsere Kunden ran, deswegen brauchen wir erst gar nicht über Tests mit ihnen nachdenken.
Auf Argument Nr. 5 folgt ganz schnell Nr. 6: Wir können keine Tests mit unseren Kunden machen, die haben an so etwas kein Interesse. Oftmals ist ein Unternehmen davon überzeugt, dass seine Kunden bzw. die Nutzer des Produktes kein Interesse an Usability-Tests haben. Sie wollen die Nutzer nicht mit Tests belasten, die ja schließlich jeden Einzelnen Zeit und Geld kosten. Aus diesem Grund wird oft direkt zu Beginn die Frage nach Kontakt zu den Kunden/Nutzern abgeschmettert. Dabei ist es enorm wichtig, den Nutzer direkt von Beginn an mit einzubeziehen und ihn teilhaben zu lassen. Schließlich profitiert er später am meisten von den Usability-Maßnahmen. Erfahrungsgemäß freuen sich die meisten Nutzer sogar, dass sie miteinbezogen werden und ihre Meinung wichtig ist.
7. Alle Informationen sind wichtig, deswegen müssen sie alle gleichzeitig sichtbar sein, da können wir nichts weglassen.
Für den Product Owner und die Stakeholder sind die meisten fachlichen Anforderungen glasklar und unumstritten. Das Ergebnis eines Usability-Tests kann aber belegen, dass die Nutzer von zu vielen Informationen erschlagen werden und sich daher nicht mehr zurechtfinden. Damit der Product Owner und die Stakeholder von diesem Punkt überzeugt werden können, ist es hilfreich, sie zu dem Usability-Test als Beobachter einzuladen. Das direkte und schonungslose Feedback eines Nutzers wirkt manchmal Wunder.
8. Wir brauchen keine Personas, wir haben nur die eine Kundengruppe.
Personas können bei der Anforderungspriorisierung unterstützen, sie dienen als konkrete Bezugsperson für die Entwickler und helfen den gesamten Entwicklungsprozess auf die Bedürfnisse ihrer Nutzer und Zielgruppen auszurichten. Selbst wenn ein Unternehmen der Auffassung ist, dass es nur eine sehr spezielle Kundengruppe bedient, lohnt es sich, Personas zu erstellen. Oft stellt sich heraus, dass die Nutzer innerhalb einer eigentlich homogenen Gruppe doch sehr unterschiedliche Bedürfnisse haben, was das Produkt angeht.
9. Alle unsere Nutzer müssen eine Schulung absolvieren, dann lernen sie, wie es geht.
Stellte sich in einem Test heraus, dass der Nutzer das Produkt nicht richtig verstanden hat oder bedienen konnte, dann flüchtet sich der Kunde oft in die Schulungs-Ausrede. Die Annahme: Wenn der Nutzer einmal gezeigt bekommen hat, wie alles funktioniert, dann hat er keine Probleme mehr. Bei sehr speziellen und komplexen Produkten mag es der Fall sein, dass eine Schulung obligatorisch ist. Darüber hinaus ist eine gute Onboarding-Hilfe prinzipiell natürlich sinnvoll. In den meisten Fällen handelt sich jedoch lediglich um den Versuch mit diesem Argument die schlechte Usability des Produktes zu rechtfertigen.
10. Das ist technisch nicht möglich.
Das Totschlag-Argument schlechthin: Wenn gar nichts anderes geht, dann ist es Zeit für die technische Machbarkeits-Hürde. Will ein Kunde überhaupt nicht wahrhaben, dass es sinnvoll wäre, bestimmte Features zu entwickeln (oder wegzulassen), folgen oft Diskussionen über technische oder politische Beschränkungen. Auch Entwickler bringen dieses Argument an, wenn ihnen ein Feature sinnlos oder zu aufwändig erscheint. Ein Usability-Experte sollte sich von diesem Argument jedoch nicht abschrecken lassen. In den meisten Fällen zeigt sich entweder, dass es technisch doch kein großes Problem ist oder aber, dass man einen anderen, einfacheren Weg findet, mit dem die Nutzer ebenfalls effizient an ihr Ziel kommen.
Kommen euch manche dieser zehn Argumente auch bekannt vor? Wichtig ist, dass man sie nicht einfach hinnimmt, sondern dem Kunden die Wichtigkeit und den Mehrwert von gutem Usability Engineering aufzeigt. Es ist nicht immer einfach, diesen Standpunkt konsequent zu vertreten, da die schwierigen Rahmenbedingungen mancher Projekte Diskussionen kaum zulassen. Meine Erfahrung zeigt jedoch, dass es oftmals bereits kleine Anpassungen sind, die ein Argument für schlechte Usability schnell entkräften können.
Übrigens: Unser kostenloses E-Book gibt Hilfestellung, wenn es genau darum geht, diesen Argumenten als Usability Engineer entgegenzustehen. Schaut doch mal rein!
Kommentare