![\"UX](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/1620645124305.png\")
<\/p>\n<\/p>\n
Ich hatte vor kurzem den Artikel\u00a0UX Design ist tot – lang lebe UX Design<\/a> ver\u00f6ffentlicht und darin beschrieben, warum ich ein neues Verst\u00e4ndnis der Rolle UX Designer*in<\/em>\u00a0f\u00fcr dringend n\u00f6tig halte. Mein Aufruf war damals:<\/p>\n Lasst uns gemeinsam die Rolle ‚UX Designer*in‘ modernisieren, um die digitalisierte Welt von Morgen mit besseren Produkten und Services ein kleines St\u00fcck besser zu machen.<\/p><\/blockquote>\n Ein Grund f\u00fcr 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\u00df erschien. Ich habe daraufhin gl\u00fccklicherweise\u00a0jede Menge Input\u00a0von anderen professionellen UX & CX oder\u00a0Digital Design Professionals<\/a>, Software Engineers oder – generell – Produktschaffenden bekommen. Daf\u00fcr vielen Dank, denn es gab mir die M\u00f6glichkeit, meine Gedanken zur Rolle ‚UX Designer*in‘ weiter zu sch\u00e4rfen.<\/p>\n Aufbauend dem Feedback, denke ich inzwischen, dass gar nicht die Rolle UX Designer*in<\/em>\u00a0sondern bereits der Begriff\u00a0Design<\/em>\u00a0als solches die Wurzel des \u00dcbels ist.<\/p>\n Der Begriff kann aufgrund diverser Urspr\u00fcnge und Interpretationen zwei grundlegend verschiedene Bedeutungen annehmen:<\/p>\n Design ist Gestaltung und Formgebung.<\/p><\/blockquote>\n oder aber:<\/p>\n Design ist die M\u00f6glichmachung einer technischen Umsetzung.<\/p><\/blockquote>\n Man kann viel dar\u00fcber diskutieren, welche Definition die „richtigere“ ist. Aber ich denke, dass diese Diskussion m\u00fc\u00dfig ist. Wenn man der Sache mensch-zentriert auf den Grund geht, dann geht es profanerweise einzig und alleine darum,\u00a0was diejenigen Menschen unter dem Design-Begriff verstehen, die auch ein berechtigtes Interesse an Design haben<\/em>\u00a0– die Stakeholder*innen also. Denn ohne diese Interessenten g\u00e4be es kein Design mehr, sondern nur noch Kunst.<\/p>\n Wenn ich meine Erfahrung in hunderten UX Projekten<\/a> 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\u00a0nicht<\/em>\u00a0interpretiert als die\u00a0M\u00f6glichmachung einer technischen Umsetzung<\/em>, sondern in folgender Weise:<\/p>\n Design ist, was mir pers\u00f6nlich gef\u00e4llt.<\/p><\/blockquote>\n Das ist aber leider keine tragf\u00e4hige Definition f\u00fcr den professionellen Arbeitsalltag, denn zu viele Fragen bleiben offen:<\/p>\n Ist Design eher, das was Geldgeber*innen und Entscheider*innen gef\u00e4llt oder was den Nutzer*innen gef\u00e4llt? Wo ein Wireframe optisch doch keinem so wirklich gef\u00e4llt, ist es dann gar kein Design? Aber warum erstellen UX Designer*innen dann Wireframes? Ist ein Design System, ein System, welches ausschlie\u00dflich aus Elementen besteht, die ihrerseits bereits gefallen m\u00fcssen? Aber was ist, wenn ein Design System gef\u00e4llige Elemente enth\u00e4lt, jedoch aufgrund mangelnder DesignOps Infrastruktur falsch verwendet werden kann und das daraus erschaffene Produkt daher wiederum dem Nutzer nicht gef\u00e4llt? Ist es dann gar kein Design System? Oder einfach nur ein schlechtes Design System?<\/em><\/p>\n Man kann diese Fragen leider nur widerspr\u00fcchlich beantworten. Der Grund steckt meiner Ansicht nach in folgender wichtiger Aussage:<\/p>\n Design ist ein Prozess und kein Deliverable.<\/p><\/blockquote>\n Etwas genauer gesagt ist Design ein\u00a0Schaffensprozess<\/em>, sprich ein Prozess bei dem vorwiegend kreiert und nicht analysiert wird. Oder – um an dieser Stelle ein Bild zu bem\u00fchen:<\/p>\n Design ist ein „\u00c4rmel hoch“ und kein „Brille auf“ Prozess.<\/p><\/blockquote>\n Nat\u00fcrlich f\u00e4llt auch hier die klare Unterscheidung schwer. Sollten wir als gute Designer*innen nicht zun\u00e4chst die \u00c4rmel hochkrempeln, dann etwas erschaffen, dann die Brille aufsetzen, um zu schauen ob’s gef\u00e4llt und danach entsprechend feinjustiert weiterarbeiten? Oder sollten wir besser noch, bereits\u00a0vor<\/em>\u00a0unseren allerersten Design-Aktivit\u00e4t die Brille aufsetzen und anschlie\u00dfend sogar immer wieder? \u00c4hnlich wie bei Bildhauer*innen, die zun\u00e4chst mit offenen Augen durch die Welt gehen, um Inspiration zu sammeln, dann mit ihrer Arbeit beginnen und jedes Mal nach ein paar Hammerschl\u00e4gen ihr Werk mit zugekniffenem Augen und ausgestrecktem Daumen begutachten (oder besser noch von den Auftraggeber*innen begutachten\u00a0lassen<\/em>)?<\/p>\n Das geschilderte Wechselspiel aus\u00a0Schaffen und Analysieren<\/em>\u00a0ist nat\u00fcrlich der Schl\u00fcssel 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.<\/p>\n 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\u00a0gezwungen<\/em>\u00a0in Deliverables, also Lieferungen und Zwischen-Lieferungen zu denken. Denn nur durch Lieferung eines Zwischenstandes an den jeweils n\u00e4chsten 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\u00f6nnte und nicht als Prozess.<\/p>\n Mein Anliegen ist es also, dass Design als team-\u00fcbergreifender Schaffensprozess verstanden wird, w\u00e4hrend die Deliverables, die diesen Schaffensprozess befeuern als etwas anderes, noch zu benennendes verstanden werden.\u00a0„Etwas anderes noch zu benennendes“<\/em>\u00a0bleibt an dieser Stelle nat\u00fcrlich unzufriedenstellend vage.<\/p>\n Doch manchmal erkl\u00e4rt sich was etwas ist, indem man erkl\u00e4rt was es nicht ist.<\/p>\n Schauen wir auf moderne UX Design-Prozesse, dann werden wir nicht umhin kommen, uns mit dem obligatorischen\u00a0Wireframe<\/em>\u00a0zu besch\u00e4ftigen, denn er ist in der Zusammenarbeit digitaler Produktteams aktuell omnipr\u00e4sent und wird von Stakeholdern gemeinhin als eine Art\u00a0Design Manifestierung<\/em>\u00a0verstanden.<\/p>\n Wenn Design aber gar kein Deliverable, sondern ein Prozess ist, dann ergibt sich daraus folgende wichtige Kernaussage:<\/p>\n Ein Wireframe ist kein Design sondern ein Deliverable.<\/p><\/blockquote>\n Was uns logischerweise zu folgender Aussage f\u00fchrt:<\/p>\n Die Hauptaufgabe eines UX Designers ist nicht die Erstellung von Wireframes.<\/p><\/blockquote>\n Zugegeben – diese Kausalkette mutet an wie ein H\u00fctchenspieler-Trick. Es klingt, als wolle ich auf Teufel komm raus, die Rolle des UX Designers abwerten und dabei\u00a0Wireframes als Anti-Pattern<\/a>\u00a0gleich mit. Aber darum geht es mir nicht.<\/p>\n Ich m\u00f6chte Augenmerk darauf legen, wie der zu starke Fokus von UX Designer*innen auf\u00a0vermeintliche Design-Deliverables\u00a0<\/em>wie Wireframes dazu f\u00fchren kann, dass ein ganzer Schaffensprozess ins Schlingern ger\u00e4t.<\/p>\n Jeff Gothelf schreibt markig in seinem gro\u00dfartigen\u00a0Lean UX<\/a>\u00a0Buch:<\/p>\n Get out of the deliverables business!<\/p><\/blockquote>\n So sehr ich dieses Zitat unterschreibe, um das Pendel rumzurei\u00dfen: Ich f\u00fchle mich aber auch immer wieder ertappt, dass es ohne Deliverables einfach nicht geht. Der Schaffensprozess ger\u00e4t ohne Deliverables und Artefakte nicht einmal ins Schlingern – er erlahmt v\u00f6llig.<\/p>\n Also lieber schlechte Deliverables liefern statt gar keine? Das w\u00e4re eine Option.<\/p>\n Eine weitere Option ist, das den Deliverables-Kasten nochmals einer gr\u00fcndlichen Inventur zu unterziehen und zu fragen:\u00a0Was geh\u00f6rt im Sinne eines guten Design-Prozesses in unseren Deliverables-Kasten rein und was muss raus?<\/em><\/p>\n Um die Erwartungen zu d\u00e4mpfen: Egal wie gut wir unseren Deliverables-Kasten aufger\u00e4umt haben, wir werden entt\u00e4uscht sein, wenn wir als Team nicht gut kommunizieren k\u00f6nnen:<\/p>\n Kommunikation und Dokumentation ist der M\u00f6rtel, der unsere Deliverables-Bausteine aufeinander geschichtet \u00fcberhaupt halten l\u00e4sst.<\/p><\/blockquote>\n So gesehen sind Wireframes durchaus in Betracht zu ziehende Deliverables – sie sind nur unhandlich und setzen\u00a0jede Menge zus\u00e4tzlicher Kommunikation<\/em>\u00a0oder\u00a0Dokumentation<\/em>\u00a0voraus, um positiv auf den UX Design-Prozess zu wirken.<\/p>\n Um im Bild des konstruktiven Schaffensprozess zu bleiben, haben wir es bei Wireframes mit riesigen, unhandlichen Deliverables-Bausteinen ohne M\u00f6rtel dazwischen zu tun.<\/p><\/blockquote>\n Und genau hier liegt das Problem: Was auf einer echten Baustelle jedem sofort als „verd\u00e4chtig“ ins Auge springen w\u00fcrde, tut es in der abstrakten Welt der digitalen Produktentwicklung offensichtlich nicht.<\/p>\n Denn ein Wireframe\u00a0erscheint<\/em>\u00a0auf den ersten Blick als sei er ein\u00a0Self-Explaining Deliverable<\/em>, also ein\u00a0selbsterkl\u00e4render Liefer-Baustein<\/em>, der keiner weiteren Erl\u00e4uterung oder Erg\u00e4nzung der Lieferant*innen bedarf. Genau das Gegenteil ist aber der Fall: ein Wireframe braucht\u00a0jede Menge verbaler oder schriftlicher Erl\u00e4uterungen<\/em>, um als Liefergegenstand f\u00fcr visuellen Designer*innen oder Software Ingenieur*innen verwertbar zu sein.<\/p>\n Hier nur ein paar Fragen, die sich der Empf\u00e4nger bei jeder traditionellen Wireframe-Lieferung meiner Erfahrung nach immer wieder stellt:<\/p>\n 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\u00e4ume? Sind die Texte und Benennungen genau so final oder werden die sich noch \u00e4ndern? Was f\u00fcr ein Informationsmodell soll diesem Wireframe zugrunde liegen? Welche Edgecases gibt es, wenn der Benutzer nicht den Happy Path beschreitet? Welche User Needs, also Nutzerbed\u00fcrfnisse werden durch diesen Wireframe eigentlich \u00fcberhaupt aufgel\u00f6st? Sind diese User Needs validiert worden oder gar noch riskante Annahmen? …<\/em><\/p>\n Ich k\u00f6nnte viele weitere Fragen erg\u00e4nzen, aber verkneife es mir im „leser*innen-zentrierten“ Sinne. Und nat\u00fcrlich 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\u00e4ufig mono-thematisch zurate gezogen werden und durch ihre visuelle Erscheinung sogar eher\u00a0verschleiern<\/em>, dass sie viele Fragen unbeantwortet lassen.<\/p>\n Wenn also UX Design<\/a>\u00a0ohne<\/em>\u00a0Deliverables auch nicht auskommt, Wireframes aber eigentlich nur zu gro\u00df geratene, zu mono-thematische, zu l\u00fcckenhafte Zwischenlieferungen sind, die eigentlich durch viel mehr Kommunikation oder Dokumentation erg\u00e4nzt werden m\u00fcssten… was\u00a0ist<\/em>\u00a0denn dann das Deliverable der Wahl?<\/p>\n Meine Antwort darauf lautet: Alle Deliverables, die lediglich Zwischenlieferungen darstellen, sollten den Kriterien eines\u00a0Modells<\/em>\u00a0gen\u00fcgen.\u00a0Herbert Stachowiak<\/a>\u00a0kennzeichnet ein Modell durch folgende drei Merkmale:<\/p>\n Ein Modell steht immer\u00a0f\u00fcr etwas<\/em>\u00a0anderes \u2013 n\u00e4mlich f\u00fcr ein nat\u00fcrliches oder ein k\u00fcnstliches Original, welches es somit abbildet oder repr\u00e4sentiert.<\/p>\n Ein Modell erfasst nicht alle Attribute des Originals, sondern nur diejenigen, die den Modellschaffenden bzw. Modellnutzenden relevant erscheinen.<\/p>\n Modelle sind ihren Originalen\u00a0nicht eindeutig zugeordnet<\/em>. Sie erf\u00fcllen ihre Ersetzungsfunktion<\/p>\n Der Vorteil beim Modell-Begriff ist also, dass er im Gegensatz zum Design-Begriff keine Erwartungen sch\u00fcrt, derart:\u00a0„Ein Deliverable muss immer auch gefallen, um zu taugen.“<\/em>\u00a0(Au\u00dfer nat\u00fcrlich man bewege sich in der Dom\u00e4ne der Fashion-Industrie, bei der ich mich an dieser Stelle schon einmal vorab entschuldige).<\/p>\n Zum anderen dr\u00fcckt der Modell-Begriff von seinem Wesen bereits aus, dass es bei Modellen als Deliverables-Bausteine keineswegs darum geht, bereits\u00a0die Wirklichkeit zu schaffen<\/em>, sondern lediglich darum, ein\u00a0vereinfachtes Abbild der Wirklichkeit zu liefern<\/em>. Modelle sind somit sowohl f\u00fcr\u00a0Entdeckungsprozesse<\/em>\u00a0(im Problemraum) als f\u00fcr\u00a0Schaffensprozesse<\/em>\u00a0(im L\u00f6sungsraum) geeignet und bilden somit sogar die Br\u00fccke zwischen zwei Welten.<\/p>\n Eine\u00a0Persona<\/a>\u00a0beispielsweise ist bereits per Definition ein Modell, denn jede Persona ist ein Abbild einer Person, die real existieren\u00a0k\u00f6nnte<\/em>\u00a0und repr\u00e4sentativ f\u00fcr die anvisierte Nutzergruppe ist. Es geht aber v\u00f6llig in Ordnung und ist sogar zu empfehlen, dass die modellierte Person\u00a0nicht wirklich real existiert<\/em>.<\/p>\n Genauso ist aber auch ein „User Flow“ in Form eines\u00a0Aktivit\u00e4tsdiagramms<\/a>\u00a0ein pragmatisches Modell, denn es ist damit auf einen Blick erkennbar, dass ein Aktivit\u00e4tsdiagramm einen bestimmten Arbeitsablauf in m\u00f6glichen Variationen modelliert ohne dabei auch nur ann\u00e4hernd auf die \u00e4sthetische Visualisierung dieser Arbeitsabl\u00e4ufe einzugehen. Ein Aktivit\u00e4tsdiagramm ist somit in allen drei Kriterien eines Modells (Abbildung<\/em>,\u00a0Verk\u00fcrzung<\/em>\u00a0und\u00a0Pragmatismus<\/em>) siegreich.<\/p>\n Wireframes hingegen straucheln sowohl bei der\u00a0Verk\u00fcrzung<\/em>\u00a0als auch beim\u00a0Pragmatismus<\/em>, denn es ist selten klar, welche der im Wireframe dargestellten Boxen welche Relevanz besitzt oder f\u00fcr wen diese Boxen zu welchem Zeitpunkt mit welcher Einschr\u00e4nkung \u00fcberhaupt G\u00fcltigkeit besitzen. Aus diesem Grund wird ein Wireframe von den Stakeholder*innen auch nicht als\u00a0erg\u00e4nzungsw\u00fcrdiges Abbild<\/em>\u00a0verstanden, sondern als\u00a0vollst\u00e4ndiges Design-Artefakt<\/em>\u00a0– mit allen bereits aufgef\u00fchrten negativen Konsequenzen.<\/p>\n Offensichtlich braucht es professionelle Menschen, die in der Lage sind, verwertbare Modelle an ihre Kollegen abzuliefern. Modelle, die bei allen drei Kriterien\u00a0Abbildung<\/em>,\u00a0Verk\u00fcrzung<\/em>\u00a0und\u00a0Pragmatismus<\/em>\u00a0in hohem Ma\u00dfe gl\u00e4nzen. Diese Menschen sind essenziell f\u00fcr die Befeuerung des digitalen Designprozesses. Nach diesen Menschen halten auch wir bei\u00a0Centigrade\u00a0verst\u00e4rkt die Augen offen<\/a>.<\/p>\n 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\u00fcrlich genauso im Design-Prozess – diese sind aber eben keine professionellen Modellierer!<\/p>\n Es geht mir um Menschen, die verstehen, dass Modelle variantenreich sein m\u00fcssen 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\u00e4zise und verbindlich ist und was f\u00fcr die jeweils n\u00e4chsten in der Lieferkette immer auch\u00a0direkt verwertbar<\/em>\u00a0sein muss.<\/p>\n Doch wie hei\u00dft denn jetzt die Rolle, die diesem Profil zugrunde liegt? Ich kann es noch nicht mit Sicherheit sagen, aber ich denke, dass der Begriff\u00a0UX Konzepter\u00a0<\/em>oder gar\u00a0UX Modeler<\/em>\u00a0schon ein recht guter Start sein d\u00fcrfte. Fr\u00fcher nannte man sie vielleicht\u00a0Informationsarchitekt*innen<\/em>… 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\u00a0UX Architekt<\/em><\/a>\u00a0kl\u00e4nge dann doch schon recht passend…<\/p>\n Im Grunde ist es auch egal, wie die von mir gemeinte Profession hei\u00dfen k\u00f6nnte. Zu den Kern-Aufgaben der Rolle z\u00e4hlt meiner Ansicht jedenfalls:<\/p>\n <\/p>\n Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen<\/strong><\/a> an!<\/strong><\/p>\nDa haben wir den \u00dcbelt\u00e4ter: Design war’s!<\/h2>\n
Design ist was gef\u00e4llt?<\/h2>\n
Design ist kein Deliverable!<\/h2>\n
Sad but true: kein Weg vorbei am Deliverable<\/h2>\n
Erstellen UX Designer Wireframes?<\/h2>\n
Bessere<\/em>\u00a0Deliverables sind auch eine Option<\/h2>\n
Liefert doch einfach… Modelle!<\/h2>\n
1. Abbildung<\/h3>\n
2. Verk\u00fcrzung<\/h3>\n
3. Pragmatismus<\/h3>\n
\n
Modelle m\u00fcssen nicht gefallen, nur weiterbringen<\/h2>\n
Beispiele f\u00fcr Modelle<\/h2>\n
Fazit: UX Modellierer*innen erhebet euch!<\/h2>\n
\n