Fehlschläge sind keine Option, sondern Notwendigkeit

Die letzten Monate waren schwierig für das Team. Nicht schwierig im Sinne von „wir haben uns den Hintern aufgerissen und schlussendlich geliefert“, das war Monate her.

Nein, dieses Mal war es auf eine andere Art schwierig. Wollen wir es „nach-dem-Launch-sind-unsere-Umsätze-um-30-Prozent-zurückgegangen“-schwierig nennen.

Das Team hat sich auf ein Glücksspiel mit einem komplett neuen Design eingelassen, das das Nutzererlebnis der Kunden eigentlich dramatisch verbessern sollte. Hat es aber nicht. Nun haben sie den Preis dafür bezahlt.

Sind Fehlschläge immer schlecht?

Man ist geneigt zu denken, dass Teams Fehlschläge unter allen Umständen vermeiden sollten. Am Ende will ja niemand derjenige sein, der allein in der Cafeteria sitzt und die anderen flüstern hört: „Das ist einer von denen, die es vermasselt haben.“

Wenn Sie sich aber andererseits die vielen großartigen Innovationen der letzten Jahrhunderte ansehen, wird ein Aspekt schnell deutlich: Fehlschläge haben immer eine wesentliche Rolle gespielt. Wir müssen Fehler machen, um zu lernen.

Wenn wir Erfolg haben, wissen wir zwar, dass wir erfolgreich waren, aber wir können nicht genau eingrenzen, warum. Welcher Schritt oder welches Element war der Schlüssel zum Erfolg? Es ist sehr schwer, aus Erfolgserlebnissen zu lernen. Gerade ernüchternde Lektionen sind essenziell für den langfristigen Erfolg von Teams.

Fehlschläge bergen die Chance, unsere Fähigkeiten einem Feinschliff zu unterziehen. Wenn wir versagen – und uns die Zeit zum Lernen nehmen –, decken wir auf, was wir verbessern müssen. Wie sagt man so schön: Der größte Raum der Welt ist der Raum für Verbesserungen.

Wir wollen Fehlschläge. Aber das Risiko möchten wir minimieren.

Die langsame und gemächliche Methode

Amazon.com hat unlängst eine große Änderung am System vorgenommen, und zwar eine, die katastrophale Folgen hätte haben können, hätten sie das Risiko nicht kontrolliert. Amazon verkauft Waren für 12 Milliarden USD im Jahr. Eine Design-Änderung, die nicht funktioniert – und wenn auch nur für einen Tag –, könnte Millionenschäden verursachen.

Die Amazon-Leute beschlossen den Launch ihrer neuen Navigation (und damit das Abschaffen der Tabs, die sie vom ersten Tag an hatten) im vergangenen Sommer und waren natürlich vorsichtig. Alle schauten auf die Zahlen und niemand wünschte sich eine „Verbesserung“, die das Unternehmen versenkt.

Das Resultat war eine der konservativsten Design-Einführungen, die wir je gesehen haben. Es begann damit, die „ungefährlichsten“ Nutzer zu identifizieren. Das waren die Nutzer, die dem System nicht bekannt waren, weil sie keinen Cookie für die Site gespeichert hatten. (User mit Cookies werden mit Amazons Markenzeichen, der persönlichen Begrüßung, bedacht.)

Als das Team die Vorbereitungen abgeschlossen hatte, durften zunächst nur einige wenige Nicht-Cookie-Besucher die neue Navigation sehen. Als die Amazon-Leute zufrieden feststellten, dass diese Leute gut mit dem Design umgehen konnten, drehten sie das Ventil langsam auf und gewährten mehr Nicht-Cookie-Usern einen Blick auf die neue Navigation.

Nach Wochen begann Amazon schließlich, den loyaleren Kunden (die einen Cookie gespeichert hatten) Zugang zu gewähren. Auch dabei hatten sie es nicht eilig und es dauerte weitere Wochen, bis der Wechsel vollständig vollzogen war.

Das Risiko abschwächen

Es war zwar zeitaufwändig, doch durch die allmähliche Umstellung konnte das Amazon-Team sein Risiko minimieren. Wäre ein Fehlschlag aufgetreten, hätten sie die Folgen rechtzeitig eindämmen können. Nur wenn sie zufrieden waren, gewährten sie mehr Usern Zugang.

Eine langsame Umstellung ist eine Möglichkeit zur Risikoabschwächung. Es gibt auch noch zwei andere Wege:

Beispielsweise sind Prototypen auf Papier eine großartige Technik. Durch die Abbildung des interaktiven Modells auf Papier, das von potenziellen Usern ausprobiert wird, erhalten Sie solides Feedback in einem sehr frühen Prozessstadium. Das Risiko besteht darin, dass Sie etwas schaffen und zu viel Zeit mit etwas verbringen, was am Ende keinen Einfluss auf das endgültige System hat.

Das schnelle Wiederholen (fast iteration) ist eine weitere Technik zur Risikoabschwächung. Wird es gut gemacht, produziert jede Wiederholung Informationen über die User und ihre Bedürfnisse, die das Team in den nächsten Entwurf einfließen lassen kann. Je schneller das Team vorgeht, desto rascher entwickelt sich der Entwurf in etwas, das die User lieben werden.

Häufige Fehlschlag-Fehler

„Gute Urteile resultieren aus Erfahrung, und Erfahrung resultiert aus schlechten Urteilen.“
„Erfahrung ist der Name, den jeder seinen Fehlern gibt.“

Bei unseren Untersuchungen sind uns immer wieder Fehler aufgefallen, die Teams begehen – Dinge also, die sie tun (oder unterlassen) und die produktive Fehlschläge verhindern.

Fehler #1: Ohne klare Vision agieren. Wenn das Team nicht weiß, in welche Richtung es steuert, ist es schwer zu wissen, wann es einen Fehltritt gemacht hat. Mit einer klar umrissenen Vision können die Mitglieder einen Fehler unmittelbar feststellen und sofort eine Kurskorrektur einleiten.

Fehler #2: Keine Selbstbeobachtung nach einem Fehlschlag. Es ist ein verständliches Bedürfnis, schnell wieder zum Tagesgeschäft überzugehen, wenn etwas schief gegangen ist. Trotzdem ist es wichtig, dass Teams diesem Drang widerstehen und sich stattdessen zwei Fragen stellen: „Was genau ist passiert?“ und „Was lernen wir daraus?“

Fehler #3: Keine Kommunikation der gelernten Lektionen. In größeren Teams können kleine Fehler (und einige weniger kleine) etwas untergehen, sodass nicht unmittelbar involvierte Team-Mitglieder sie nicht registrieren. Deshalb ist es wichtig, Fehlschläge dem gesamten Team zu kommunizieren, damit jeder Einzelne etwas lernen kann.

Fehler #4: Keine Zeit zum Wiederholen oder Experimentieren. Das Mantra „Fertig, schießen, zielen“ lässt sich nur durch ständiges Wiederholen erfolgreich umsetzen. Teams entwickeln anfangs einen so ausgeprägten Optimismus, dass sie Fehler nicht einkalkulieren und sich dann schämend in der Ecke wiederfinden, wenn etwas schief gegangen ist. Wie uns Amazon zeigt: Wer sich Zeit zum Auswerten und Experimentieren nimmt, erzielt die besten Ergebnisse.

Fehler #5: Unflexible Plattform. Wir hören häufig Kommentare wie „Wir würden es so gerne versuchen, aber wir können unser Content-Management-System nicht dazu bringen“. Teams, die sich an eine unflexible Plattform klammern, bekommen Probleme, wenn sie auf Fehlschläge reagieren müssen. Teams, die auf flexible Plattformen setzen (und fähig sind, diese auch auszuschöpfen), sind in der besten Position, um aus Fehlern Profit zu schlagen.

Fehler #6: Zu viele Ergebnisse vor einer Feedback-Runde. Zu viel Code leitet ein Team in eine Richtung, die nachträglich schwer zu korrigieren ist. Die besten Teams holen frühzeitig Rückmeldungen ein und nutzen schnelle Prototyping-Werkzeuge. Sie beginnen nicht mit dem Programmieren, ehe ihnen grundsätzliches User-Feedback vorliegt, denn nur dann wissen sie, ob die Richtung vielversprechend ist.

Fehler #7: Kein Testinstrumentarium. Viele Teams denken nicht darüber nach, wie sie erklären sollen, ob ein Entwurf denn eigentlich funktioniert. Sie gehen online, ohne etablierte Testmethoden und -instrumente genutzt zu haben. Die besten Teams sondieren und implementieren dieses Instrumentarium frühzeitig. Bei einigen gehört dies sogar zum Teil der Vision.

Fehler #8: Nicht genug Tiefe im Feedback. „War das hilfreich? J/N“ ist eine interessante Frage, aber was soll das Team damit anfangen? Was sollte das Team anders machen, wenn viele Leute mit "nein" antworten? Die besten Teams stellen sicher, dass sie beim Einholen von User-Feedback in die Tiefe gehen. (Netflix kombiniert beispielsweise Live-A/B-Tests mit User-Tests und erhält sowohl qualitativ als auch quantitativ hochwertige Ergebnisse.)

Eine Kultur der Fehlschläge

Der wirklich erfolgskritische Faktor für einen produktiven Umgang mit Fehlschlägen – das sehen wir immer wieder – ist die Unternehmenskultur. Eine Kultur, in der Fehler als Teil des Wachstumsprozesses akzeptiert und in der alle Lernerfahrungen gefeiert werden, ist jedem risikoscheuen Umfeld überlegen. Dies muss sich auch in den Köpfen von Managern festsetzen, die die Courage derjenigen belohnen sollten, die ihre (aus Fehlern resultierenden Einsichten) öffentlich machen.

Eines ist klar: Der richtige Umgang mit Fehlschlägen ist harte Arbeit. Regelmäßiges Praktizieren hilft Teams, darin besser zu werden.

-

Dieser Artikel wurde im Original 29. Oktober 2008 unter dem Titel „Failure Is Not an Option – It's a Requirement“ von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.