Ich hatte vor kurzem den Artikel UX Design ist tot – lang lebe UX Design veröffentlicht und darin beschrieben, warum ich ein neues Verständnis der Rolle UX Designer*in für dringend nötig halte. Mein Aufruf war damals:
Lasst uns gemeinsam die Rolle ‚UX Designer*in‘ modernisieren, um die digitalisierte Welt von Morgen mit besseren Produkten und Services ein kleines Stück besser zu machen.
Ein Grund für den Aufruf war, dass mir auch nach vielen Jahren in der Branche der Abstand zwischen UX Designer*innen und Software Ingenieur*innen immer noch zu groß erschien. Ich habe daraufhin glücklicherweise jede Menge Input von anderen professionellen UX & CX oder Digital Design Professionals, Software Engineers oder – generell – Produktschaffenden bekommen. Dafür vielen Dank, denn es gab mir die Möglichkeit, meine Gedanken zur Rolle ‚UX Designer*in‘ weiter zu schärfen.
Da haben wir den Übeltäter: Design war’s!
Aufbauend dem Feedback, denke ich inzwischen, dass gar nicht die Rolle UX Designer*in sondern bereits der Begriff Design als solches die Wurzel des Übels ist.
Der Begriff kann aufgrund diverser Ursprünge und Interpretationen zwei grundlegend verschiedene Bedeutungen annehmen:
Design ist Gestaltung und Formgebung.
oder aber:
Design ist die Möglichmachung einer technischen Umsetzung.
Man kann viel darüber diskutieren, welche Definition die „richtigere“ ist. Aber ich denke, dass diese Diskussion müßig ist. Wenn man der Sache mensch-zentriert auf den Grund geht, dann geht es profanerweise einzig und alleine darum, was diejenigen Menschen unter dem Design-Begriff verstehen, die auch ein berechtigtes Interesse an Design haben – die Stakeholder*innen also. Denn ohne diese Interessenten gäbe es kein Design mehr, sondern nur noch Kunst.
Design ist was gefällt?
Wenn ich meine Erfahrung in hunderten UX Projekten sowie zahlreiche Bewerbungen und Erfolge meines Unternehmens bei diversen Design Awards zu Rate ziehe, dann komme ich zum Schluss, dass Design von den meisten Stakeholder*innen faktisch nicht interpretiert als die Möglichmachung einer technischen Umsetzung, sondern in folgender Weise:
Design ist, was mir persönlich gefällt.
Das ist aber leider keine tragfähige Definition für den professionellen Arbeitsalltag, denn zu viele Fragen bleiben offen:
Ist Design eher, das was Geldgeber*innen und Entscheider*innen gefällt oder was den Nutzer*innen gefällt? Wo ein Wireframe optisch doch keinem so wirklich gefällt, ist es dann gar kein Design? Aber warum erstellen UX Designer*innen dann Wireframes? Ist ein Design System, ein System, welches ausschließlich aus Elementen besteht, die ihrerseits bereits gefallen müssen? Aber was ist, wenn ein Design System gefällige Elemente enthält, jedoch aufgrund mangelnder DesignOps Infrastruktur falsch verwendet werden kann und das daraus erschaffene Produkt daher wiederum dem Nutzer nicht gefällt? Ist es dann gar kein Design System? Oder einfach nur ein schlechtes Design System?
Design ist kein Deliverable!
Man kann diese Fragen leider nur widersprüchlich beantworten. Der Grund steckt meiner Ansicht nach in folgender wichtiger Aussage:
Design ist ein Prozess und kein Deliverable.
Etwas genauer gesagt ist Design ein Schaffensprozess, sprich ein Prozess bei dem vorwiegend kreiert und nicht analysiert wird. Oder – um an dieser Stelle ein Bild zu bemühen:
Design ist ein „Ärmel hoch“ und kein „Brille auf“ Prozess.
Natürlich fällt auch hier die klare Unterscheidung schwer. Sollten wir als gute Designer*innen nicht zunächst die Ärmel hochkrempeln, dann etwas erschaffen, dann die Brille aufsetzen, um zu schauen ob’s gefällt und danach entsprechend feinjustiert weiterarbeiten? Oder sollten wir besser noch, bereits vor unseren allerersten Design-Aktivität die Brille aufsetzen und anschließend sogar immer wieder? Ähnlich wie bei Bildhauer*innen, die zunächst mit offenen Augen durch die Welt gehen, um Inspiration zu sammeln, dann mit ihrer Arbeit beginnen und jedes Mal nach ein paar Hammerschlägen ihr Werk mit zugekniffenem Augen und ausgestrecktem Daumen begutachten (oder besser noch von den Auftraggeber*innen begutachten lassen)?
Sad but true: kein Weg vorbei am Deliverable
Das geschilderte Wechselspiel aus Schaffen und Analysieren ist natürlich der Schlüssel zu einem guten Design-Prozess. Aber dieses Wechselspiel stellt nur so lange kein Problem dar, wie man als Designer den Design-Prozess alleine und mit sich selbst ausmachen kann.
Ist der Design-Prozess auf viele Schultern verteilt, wie es in modernen Produktteams der Normalfall ist, dann sieht die Sache schon gleich ganz anders aus. Dann ist das Team gezwungen in Deliverables, also Lieferungen und Zwischen-Lieferungen zu denken. Denn nur durch Lieferung eines Zwischenstandes an den jeweils nächsten in der Schaffenskette bleibt der Design-Prozess in Fahrt. Und schon stecken wir wieder im Dilemma, dass Design sehr schnell als Deliverable gesehen werden könnte und nicht als Prozess.
Mein Anliegen ist es also, dass Design als team-übergreifender Schaffensprozess verstanden wird, während die Deliverables, die diesen Schaffensprozess befeuern als etwas anderes, noch zu benennendes verstanden werden. „Etwas anderes noch zu benennendes“ bleibt an dieser Stelle natürlich unzufriedenstellend vage.
Doch manchmal erklärt sich was etwas ist, indem man erklärt was es nicht ist.
Erstellen UX Designer Wireframes?
Schauen wir auf moderne UX Design-Prozesse, dann werden wir nicht umhin kommen, uns mit dem obligatorischen Wireframe zu beschäftigen, denn er ist in der Zusammenarbeit digitaler Produktteams aktuell omnipräsent und wird von Stakeholdern gemeinhin als eine Art Design Manifestierung verstanden.
Wenn Design aber gar kein Deliverable, sondern ein Prozess ist, dann ergibt sich daraus folgende wichtige Kernaussage:
Ein Wireframe ist kein Design sondern ein Deliverable.
Was uns logischerweise zu folgender Aussage führt:
Die Hauptaufgabe eines UX Designers ist nicht die Erstellung von Wireframes.
Zugegeben – diese Kausalkette mutet an wie ein Hütchenspieler-Trick. Es klingt, als wolle ich auf Teufel komm raus, die Rolle des UX Designers abwerten und dabei Wireframes als Anti-Pattern gleich mit. Aber darum geht es mir nicht.
Ich möchte Augenmerk darauf legen, wie der zu starke Fokus von UX Designer*innen auf vermeintliche Design-Deliverables wie Wireframes dazu führen kann, dass ein ganzer Schaffensprozess ins Schlingern gerät.
Bessere Deliverables sind auch eine Option
Jeff Gothelf schreibt markig in seinem großartigen Lean UX Buch:
Get out of the deliverables business!
So sehr ich dieses Zitat unterschreibe, um das Pendel rumzureißen: Ich fühle mich aber auch immer wieder ertappt, dass es ohne Deliverables einfach nicht geht. Der Schaffensprozess gerät ohne Deliverables und Artefakte nicht einmal ins Schlingern – er erlahmt völlig.
Also lieber schlechte Deliverables liefern statt gar keine? Das wäre eine Option.
Eine weitere Option ist, das den Deliverables-Kasten nochmals einer gründlichen Inventur zu unterziehen und zu fragen: Was gehört im Sinne eines guten Design-Prozesses in unseren Deliverables-Kasten rein und was muss raus?
Um die Erwartungen zu dämpfen: Egal wie gut wir unseren Deliverables-Kasten aufgeräumt haben, wir werden enttäuscht sein, wenn wir als Team nicht gut kommunizieren können:
Kommunikation und Dokumentation ist der Mörtel, der unsere Deliverables-Bausteine aufeinander geschichtet überhaupt halten lässt.
So gesehen sind Wireframes durchaus in Betracht zu ziehende Deliverables – sie sind nur unhandlich und setzen jede Menge zusätzlicher Kommunikation oder Dokumentation voraus, um positiv auf den UX Design-Prozess zu wirken.
Um im Bild des konstruktiven Schaffensprozess zu bleiben, haben wir es bei Wireframes mit riesigen, unhandlichen Deliverables-Bausteinen ohne Mörtel dazwischen zu tun.
Und genau hier liegt das Problem: Was auf einer echten Baustelle jedem sofort als „verdächtig“ ins Auge springen würde, tut es in der abstrakten Welt der digitalen Produktentwicklung offensichtlich nicht.
Denn ein Wireframe erscheint auf den ersten Blick als sei er ein Self-Explaining Deliverable, also ein selbsterklärender Liefer-Baustein, der keiner weiteren Erläuterung oder Ergänzung der Lieferant*innen bedarf. Genau das Gegenteil ist aber der Fall: ein Wireframe braucht jede Menge verbaler oder schriftlicher Erläuterungen, um als Liefergegenstand für visuellen Designer*innen oder Software Ingenieur*innen verwertbar zu sein.
Hier nur ein paar Fragen, die sich der Empfänger bei jeder traditionellen Wireframe-Lieferung meiner Erfahrung nach immer wieder stellt:
Welchen Nutzungskontext betrachten wir hier? Welche Persona interagiert hier gerade? Was ist vorher passiert? Soll dieses Layout auch genau so im visuellen Design aufgegriffen werden oder gibt es Freiräume? Sind die Texte und Benennungen genau so final oder werden die sich noch ändern? Was für ein Informationsmodell soll diesem Wireframe zugrunde liegen? Welche Edgecases gibt es, wenn der Benutzer nicht den Happy Path beschreitet? Welche User Needs, also Nutzerbedürfnisse werden durch diesen Wireframe eigentlich überhaupt aufgelöst? Sind diese User Needs validiert worden oder gar noch riskante Annahmen? …
Ich könnte viele weitere Fragen ergänzen, aber verkneife es mir im „leser*innen-zentrierten“ Sinne. Und natürlich lassen nicht nur Wireframes viele Fragen offen. Auch andere Deliverables werfen so manche weitere Frage auf. Ich konzentriere mich hier nur deshalb so stark auf Wireframes, weil sie besonders häufig mono-thematisch zurate gezogen werden und durch ihre visuelle Erscheinung sogar eher verschleiern, dass sie viele Fragen unbeantwortet lassen.
Liefert doch einfach… Modelle!
Wenn also UX Design ohne Deliverables auch nicht auskommt, Wireframes aber eigentlich nur zu groß geratene, zu mono-thematische, zu lückenhafte Zwischenlieferungen sind, die eigentlich durch viel mehr Kommunikation oder Dokumentation ergänzt werden müssten… was ist denn dann das Deliverable der Wahl?
Meine Antwort darauf lautet: Alle Deliverables, die lediglich Zwischenlieferungen darstellen, sollten den Kriterien eines Modells genügen. Herbert Stachowiak kennzeichnet ein Modell durch folgende drei Merkmale:
1. Abbildung
Ein Modell steht immer für etwas anderes – nämlich für ein natürliches oder ein künstliches Original, welches es somit abbildet oder repräsentiert.
2. Verkürzung
Ein Modell erfasst nicht alle Attribute des Originals, sondern nur diejenigen, die den Modellschaffenden bzw. Modellnutzenden relevant erscheinen.
3. Pragmatismus
Modelle sind ihren Originalen nicht eindeutig zugeordnet. Sie erfüllen ihre Ersetzungsfunktion
- für bestimmte Subjekte (für wen?)
- innerhalb bestimmter Zeitintervalle (wann?)
- unter Einschränkung auf bestimmte gedankliche oder tatsächliche Operationen (wozu?)
Modelle müssen nicht gefallen, nur weiterbringen
Der Vorteil beim Modell-Begriff ist also, dass er im Gegensatz zum Design-Begriff keine Erwartungen schürt, derart: „Ein Deliverable muss immer auch gefallen, um zu taugen.“ (Außer natürlich man bewege sich in der Domäne der Fashion-Industrie, bei der ich mich an dieser Stelle schon einmal vorab entschuldige).
Zum anderen drückt der Modell-Begriff von seinem Wesen bereits aus, dass es bei Modellen als Deliverables-Bausteine keineswegs darum geht, bereits die Wirklichkeit zu schaffen, sondern lediglich darum, ein vereinfachtes Abbild der Wirklichkeit zu liefern. Modelle sind somit sowohl für Entdeckungsprozesse (im Problemraum) als für Schaffensprozesse (im Lösungsraum) geeignet und bilden somit sogar die Brücke zwischen zwei Welten.
Beispiele für Modelle
Eine Persona beispielsweise ist bereits per Definition ein Modell, denn jede Persona ist ein Abbild einer Person, die real existieren könnte und repräsentativ für die anvisierte Nutzergruppe ist. Es geht aber völlig in Ordnung und ist sogar zu empfehlen, dass die modellierte Person nicht wirklich real existiert.
Genauso ist aber auch ein „User Flow“ in Form eines Aktivitätsdiagramms ein pragmatisches Modell, denn es ist damit auf einen Blick erkennbar, dass ein Aktivitätsdiagramm einen bestimmten Arbeitsablauf in möglichen Variationen modelliert ohne dabei auch nur annähernd auf die ästhetische Visualisierung dieser Arbeitsabläufe einzugehen. Ein Aktivitätsdiagramm ist somit in allen drei Kriterien eines Modells (Abbildung, Verkürzung und Pragmatismus) siegreich.
Wireframes hingegen straucheln sowohl bei der Verkürzung als auch beim Pragmatismus, denn es ist selten klar, welche der im Wireframe dargestellten Boxen welche Relevanz besitzt oder für wen diese Boxen zu welchem Zeitpunkt mit welcher Einschränkung überhaupt Gültigkeit besitzen. Aus diesem Grund wird ein Wireframe von den Stakeholder*innen auch nicht als ergänzungswürdiges Abbild verstanden, sondern als vollständiges Design-Artefakt – mit allen bereits aufgeführten negativen Konsequenzen.
Fazit: UX Modellierer*innen erhebet euch!
Offensichtlich braucht es professionelle Menschen, die in der Lage sind, verwertbare Modelle an ihre Kollegen abzuliefern. Modelle, die bei allen drei Kriterien Abbildung, Verkürzung und Pragmatismus in hohem Maße glänzen. Diese Menschen sind essenziell für die Befeuerung des digitalen Designprozesses. Nach diesen Menschen halten auch wir bei Centigrade verstärkt die Augen offen.
Ich meine mit „professionellen UX Modellierer*innen“ keineswegs Menschen, die in der Lage sind, Design Thinking Workshops zu moderieren oder Sticky Notes mit inspirierenden Ideen auszustatten, auf ein virtuelles Whiteboard zu kleben oder gar Storyboards auf einem iPad zu scribbeln. Die braucht es natürlich genauso im Design-Prozess – diese sind aber eben keine professionellen Modellierer!
Es geht mir um Menschen, die verstehen, dass Modelle variantenreich sein müssen und dass jedes einzelne Modell nur eines von vielen Deliverable-Bausteinen in der inzwischen langen UX Lieferkette ist. Es geht mir um Menschen, die Modelle als etwas verstehen, das präzise und verbindlich ist und was für die jeweils nächsten in der Lieferkette immer auch direkt verwertbar sein muss.
Doch wie heißt denn jetzt die Rolle, die diesem Profil zugrunde liegt? Ich kann es noch nicht mit Sicherheit sagen, aber ich denke, dass der Begriff UX Konzepter oder gar UX Modeler schon ein recht guter Start sein dürfte. Früher nannte man sie vielleicht Informationsarchitekt*innen… auch nicht schlecht – aber was ist das Kern-Deliverable von Informationsarchitekt*innen? Informationen? Eine Informationsarchitektur? Das klingt recht statisch und wird der dynamischen Natur von User Experience nicht gerecht. Aber UX Architekt klänge dann doch schon recht passend…
Im Grunde ist es auch egal, wie die von mir gemeinte Profession heißen könnte. Zu den Kern-Aufgaben der Rolle zählt meiner Ansicht jedenfalls:
- Verständnis und Dokumentation des mentalen Modells eines Zielnutzers
- Übersetzung zwischen den mentalen Modellen der Zielnutzer und den Domänen- sowie Businessmodellen der Stakeholder
- Gute Kenntnisse der Unified Modeling Language (UML)
- Modellierung von Nutzungsszenarien und Use Cases
- Modellierung von Personas und User Needs
- Modellierung von Arbeitsabläufen in Form von Aktivitätsdiagrammen und Sequenzdiagrammen
- Modellierung von nutzungsnahen Informationsstrukturen in Form von Klassendiagrammen oder Entity-Relationship Diagrammen
- Modellierung von Systemverhalten in Form von Zustandsdiagrammen
- Kollaborative Unterstützung beim Entwurf von Programmierschnittstellen (APIs) und Übersetzung in die Nutzerperspektive, Übersetzer von „data-driven“ zu „information-driven“ also.
- Strukturierung und Dokumentation von Design System Elementen
Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen an!
