Rossler: “Wie User Experience in der Praxis wirklich funktioniert”

ÜBER DAS BUCH

Das Buch von Rossler gibt einen Einblick in den Prozess des User-Experience-Designs. Hierbei wird versucht, dieses Feld möglichst aus einer praktischen Perspektive zu beschreiben.
Das Ziel von UX ist es, so Rossler, möglichst einfache & klar verständliche Lösungen für Probleme zu entwickeln. Deshalb ist UX in allen Design-Disziplinen gleichermaßen wichtig und kann eigentlich nicht als einzelnes Fachgebiet verstanden werden.
Wenn man den UXD-Prozess beschreibt, lässt sich der Vorgang allgemein in zumindest 2 Phasen unterteilen: die Phase der Problemidentifikation und die Phase der schrittweisen Problemlösung.

PROBLEMIDENTIFIKATION & RECHERCHE

Rossler beschreibt das Grundwesen eines Problems als Diskrepanz zwischen der Wahrnehmung eines Ist-Zustandes und der Wunschvorstellung, wie der Idealzustand eines bestimmten Produkts/Gegenstands/Services aussehen könnte. Um adäquate Lösungen für solche Probleme anbieten zu können, muss man zunächst das Problem erkennen und genau analysieren bzw. darstellen. Hierbei ist darauf zu achten, dass man das Problem nicht aus der eigenen, womöglich verzerrten Wahrnehmung oder der Wahrnehmung eines einzelnen Anderen heraus angeht, sondern verschiedene Blickwinkel von Außen auf die Problemstellung zulässt, und sich mehrere Meinungen einholt.

So kann man einerseits sicherstellen, dass man auch ein tatsächlich relevantes und vorhandenes Problem löst, und nicht ein unwichtiges oder gar fiktives. Andererseits kann man durch den gegenseitigen Austausch, beispielsweise mit den vom jeweiligen Problem betroffenen Personen und allen am Projekt Beteiligten sich ein genaues Bild von Ursache und Wirkung des Problems machen, sowie davon, wer vom Problem betroffen ist. Außerdem wird es so leichter, Probleme von bloßen Symptomen zu unterscheiden. Hat man ein relevantes Problem entdeckt und ist durch Recherche in der Lage es richtig zu beurteilen sowie seine Ursache zu erahnen, kann man beginnen schrittweise und zielgerichtet an einer prototypischen Lösung zu arbeiten.

PROBLEMLÖSUNG

Während der Entwicklung einer Lösung sind zwei Dinge gleichermaßen relevant: erstens das sinnvolle Ganze im Auge zu behalten und zweitens, im Einzelnen die richtigen Entscheidungen zu treffen.
Nach der Recherche sieht der Design-Prozess im Überblick folgendermaßen aus: Erst leitet man von der Recherche Verhaltensmuster und zielgruppenbezogene Personas ab. Anschließend kann man auf dieser Basis Anwendungsszenarien entwickeln und die Anforderungen dieser festlegen. Nachdem man in Bezug auf die Anforderungen Skizzen von Lösungsideen angefertigt hat, entscheidet man sich schließlich für die am sinnvollsten erscheinende Design-Skizze und entwickelt daraus einen Prototypen, den man testet und schrittweise überarbeitet. Das Ergebnis dieses Prozesses ist ein sogenanntes MVP (Minimal Viable Product).

Das heißt also man führt zuerst User-Interviews, um die subjektive Wahrnehmung der potenziellen Nutzer bzgl. des zu lösenden Problems qualitativ zu erfassen. Letztlich lässt sich aus diesen Gesprächen im Bestfall ein grundlegendes Verständnis für das Verhalten der User generieren. Auf Basis dieses Verständnisses ist es nun möglich, den unterschiedlichen Verhaltensmustern (Proto-)Personas zuzuordnen. Aus Diesen ergeben sich dann die Hauptnutzungsfälle des Produkts, die die Anforderungen der potenziellen User an das Produkt festlegen. Diesen sollte man gerecht werden. Mögliche Lösungsansätze werden dann in sog. Szenarien festgehalten. Dies sind Geschichten mit Anfang und Ende, die die perfekte Interaktion mit dem Produkt aus Sicht der User beschreiben. Sie sind die Eckpfeiler für das Design, die verwendet werden um bei der Findung von Lösungsideen in Form von Skizzen den Alltag der Anwender vor Augen zu haben. Außerdem wird so sichergestellt, dass das Team hinter dem Projekt gemeinsam an einer Vision arbeitet. Hat man viele mögliche Lösungsideen skizziert und im Team besprochen, entscheidet man sich für den besten Lösungsvorschlag und entwickelt auf dessen Basis einen Prototypen, der mit Hilfe von Usability-Tests an echten Anwendern getestet und optimiert wird. Zuletzt kann man nun den optimierten Prototypen als minimale Version des fertigen Produkts veröffentlichen.

MÖGLICHE KOMPLIKATIONEN

Ein Problem, das bei der Produktentwicklung oft auftritt, ist, dass etwas entwickelt wird, das niemand braucht, weil das Produkt nur ein fiktives Problem löst. Eine weitere Schwierigkeit ist, sich von Ideen, die nicht so gut sind, wieder zu trennen. Oft überschätzt man seine eigenen Ideen bzgl. ihrer Qualität nämlich maßlos. Außerdem kommt es oft vor, dass man bei der Planung eines Projektes immer vom idealen Ablauf ausgeht und auftretende Probleme während der Durchführung vernachlässigt. Zuletzt ist Perfektionismus, so Rossler, ein fragwürdiger Anspruch: Wenn man sich auf seine Idee versteift, nur mit Detailarbeit daran beschäftigt ist, und zu spät mit seinem Produkt an die Öffentlichkeit geht aus Angst etwas Unfertiges zu präsentieren, dann kommt das Projekt zu spät in Kontakt mit der Realität und etwaige Fehler im Projekt kommen sehr spät ans Licht. Das Beheben solcher Fehler ist um ein Vielfaches schwieriger und kostenintensiver, als wenn man sich früh zum Stand seines Projekts bekennt und es der Öffentlichkeit präsentiert.

WAS KANN ICH, ALS SOUNDDESIGNER, VOM UX-DESIGN-PROZESS LERNEN?

Vieles von dem, was in diesem Buch beschrieben wird, ist mir, als Quereinsteiger in die Design-Welt noch recht neu, auch wenn ich davon mittlerweile schon einmal gehört habe. Der Überblick über einen UXD-Prozess bietet mir also viele Anhaltspunkte, für jetzt, während meines Studiums, aber auch für später im Berufsleben: So habe ich zwar als Sounddesigner bisher noch nicht wirklich Kontakt zu echten Kunden gehabt, aber die Tipps dazu, wie und warum man ein User- oder Stakeholder-Interview führt, können mir dabei in Zukunft eine große Hilfe darstellen. Fragen wie “Wie finde ich heraus welche Anforderungen an mein Sounddesign gestellt werden?” oder “Wie komme ich an vernünftiges Feedback?” werden im Buch gut beschrieben.

Einige Dinge im Buch betreffen mich aber generell, und diese kann ich, wenn ich sie in meine Arbeitsweise einfließen lasse, nutzen, um meine eigenen Schaffensprozesse jetzt schon zu optimieren. Konkret meine ich damit problematische Charaktereigenschaften und Ansprüche an mich und mein Tun, wie die Schwierigkeit Ideen loszulassen oder den Hang zu Perfektionismus:

Oft habe ich, wenn ich ein sounddesignerisches Problem lösen möchte, sofort eine fixe Idee im Kopf, wie dieses zu lösen ist. Anstatt erst einmal verschiedene Ideen zu sammeln und dann die sinnvollste daraus auszuwählen stürze ich mich zu oft gleich ins Geschehen und versuche, die erste Idee umzusetzen. Selbst wenn sich herausstellt, dass der Lösungsweg, den ich eingeschlagen habe, nicht der eleganteste ist oder ich gar auf scheinbar unlösbare Probleme stoße, beiße ich mich oft noch stundenlang fest und versuche mit allen Mitteln diese eine Idee umzusetzen. Vielleicht wäre es eine gute Idee, mit dem Sammeln von vielen Ideen zur Lösung des jeweiligen Problems zu beginnen und die beste daraus auszuwählen, so wie es im Buch beschrieben wird. So würde ich sicher effizienter ans Ziel gelangen und womöglich auch qualitativ bessere Ergebnisse erzielen.

Auch trifft, wenn ich ehrlich zu mir selbst bin, die problematisierende Beschreibung einer perfektionistischen Haltung viel zu häufig auch auf mein Tun zu. Oft bastle und bastle ich an einem Projekt, um es immer weiter zu verbessern, und seien die “Verbesserungen” auch noch so minimaler und kosmetischer/esoterischer Natur. Im Nachinein hat sich aber schon oft herausgestellt, dass vieles von dem, was ich noch “verbessert” habe, unwichtig, unnütz und nur zeit- und energieraubend war. Dies geht manchmal sogar so weit, dass ich eigentlich potenziell gut geratene Projekte nie zu Ende produziere, weil ich mich in Detailverbesserungen verliere, anstatt die wirklich gravierenden Dinge zu erkennen und auszuräumen und das Projekt abzuschließen. Aus diesem Grund besitze ich eine Vielzahl an unfertigen Projekten, um die es eigentlich schade ist. Hier wäre ein pragmatischerer und effizienterer Zugang zur Umsetzung von Projekten sicher hilfreich. Ich werde versuchen, das Gelesene und Gelernte gleich in meinen künftigen und laufenden Projekten umzusetzen und beispielsweise meine PD-(Sub-)Patches in Zukunft erst grundsätzlich zum Laufen zu bringen und zu optimieren, bevor ich an Klangdetails arbeite. Außerdem werde ich versuchen noch häufiger Feedback einzuholen, auch bei nur kleinen Veränderungen an meinen Projekten, um nicht so viele Schritte doppelt und dreifach machen zu müssen.