Schlagwort-Archiv: change management

chi2016: Conversation between Marissa Mayer and Terry Winograd 

Marissa Mayer (Yahoo!) und Terry Winograd (ehem. Stanford University) eröffnete den 3. Tag der CHI 2016 mit einer Diskussion über gut gemeinte aber erzwungene Veränderung von Nutzerverhalten, die Gestaltung von Organisationen, die Balance zwischen Beweis und Intuition in der Produktgestaltung sowie Tipps für die Karriere.

Zu Beginn sprach Marissa Mayer über ihre Zeit bei Google und was sie in dieser Zeit gelernt hat. Konkret ging es um das Fehlen des „Löschen“-Buttons in Google Mail. Die Funktion wurde nicht eingebaut, weil Google beobachtet hatte, das Menschen viel Zeit mit der Organisation ihrer Mails verbringen – also verschieben, sortieren und löschen. Das führte zu der Idee dieses Verhalten zu ändern und Menschen dazu zu bewegen auf diese Tätigkeit zu verzichten. Die Anwender sollte mehr Zeit für andere Tätigkeiten bekommen und als Nebeneffekt sich auf die Fähigkeiten der mächtigen Suchmaschine des Mailservices verlassen. Allerdings hatte Google übersehen, dass es für bestimmte Situationen notwendig ist, dass eine „Löschen“-Funktion vorhanden ist. Das Löschen von Mails war nicht etwa ein verzichtbarer Wunsch, sondern ein grundlegendens Bedürfnis. Heute ist es ihr wichtig, dass bei Designentscheidungen grundsätzliche Nutzerbedürfnisse beachtet werden … auch wenn es verlockend ist das Nutzerverhalten ändern zu wollen.

The best strategy supports what users need.

In ihrer Zeit bei Google folgte sie dem Motto „We donˋt need more opinions. We need data.“ Ihre Entscheidungen traf sie eher aus einer mathematischen Sichtweise. Das prominenteste Beispiel dafür ist als Googles „41 shades of blue“ bekannt. Damals wurde eine Farbauswahl für Links dadurch getroffen, dass 41 Abstufungen von Blau durch A/B-Testing im Feld mit Anwendern getestet wurde. Es wurde dann das Blau mit den besten Kennzahlen ausgewählt. Heute ist sie überzeugt, dass diese extrem mathematische Herangehensweise nicht der richtige Weg war. Wenn Gestaltungsentscheidungen nur auf Basis von Daten getroffen werden, kann das dazu führen, dass Chancen oder Innovationsmöglichkeiten verpasst werden. Heute geht es ihr darum die richtige Balance zwischen intuitiven und datenbasierten Gestaltungsentscheidungen zu finden. Es geht ihr nicht mehr nur um den mathematischen Beweise sondern auch darum das Experimentieren und Ausprobieren.

Das Design von Produkten ist für Marissa Mayer der Schlüssel für Wachstum, weil es maßgeblich dazu beiträgt die Verbundenheit der Anwender mit den Produkten zu steigern.

Search is incredible, but it hasn’t evolved enough.

Sie berichtete davon, wie sie das Vorgehen bei der Gestaltung von Produkten auf die Gestaltung der Unternehmensotganisation bei Yahoo! überträgt. Die Lösung von Yahoo!s Problemen ist nicht einfach. Die Probleme sind vielschichtig und teilweise undurchsichtig. Sie ist überzeugt davon, dass es nicht die eine Person geben kann, welche die Lösung auf all diese Probleme kennt und sie einfach auf den Tisch legen kann. Wäre das so, wäre das schon längst geschehen.

Everything is a design challenge. 

Sie setzt bei der Lösung der Organisations-Probleme von Yahoo! auf die Mitarbeiter des Unternehmens. Als Grundlage dafür schaffte sie eine Unternehmenskultur in der jeder Mitarbeiter die Möglichkeit hat seine Ideen und Problemstellungen sichtbar zu machen. So soll das ganze Wissen der Organisation genutzt werden, um Yahoo! in eine erfolgreiche Zukunft zu führen. Sie nutzen dafür ein internes Moderationswerkzeug. In diesem werden Probleme und Ideen benannt und priorisiert. Das oberste Board von Yahoo! nimmt regelmäßig von dort die TOP-Themen, diskutiert diese und trifft bei Bedarf die notwendigen Entscheidungen. Die Entscheidungen und deren Hintergründe werden auf dem gleichen Weg wieder sichtbar gemacht. Ihr ist die Transparenz von Entscheidungen und deren Hintergründe wichtig.

You need to listen to the organisation, listen to the people. We have to listen to everyones ideas.

Und dann gab sie noch einen interessanten Ratschlag für junge Menschen, die Karriere machen wollen. Sie rät nicht zu viel Zeit mit dem theoretischen Lernen zu verbringen. Man sollte nur soviel theoretisch lernen, bis man in der Lage ist das Wissen praktisch anzuwenden, auszuprobieren und anderen zu erklären. Nur durch die letzten Schritte ist es möglich die Karriereleiter hinauf zu klettern. Sie empfiehlt sich immer wieder Feedback von Mentoren einzuholen.

The key is moving very quickly from being a student to becoming a practitioner.

Zum Abschluss hat sie noch etwas zu ihrem Lebensmotto gesagt. Ihr ist es wichtig immer und immer wieder Dinge anders zu machen und auszuprobieren. So hat sie ihren Weg vom Studium an die Spitze der Unternehmenswelt geschafft. In diesem Sinne:

Do it different.

Die gesamte Diskussion könnt Ihr hier anschauen:

MuC14: bringing change to life

Was für eine inspirierende Keynote und dabei hat Bill Scott (Paypal) nichts anderes gemacht als über die Veränderungen zu erzählen, die er in den letzten drei Jahren bei PayPal erlebt hat.

culture = norms of behaviour + underlying shared values

Zu Beginn seines Vortrages schwärmte er von der Unternehmenskultur bei Netflix, die er vor seiner Zeit bei PayPal kennenlernen durfte: kundenorientiert (kontinuierliches Feedback, anwenderorientierte Kennzahlen), agile Entwicklung, experimentierfreudig, lean, agile. Netflix stand in den letzten Jahren vor der Herausforderung seinen Schwerpunkt von DVD-Versand auf Streaming zu verändern. Die Unternehmenskultur half dem Unternehmen dabei diese Veränderung zu meistern.

Lean-Engineering is about how do we enable learning?

Dann traf er auf PayPal – ein Unterschied wie Tag und Nacht. Zwar war die Veränderungsbereitschaft in der PayPal-Belegschaft hoch. Allerdings behinderte die Unternehmenskultur die Veränderungsmöglichkeiten. Beispielsweise dauerte die Abstimmung eines kleinen Textes auf der Webseite 6 Wochen.

PayPal was the last place, I expected to go to.

Die PayPal-Kultur war 2011 geprägt von der „Not invented here“-Einstellung, langen Abstimmwegen, langen Entwicklungszeiten und Produktentwicklungszyklen sowie Teams, dies sich mehr mit sich beschäftigt haben und es scheuten Risiken einzugehen. Die langen Entwicklungszeiten und Produktlebenszyklen sowie die damit einhergehenden wenigen Release-Termine waren ein wichtiger Grund dafür, dass die Produkte funktional überladen waren. Wenn beispielsweise nur einmal im Jahr releast wird, ist der Druck hoch möglichst viele Funktionen in diesem Release unterzubringen.

build/measure/learn

Eines seiner Ziel war es daher PayPal dazu zu bringen im Sinne des Lean UX-Gedanken schneller zu entwickeln und Veränderungen öfter in kleinen Schritten nach außen zu bringen und zu evaluieren.

Organisations contain anti-bodies that resist change.

Rückblickend kam er zum Schluss, dass es zwei wesentliche Erfolgsfaktoren für erfolgreiche Veränderer gibt:

Persistence: Wenn Du weißt, was Du verändern willst, dann sei beharrlich und halte an deinen Prinzipien fest. Sei dabei aber nicht sturr und gehe flexibel auf die aktuellen Bedürfnisse des Unternehmens ein.

Improv: Du musst davon ausgehen, dass Du bei Veränderungsprojekten nicht alles vorausplanen kannst. Baue im Unternehmen ein Netzwerk von Gleichgesinnten auf, höre mit der notwendigen Demut zu und improvisiere im Sinne Deines Ziels.

Improv is based on humility to listen and adapt to what you hear.

Aus seiner Sicht gibt es 7 Schritte in denen Veränderungen eingeführt werden sollten. Sicherlich sind diese 7 Schritte eine idealisierte Darstellung. In der Realität hat es sicher nicht 1:1 so funktioniert. Seine Liste der 7 Schritte für Veränderung gibt aber nichtsdestotrotz hilfreiche Tipps:

  • Believe something deeply: Du musst von der Notwendigkeit und dem Ziel der Veränderung überzeugt sein. Mache die Bedürfnisse der Kunden des Unternehmens zur Basis Deiner Prinzipien. Vermische Deine Prinzipien nicht mit Prozessen und Projekten.
  • Understand the culture: Höre zuerst aufmerksam zu und verstehe die Unternehmenskultur. Du kannst davon ausgehen, dass im Unternehmen der Veränderungsbedarf, die Probleme und die Lösungen bereits bekannt sind. Deine Aufgabe ist es diese ans Licht zu bringen und zu fördern. Formuliere auf Basis dessen, was Du gehört hast Hypothesen für die notwendige Veränderung und verifiziere diese Hypothesen. Begegne Kollegen und deren Einstellungen immer mit Wertschätzung und Respekt.
  • Fix the pain points: Analysiere die Hauptproblemen und beginne mit diesen. Versteife Dich in der Kommunikation aber nicht auf die Lösung, die Du Dir vorstellst. Dies bringt Dich in eine Verteidigungshaltung. Fokussiere Dich auf das Problem und den Bedarf dies zu lösen.
  • Rally the troops: Suche Gleichgesinnte im Unternehmen und baue Dir ein Netzwerk auf. Finde die, die den gefundenen Problemen am nächsten sind. Suche Dir Unterstützung von außerhalb des Unternehmens.
  • Prototype the change: Finde einen Weg die Veränderungen nach dem Prinzip „Fail fast, learn fast“ in kleinen Schritten auszuprobieren. Du brauchst Budget für Fehlschläge. Dabei ist es wichtig den Fortschritt und den Erfolg zu messen.
  • Tell a story: Erzähle Erfolgsgeschichten über das, was bei der Veränderung gut funktioniert hat. Hol Dir Experten und Feedback von außen um die Geschichte zu bestärken und die Glaubwürdigkeit zu steigern.
  • Keep iterating: Du musst davon ausgehen, dass Dinge, die einmal funktioniert haben, kein zweites Mal funktionieren. Beobachte, lerne und improvisiere. Halte durch und bewege Dich in Iterationen weiter in Richtung Deines Ziels.
  • Abschließend möchte ich noch die drei Punkte benennen, die er als Bewertungsgrundlage für die Evaluation von Teams anlegt:

    • Shared understandig: Weil coole Produkte in der heutigen Welt immer in interdisziplinären Teams entstehen, ist ein gemeinsames Verständnis notwendig. Es muss Möglichkeiten zum interdisziplinären Austausch zwischen den Team (Design, Entwicklung, …) geben, damit dieses gemeinsames Verständnis entstehen kann.
    • Deep collaboration: Die Teams müssen transparent gegenüber einander sein und verstehen, dass sie nur gemeinsam großartige Produkte erzeugen können.
    • Continuous feedback: Kundenfeedback muss in Projekten ein wesentlicher Treiber sein.

    @billwscott: Vielen Dank für diesen Vortrag.

Never change a running user interface – Designveränderungen bei bestehenden Produkten

Ich hatte kürzlich ein aufschlussreiches Gespräch mit einem sehr erfahrenen und erfolgreichen Manager. Er vertrat die Auffassung, dass man bestehende Business-Software in ihrem Produktlebenszyklus – insbesondere in der Wartungsphase – nicht verändern sollte. Notwendige Veränderungen sowie Neuerungen sollten in einem neuen Produkt angeboten werden. Zu Begründung führte er folgendes Beispiel an:

Stellen Sie sich mal vor, ich hätte eine Autowerkstatt und Sie hätten ihr Auto bei mir in die Wartung gegeben. Weil ich ja für meine Kunden vorausdenke und weil viele Kunden anfängliche Probleme mit dem Blinker haben, habe ich ein neues Konzept für die Blinker entworfen. Es ist hocheffizient und intuitiv, da die Blinker-Schalter direkt am Lenkrad angebracht sind. So kann man einfach mit dem linken Daumen den linken Blinker und mit dem rechten Daumen den rechten Blinker einschalten. Die Einarbeitungszeit ist sehr kurz – das habe ich natürlich quantitativ gemessen. Kurzum das Konzept ist einfach und logisch. Ich bin von diesem Konzept so überzeugt, dass ich ihren Blinkerhebel ausbaue und ihn durch meine neue Schalter am Lenkrad ersetze.

Sie holen dann ihr Auto ab. Zur Sicherheit habe ich Ihnen einen roten Zettel an die Rechnung geheftet, der auf die Änderung hinweist. Aber den haben sie trotz oder wegen seiner Farbe übersehen. Sie fahren also los. Dann kommen Sie an eine Kreuzung. Was glauben Sie was passiert? Wie gewohnt, greifen Sie nach ihrem alten Blinkerhebel und sind erst verwundert und dann verärgert, dass der nicht mehr da ist.

Seine Schlussfolgerung aus diesem Beispiel hat mich nachdenklich gemacht. Die digitale Welt zeichnet sich doch gerade dadurch aus, dass die Dinge kontinuierlich besser werden. Sollte man ausgerechnet bei Business-Software auf die Optimierung von Bedienabläufen oder Interaktionsprozessen verzichten, wenn sich die Bestandsanwender erstmal daran gewöhnt haben, und eine parallele Neuentwicklung vorziehen? Kann man sich als Unternehmen nicht vor Fehlschlägen bei der Weiterentwicklung schützen, indem man Anwender bei derartigen Veränderungen frühzeitig einbezieht und mit ihnen gemeinsam die Veränderung mittels Human Centered Design (HCD)-Maßnahmen, wie z.B. Usability Tests, evaluiert?

In der Tat habe ich es schon ab und zu erlebt, dass die Absicherung von gestalterischen Veränderungen mittels HCD-Maßnahmen nicht so gut funktionierte, wie ich das erwartet hätte. Insbesondere dann, wenn die Anwender schon lange, regelmäßig und intensiv mit dem Produkt gearbeitet haben und sich das Produkt seit langer Zeit nicht mehr verändert hat.

Der Grund dafür liegt vermutlich darin: Bei der Evaluation im Rahmen des Human Centered Design-Prozesses wird in der Regel auf Testpersonen gesetzt, die sich freiwillig in eine Testsituation begeben. Diese Testpersonen sind allein schon wegen der besonderen Testsituation besser auf Veränderungen eingestellt, als dies in der Realität der Fall wäre. In der Realität käme die Veränderung viel überraschender und wäre deutlich kritischer, weil sie auch negative Konsequenzen, wie Lernaufwand und steigende Fehlerraten, bedeuten kann.

Die Erkenntnisse aus der Evaluation von Designveränderungen sind also nur bedingt auf reale Situationen übertragbar, in denen trainierte Anwender mit der gestalterischen Veränderung konfroniert werden. Erschwerend kann dann hinzukommen, dass der bisherige komplizierte Ablauf von einem trainierten Anwender sogar als effizient erlebt wurde. Oder es kann passieren, dass trainierte Anwender mit einem komplizierten System anfänglich schneller arbeiten, als ungeübte Anwender mit der optimierten Version des Systems. Manchmal sind komplexe Abläufe aber auch einfach eine Daseinsberechtigung für einzelne Anwender, weil sie die Einzigen sind, die diese bedienen können. Uns muss einfach bewusst sein, dass wir durch gravierende Designveränderungen Experten mitunter zu Anfängern machen. Dies kann dann im schlimmsten Fall dazu führen, dass eine Designveränderung, die im Usability Labor noch mit Bravour bestanden hat, in der Praxis plötzlich vom Markt kritisiert bzw. abgelehnt wird. Nicht etwa weil die gestalterische Veränderung per se schlecht ist, sondern weil übersehen wurde, dass die gestalterische Veränderung auch eine Veränderung von trainierten Verhaltensweisen bewirkt hat.

Die Optimierung von User Interfaces und Bedienabläufen ist in diesem Fall nicht nur ein Designprojekt. Sie wird viel mehr zu einem Veränderungsprojekt. Es gilt nicht nur das User Interface so zu optimieren, dass neue und ungeübte Anwender besser damit arbeiten können. Ebenso wichtig ist es, trainierte bzw. konditionierten Anwendern dabei zu helfen, ihre eingeübten Verhaltensweisen anzupassen, ohne das Gefühl aufkommen zu lassen, ihnen würde die Veränderung aufgezwungen werden.

„We believe that initiating and sustaining new attitudes or behaviors or modifying old ones is difficult, whereas much of the popular literature seems to imply that change is easy. (…) We believe that people need to take the first step. Change should not be forced on them.“ – aus Slow Change Interaction Design

Mein Schlussfolgerung auf das obengenannte Beispiel fällt daher etwas differenzierter aus. Stillstand ist in der digitalen Welt keine gute Überlebensstrategie. Um die notwendige Weiterentwicklung der Oberflächengestaltung von bestehenden Produkten erfolgreich zu meistern, ist es notwendig im Human Centered Design-Prozess auch den Konditionierungs- bzw. Trainingsgrad der Anwender zu berücksichtigen. Der Konditionierungsgrad der Anwender ergibt sich für mich aus der prozentualen Anzahl der Anwender, die die zu verändernde Bedienoberfläche im Arbeitsalltag häufig und wiederholt sowie schon seit längerer Zeit nutzen. Verstärkt wird der Konditionierungsgrad der Anwender durch den erbrachten Einarbeitungsaufwand bzw. die Komplexität der Bedienoberfläche sowie die Zeitdauer, in der sich die Bedienoberfläche nicht verändert hat.

Je trainierter bzw. konditinierter die Anwender sind, umso mehr gehören auch Kommunikationskonzepte für die Einführung der Veränderung sowie Strategien zur Verhaltensveränderung zu den Aufgaben des Redesign-Projektes. Die Kommunikation der Veränderung sollte dabei sowohl innerhalb als auch außerhalb des Produktes erfolgen. Je höher der Trainingsgrad, umso mehr Abstand sollte man von einer gut gemeinten Radikalkur in der Oberflächengestaltung nehmen und über eine Strategie der kleinen Schritte bzw. Slow Change Interaction Design oder einen Parallelbetrieb von alter und neuer Version nachdenken.

Immer dann, wenn wir bestehende Produkte mit einer hohen Anzahl an trainierten Anwendern redesignen, müssen wir uns darüber im Klaren sein, dass dieses Vorhaben zu den größten Herausforderungen für UX Designer zählt. Große Veränderungen lassen sich oft nicht einfach direkt durchsetzen – auch wenn sie nach objektiven Kriterien effizienter, schöner, besser, usw. sind. Bestes Beispiel dafür ist Windows 8: schöner, besser, moderner – und trotzdem kommt es im Markt nicht so an, wie es müsste. Um große Veränderungen zu erreichen, ist es sinnvoll zuerst eine Kultur der Veränderungsbereitschaft zu schaffen und Redesign-Projekte wie Change Management-Projekt zu organisieren (Ihr wisst schon: Schock/Auslöser, Verneinung/Ablehnung, Einsicht/Akzeptanz, Befähigen/Ausprobieren, Erkenntnis). Um in der digitalen Welt schnell auf Trends reagieren zu können, ist es nicht nur notwendig auf eine agile Organisation und Human-Centered-Design zu setzen. Es ist ebenso notwendig sich von langfristiger Stabilität an der Bedienoberfläche zu verabschieden und Anwender durch regelmäßige kleine „schmerzfreie*“ Veränderungen veränderungsbereit zu machen bzw. zu halten.

* schmerzfrei = keine Effizienzeinbußen, sehr geringer Lernaufwand