Wie und wozu noch UX, wenn schon alles klar ist?

Bei dreipol arbeiten wir täglich daran, die User Experience (UX) von digitalen Produkten zu optimieren. Manchmal starten wir dabei auf der grünen Wiese. Manchmal aber scheint, plakativ formuliert, bereits bei Beginn alles klar zu sein: Was man bauen will, für wen und mit welchen Features. Warum braucht es dann noch UX? Wie wir in unseren Jobs als UX-Designer:innen mit solchen Situationen umgehen können, möchte ich euch in diesem Artikel aufzeigen.

Hinterfragen ist erlaubt

dreipol

Hoi, wir sind dreipol aus Zürich. Seit 2010 konzentrieren wir uns auf das, worin wir richtig gut sind: innovative Mobile- und Web-Applikationen. Wir sind überzeugt,…

Firmenprofil anzeigen

Vorweg: Es ist meines Erachtens völlig normal, als UX-Designer:in in solchen Fällen erst einmal etwas skeptisch zu sein. Schliesslich weiss man noch nicht, wie fundiert die vermeintliche Ausgangslage ist: Hat bereits Research stattgefunden? Sind allfällig vorhandene Personas solide? Machen die gewünschten Features wirklich Sinn? Generell ist es sicher sinnvoll, diese Fragen aufzuwerfen und die vorhandenen Informationen genauer zu betrachten. Vielleicht sind diese ja von einem oder einer anderen UX-Designer:in erarbeitet worden. Vielleicht sind es aber auch eher Ideen, welche besser nochmals geprüft werden sollten. Wenn sich dies nicht so deutlich eruieren lässt, steckt man als UX-Designer:in schnell mal etwas in der Zwickmühle: Ist die bisher geleistete Arbeit eventuell gar nichts wert? Und wie bringt man das dem oder der Kund:in bei? 

Von vorhandenem Wissen profitieren

Wenn wir von dreipol für ein Projekt engagiert werden, gehen wir immer davon aus, dass die intensive Mitarbeit beider Seiten enorm wichtig ist: Unsere Kund:innen sind die Expert:innen für ihr Geschäftsfeld, wir für die Umsetzung inklusive User Experience Design. Nur wenn wir zusammen unser Know-how einbringen, können wir ein optimales Produkt gestalten. Und dann gibt es natürlich noch die beim User Centered Design sehr wichtigen Nutzer:innen. Auf diese hier auch einzugehen, würde aber den Rahmen sprengen. Ich erlaube mir deshalb, sie für einmal auszuklammern und auf die Zusammenarbeit zwischen Kund:in und Agentur respektive UX-Designer:in zu fokussieren – insbesondere eben in jenen Momenten, in denen bereits «alles» als klar erscheint.

Selbstverständlich gibt es Projekte, bei welchen wirklich das Meiste schon ziemlich eindeutig definiert ist (Ausnahmen bestätigen die Regel), und man mehr oder weniger direkt in die Umsetzung starten kann. In diesen Fällen nimmt UX Design dann eher eine begleitende Rolle ein. Unserer Erfahrung nach ist es sonst aber sinnvoll und essenziell, vorhandene Anforderungen und Informationen nochmals genauer unter die Lupe zu nehmen und bei Bedarf zu hinterfragen. Dies stellt auch keine generelle Kritik an der für diese Anforderungen und Informationen bereits geleisteten Arbeit dar, und es muss auch nicht alles prinzipiell erst mal «in den Kübel» geworfen oder zwingend nochmals neu erfunden werden. Denn, wie erwähnt: Die Kund:innen sind meist die Expert:innen in ihrem Gebiet und haben viel (implizites) Wissen, von welchem man unserer Meinung nach unbedingt profitieren muss.

Darum braucht’s dennoch UX Design

Bei dreipol sehen wir es im UX Design deshalb als unsere Aufgabe, mit den zeitlichen und finanziellen Ressourcen unserer Kund:innen sorgfältig umzugehen und Vorhandenes nicht zu ignorieren, sondern überall dort zu komplettieren und anzupassen, wo effektiv Lücken sichtbar werden. Häufig betrifft dies mindestens die Feinarbeit, wo unter anderem User Flows intuitiv gestaltet, Micro-Interactions konzipiert und alle möglichen Bedienungsfehler abgefangen werden sollen (sowie weitere UX-Zutaten, die glücklich machen). 

Dies liefert somit mitten im Text auch gleich schon eine plausible Antwort auf die eingangs gestellte Frage, wozu UX denn doch noch wichtig ist, wenn alles schon klar ist: Der Teufel steckt, wie meistens, im Detail; und um diese Details kümmern sich eben am besten immer UX-Designer:innen, da bei ihnen die notwendige Expertise vorhanden ist!

UX Design trägt natürlich aber auch im grösseren Rahmen viel dazu bei, Produkte optimal zu gestalten. Dazu sollten wir die Kund:innen schon bevor es um die Feinheiten geht, an Bord holen und solide davon überzeugen können, dass je nachdem ein paar Anpassungen an bereits Vorgegebenem sinnvoll investierte Zeit ist. Wie dies gelingen kann, möchte ich euch exemplarisch anhand von zwei Beispielen aufzeigen.

Expert Reviews nutzen

Nehmen wir an, es gibt schon ein bestehendes Produkt, das optimiert werden soll, und wie ist auch schon halbwegs klar. Hier bietet sich der Einsatz einer «internen» Expert Review an (mehr Infos zu Expert Reviews haben wir bei dreipol hier zusammengestellt). So können mit relativ wenig Aufwand (vorbestehende) Schwächen in der Nutzer:innenführung eruiert und klassifiziert werden. Diese bilden dann meist einen soliden Ansatz für die Verbesserung bestehender Vorschläge und Ideen, oder zeigen sogar auf, dass eine grundlegend andere Herangehensweise angebracht wäre. Da die Expert Reviews nicht nur «einfach eine neue Meinung» ist, sondern konkret auf Existierendes (wie ein bestehendes Produkt, Wireframes, skizzierte Ideen etc.) eingeht, steigt unserer Erfahrung nach das Akzeptanz-Level für Optimierungen und Neuerungen.

«Feature-Check-Szenarien» einsetzen

Nehmen wir weiter an, die Kund:innen haben bereits Features definiert, die definitiv ins Produkt aufgenommen werden sollen. Wir sind uns aber aus UX-Sicht nicht auf Anhieb sicher, ob diese Features (sowohl für die Kund:innen als auch die Nutzer:innen) wirklich sinnvoll sind. Im UX Design kennen wir unter anderem diverse Design-Thinking-Methoden, welche uns sonst dabei helfen, ebensolche Features zweckgemäss zu definieren. Wieso also nicht gängige UX-Methoden leicht zweckentfremden, um eine Prüfung von bereits vorhandenen Features zu ermöglichen? Meiner Meinung nach eignet sich beispielsweise eine Form von Szenarien (wie hier von Toni Steimle und Dieter Wallach in Collaborative UX Design beschrieben). Ich nenne diese abgewandelte Methode einfach einmal «Feature-Check-Szenarien», mittels welcher wir aber eben nicht Szenarien generieren, sondern ein Feature auf Herz und Nieren prüfen wollen.

Wir nehmen nun also ein Feature als Ausgangslage und ergänzen es mit prototypischen Nutzer:innen sowie einem zu erreichenden Ziel. Dann versuchen wir gemeinsam mit dem oder der Kund:in für verschiedene Stadien der Feature-Nutzung sinnvolle Schritte zu notieren. Schaffen wir es, stringente Szenarien inklusive Teilschritte zu bilden, dann ist das Feature vielleicht noch nicht perfekt, aber wahrscheinlich geeignet. Fällt es uns schwer, Szenarien zu bilden oder zeigen sich in den Teilschritten grosse Lücken, dann sollte das Feature allenfalls verworfen oder mindestens optimiert werden. Auch hier haben wir sodann relativ schnell Kriterien zur Hand, die uns einen guten Eindruck und ein gemeinsames Verständnis davon vermitteln, wie sinnvoll ein von Anfang an vorhandenes Feature ist und ob allenfalls doch noch einiges Optimierungspotenzial besteht. 

Und zum Schluss…

Ich erhebe hier nun natürlich keinen Anspruch auf Vollständigkeit, und sicher sind die geschilderten Situationen von Projekt zu Projekt unterschiedlich und diverse weitere Vorgehensweisen möglich. Dennoch haben sich meines Erachtens wohl viele Projektbeteiligte schon mit ähnlichen Situationen konfrontiert gesehen. Ich hoffe deshalb, euch hiermit eine kleine Inspiration für Lösungsansätze und einen kurzweiligen und vielleicht auch relativierenden Einblick gegeben haben zu können. Falls sich irgendwann und irgendwo ein Austausch dazu ergäbe, fände ich dies, wie immer, sehr spannend!

Autor: Tobias Koller, CDO & Partner von dreipol

Interessiert bei dreipol tiefer in die Thematik einzutauchen?

Lerne ihren Bewerbungsprozess kennen, oder schau dir ihre offenen Stellen an.