Eine meiner liebsten Kindheitsgeschichten stammt aus A. A. Milnes "Pu der Bär". Es ist eine Geschichte, in der Pu und Ferkel sich aufmachen, ein Wiesel zu jagen.
Zu Beginn stößt Ferkel auf Pu, der durch den Hundert-Morgen-Wald wandert, und schließt sich dem Spaziergang an. Pu zeigt Ferkel Spuren im Schnee, denen er folgt und von denen er glaubt, dass sie von einem Wiesel stammen, das er sehr gerne fangen würde. Ferkel und Pu gehen den Abdrücken aufgeregt hinterher.
Nach einem Weilchen bemerken Ferkel und Pu eine zweite Spur, die sich zur ersten gesellt. "Oh, es müssen zwei Wiesel sein", folgert Pu. Sie folgen den Abdrücken weiter, um plötzlich an einen Punkt zu gelangen, an dem eine dritte Spur hinzukommt. Allerdings ist diese anders, also entsteht eine Diskussion darüber, ob es sich womöglich um zwei Wiesel und ein Wuschel oder zwei Wuschel und ein Wiesel handelt.
Schließlich kommt der ständige Held der Geschichte - Christopher Robins - hinzu und fragt Pu, was denn los ist. Er sagt, er habe gesehen, wie die beiden in Kreisen um eine große Eiche gehen. Pu erzählt von dem Abenteuer der Wuschel- und Wieseljagd, nur um dann zu erkennen, dass er und Ferkel die ganze Zeit den eigenen Spuren gefolgt waren.
Warum Out-of-the-box-Analytics für UX-Metriken nicht hilfreich sind
Wenn ich Teams beobachte, die Probleme damit haben, die wichtigen UX-Metriken zu identifizieren, denke ich mir manchmal, dass sie sich wie Pu und Ferkel verhalten, die durch den Hundert-Morgen-Wald spazieren. Die Teams jagen nach einem Maß (oder zwei oder drei), das sie für die Beweisführung nutzen können, dass sich die Investition des Unternehmens in bessere Nutzererlebnisse auszahlt. Schlüsselmetriken zu finden, ist schwierig. Wie das trügerische Wiesel, sind sie schwer einzufangen.
Team beginnen oft mit Metriken von der Stange. Tools wie Google Analytics bieten Metriken mit wichtig klingenden Namen wie eindeutige Nutzer, Absprungrate und Sitzungsdauer. Doch die meisten Teams bemerken schnell, dass diese Metriken tatsächlich nichts tracken, was sinnvolle Aussagen über das Nutzererlebnis zulässt.
Sicher, die Absprungrate, die messen soll, ob jemand die Site sofort wieder verlässt oder bleibt, klingt wichtig im Hinblick darauf, wie Leute mit dem Design interagieren. (Ich sage "messen soll", weil die Funktion das nur tut, wenn der Website alle Zusatzinformationen korrekt hinzugefügt wurden, was, wie sich herausgestellt hat, selten der Fall ist.) Hat die Person die Website verlassen, weil sie verwirrt war und aufgegeben hat? Oder weil die Site genau das getan hat, was die Person wünschte, sodass sie sich glücklich ihren weiteren Abenteuern zuwenden konnte?
Eine hohe Absprungrate könnte schlecht sein (und sollte gesenkt werden). Oder sie könnte gut sein (und wir sollten mehr vom Selben tun). Was davon, können wir aus dieser Zahl nicht ablesen.
Die Absprungrate ist nicht der einzige Übeltäter unter diesen Out-of-the-box-Metriken von der Stange.
Viele eindeutige Besucher sind gut, wenn es sich um exakt diejenigen handelt, von denen wir im geschäftlichen Interesse wollen, dass sie das Design nutzen. Aber wenn ein gezählter Besucher jemand ist, der versehentlich auf eine Anzeige geklickt hat (und ungefähr 50 Prozent aller Anzeigen auf mobilen Geräten werden aus Versehen angeklickt), dann bedeutet die Zahl der eindeutigen Besucher nicht das, was wir denken. Ein Anstieg der eindeutigen Nutzer ist nicht immer eine gute Sache.
Vielleicht ist die Sitzungsdauer eine gute Sache, weil wir meinen, dass die Leute viel Zeit damit verbringen, sich all unsere tollen Dinge anzusehen? Oder ist die Sitzungsdauer etwas Schlechtes, weil wir denken, dass die Leute viel Zeit damit verbringen, verwirrt herumzuklicken? Wenn wir uns nur die Sitzungsdauer anschauen, wissen wir nicht, ob es besser wäre, wenn der Zeitaufwand steigt oder sinkt. Was sollten wir anders machen?
Wiesel und UX-Metriken
Out-of-the-box-Metriken für sich sind nur Beobachtungen. Wir haben keine Geschichte, die uns zu verstehen hilft, ob ein besseres Design sie senken oder erhöhen sollte. Ohne die Geschichte wissen wir nicht, was wir anders machen sollen.
Zur Kompensation nutzen Teams eine Schlussfolgerung. Schlussfolgerungen sind Geschichten, die wir heranziehen, wenn die direkte Beobachtung unsere Bedürfnisse nicht erfüllt.
Pu und Ferkel hatten eine Beobachtung gemacht: Die Spuren wurden mehr. Sie schlussfolgerten, dass es die eines Wiesels waren, dann die von zwei Wieseln, dann die von zwei Wieseln und einem Wuschel. Es gab keinen direkt beobachteten Beleg dafür, dass es irgendwo im Hundert-Morgen-Wald Wiesel oder Wuschel gab. Und ohne Christopher Robins' Hilfe hätten sie die Wiesel und Wuschel erfolglos bis in alle Ewigkeit gejagt.
Wenn wir Dinge wie "Okay, sie haben die Website verlassen, weil unsere Inhalte langweilig sind!" sagen, ziehen wir eine Schlussfolgerung wie Pu. Es gibt keinen beobachteten Beleg dafür, dass unsere Site langweilig ist. Die Schlussfolgerung ist ein Wiesel, und wenn wir entsprechend handeln, begeben wir uns auf eine Wieseljagd.
Ein Transaktionssicherheits-Wiesel jagen
Vor Jahren, als der E-Commerce noch in den Kinderschuhen steckte, wurden wir vom E-Commerce-Manager einer führenden amerikanischen Kette für Bürobedarf kontaktiert. Er suchte bei uns jedwede Informationen darüber, wie Kunden entscheiden, ob eine Website sicher ist, sodass sie dort bestellen können. Ob wir irgendwelche guten Wege kennen würden, um die Kunden davon zu überzeugen, dass sie eine sichere Shopping-Umgebung implementiert hatten?
In jenen Tagen waren die Abendnachrichten voll von Geschichten über Leute, die von Fake-Internet-Websites übers Ohr gehauen worden waren, und von entsprechenden Aufrufen, beim Online-Shopping extra vorsichtig zu sein. Der Manager erzählte mir, dass sie eine große Investition in eine sichere Transaktionstechnologie getätigt hatten. Die Befürchtung war aber, die Nutzer würden das nicht bemerken, und dies beeinträchtigte ihre Verkäufe.
Ich fragte den Manager, woher er wüsste, dass Sicherheitsbedenken die Ursache für schlechte Verläufe seien. Er berichtete von einem großen Einbruch in der Checkout-Sequenz an jenem Punkt, an dem die Leute nach ihren Zahlungsinformationen gefragt wurden. Er sagte, sein ganzes Team sei überzeugt davon, dass die Nutzer die Website als nicht sicher wahrgenommen und deshalb abgebrochen hätten.
Zu allem Übel hatte das Team eine Weile geglaubt, es handele sich um ein wirkliches Sicherheitsproblem, und teure Schritte unternommen, um es zu beheben. Sie arbeiteten ihr gesamtes E-Commerce-Transaktionssystem um, weil sie das Gefühl hatten, die Handhabung von SSL-Zertifikaten sei nicht gut genug. Und sie zahlten eine Menge Geld an diverse externe Trust-Partner, die die Sicherheit validierten und verifizierten.
Und trotz all der Ausgaben und des Zeitaufwands schien keine dieser Verbesserungen die Absprungrate auf der Bezahlungsseite zu reduzieren. Was könnten wir tun, um zu helfen?
Wir sagten ihnen, dass wir mit Nutzerforschung helfen könnten. Wir begannen unsere Untersuchung so, wie wir es oft tun, nämlich damit, echte Kunden beim Einkaufen auf der Website zu beobachten. Das Team hatte das nie zuvor gemacht, es war eine rundum neue Erfahrung für sie.
Auf Basis von Beobachtungen, nicht von Schlussfolgerungen handeln
Der erste Käufer in unserer Studie war der Inhaber eines kleinen Geschäfts, der da war, um zufälligerweise einen neuen Highend-Drucker zu kaufen. Er wollte ein Gerät für 2.400 Dollar und war ziemlich erfreut, als er es im Angebot für 200 Dollar weniger sah. Er war bereit zum Bestellen und startete seinen Weg durch den Checkout. Freilich stoppte er, als er zur Seite für die Zahlungsinformationen kam.
Allerdings war es nicht die Sicherheit, die ihn vollends zum Anhalten brachte. Tatsächlich hatte er über Sicherheit überhaupt nicht nachgedacht, sondern war davon ausgegangen, dass der Händler seriös und die Website sicher war.
Der Grund für sein Anhalten war stattdessen, dass dieser High-end-Drucker 140 Pfund wog. Ein so schwerer Drucker würde teuer im Versand sein. Und er wusste nicht, wie hoch die Versandkosten waren. Auf keinen Fall würde er seine Zahlungsinformationen eingeben, ehe er nicht die Gesamtkosten seiner Bestellung kannte und nicht nur das Preisschild des Geräts. Da er keine Informationen über die Versandkosten besaß, würde er nicht weitermachen.
Was der Käufer nicht wusste – und was er nicht wissen konnte – war, dass die nächste Seite ihm die Versandkosten nennen würde und dass er dort nein zu seiner Transaktion sagen könnte, falls ihm das zu teuer wäre. Auch hatte er nicht bemerkt, dass Bestellungen über 25 Dollar versandkostenfrei waren. (Die Website sagte das in einer kleinen, wie eine Anzeige aussehenden Box auf der Homepage, die er nie wahrgenommen hatte, weil er sich aufs Finden seines Druckers fokussiert hatte. Es wurde auch an keiner anderen Stelle wiederholt.)
Es stellte sich heraus, dass er nicht der einzige Teilnehmer an unserer Studie war, der auf der Seite für die Zahlungsinformationen ins Stocken kam, weil er die Versandkosten nicht kannte. Einem signifikanten Anteil ging es so.
Folgerichtig reagierte das Team auf diese Beobachtung, indem es klarstellte, welche Bestellungen versandkostenfrei waren, und den Versandkostenrechner an eine frühere Stelle im Checkout-Prozess verschob. Dadurch erlebten sie eine enorme Reduktion der Seitenabsprünge vom Kreditkarten-Bildschirm. Das Ergebnis waren zusätzlich komplettierte Verkäufe im Wert von Millionen von Dollar.
Die Beobachtung des Teams (Nutzer springen von der Seite mit den Zahlungsinformationen ab) war korrekt gewesen. Aber die Schlussfolgerung, die Website sei nicht sicher genug, war falsch. Zu denken, es wäre ein Problem der Transaktionssicherheit, war eine sehr teure Wieseljagd.
Weitere Beispiele beschreibt der Autor im zweiten Teil des Artikels.
Dieser Artikel wurde im Original am 22. März 2017 unter dem Titel UX Metrics: Identify Trackable Footprints and Avoid the Woozles 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.
