Welchen Mehrwert hat UX für Kunden?
Kürzlich haben wir vom UX Team bei EBP eine Umfrage unter unseren Kolleginnen und Kollegen im Geschäftsbereich Informatik gemacht. Wir wollten wissen, welche Vorbehalte sie selbst oder auch KundInnen gegen UX haben. Diese Sammlung an Argumenten und Vorbehalten haben wir ausgewertet, sortiert und Antworten auf diese Aussagen gesammelt.
Wir haben den Begriff UX (User Experience) beibehalten, da dieser geläufiger ist. Im Grunde geht es aber um User-Centered Design (UCD). Eine User Experience, also ein Nutzererlebnis, hat jedes Produkt, User-Centered Design ist jedoch die Methode, über die eine gute User Experience durch konsequentes Einbeziehen der NutzerInnen erreicht wird.
Dies waren die Vorbehalte und unsere Antworten:
UX ist zu teuer.
Das ist sehr kurzfristig gedacht.
UCD zahlt sich während der Entwicklungsphase aus. Frühzeitige Validierung mit Prototypen reduziert Risiken und mögliche Entwicklungskosten. Validierte und visualisierte Konzepte (z.B. Wireframes, Prototypen) sorgen für eine reibungslosere Entwicklungsphase und weniger Nachbesserungen. Und die Entwicklungskosten können durch den Fokus auf für NutzerInnen notwendige Features reduziert werden, z.B. eine Datenexportfunktion, die niemand nutzt.
UCD ist eine Investition in die Zukunft. Auf den Kenntnissen aus der Nutzerforschung kann auch künftig aufgebaut werden. Und Benutzerfreundlichkeit steigert die Wettbewerbsfähigkeit.
Es gibt immer eine User Experience. Das Design muss ohnehin konzipiert werden, wenn es nutzerzentriert entwickelt wird, ist es zielorientierter und diese Grundlage ermöglicht eine transparentere, faktenbasierte Zusammenarbeit mit dem Auftraggeber.
Wir haben keine Zeit für UX
UCD ist nicht unbedingt ein grosser Zusatzaufwand. Denn wie gesagt, das Design muss ohnehin entwickelt werden und ein iteratives Vorgehen erspart Aufwand durch Nachbesserungen im Detaildesign. Bereits mit fünf Benutzertests findet man 85% der Usability Probleme einer Lösung (Jacob Nielsen, Why You Only Need to Test with 5 Users). Und beim Testen mit NutzerInnen fokussieren wir auf die Bereiche mit der grössten Unsicherheit und dem grössten Risiko.
UCD spart sogar Zeit. Bereits kurze Tests, auch zu einem späten Zeitpunkt im Projekt, können aufwändige Change Requests verhindern. Und es kann auf wirklich für die NutzerInnen notwendige Funktionen fokussiert, weniger dringliche können ins Backlog verschoben werden.
Und es ist nie zu spät. Das Wissen aus Tests ermöglicht ein informiertes Weitergehen. Erkenntnisse können ins Backlog für eine nächste Version einfliessen und noch offene Stories können besser priorisiert werden. Zudem gibt es immer Quickwins, das heisst geringfügige Änderungen, die eine deutliche Verbesserung der Usability bewirken. Die Probleme schlechter Usability zeigen sich spätestens in der realen Nutzung der Lösung. Wenn wir sie ignorieren, heisst das nicht, dass sie nicht existieren.
UX, das ist wieder so ein Buzzword für etwas, dass wir sowieso machen.
Ist wirklich klar, was UX bedeutet? UX, respektive nutzerzentriertes Design bedeutet kontinuierliches Einbeziehen von repräsentativen NutzerInnenn, initial und während der Entwicklung des Designs, die Anwendung von bewährten Methoden aus der Psychologie mit einer systematischen Herangehensweise. Aus den Erkenntnissen der Nutzerforschung resultieren belastbare Aussagen. Methodische Fehler sind häufig Erhebungen mit den falschen NutzerInnenn, ein unpassende Erhebungsmethode, zu kleine Stichproben oder fehlerhafte Auswertung der Ergebnisse.
Wozu müsst ihr mit Nutzern sprechen? Ihr seid doch die UX-Experten!
Wir differenzieren zwischen sogenanntem Problemraum und Lösungsraum: Um das Problem, für das wir eine Lösung suchen zu verstehen, müssen wir mit NutzerInnen sprechen. Unsere Expertise als Designer (auch EntwicklerInnen, NutzerInnen, PL) und unsere Erfahrung hilft uns bei der Lösungsfindung. Unsere Lösungen müssen trotz unserer Expertise mit echten NutzerInnen validiert werden. Denn oft gehören wir nicht zur Zielgruppe und können nur Vermutungen anstellen, welche Bedürfnisse diese Nutzergruppen haben und welche Vorkenntnisse und Erwartungen sie mitbringen.
Wir wissen schon was unsere Nutzer brauchen, das ist ja nicht so schwer.
Nutzerbedürfnisse erheben bedeutet, systematisch den Arbeitskontext, Aufgaben und Bedürfnisse von realen NutzerInnenn zu verstehen. Ausserdem muss man die Befangenheit von NutzerInnen gegenüber Vorgesetzten und soziale Erwünschtheits-Effekte berücksichtigen. Und Nutzerforschung bedeutet nicht nur, die NutzerInnen zu befragen, sondern auch zu beobachten, um unerkannte Bedürfnisse und unbewusste Handlungsweisen zu entdecken.
Das kann passieren, wenn man auf Nutzerforschung verzichtet: When the client says „We don’t need research, we know our users“ Auch wenn man die Bedürfnisse der NutzerInnen kennt, heisst es noch lange nicht, dass die Lösung die richtige ist für die NutzerInnen.
Wir sind zufrieden mit der gegenwärtigen Lösung. Die neue Applikation soll das 1:1 wieder abbilden
Diese Hypothese sollte überprüft werden. Zum einen um Sicherheit und Gewissheit zu erlangen, dass in die richtige Lösung investiert wird und zum anderen könnten möglicher Weise Funktionen einspart werden, weil sie nicht genutzt werden. Oder es gibt bisher unerkannte Bedürfnisse, die die NutzerInnen unbewusst anders lösen, in dem sie zum Beispiel separate Excellisten führen.
Wir wecken damit nur Erwartungen bei den NutzerInnen.
In diese Richtung zielen auch Argumente wie «Die Anwender müssen diese Fachapplikation sowieso verwenden.» und «Die wenigen NutzerInnen können wir schulen.»
Nutzerzentriertes Vorgehen zahlt sich aus. Hohe Usability führt zu effizienterem Arbeiten und weniger Fehlern und verringert somit die Arbeitszeit. Undgute Arbeitswerkzeuge bringen mehr Freude und weniger Frust. Es entsteht weniger Aufwand für Onboarding, Schulungen und reduziert Support-Anfragen.
Das Wichtigste zum Schluss
UCD bringts einfach! Es sorgt für mehr Spass im Projekt, denn es weckt Empathie mit den NutzerInnen. Und die Akzeptanz der Lösung ist höher, wenn NutzerInnen sich beim Entwicklungsprozess einbringen können.
Mit welchen Argumenten gegen UX werdet ihr im Projektalltag konfrontiert? Oder welche Vorbehalte habt ihr selbst?