Warum Sie die Usability Ihrer Software und die User Experience nicht erst am Ende der Entwicklung berücksichtigen sollten.
Kennen Sie das? Die erste Version eines Software-Produktes ist fast fertig. Die Architektur wurde schon lange entschieden, die Kernfunktionen sind implementiert und ein Grafisches User Interface (GUI) ist auch vorhanden. In der kurzen verbleibenden Zeit bis zur Markteinführung soll nur noch die Usability verbessert werden, um die User Experience zu steigern.
So oder so ähnlich planen diejenigen, die sich einen Nutzen aus Usability und User Experience versprechen. Da die Themen Neuland für sie sind, wissen sie noch nicht, welche Herausforderungen dieses Vorgehen mit sich bringt.
Mangelhaftes User Research
Guten Gewissens werden also die Usability Experten oder User Experience Designer vom IT-Hersteller dazu geholt. Gemeinsam steigen sie mit einem Workshop ein, um sich über das Produkt und seinen Nutzungskontext auszutauschen.
Diese Informationsbeschaffung ist Teil des User Researches, das für eine hohe Usability unbedingt notwendig ist. Trotz intensiver Analyse seitens der IT-Hersteller erleben wir in dieser Situation regelmäßig, das zuvor die falschen Fragen gestellt wurden oder Hersteller sich zu schnell mit den Antworten zufrieden gaben. Anbei nur ein paar Beispiele:
Halbwissen zur Zielgruppe
Die interne IT-Abteilung eines Industrieunternehmens hatte uns ausführlich seine Zielgruppe beschrieben. Das Analphabeten dazu gehören, war bis dato nicht bekannt. Dies stellte sich erst durch unsere systematische Kontextanalyse heraus.
Mit dem Wissen um die Analphabeten evaluierten wir das Touch-Interface der kurz vor dem Roll-Out stehenden Software. Dabei erwiesen sich die implementierten Softkeys, die je nach Ansicht ihre Bezeichnung veränderten, als eine große Usabilityhürde für die Analphabeten.
Unbekannter Workflow
Eine andere Usabilityhürde kann vermieden werden, indem Sie den Workflow der User kennen. Nur wer weiß, was Anwender in einer bestimmten Phase brauchen, kann die unnötigen Funktionen aus dem Grafischen User Interface herausnehmen und so seine Komplexität reduzieren. Das steigert die Usability und schafft eine positive User Experience.
Hier haben wir mehrfach erlebt, dass unsere Auftraggeber den Workflow einfach aus ihrem entwickelten Produkt konstruierten. Mit dem Wissen um diese Arbeitserleichterung bohren wir natürlich nach, woher IT-Hersteller den Workflow kennen. Dabei zeigt sich schnell, wie sorgfältig der implementierte Workflow im Nutzungskontext untersucht wurde.
Widersprechen sich Implementierung und Realität sind die User verwirrt oder gar frustriert. Ein erstes Gefühl dafür, was die Nutzer in diesem Moment erleben, erhalten Sie mit dem Versuch zum sogenannten Stroop Effekt. Mit ihm wird die Auswirkung von Aufgaben untersucht, die nicht zum automatisierten Vorwissen der Menschen passen.
Versuchen Sie beim nachfolgenden Bild schnell die Farbe der Worte zu benennen.
Quelle: wikipedia.org
Das Stocken der Anwender oder gar benötigte Hilfe, sind für eine hohe Usability und ein positives Nutzererleben unbedingt zu vermeiden. Es lohnt sich also, den Workflow der User frühzeitig in der Realität zu untersuchen.
Unbekannte Ziele
Ebenfalls zu vermeiden sind Informationslücken darüber, wofür die User das Produkt verwenden wollen. Welche Arten von Ergebnissen die User erwarten, können wir im Kick-off Workshop kaum überprüfen.
In den Projekten, in denen wir Zugang zu den Usern erhalten, decken wir regelmäßig wichtige, bis dahin unbekannte, Nutzerziele auf. Dass sie nicht vom Produkt unterstützt werden, geht zu Lasten der Usability und User Experience.
Moving Targets
Ein letzter Punkt, den wir hier ansprechen wollen, sind die Produktanforderungen, die sich während der Entwicklung verändern. Ist das der Fall, wurden die User zuvor häufig gefragt, was sie sich wünschen.
Das funktioniert jedoch offensichtlich nicht. Für nachhaltige Produktanforderungen ist sowohl das Kontextwissen der Anwender (WAS) als auch das Technikwissen der IT-Hersteller (WIE) nötig. Meistens fehlt den Usern das technische Know-how, um Produktanforderungen benennen zu können.
Die Kosten nachträglicher Usability
Informationsmangel wie beispielsweise zur Zielgruppe, dem Workflow und den Zielen der User sind häufig Grund für Änderungsbedarf. Das gilt bis hin zum User Experience Design samt der Usability der GUI. Im Folgenden gehen wir darauf ein, welche Kosten mit diesen Änderungen am Ende einher gehen.
Änderungskosten für das User Interface
Laut Myers & Rosson [1] machte die Implementierung eines Grafischen User Interfaces 1992 etwa 50% des gesamten Programmieraufwandes aus. Für die heutige Zeit werden mehr als 75% des Aufwandes bei der Programmierung des User Interfaces gesehen [2].
Ohne frühzeitige Berücksichtigung der Usability stellt sich häufig heraus, dass die User die Bedienoberfläche nicht verstehen. Der Programmieraufwand hierfür war umsonst und Änderungen sind nötig.
Abgesehen davon brauchen die Entwickler sowieso eine GUI um die Funktionen während der Programmierung schnell testen zu können. Damit fallen die Kosten für die GUI Entwicklung auf jeden Fall an. Sparen können Sie sich also nur die kostenintensive Mehrarbeit, die durch die Änderung des User Interfaces entsteht.
Änderungsbedarf an Kernfunktionen und Architektur
Mit dem Grafischen User Interface hören die Mehrkosten jedoch noch nicht auf. Auch Änderungen an den Funktionen sind aufgrund von Usability Engineering wahrscheinlich. Wie oben beschrieben, müssen in der Regel bei einer späten Betrachtung der Usability fehlende Funktionen ergänzt und unnötige wieder entfernt werden.
Quelle: apliki.de
Jeder Entwickler weiß, dass der Änderungsaufwand für Funktionen von der Software-Architektur abhängt. An dieser Stelle heißt es Daumendrücken, dass nicht auch noch Änderungen an der Architektur nötig sind.
Wiederholtes User Research
Das Ausmaß der notwendigen Änderungen für eine überzeugende Usability kann nur durch entsprechende User Research Maßnahmen aufgedeckt werden.
Die gute Nachricht lautet an dieser Stelle: Wer sich die erneuten Analysekosten spart, muss sich noch nicht mit den unbekannten Problemen konfrontieren. Das darf dann der Support später machen.
Quelle: apliki.de
IT-Hersteller, denen die User Experience jedoch wichtiger als eine heile Scheinwelt ist, müssen nun auch noch einmal Ressourcen für die erneute Analyse bereitstellen.
Never Change A Running System
Das führt natürlich zu einem Interessenkonflikt. Auf der einen Seite stehen die bevorstehende Markteinführung sowie die stabile und performante Software. Auf der anderen Seite ist die angestrebte hohe Usability für eine exzellente User Experience.
In den meisten Fällen gewinnt an dieser Stelle das „Never Change A Running System“ Prinzip. Natürlich wird versucht mit sogenannten Quickwins eine Verbesserung der Usability und User Experience zu erzielen.
Doch in manchen Fällen waren diese nicht ausreichend. Daumendrücken, dass die bisher erreichte Bedienqualität ausreicht, um erste Umsätze zu generieren, ist da zu wenig.
Usability-Maßnahmen beginnen vor der Implementierung
Maßnahmen für gute Usability und User Experience beginnen deutlich früher als Einsteiger annehmen. Ihre Methoden berühren alle Fachbereiche, die an der Planung, der Analyse, dem Design und der Umsetzung beteiligt sind. Fehlen die Usability-Maßnahmen ist in all diesen Bereichen mit zusätzlichen Kosten für die notwendigen Änderungen zu rechnen.
Diese Erkenntnis teilen alle, die Usability Engineering ausprobiert und den positiven Effekt des Vorgehens erlebt haben.
Ihre Gedanken zu diesem Artikel sind uns wichtig. Bitte teilen Sie Ihre Fragen oder Anregungen mit uns und hinterlassen Sie einen Kommentar. Danke und viel Spaß beim Weiterlesen!
Quellen
[1] Myers, Brad A. & Rosson, Mary Beth (1992). Survey on user interface programming.
[2] HARTMUT WANDKE, RICHARD OED, EDUARD METZKER, MARKUS VAN BALLEGOOY UND JULIA NITSCHKE (2001). DIE ENTWICKLUNG VON USER INTERFACES ALS ARBEITSWISSENSCHAFTLICHER PROZESS UND SEINE UNTERSTÜTZUNG DURCH SOFTWARE-WERKZEUGE.
apliki.wordpress.com 