UX-Design: Nutzer hassen nicht Veränderung, sie hassen unser Design-Entscheidungen (Teil 2)

Im ersten Teil des Artikels hat UX-Experte Jared Spool beschrieben, dass User Software-Änderungen gar nicht grundsätzlich ablehnen, sondern nur die Art und Weise, wie sie oft ausgeliefert werden. Denn dabei lassen viele Design- und Entwicklungsteams den entscheidenden Aspekt außen vor: das Nutzererlebnis und damit die Qualität. Dieser zweite Teil knüpft mit vier Prinzipien für umarmbare Design-Veränderungen direkt an diese Überlegungen an.

Die Prinzipien umarmbarer Veränderung

Unsere Untersuchungen haben zu vier Prinzipien geführt, die die Beispiele, in denen Nutzer negativ auf Veränderung reagierten, von denen trennen, in denen die Nutzer die Änderungen bereitwillig angenommen haben.

Prinzip #1: Die Änderungen auf die kleinsten möglichen Einheiten begrenzen

Wenn der Nutzer die Design-Änderungen nicht sehen kann, wird er schwerlich negativ auf sie reagieren. Oftmals packen Designer viele Änderungen auf einmal zusammen. Aber in Zeiten von Continuous Deployment können Designer jede Änderung aufbrechen und sie langsam einphasen, was die schrillen Auswirkungen auf plötzliche, offensichtliche Änderungen eindämmt.

Die Google-Designer hätten die Nutzermanagement-Funktion langsam über mehrere Wochen oder Monate hinweg anpassen können. Eine einzelne dieser Änderungen wäre nicht signifikant und würde die Aufmerksamkeit der Nutzer nicht erregen. Die Farben könnten sich in einer Woche ändern, die Schriftarten in einer anderen. Die meisten User würden keine Notiz davon nehmen.

Prinzip #2: Nutzern die Kontrolle darüber geben, wann Veränderungen sie betreffen

Die Designer der G Suite-Nutzerverwaltung haben ihren Usern die Wahl gelassen, das neue Design zu nutzen oder beim alten zu bleiben. Sie haben ihnen die Option zum Zurückrollen gegeben.

Wenn die Nutzer die Kontrolle darüber haben, wann die Änderungen eintreten, können sie es dann tun, wenn es für sie bequem ist. Es gibt normalerweise keinen Grund dafür, dass Änderungen die User belästigen müssen.

Prinzip #3: Den Nutzern zeigen, warum die Veränderungen für sie vorteilhaft sind

Bei unseren Untersuchungen haben sich User oft darüber beklagt, dass sie keine Vorteile in den Änderungen sehen würden, die ihnen aufgezwungen wurden. In vielen Fällen gab es Vorteile für diese Nutzer, aber diese Vorteile wurden nicht erklärt.

Beispielsweise dachten die Designer, sie würden das Design verbessern, indem sie versteckte Features besser sichtbar machen oder Basisfunktionen auf eine Weise gruppieren, die logischen Aspekten besser folgt. Aber die User erkannten diese Vorteile nicht. Für sie war es Veränderung um der Veränderung willen.

Manchmal war das auch so. Änderungen wurden eingeführt, weil es ein neues Release war und weil neue Releases eben verlangen, dass sich etwas ändert. (Kein Wunder, dass User neue Releases fürchten.)

Wenn Designer den Mehrwert des neuen Designs zeigen, ruft das bei den Usern oft eine positive Reaktion hervor. Sie freuen sich, ein neues Design zu nutzen, wenn die Vorteile auf der Hand liegen. "Es ist, als hätten die Designer meine Gedanken gelesen", sagte uns ein Nutzer.

Prinzip #4: Die bestehende Investition des Users in das Design respektieren

Schlechte Design-Entscheidungen können dazu geführt haben, dass die bestehende Version komplex und schwierig zu nutzen ist. Doch die Nutzer kapieren es trotzdem und nutzen sie.

Die User haben investiert, um Vorteile aus dem bestehenden Design zu ziehen. Sie haben Zeit und Energie hineingesteckt, um zu erlernen, was wir für sie entwickelt haben, egal, was für furchtbare Arbeit wir abgeliefert haben.

Es ergibt Sinn, dass wir es verbessern wollen. Wenn wir unsere User allerdings dazu zwingen, ihre Investition wegzuwerfen, regen sie sich zurecht auf.

Stattdessen können wir im Hinblick auf vorhandene Wissen der Nutzer designen. Wir könnten unterschiedliche Wege anbieten, um zum selben Ergebnis zu kommen. Oder wir könnten eine behutsame Umschulungsmöglichkeit bieten, die vorsieht, dass der alte Weg beibehalten wird, während wir die User langsam zum neuen, besseren Weg geleiten, dieselben Dinge zu erreichen. So oder so respektieren wir, was die Nutzer bereits wissen.

Das Nutzererlebnis ist das Herz der Qualität

Es gibt einen alten Spruch: Sobald wir die Qualität als Anforderung beseitigen, wird alles andere einfacher und billiger. Für unsere bestehenden Nutzer ist Stabilität in puncto UX-Design ein Zeichen von Qualität. Wenn die Dinge, die die gelernt und gemeistert haben, nicht mehr funktionieren, haben wir aus ihrer Sicht die Qualität des Produkts geschmälert.

Wenn wir jedoch proklamieren, dass Nutzer Veränderung hassen und wir da nun mal nichts machen können, entfernen wir die Anforderung, ein hochqualitatives Nutzererlebnis zu bieten. Wir nehmen einen Ausweg, weil wir denken, das wäre etwas, was sich unserer Kontrolle entzieht.

Es als außerhalb unserer Kontrolle zu erklären, ist der einfachere, billigere Weg. In einigen Fällen mag das auch das Richtige sein.

Aber wir können es kontrollieren. Wir haben die Wahl. Wenn wir uns für diesen einfacheren, billigeren Weg entscheiden, opfern wir unser Nutzererlebnis.

Wenn diese Wahl für uns okay ist, sollten wir sie treffen und dabei bleiben. Wir sollten nicht die Nutzer tadeln, weil wir meinen, dass sie uns so oder so hassen. Wir müssen einräumen, dass die User unsere Entscheidungen hassen, nicht Veränderungen an sich.

Entwicklung für Unsichtbarkeit

Gutes UX-Design ist unsichtbar. Es ist wie die Klimaanlage im Zimmer. Wenn wir uns der Klimaanlage bewusst sind, dann wahrscheinlich deshalb, weil etwas nicht stimmt. Es ist zu kalt, zu warm, zu laut oder es tropft. Die beste Klimaanlage ist die, von der wir nichts wissen.

Das gilt auch für Veränderung. Der beste Weg, im Hinblick auf umarmbare Veränderungen zu designen, besteht darin, sie für die User unsichtbar zu machen.

Ein Produktmanager, mit dem wir letztens gearbeitet haben, hatte es mit einem massiven Architektur-Redesign zu tun. Doch sein Ziel bestand darin, die Veränderung für die Nutzer unsichtbar zu machen. "Wenn sie die Änderungen bemerken, haben wir es falsch gemacht", sagte er uns.

Während ich diesen Artikel schrieb, wurde für Thing von Culture Code, eine meiner liebsten Apps für To-do-Listen, ein neues Release veröffentlicht. Die Version 3.5 ist "ein blitzsauberes Release, das 29 tolle kleine Features und Verbesserungen in einem großen Update kombiniert". Die Designer von Culture Code liefern Veränderung nicht nur mit voller Intention an ihre Nutzer aus, sie sind sogar stolz darauf.

Wir sagen, dass Nutzer Veränderung hassen, doch gleichzeitig beharren wir auf große Releases wie dieses. Wenn wir unseren Projekten Namen wie Neues Release, Produkt-Upgrade oder Digital Transformation geben, wecken wir die Erwartung, dass sich etwas ändert. Wenn diese Änderungen für unsere Kollegen nicht sichtbar sind, erfüllen wir diese Erwartung nicht. Was wurde denn nun "geupgradet" oder transformiert? Es ist nicht passiert, wenn man es nicht sehen kann.

Zum Glück bilden große Releases, Upgrades und Transformationen nicht die einzige Alternative. Continuous-Deployment-Methoden rollen konstant kleine Änderungen aus. Sie erlauben es uns, die Änderungen in kleine Teile aufzubrechen – so klein, dass die User sie womöglich nie wahrnehmen.

In einer Continuous-Deployment-Umgebung UX-Design zu betreiben, unterscheidet sich stark von Design im Umfeld Meilenstein-basierter Release-Termine, wo die Änderungen gebündelt werden und verlockend sein müssen, um die Idee von stetigem Fortschritt zu verkaufen. Wir müssen lernen, wie wir den Wert unserer Arbeit in Continuous-Deployment-Umgebungen zeigen.

Nutzer hassen nicht Veränderung, sie hassen unsere Design-Entscheidungen

Wir sind verantwortlich für die schlechten Nutzererlebnisse, mit denen viele User konfrontiert sind, wenn wir unser Design unter ihren Füßen ändern. Das bedeutet nicht, dass wir nichts ändern sollten. Es bedeutet, dass wir sorgsam bedenken müssen, wie wir die Nutzer zu dem neuen Design migrieren.

Design für umarmbare Veränderung gibt uns Prinzipien an die Hand, mit denen wir arbeiten können. Anhand dieser Prinzipien können wir das Veränderungserlebnis unserer bestehenden Nutzer betrachten, wenn wir die Fähigkeiten unserer Designs erweitern. Wir können die Reibung, die für die User durch die Veränderung unserer Designs entsteht, minimieren oder womöglich ganz eliminieren. Auf diese Weise bleiben sie glücklich und zufrieden, während wir integrieren können, was wir gelernt haben.

Dieser Artikel wurde im Original am 20. April 2018 unter dem Titel Users Don’t Hate Change. They Hate Our Design Choices. von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden User-Experience-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im UX-Special von //SEIBERT/MEDIA.

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.
didit checklists for Atlassian Cloud. Präzision, Effizienz, Erfolg. Alles abgehakt. didit checklists for Atlassian Cloud. Präzision, Effizienz, Erfolg. Alles abgehakt. didit checklists for Atlassian Cloud. Präzision, Effizienz, Erfolg. Alles abgehakt.

Schreibe einen Kommentar