zurück zur Übersicht

UX sucks – das UX-Design-Diva-Problem

Es ist Mittwoch. Das erste Meeting beim Kunden. Die Nutzertestergebnisse sind im Sack, der Plan für das weitere Vorgehen gemacht, Stakeholder sind an Board. Da passiert es: «Der Jakob hat gesagt, die Grafik ist hässlich.» «Wer ist denn der Jakob?» «Das ist der Lead-Designer von Projekt xxxx.» 😤 Was ist los? Ein Projektmitarbeiter eines völlig anderen Projekts fängt an, um sich zu beissen? Was weiss dieser Designer über den zu kommunizierenden Inhalt der Grafik? Was weiss dieser Designer über Ziele und Strategie des Produktes und seinen Kontext? Wie kommt er überhaupt darauf, seine Meinung – und das auch noch relativ unqualifiziert – kund zu tun?

So etwas in der Form oder so ähnlich passiert leider ab und an. Selbsternannte, aber auch durchaus berechtigte UX-Experten schwingen sich auf zur alleinigen Instanz über das Design in digitalen Produkten. Gefragt oder ungefragt, 99 % der ausserhalb ihres Kopfes entstandenen Designlösungen sind schlecht aus mindestens einem der folgenden Gründe:

  1. ihr habt mich bisher nicht gefragt, das kränkt mich,
  2. es ist hässlich, weil ich der einzige bin, der das sagen darf,
  3. damit kommt kein Nutzer zurecht und ihr habt sicher auch nicht mit solchen gearbeitet,
  4. und wenn ihr mit Nutzern gearbeitet habt, dann sicher nicht richtig

So können wir Entwicklungsvorhaben die Freude an UX wirklich verderben und ihr Schluss ist längst: «UX sucks!»

Was ist eine UX-Design-Diva?

Eine Diva ist ein Mensch, der auf der Basis seiner Popularität die Regeln für sich und seine Fachkollegen setzt oder markiert, wo eben «die Messlatte hängt». Er oder sie ist vermutlich bereits in positiven Augenschein getreten und «kann es sich leisten». Er oder sie duldet keinen auf der gleichen Stufe, denn eine Diva kann es nur eine geben. Übrigens gibt es eine männliche Form von Diva – den Divo – aber genauso wie der Hexer ist diese Form weniger gebräuchlich (das kommentiere ich mal nicht weiter…).

Eine Design-Diva kennen wir bereits seit vielen Jahren. Wenn du mal einen so richtigen Designer im Projekt hast, der die Peitsche und Tortur seiner Ausbildung nicht überwinden kann und weiter durch seine Umwelt streift mit der Attitude, sein erlebtes Leid weiterzugeben, lernst du, was Körperbeherrschung bedeutet. Designs entstehen neben den durch das Business verlangten Anforderungen nur durch den kreativ-chaotischen Geist der Einzelperson und auch zu völlig überraschenden Zeitpunkten. In einem meiner ersten Projekte habe ich mit einer solchen Person zusammengearbeitet und jeden Abend vor den Steuerungsausschüssen gebetet, dass sie gut und fest schläft. Sonst wäre am nächsten Morgen wieder ein komplett überarbeitetes, unabgestimmtes, ungeprüftes, aber natürlich «revolutionär-besseres» Design in den Folien für die Bordmitglieder gelandet. Während ich mittlerweile gut mit Design-Divas umgehen kann, weil zum Beispiel das Zuschauen bei Nutzertests recht heilsame Wirkungen zeigt, kommt jetzt offenbar eine neue Untergattung dazu, die UX-Design-Diva.

Die UX-Design-Diva hat anders als die Design-Diva bereits verstanden, dass es hilft, sich den Nutzer vorzustellen und sich ein Bild über seine Bedürfnisse zu machen. Reden mit oder Beobachten von Nutzern sieht sie aber nicht in ihrem Aufgabenfeld. Sie hat auch internalisiert, dass Entwürfe getestet werden sollten. Aber: Research ist eigentlich nur bestätigend einzusetzen. Zudem scheint mir gerade die UX-Design-Diva nicht in der Lage, das eigene Framing zu hinterfragen oder sich dieses zu vergegenwärtigen. (Kleine Nebenbemerkung: Das eigene, nicht hinterfragte Framing gepaart mit ein bisschen Selbstüberschätzung und dem Drang nach Omnipräsenz und du hast einen echten Kotzbrocken vor dir.) Mit einer Leichtigkeit werden auch nach Nutzerinterventionen unzählige Design-Entscheide gefällt, die reichlich konzeptuelle Tragweite haben, ohne an den Bedarf iterativer Evaluation zu denken. Das Getestete ist dann soweit weg vom eigentlich Implementierten, dass man mit Fug und Recht von 2 Konzepten sprechen kann. Überdies kann eine UX-Design-Diva auch heute noch völlig fachfremd sein. Und gerade dann gilt, dass das Bauchgefühl dieses soliden Halbwissers definitiv schlauer ist als der Rat eines Profis. Treffen zwei solche Exemplare aufeinander, kann es in einem Projekt gerne mal Feuer unterm Dach geben. Dieser Konflikt lässt sich dann meist nur lösen, indem eine Person abgezogen wird.

Insgesamt also können wir dem Stereotyp Folgendes unterstellen:

  • Arbeitet ungeheuer viel
  • Arbeitet am liebsten allein
  • Arbeitsprozess ist nicht vorhersagbar
  • Diskussionen haben nicht zwingend das Ziel des besseren Produkts, sondern dienen der Verteidigung der eigenen Idee

Die Angst vor der Diva im agilen Projektmanagement

Genau die Eigenschaft, unvorhersehbar und nicht wahnsinnig teamfähig zu sein, macht die UX-Design-Diva zum Albtraum von Projektmanagern, Scrum-Mastern und Co. In einer Welt, in der digitale Produkte mehr und mehr kooperativ entworfen werden, ist das abgekapselte, nebenstehende Design nicht mehr möglich. Die immanente Angst vor der Design-Diva ist sogar in den Leitdokumentationen der Projekt- und Programmmanagementmodelle verankert. So werden zum Beispiel im Scaled Agile Framework SAFe Jeff Gothelf and Josh Seiden aus ihrem Buch Lean UX von 2016 klar und deutlich zitiert: «Lean UX literally has no time for heroes. The entire concept of design as a hypothesis immediately dethrones notions of heroism; as a designer, you must expect that many of your ideas will fail in testing. Heroes don’t admit failure. But Lean UX designers embrace it as part of the process.» (Kann man bei SAFe selbst lesen.) Mal abgesehen davon, dass das Falsifizieren der Designhypothese(n) zu den Aufgaben der UX-Disziplinen gehört, verfehlen die «ich-bin-die-letzte-Cola-in-der-Wüste»-Verhaltensweisen das kooperative Designparadigma modernen Projekt- und Produktmanagements.

ABER: Nicht immer ist es vollumfassend das Problem der Personen, dass es zum Diva-Phänomen kommt. Organisatorisch kann man einiges dazu beitragen, dass sich der Graben zwischen Konzept und Entwicklung vergrössert. Zum Beispiel kann man UX komplett zentralisieren und die UX Artefakte ohne Sinn für die Bedürfnisse der Teams gemäss eines Unternehmensstandards anfertigen lassen. Wenn sich UX-Experten den Teams geradezu aufdrängen müssen, weil in ihre Teamvorgehensweisen durch Projekt- oder Produktmanager die systematische Konzeption nicht integriert ist, schafft man direkt ein Umfeld, in dem ein UXler nur als Diva angesehen werden kann. Und das geht sowohl in grossen als auch in kleinen Organisationen, die Entwicklungsteams von extern beauftragen und einen UXler mitordern oder durch einen dritten Dienstleister beauftragen.

Folgen der Diva-Vorkommnisse

Für mich persönlich ist insbesondere das Erlebnis einer fachfremden UX-Design-Diva immer einmal wieder eine der grössten charakterlichen Herausforderungen. Die Zugänglichkeit dieser Menschen für Erkenntnisse aus empirischen Untersuchungen ist extrem gering. Und ich bemerke, wie ich selbst bisweilen in Schockstarre gerate, wenn ich mit dem offensichtlichen Unfug dieses «also ich als Kunde…» konfrontiert werde. Da wir in dem Fall einen Halbwisser vor uns haben, ist es besonders schwierig, Blödsinn von ausnahmsweise richtig zu trennen und die intensiven Gespräche brauchen Kraft und Zeit. Lohnt sich die Diskussion? Wenn ich an die armen Nutzer und Kunden denke – immer!

Erleben agile Produktentwicklungen die UX-Design-Diva immer einmal wieder oder sogar durchgängig, lassen sich zwei Reaktionen in den Organisationen beobachten:

  • Unsichere Lähmung der Teams und damit Verzögerung der konzeptuellen Weiterentwicklung
  • Bypassen der Protagonisten und damit häufig Erhöhen der Korrekturaufwände

Aus Managementoptik ist gerade das zweite Phänomen nicht sofort sichtbar, weil Velocity und Burndown noch eine ganze Weile stimmen, bevor es zu den ersten Korrekturen kommen muss. Zwischenmenschlich entstehen die Barrieren aber schnell. Und zusätzlich wird eine ganze Philosophie, nämlich das nutzer- oder menschzentrierte Entwickeln, mit einem schlechten Karma versehen. Und ehrlich gesagt, gibt es auch Tage, an denen mir das wahnsinnig auf die Nerven geht, wenn jemand aus «UX-Optik» argumentiert. Dann geht UX einfach nur noch auf den Sack.

Was kann ein UXler tun, keine Diva zu sein oder als solche angesehen zu werden?

UX ist die Aufgabe des gesamten Projekt- oder Produktteams. Der Experte dafür hilft dem gesamten Team dabei und sollte offen sein für die Anpassung seiner Artefakte an die Bedürfnisse des Teams. Gemeinsam erstellen wir auf allen Ebenen Geschäft, Nutzer und Technologie ein Konzept für das neue Epic, Feature oder die Story. Und je nach Komplexität oder Menge der Annahmen, muss mehr oder weniger vor der ersten Zeile Code getan werden. Hier gibt es kein Schema F. Aber es braucht jemanden, der weiss, was er tut, wenn Abkürzungen genommen werden. Die Grenze zwischen pragmatisch und jetzt wird’s leider Unfug ist schmal!

Wir stellen oft diese Fragen an Entwickler:

  • Wie braucht ihr das dokumentiert? Wir haben diese Möglichkeiten …
  • Was hindert euch daran, den Prototyp noch einmal durchzuklicken, wenn ihr eine neue Story in Angriff nehmt? (oft sind es Zugänglichkeitsbarrieren)
  • Warum bist du vom Konzept abgewichen?

Bisweilen gibt es gute Gründe, aus denen wir für die Kooperation lernen können. Gerne zitiere ich selbst auch die zweite Seite des agilen Manifests: «The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.» Am Anfang einer Zusammenarbeit weiss man schlicht noch nicht alles, was es braucht, gemeinsam ein erfolgreiches Produkt zu entwickeln. Dafür müssen alle Seiten dazulernen, gerade bei den Kommunikationsmitteln und den gemeinsamen Artefakten. In der Realität gibt es selbst in kolokalisierten Teams zu viel Kommunikation über E-Mail oder JIRA-Tasks und virtuelle Boards, als Artefakte zu viele schwergewichtige Dokumente oder ein Wirrwarr an digitalen Tools (bisschen was im Excel, bisschen in Confluence, bisschen hier, bisschen da…). Die Angemessenheit dieser Hilfsmittel bei der Klärung komplexerer Aufgaben ist allerdings unterirdisch. Wer das ein bisschen fundierter anschauen will, kann sich einmal einige Medienwahltheorien «reinpfeifen». Ein guter Ausgangspunkt sind die Media Richness und die Media Synchronicity Theory. Beide sollten zur Grundausbildung von egal wem gehören, der mal mit Menschen zusammen arbeiten soll… Jedes Produkt ist einzigartig, jedes Team ist einzigartig und es überlebt nur der, der sich an die Umstände anpassen kann, ohne die schützenswerten Ideale der menschzentrierten Entwicklung aufzugeben.

 

Haben Sie Fragen zum Artikel?