<\/p>\n
Klar, gerne. Also zun\u00e4chst einmal fragen wir uns in einem Scoping Workshop<\/a> gemeinsam mit unserem Auftraggeber \u201eWarum wollt ihr eigentlich nutzer-zentrierter Denken und Handeln? Was verspricht ihr euch an strategischen Gesch\u00e4ftsmehrwerten davon?\u201c Die Frage klingt zwar zun\u00e4chst einmal trivial, sie wird in der Praxis aber leider nur selten mit UX Design in Verbindung gebracht. Es ist f\u00fcr unsere Arbeit einfach sehr wichtig zu wissen, inwiefern unsere UX Designs neben dem tats\u00e4chlichen Endnutzer auch f\u00fcr den Auftraggeber einen Mehrwert bringen, denn nur wenn dieser Punkt von Anfang an klar ist, kann man viele nachfolgende Designentscheidungen und nat\u00fcrlich auch teure Entwicklungsaktivit\u00e4ten besser verargumentieren.<\/p>\n Zudem \u2013 und noch viel essenzieller \u2013 haben wir mit dieser Vorabkl\u00e4rung den entscheidenden Hinweis, welche Nutzergruppe die relevanteste Gruppe ist, um gesch\u00e4ftlich erfolgreich zu sein. Anders als bei einer klassischen Zielgruppendefinition, gehen wir hier aber auch wirklich ins Detail und trennen auch nah beieinander liegende Nutzergruppen klar voneinander.<\/p>\n Im Grunde beschreiben wir also erst einmal scharfe Nutzerprofile, sogenannte Personas, sowie scharfe Nutzungssituationen, sogenannte Szenarios im Detail, um uns w\u00e4hrend der Design-Findung wenn n\u00f6tig jederzeit in \u201egenau diesen einen Nutzer in genau dieser einen Situation\u201c reinversetzen zu k\u00f6nnen. Das bewahrt das gesamte Team davor, Designentscheidungen zu treffen, die jegliche Bodenhaftung verlieren und am Schluss auf wenig Akzeptanz sto\u00dfen.<\/p>\n Kernfragen beim nutzerzentrierten Projektstart<\/p><\/div>\n Wir durchst\u00f6bern oft sogar Internetforen, um Beweise daf\u00fcr zu finden, dass die Personas, von denen wir ausgingen, dass wir ihre Bed\u00fcrfnisse verstanden haben, wirklich so ticken wie vermutet. Nicht umsonst nennt man diese Phase des Projektes die \u201eUX Discovery\u201c<\/a> Phase: wir sammeln wichtige psychologische Erkenntnisse bevor wir anfangen zu gestalten! Wir gehen also immer mit Demut an die Sache ran und in dem Wissen, dass die potenziellen Nutzer da drau\u00dfen ggf. anders denken als wir das im Team vermuten.<\/p>\n Befragung und Beobachtung repr\u00e4sentativer Nutzer<\/p><\/div>\n <\/p>\n Welche Herausforderungen siehst du speziell in Gro\u00dfkonzernen und wie kann man diese l\u00f6sen?<\/strong><\/p>\n Wie Steve Jobs schon ganz treffend sagte:<\/p>\n \u201cFocus means saying no to the hundred other good ideas that there are.\u201c<\/p><\/blockquote>\n In meiner Laufbahn habe ich immer wieder beobachtet, dass es Produkt Managern oder Product Ownern am schwersten f\u00e4llt \u201eNein\u201c zu m\u00f6glicherweise interessanten Produktfeatures oder Service-Ideen zu sagen. Das kommt aus einer Angst heraus, eine Fehlentscheidung zu treffen, die dann \u2013 bei einem fehlenden Feature \u2013 entlarvend und schmerzlich transparent f\u00fcr alle auf dem Tisch liegt. Viel entlarvender, als wenn man in das Produkt alle m\u00f6glichen Features reinpackt und beim Kunden dadurch \u201enur\u201c eine diffuse Unzufriedenheit ausl\u00f6st. \u201eNur\u201c in Anf\u00fchrungszeichen. Denn genau diese diffuse Unzufriedenheit f\u00fchrt nat\u00fcrlich dazu, dass wir potenzielle Nutzer auf ihrer ganz pers\u00f6nlichen User Journey verlieren. Und die kommen nicht wieder. Fakt ist: Nutzer wollen weniger, daf\u00fcr passgenauere Features. Dann bleiben sie im Flow und somit auf der Reise. Die geschilderte Herausforderung gilt aber bei Traditionskonzernen genauso wie bei Startups oder Mittelst\u00e4ndlern. Am Ende des Tages geht es um die Courage, Nein zum \u201enicht-essenziellen Feature\u201c zu sagen. Aber um das \u00fcberhaupt tun zu k\u00f6nnen, muss man eben genau wissen, wen man als Nutzer in welchem Moment gerade vor sich hat.<\/p>\n <\/p>\n Verlassen wir nun unsere Innensicht und gehen \u201eZur\u00fcck in die Zukunft\u201c bzw. zur\u00fcck zum Nutzer! Welche Kriterien sind aus Design- & Nutzersicht der Schl\u00fcssel zum Erfolg?<\/strong><\/p>\n Unsere bew\u00e4hrte UX Methoden-Toolbox Continuous UX<\/a> bringt sehr viele universelle Leitplanken mit sich, die ein kolossales Scheitern grunds\u00e4tzlich verhindern. Beispielsweise werden dadurch immer wieder repr\u00e4sentative Nutzer in den Prozess einbezogen. Es werden g\u00fcnstige Wegwerf-Prototypen gebaut und diese zun\u00e4chst getestet bevor teure Entwicklungsentscheidungen getroffen werden. Immer wieder wird auch der Rotstift angesetzt und es werden alle Features gestrichen, die keine Miete zahlen. Das reduziert von Grund auf das Risiko eines Scheiterns oder einer Kostenexplosion.<\/p>\n Trotzdem ziehen wir auch w\u00e4hrend der Zusammenarbeit besondere Designprinzipien zu Rate, die f\u00fcr den Kontext des Projekts besonders erfolgsbringend sind. Beispielsweise h\u00e4ngen wir oft das Prinzip \u201eJede Sekunde des Nutzers z\u00e4hlt.\u201c sehr hoch auf. Wir m\u00fcssen uns immer wieder vor Augen f\u00fchren: Wenn wir folgende Designentscheidung zu willk\u00fcrlich treffen oder nicht testen, verlieren wir vielleicht diesen Nutzer auf seiner Reise \u2013 jetzt und hier. Es geht nicht darum, was wir gut finden oder worauf wir<\/em> stolz sind, sondern einzig und alleine um die Frage, was den Nutzer dazu motiviert, am Ball zu bleiben.<\/p>\n \u00a0<\/strong><\/p>\n Als ehemaliger Videospiele-Entwickler wei\u00dft du um die Bedeutung von \u201eGamification\u201c rund um das Nutzerverhalten. Wo siehst du hier die gr\u00f6\u00dften Vorteile und worauf gilt es dabei zu achten?<\/strong><\/p>\n Zun\u00e4chst einmal: Gamification ist die \u201eAnwendung spieltypischer Elemente in spielfremden Kontexten\u201c. Nat\u00fcrlich ist es selten, dass traditionelle Gro\u00dfkonzerne eine verspielte App entwickeln. Aber es geht bei Gamification ja eben um einzelne Spielelemente<\/em>, die den Nutzer auf seiner Reise motivieren sollen, ein n\u00e4chstes Ziel zu erreichen \u2013 und eben nicht, um komplette Spiele im klassischen Sinne. Beispielsweise sind Nutzer motivierter, einen Onboarding-Prozess \u00fcberhaupt in G\u00e4nze abzuschlie\u00dfen, wenn sie jederzeit klar vor Augen haben, wieviel Zeit und Ressourcen es sie kostet oder welche neuen M\u00f6glichkeiten sie sich hierdurch freischalten k\u00f6nnen. Es geht bei Gamification, entgegen der vorherrschenden Meinung, auch weniger um Belohnung und Punkte (das w\u00e4re Inzentivierung), sondern um Selbstwirksamkeit, Kompetenzerlebnisse und das Gef\u00fchl des pers\u00f6nlichen Fortschritts.<\/p>\n Fakt ist: jeder Mensch spielt von der Geburt bis ins hohe Alter und entfaltet genau dabei seine gr\u00f6\u00dfte Konzentration und Leistungsf\u00e4higkeit. Paradoxerweise wird das gerade in Deutschland leider oft \u00fcbersehen, weil nach weit verbreitetem Glaube Arbeiten und Spielen ja \u00fcberhaupt nicht zusammengehen. Dazu kann ich aber nur ein wundervolles Zitat von Dr. Stuart Brown bringen:<\/p>\n \u201eDas Gegenteil von Spiel ist nicht Arbeit sondern Depression.\u201c<\/p><\/blockquote>\n <\/p>\n Ein wichtiger Schritt eines UX Projekts ist oft die Verbesserung der User Journey. Aber ist das schon alles? Was bleibt zu tun in einer Welt in der sich Nutzerverhalten & Pr\u00e4ferenzen kontinuierliches ver\u00e4ndern?<\/strong><\/p>\n Die Verbesserung der User Journeys h\u00f6rt eigentlich niemals auf. Zum einen trifft der Nutzer auf seiner Reise immer wieder auf die gleichen Stationen, beispielsweise auf elektronische Zahlvorg\u00e4nge. Gerade diese wiederkehrenden Touchpoints sollten ihm aber doch stetig das Gef\u00fchl der Kompetenz vermitteln und daher auch kontinuierlich verbessert werden. Wenn ich als Nutzer das Gef\u00fchl habe, dass jedes Mal, wenn eine Woche zwischen zwei \u00dcberweisungen vergangen ist, ich schon wieder nicht wei\u00df, wie der Prozess jetzt eigentlich l\u00e4uft und welche PIN, Passwort oder ID an welcher Stelle daf\u00fcr ben\u00f6tigt wird, dann muss nur ein kleines Startup um die Ecke kommen, was genau diese kurze Reise besser hinbekommt. Der Nutzer ist f\u00fcr den Gro\u00dfkonzern dann weg.<\/p>\n Zum anderen \u00e4ndert sich die Welt um uns herum rapide. Man muss st\u00e4ndig auf dem Radar halten, wenn pl\u00f6tzlich eine ganze Gruppe von Menschen pl\u00f6tzlich ganz neu \u00fcber ein bestehendes Thema denkt, z.B. Vorsorgen, Sparen oder Mobilit\u00e4t. Es hilft an der Stelle nichts, an alten Modellen festzuhalten. Es ist Eile geboten! Man muss solche Ph\u00e4nomene fr\u00fch ernst nehmen, als Chance begreifen und z\u00fcgig neue Services und Touchpoints in die Reise des Nutzers integrieren. Das bekommen die Amerikaner leider viel schneller hin als wir in Deutschland.<\/p>\n <\/p>\n Kommen wir abschlie\u00dfend nochmal zum Kern vom Kern. Worauf kommt es f\u00fcr den Erfolg einer (neuen) User Journey an und wo darf man dabei keine Kompromisse machen?<\/strong><\/p>\n Gerade bei einer neuen User Journey ist das Risiko hoch, mit dem ersten Design daneben zu liegen. Nutzer beobachten, Features klein denken, fr\u00fch zum Testen ins Feld gehen \u2013 das alles gilt eigentlich sowieso immer, aber bei neuen Journeys umso mehr.<\/p>\n Ich bin der Meinung, dass man w\u00e4hrend der Projektentwicklung Kompromisse sogar machen sollte. Aber in der Art, dass man, z.B. nur des Erkenntnisgewinns wegen, fr\u00fche Software St\u00e4nde austestet, die noch buggy und\/oder h\u00e4sslich sind. Solange man die Kompromisse, die man zugunsten fr\u00fcher Erkenntnisse gewonnen hat, sukzessive und kontinuierlich in qualitativ und tragf\u00e4hige L\u00f6sungen \u00fcberf\u00fchrt, ist das sehr erfolgversprechend. Riskant ist es, wenn man das nicht tut, sondern \u00fcberall neue Baustellen aufrei\u00dft \u2013 das f\u00fchrt meiner Ansicht nach zu Systemen, die wie ein Teich mit zu wenig Sauerstoff von einem Tag auf den anderen \u201eumkippen\u201c und nur noch schwer zu retten sind. Die Kunst ist es, langfristig gerade diejenigen Features zu polieren, die auf der Nutzerreise den gr\u00f6\u00dften Mehrwert bringen und diejenigen Features, die eigentlich selten verwendet werden, auch mal bewusst zu vernachl\u00e4ssigen, um damit Entwicklungs-Ressourcen freizuschaufeln. Auch Gro\u00dfkonzerne haben begrenzte Ressourcen und m\u00fcssen es in Punkto Geschwindigkeit mit den kleinen Startups aufnehmen k\u00f6nnen.<\/p>\n Features sollte so priorisiert werden, dass sie m\u00f6glichst viele User Needs gleichzeitig aufl\u00f6sen<\/p><\/div>\n <\/p>\n Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen<\/a> an!<\/strong><\/p>\n![\"Nutzerzentrierter](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Nutzerzentrietrer-Projektstart-Kernfragen-2.jpg\")
![\"Befragung](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/repraesentative-nutzer.jpg\")
![\"Features](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Features-und-User-Needs-3.jpg\")