Usability als Prozess in Theorie und Praxis
Friday, 26. March 2021
Ich habe hier jetzt viel über Usability geschrieben und wer mir folgte weiß jetzt so einiges. Wir wissen, was Usability ist, können Usability von UX unterscheiden und haben Beispiele für diese Prinzipien anhand von Alltagsbeispielen gesehen. Vor einer Weile schrieb ich sogar schon über typische konkrete Hürden bei der Softwarenutzung. Aber wenn ich jetzt eine neue Anwendung bauen will, wie beachte ich dann dieses ganze Wissen und erbaue die Anwendung mit guter Usability? Die Antwort: Indem im wie auch immer gearteten Entwicklungsprozess Usability explizit berücksichtigt wird.
Eine Prozessblaupause
Es geht dabei ausdrücklich nicht darum, einen bestimmten Entwicklungsprozess vorzuschreiben. Es ist egal, ob das Wasserfall, Scrum, agile Entwicklung oder eine Mischform ist. Es gibt nur zwei Kernbedingungen, die meist hinzugefügt werden müssen: Die Nutzungsanforderungen müssen möglichst früh erhoben und die Usability der Software muss mit echten Zielgruppennutzern getestet werden.
In irgendeiner Form sollte dabei dieser modisch als Kreislauf gezeichnete Prozess abgebildet werden:
Den Kreislauf als Teil des eigentlichen Prozesses beginnt man möglichst früh und hört erst auf, wenn die Lösung sich in einer Evaluation bewährt hat. Für jeden dieser Schritte gibt es eine Menge an Werkzeugen, die üblichsten liste ich hier auf:
1. Nutzungskontext erheben
Wir erinnern uns: Den Nutzungskontext brauchen wir, weil wir Usability immer im Kontext einer bestimmten Nutzung für eine bestimmte Aufgabenerledigung betrachten. Ohne den Kontext können wir ins Blaue designen und testen, reduzieren damit aber eben erheblich die Chance für die Zielnutzung eine gute Lösung zu finden. Um den Kontext zu erheben greife ich üblicherweise auf Nutzerinterviews zurück. Was auch gehen könnte: Beobachtungen. Die sind aber meist schwer umzusetzen. Fokusgruppen wären auch denkbar, verleiten aber dazu, die tatsächliche Nutzungspraxis in der Diskussion durch Gruppendynamiken zu verdecken.
Bei Interviews ist es dann noch wichtig, tatsächlich mit Nutzern zu reden und nicht mit Leuten, die über Nutzer sprechen. Lass dir von ihnen ihre tatsächliche Praxis beschreiben. Aus den Interviews lassen sich dann die Nutzungsanforderungen ableiten.
2. Nutzeranforderungen spezifizieren
Wie das genau aussieht folgt aus dem vorherigen Schritt. Habe ich Interviews gewählt und transkribiert, leite ich aus diesen Texten Anforderungen ab und packe sie in ein Dokument. Oder man muss sich die Videos anschauen, oder die eigenen Beobachtungsnotizen durchforsten. Egal wie: Am Ende diesen Schrittes sollte eine Liste von Anforderungen an die Lösung stehen, die bei deren Entwurf zu berücksichtigen ist.
3. Lösung implementieren
Mit den Anforderungen in der Hand kann nun die Lösung gebaut werden. Je nachdem, in welchem Entwicklungsstand man ist und was man am Ende baut wird das völlig unterschiedlich aussehen. Bei Software starte ich eventuell mit einem Papier-Prototyp, oder einer Prototyp-Software. Später ist die Umsetzung schlicht Softwareentwicklung. Vielleicht aber stellt man mit den Anforderungen in der Hand fest, dass Software gar nicht die Lösung ist, sondern eine Prozessänderung oder ein Echtwelt-Artefakt bauen die beste Lösung wäre.
4. Lösung evaluieren
Am Ende des iterativen Prozess steht dieser allerwichtigste Schritt: Die Evaluierung der Lösung mittels Nutzungstests.
Dabei ist es völlig egal was gebaut wurde. Und selbst wenn alles andere ignoriert wurde: Echte Nutzungstests mit echten Nutzern bringen so viele Erkenntnisse, dass sie auf jeden Fall durchgeführt werden sollten. Dabei liegt die Betonung auf "echte". Es bringt nichts, mit Leuten zu testen die später die Lösung gar nicht benutzen sollen, beispielsweise anderen Softwareentwicklern eine neue Nähmaschine vorzusetzen. Es bringt genausowenig falsch zu testen, also nicht Nutzer die konkrete Aufgabenerledigung durchspielen zu lassen und dabei Probleme zu beobachten, sondern ihre Meinung zur Hintergrundfarbe der Titelleiste zu erfragen.
Nein, echte Nutzungstests spielen mit echten Zielgruppennutzern ihre Aufgabenerledigung nach. Dafür hat der Nutzer meist einen Testleitfaden, der die Aufgaben vorgibt. Der Tester sitzt daneben oder am anderen Ende der Telefonleitung und schaut mit auf den Bildschirm. Was ihn ausschließlich interessiert sind Momente, in denen der Nutzer irritiert ist oder nicht weiterkommt. Solche Critical Incidents (CIs) können immer auf die Verletzung von Dialogprinzipien zurückgeführt werden. Eine so generelle Aussage mag überraschen, aber die Prinzipien sind dafür wirklich ausreichend umfassend und aussagestark. Die CIs zu protokollieren und einzuordnen motiviert dann die nächste Iterationsrunde des Prozess. Mit besserem Verständnis des Nutzungskontexts bzw. der eigenen gebauten Lösung muss die nun angepasst werden, sodass die CIs beim nächsten Test nicht mehr auftreten.
Und wenn es keine CIs gab oder sie die Aufgabenerledigung nur unwesentlich behinderten? Dann sind wir mit der Usabilityarbeit fertig.
Der Prozess in der Praxis
Das oben beschriebene ist keine akademische Fingerübung. Es wird tatsächlich in der Praxis umgesetzt und es funktioniert wirklich. Klar: Niemand und kein Prozess kann garantieren, dass egal welche Hürden es gibt das Endergebnis super wird. Aber Usability mittels dieser Prozesselemente zu beachten vermeidet effektiv, am Ende Nutzern ein Produkt vorzusetzen, mit dem sie schlicht nichts anfangen können. Schon das richtige Testen alleine verhindert das. Denn wenn die Lösung nichts taugt, merkt man das in professionellen Nutzungstests zu 100%. Das Management darf diese Ergebnisse dann nur nicht ignorieren, aber das ist ein Thema für sich.
Praktisch läuft das so ab: Bei der Produktentwicklung gibt es immer ein Entwicklungsteam und Entwicklungsleiter. Dieses Team hat irgendeinen Prozess, mit dem es Lösungen entwirft und umsetzt. Diesem Prozess fügt man nun Usability-Experten hinzu. Man kann einen Usability-Experten als Consultant anheuern, eine Usability-Agentur beauftragen oder einen Usability-Experten einstellen – ob der dann Teil eines Designteam wird oder Teil des Entwicklerteams, gar ein vorheriges Entwicklungsteamitglied mit neuer Zusatzausbildung ist, ist erstmal egal.
Ich habe alle drei Lösungen in der Praxis erlebt. Meinem Eindruck nach funktioniert das Einbinden des Usability-Experten in das Softwareentwicklungsteam am besten, aber dafür muss man nunmal einen der seltenen Usabilityleute finden, die auch Softwareentwickler sind. Hier sollte ich erwähnen: Dieser mein Eindruck könnte daher kommen, dass ich eben selbst einer dieser Usability-Softwareentwickler bin. Die direkte Einbindung hat aber nunmal den Vorteil, dass in einer solchen Konstruktion die Usabilityexpertise sehr nah am Entwicklungsteam lebt und mühelos berücksichtigt werden kann. Wenn stattdessen eine externe Agentur die Usability-Analyse übernimmt, macht die ihre Arbeit und wirft schlimmstenfalls am Ende eine 300-seitiges Ergebnisdokument über den Zaun, von dem das Management nur die Zusammenfassung liest und das dann vom Entwicklerteamleiter im internen Wiki einer Unterseite als .doc angehängt wird, auf dass es keiner der praktischen Entwickler jemals auch nur aufmache. Aber vielleicht funktioniert es manchmal besser.
Egal welche Konstruktion es wird ist dies der Wunsch: Die Leute mit Usability-Expertise erheben den Nutzungskontext (wenn er noch nicht bekannt ist) und erstellen (oder ergänzen die bestehenden) Nutzungsanforderungen. Oberflächen und Funktionalität wird mit den Anforderungen vor Augen designt – prototypisch oder direkt in Zielform –, dann mit Nutzern getestet, schließlich wird auf die CIs reagiert. Und dann wird das wiederholt, wobei Kontexterhebung in späteren Iterationen meist übersprungen wird.
In irgendeiner Form muss das in jeden Entwicklungsprozess einzubauen sein. Am einfachsten ist es wohl bei echter agiler Entwicklung, bei dem die Entwickler zusammen mit den Designern je nach Prozessstand den nächsten Zeitabschnitt der anstehenden Aufgabe widmen. Also zum Beispiel nach der Entwicklung der ersten Alpha-Version im nächsten Wochensprint Nutzungstests durchführen, und im folgenden Sprint je nach Ergebnis entweder nochmal Designworkshops abhalten oder entdeckte Bugs wie Problemstellen in der Software reparieren.
Und das wärs. Usability mit all den dahinterstehenden Konzepten wird zu Prozesselementen, die Entwicklungsfirmen in den ihren einbauen können. Das zu tun verbessert ihre Produkte, vermeidet Kosten und hilft so der Firma. Nebenbei macht es die Entwicklung angenehmer: Bei Nutzungstests die Reaktionen der Nutzer mitzukriegen und Produkte daraufhin verbessern zu können, sodass Nutzer auf einmal mit ihnen gut zurechtkommen, ist auch für klassische Entwickler toll.
Usability im Entwicklungsprozess zu berücksichtigen ist eine wirklich gute Idee. Es ist wohl der einzige Weg, nicht einfach Glück haben zu müssen, sondern bei der Entwicklung einer neues Anwendung eine gute Usability gezielt herstellen zu können.
onli blogging am : Was genau wurde bei Audacity verkauft?
Vorschau anzeigen