Checkout-Abbrüche mit Aufgabe, Messung und Fehlern untersuchen
Ein ausgearbeiteter Beispielfall verbindet mobile Aufgabenprobe, Trichterdaten und Zahlungsereignisse, bevor eine Änderung am Checkout geplant wird.
Eine Lücke zwischen begonnenen und abgeschlossenen Checkouts zeigt, wo eine Untersuchung ansetzen kann. Für eine konkrete Änderung brauchen Sie zusätzlich den beobachteten Ablauf und passende technische Ereignisse. Beginnen Sie mit einer kleinen Frage: Woran scheitert eine bestimmte Kaufaufgabe auf dem Smartphone?
Zuerst festlegen, was gezählt wird
Definieren Sie Zeitraum, Gerätetyp und Schritte des Trichters. Vergleichen Sie Sitzungen mit denselben Regeln; Bestellungen und Sitzungen sind unterschiedliche Zähleinheiten. Die Shopify-Dokumentation unterscheidet zudem offene und geschlossene Trichter. Ein Vergleich passt nur, wenn Eintritte und Schrittfolgen gleich behandelt werden. Prüfen Sie bei einem Messsystemwechsel auch die Definitionen, bevor Sie eine Verhaltensänderung vermuten.
Ein ausgearbeiteter Untersuchungsfall
Ein fiktiver Zeichenbedarfshop möchte folgende Aufgabe prüfen: eine Zeichenmappe auswählen, als Gast eine Lieferadresse eingeben, die Versandart wählen und zur Zahlung weitergehen. Sämtliche Zahlen und Beobachtungen in der Tabelle sind erfunden; sie zeigen, wie unterschiedliche Befunde zusammengeführt werden können.
Quelle | Fiktiver Befund | Aussagegrenze |
|---|---|---|
Geschlossener mobiler Trichter | 100 Sitzungen erreichen den Checkout; 60 schließen ihn im selben Beobachtungszeitraum ab. | Die Lücke ist erkennbar, ihre Ursache bleibt offen. |
Nach einer ungültigen Postleitzahl steht der Fehlertext außerhalb des sichtbaren Bildschirmausschnitts. | Das ist ein konkretes Hindernis in diesem Ablauf. | |
Zahlungskontrolle | Für diese Aufgabe liegt keine verknüpfte Zahlungsanfrage vor. | Eine Ablehnung durch die Bank ist damit nicht belegt. |
Prüfen Sie zunächst, ob die Zahlungsaufzeichnungen den untersuchten Vorgang überhaupt vollständig abbilden. Fehlende Einträge können auch eine Lücke in der Zuordnung sein. Wird dagegen nachvollziehbar, dass das Formular vor der Zahlungsübermittlung stoppt, behebt eine zusätzliche Zahlungsart dieses Formularproblem nicht.
Die Aufgabe am tatsächlichen Gerät beobachten
Lassen Sie die Aufgabe in einer geeigneten Testumgebung ausführen. Halten Sie Gerät, Browser, Tastaturzustand und den letzten verständlichen Schritt fest. Kann die Person erkennen, welches Feld fehlerhaft ist? Bleiben bereits eingegebene Daten erhalten? Lässt sich die Adresse korrigieren und danach mit der gewählten Versandart fortfahren?
Die Zahlungsprüfung ergänzt diese Beobachtung. Shopify beschreibt beispielsweise Fehler aus Bankentscheidung, Zahlungsdienst oder Shopkonfiguration. Eine allgemeine Meldung auf der Oberfläche sagt noch nicht, welcher dieser Fälle vorliegt. Ordnen Sie verfügbare Ereignisse dem jeweiligen Testvorgang zu, statt sämtliche fehlenden Abschlüsse als Zahlungsfehler zu zählen.
Aus dem Befund eine prüfbare Änderung machen
Für den Beispielfall lautet der nächste Entwurf: Das betroffene Adressfeld ist erreichbar, der Fehler wird dort verständlich in Text beschrieben, und die übrigen Eingaben bleiben erhalten. W3C erläutert, dass ein automatisch erkannter Eingabefehler identifiziert und textlich beschrieben werden muss. Die vorgeschlagene Änderung ist noch keine vollständige Prüfung der Barrierefreiheit.
Wiederholen Sie nach der Umsetzung dieselbe Aufgabe und prüfen Sie anschließend die Entwicklung im gleich definierten Trichter. Dokumentieren Sie auch andere Änderungen, etwa am Angebot oder an den Besucherquellen. Eine gelungene Aufgabenprobe belegt die Bedienbarkeit dieses Ablaufs; eine allgemeine Umsatzwirkung ist damit noch nicht nachgewiesen.
Quellen
Weiterlesen
Alle Beiträge
E-Commerce mit ASES
Onlineshops, Marktplätze und B2B-Portale