Usability – Schluss jetzt mit den Missverständnissen!
Der folgende Artikel ist in einem internen Newsletter meines Arbeitgebers Steria Mummert Consulting erschienen. Er wendet sich an Berater und Projektmanager, die in der Regel keine Usability Professionals sind. Dennoch könnte der Artikel auch hier den ein oder anderen interessierten Leser finden. Zusätzlich habe ich einige Links zu anderen Artikeln eingefügt.
Begrifflichkeit: Usability ist ein Kunstwort (use + ability) und beschreibt die Gebrauchstauglichkeit eines Gegenstandes oder einer Software. Usability ist heute kein Luxus mehr sondern eine unumgängliche Voraussetzung für den wirtschaftlichen Erfolg. Leider wird der Begriff von zu vielen als leere Hülse verwendet – mehr als Buzz Word denn als Prio-1-Projektziel. Unter dem Begriff der Usability werden heute auch alle Aktivitäten zusammengefasst, die geeignet sind, eben diese Usability zu erreichen. Begegnen Ihnen Schlagwörter wie User Experience Design, User Interaction Design, User Interface Design, Usability Testing, User Centered Design usw., so hat das alles mit Usability zu tun.
Was kann man um das Thema Usability alles falsch machen? Leider mehr als ich hier aufzeigen kann. Ich möchte im Folgenden nicht auf die Dos and Don’ts des Screen Designs eingehen. Die Liste wäre extrem lang. Jenseits schräger Maskengestaltung und wirren Dialogsalats sehe ich ein gravierendes Problem darin, dass sich um das Thema Usability viele Missverständnisse ranken. Einige möchte ich aufdecken. Vielleicht erreichen wir so eine größere Bereitschaft, in dieses Thema zu investieren und so bessere Software anbieten zu können.
“Usability kann man in einem Seminar lernen.”
Manche Kunden möchten möglichst viel selbst machen. Sie haben eine Gleichberechtigungsbeauftragte, einen Umweltbeauftragten, einen Arbeitsschutzbeauftragten und nun soll noch ein Usability-Beauftragter hinzukommen. Na prima, das zeigt auch gleich den Stellenwert, der der Usability beigemessen wird – ein Deckmäntelchen. In einem Beispiel wurden wir gebeten, einer Gruppe von Entwicklern und Systemadministratoren (!) in drei einwöchigen Seminaren, “Usability beizubringen”. Nach kurzem anschließenden Coaching wollte man dann auf externe Usability-Experten verzichten. Schließlich hätte man sie dann ja selbst im Haus. Wir haben das übrigens abgelehnt.
Usability ist eine komplexe Angelegenheit, in der Techniken und Ansätze aus Psychologie, Soziologie, Design, kognitiver Ergonomie und weiteren Bezugswissenschaften zusammentreffen. Das braucht jahrelange Erfahrung, das lernt man nicht in einer Woche.
“Wir haben einen Styleguide. Wir brauchen keinen Usability Professional.”
Das Vertrauen, das in die Allmacht eines Styleguides gebracht wird, ist erschreckend. Es zeugt von größter Naivität. Viel zu häufig höre ich von Managern und Projektleitern als Beweis für die Usability-Sensibilisierung ihres Unternehmens, sie hätten eine Corporate Identity und sogar einen Styleguide für Softwareoberflächen. Es ist gut, so etwas zu haben. Das hat mit Usability aber erst mal gar nichts zu tun. Die Corporate Identity beschreibt das Branding, Logo, Briefköpfe, Farblichkeit – eben die Marke. Ein Styleguide beschreibt, wie Software bzgl. Farbe, Schrift, Wortwahl und Layout gestaltet werden sollten. Das sind aber ausschließlich statische Merkmale. Sie sagen nichts über die dynamische Gestaltung der Software aus. Sie stellen bestenfalls allgemeine Vorgaben dar, die in der konkreten Designsituation lückenhaft sein müssen. Sie können keine Antworten auf konkrete Designfragen geben. Ein Styleguide ist erst mal ein hoffentlich nicht zu umfangreicher Packen Papier, der durch User Interaction Design und User Interface Design zum Leben erweckt werden muss. Und das wiederum muss natürlich durch begleitende Usability Tests validiert werden.
Einmalig eine Agentur für die Entwicklung der Corporate Identity und eines Styleguides zu beauftragen, ist keine hinreichende Basis für gute Software.
“Usability ist uns zu teuer. Dafür reicht das Budget nicht.”
Gerade budgetverantwortlich Projektleiter neigen dazu, Usability ausschließlich als zusätzlichen Kostenfaktor zu betrachten. Das ist spätestens auf den zweiten Blick ein großer Irrtum. Doch der Reihe nach: Es ist richtig, dass Usability-Aktivitäten Geld kosten. Auch wenn mir mein Job extrem viel Spaß macht, möchte ich dennoch nicht umsonst arbeiten. Je nach Projekt sollten man zwischen fünf und zehn Prozent des Budgets für Usability einplanen. Das können schon so ein paar Euro sein. Stellt man dem aber den zu erwartenden Nutzen gegenüber, verliert dieser Aufwand seinen Schrecken. Durch gute Usability lassen sich Return On Investment-Potenziale direkt optimieren (siehe hier im Blog auch ROI-Berechnung am Beispiel einer Fachapplikation) :
Chancen für eine intern genutzte Fachapplikation…
Senkung der Entwicklungskosten durch Reduzierung teurer Change Requests
Steigerung der Mitarbeiterproduktivität durch Verschlankung der Benutzerinteraktion
Reduzierung der Schulungskosten durch intuitive Bedienbarkeit
Entlastung des User Help Desks, da es aufgrund intuitiver Bedienung weniger Probleme gibt
Steigerung der Datenqualität durch weniger Fehleingaben
Chancen für einen Onlineshop…
Senkung der Entwicklungskosten durch Reduzierung teurer Change Requests
Umsatzsteigerung durch Gewinnung neuer Kunden
Festigung der Kundenbindung
Optimierung der Conversion Rate – geringere Abbruchquoten im Shop
Entlastung des User Help Desks, da es aufgrund intuitiver Bedienung weniger Probleme gibt – weniger Fehlbestellungen und Reklamationen
Steigerung der Datenqualität durch weniger Fehleingaben
Nun, das ist ein eigenes Kapitel für sich. Es wurden darüber viele Bücher geschrieben. Zusammengefasst lässt sich sagen, dass sich über den gesamten Produkt-Lifecycle betrachtet selbst in mittleren Projekten Millionen sparen bzw. zusätzlich erwirtschaften lassen. Was sind da schon die zusätzlichen 200 Tage für Usability?
“Usability Professionals machen es am Ende hübsch.”
Beizeiten höre ich auch: “So, wir sind dann so weit. Das Konzept ist fertig, die Funktionalität ist implementiert. Sie können das jetzt hübsch machen.” Was soll man aber noch ausrichten, wenn das Projekt schon fast fertig ist? Dann kann man bestenfalls noch an der Farblichkeit was ändern. Doch das ist für die Usability von untergeordneter Bedeutung. Man kann also nicht mehr viel machen, das Kind ist schlimmstenfalls längst in den Brunnen gefallen. Nein, Usability beginnt ganz am Anfang des Projekts mit der Analyse. Was soll das System für wen leisten? Das muss auch unter Usability Aspekten analysiert werden. Wenn man weiß, was man für wen entwickeln möchte, wird im Rahmen der Konzeption geklärt, wie man das erreichen möchte. Das User Interface wird konzipiert und die Use Cases werden in Storyboards transformiert (siehe auch Storyboards: Eine Erfolgsgeschichte). Anhand von Papierprototypen wird das Konzept in ersten Usability Tests validiert – noch bevor die erste Zeile Source Code geschrieben ist. Billiger kann man kein Feedback erhalten! Die Entwicklungsphase begleitend wird das Design erforderlichenfalls verfeinert. Auch treten manche Schwierigkeiten der Oberflächenentwicklung erst jetzt zu Tage. Das ist normal. Es gilt nun in Abstimmung mit den Entwicklern gute Kompromisse zu finden und die Lösung zu formulieren. Die Entwicklung nun ohne Feedback der Kunden / Nutzer weiterlaufen zu lassen, wäre fahrlässig. Iterativ werden jetzt die Ergebnisse aus der Entwicklung in weiteren Usability Tests überprüft. Die Nutzer haben nun erstmalig die Gelegenheit, mit echter Software zu arbeiten. Dieser Prozess der Validierung und Optimierung findet bis kurz vor Abschluss der Entwicklungsphase statt. Erst jetzt können sich die Usability Professionals schrittweise zurückziehen. Usability ist also in allen drei Projektphasen Analyse, Konzeption und Implementierung von größter Bedeutung. Es wäre sogar sehr hilfreich zumindest einen Usability Professional schon in der Initialisierungsphase dabei zu haben. Je früher Usability thematisiert wird, desto größer ist die Wahrscheinlichkeit, dass das Produkt ein wirtschaftlicher Erfolg wird.
Usability nur zu Projektbeginn ist auch nicht gut.
Ich habe auch schon erlebt, dass die Usability Professionals nach der Konzeptphase nach Hause geschickt wurden. Das ist wegen der eben beschriebenen Zusammenhänge gefährlich. Es gibt noch einen anderen Grund: Bequemlichkeit! Häufig bieten die Entwicklungs-Frameworks nicht genau das, was für die Usability des Projekts notwendig ist. Es müssen also Erweiterungen implementiert werden. Wenn nun der verantwortliche Usability Professional zu früh das Projekt verlässt und nicht mehr auf die Konsistenz der entwickelten Lösung achten kann, neigen Entwickler und Projektleitung zu vermeintlich einfacheren Lösungen. Das führt in der Regel zur Unterminierung der gewählten Benutzerinteraktion. Die Anwendung wird inkonsistent, es schleichen sich Widersprüchlichkeiten ein, das System wirkt nicht mehr wie aus einem Guss. Die ganze User Experience ist verloren. Und damit eben auch der erhoffte Return On Investment. Das kann viel teurer werden als die paar eingesparten Designertage.
“Wir haben unsere Fachanwender und brauchen keine Usability-Experten.”
Und wie der geneigte Leser sich denken kann, ist auch dieser Satz eine Fehleinschätzung. Die intensive Einbindung von Fachanwendern in das Projekt ist gut. Aber nur, wenn die Fachanwender auf die richtige Art bzw. in der richtigen Rolle eingebunden werden. Die richtige Einbindung der Fachanwender besteht einerseits in der Unterstützung der Analyse (Was soll das System leisten?) und andererseits in der Überprüfung der Ergebnisse (Ist die Lösung tragfähig?) – nicht aber in der Lösungsentwicklung (Wie soll das aussehen?).
Entstehen Unsicherheiten, wie ein spezielles Problem zu lösen sei, wird häufig nach der vermeintlich omnipotenten Instanz Fachanwender gefragt: “Die sollen uns sagen, wie sie das haben wollen. Schließlich arbeiten die in dem Bereich seit Jahren.” Das ist ein verhängnisvoller Fehler.
Erstens sind Fachanwender in erster Linie Versicherungskaufleute, Finanzexperten, Polizisten usw. – aber keine Designer. Sie versuchen Probleme mit den Werkzeugen zu lösen, die sie kennen. Das führt in der Regel zu Lösungsversuchen, die die Mechanismen bestehender Altanwendungen auf den neuen Kontext übertragen. So kann keine Innovation erreicht werden. Wer nur einen Hammer kennt, für den sind alle Probleme Nägel. Dass eine elegante Schweißnaht die bessere Lösung wäre, wird bei diesem Vorgehen noch nicht mal diskutiert. Aber es ist natürlich nicht Schuld der Fachexperten, dass sie die neusten Visualisierungsmöglichkeiten und Interaction Patterns nicht kennen. Wie sollten sie auch? Ihre Expertise liegt in einem anderen Bereich.
Und zweitens – das finde ich noch schlimmer – versuchen sich Entwickler und Projektverantwortliche so aus der Verantwortung zu stehlen. Wenn das Produkt dann am Ende hakt und der wirtschaftliche Erfolg ausbleibt, wird die Schuld den Fachanwendern zugeschoben. “Warum? Ist doch genau so, wie es die Anwender haben wollten!” Das ist mit Verlaub schäbig!
Fachanwender zur Unterstützung (!) der Analyse hinzuzuziehen ist mehr als ratsam. Fachanwender in die Test- und Abnahmeprozesse einzubeziehen hat sich ebenfalls als sehr gut erwiesen. Aber lasst die User aus dem Designprozess raus. Wenn es Unsicherheiten über den Königsweg gibt, heißt es leider denken, denken, denken… Und dabei werden sich vermutlich mehrere Lösungsansätze herauskristallisieren. Die müssen dann durch Usability Tests validiert werden bis die beste bestimmt werden kann. Ja, und hierfür dürfen Fachanwender gerne wieder zu Rate gezogen werden. Siehe hierzu auch meinen Artikel Der Kunde ist König – Wovon? im usabilityblog.de.
“Usability Tests sind teuer.”
Usability Tests sind nicht notwendigerweise kostenintensiv. Es gibt auch Testverfahren, die im Rahmen eines schmalen Budgets gute Erkenntnisse liefern. Um den Rahmen dieses Artikels nicht zu sprengen, möchte ich zwei einfache Vorgehen in einem gesonderten Artikel später vorstellen.
Fazit
Ich weiß nicht, welches das schlimmste Missverständnis über die Usability ist. Mögen Sie selbst urteilen. Sicher ist aber, dass ich persönlich alle hier aufgeführten schon selbst erlebt habe.
Usability hat es im stressigen Projektumfeld häufig schwer. Will man aber vermeiden, dass Software zu ungenutzter “Schrank-Ware” verkommt, kann man auf Usability nicht verzichten. Denn auch in der Software ist der Mensch das Maß aller Dinge. Die aufgezeigten Missverständnisse zeigen sehr deutlich, dass wir noch viel Aufklärungsarbeit leisten müssen. Vielleicht habe ich Sie ja als Mitstreiter gewonnen.