Friktionslose Kassen für GAMMA und KARWEI

Im Laufe der Jahre hat Xebia die agile Softwareentwicklung bei Intergamma, bekannt für die Baumärkte GAMMA und KARWEI, vorangetrieben. Vor einem Jahr machten wir uns daran, den Checkout-Prozess für ihre Webshops zu ersetzen. Die bestehende Kasse war langsam und umständlich zu bedienen und entsprach nicht mehr den anderen Teilen der Website. Wir wussten, dass es eine Menge Raum für Verbesserungen gab. Um die Investition zu rechtfertigen, brauchten wir schnell messbare Ergebnisse. Innerhalb eines Jahres konnten wir durchweg eine deutliche Verbesserung der Konversionsrate feststellen. Bevor wir mit der Erneuerung der Kasse begannen, besprachen wir den Technologie-Stack und den allgemeinen Ansatz. Wir hatten bereits Erfahrung mit React und Next.js, entschieden uns aber wegen der damit verbundenen Komplexität gegen Next.js. Eine Checkout-App muss auch nicht von Suchmaschinen indiziert werden, weshalb Sie sonst Next.js verwenden würden. Wir haben uns für ein Standard-React-Setup entschieden, das es uns ermöglicht, uns zu konzentrieren und die Dinge einfach zu halten. Um unseren Erfolg zu messen, haben wir A/B-Tests eingerichtet, um den alten und den neuen Checkout direkt miteinander zu vergleichen, die parallel laufen.

Minimum Valuable Product

Unser ursprüngliches Ziel war es, so schnell wie möglich in Produktion zu gehen. Das bedeutete, dass wir eine Minimalversion der neuen Kasse erstellen mussten, ohne Abstriche bei der Qualität oder Benutzerfreundlichkeit zu machen. Wir nennen dies das Minimum Valuable Product. Da wir dieses Produkt an unsere Kunden ausliefern wollten, durften wir keine Kompromisse bei der Qualität, Benutzerfreundlichkeit oder Leistung eingehen. Allerdings konnten wir Funktionen weglassen, die kaum genutzt werden, vor allem, wenn wir die Kontrolle darüber haben, wer unser neues Produkt zu sehen bekommt. Der Ansatz des Minimum Valuable Product bedeutet, dass Sie es tun sollten:

• Minimieren Sie die für die Inbetriebnahme erforderliche Arbeit
• Bieten Sie ein funktionierendes, benutzbares Produkt an
• Keine Kompromisse bei Ihren Qualitätsstandards
• Messen Sie Ihre Ergebnisse, und passen Sie sie an

Wir verfolgten einen doppelten Ansatz: die Anzahl der Funktionen reduzieren und die Dinge einfach halten. Um mit weniger Funktionen auszukommen, haben wir unsere Warenkorbseite so eingerichtet, dass ein Kunde je nach Inhalt seines Warenkorbs zur alten oder neuen Kasse geleitet wird. Auf diese Weise konnten wir die Implementierung komplexer Teile der Kaufabwicklung vermeiden, wie z.B. die Lieferung im Geschäft, die Bearbeitung großer Pakete und separater Sendungen sowie den Umgang mit eingeloggten Benutzern und mehreren Sprachen. Außerdem boten wir anfangs nur iDEAL und Kreditkartenzahlungen an. Die Funktionen, die wir entwickelt haben, waren jedoch voll funktionsfähig, einschließlich aller Sonderfälle. Mit diesem Ansatz waren wir in der Lage, in nur wenigen Monaten live zu gehen.

Geringere Reibung, verbesserte Leistung

Unser Hauptziel für den neuen Checkout war es, die Reibungsverluste für den Kunden zu reduzieren. Wir haben dies auf viele Arten erreicht:

• Vermeiden Sie das Neuladen von Seiten, indem Sie alles auf einer Seite statt auf 3 separaten Seiten unterbringen und die Versandkosten im laufenden Betrieb berechnen.
• Ändern Sie die Reihenfolge der Schritte, damit wir nicht nach Informationen fragen, die wir nicht immer benötigen (z.B. Telefonnummer) und erklären Sie, warum wir sie benötigen, wenn wir sie benötigen.
• Vergewissern Sie sich, dass der Browser die Formularfelder richtig ausfüllen kann, und machen Sie Vorschläge für mögliche Fehler, wie z. B. einen Tippfehler in der E-Mail-Adresse.
• Bieten Sie eine automatische Vervollständigung der Postleitzahl an, aber erlauben Sie auch die manuelle Eingabe der Adresse.
• Integrieren Sie direkt mit unserem Zahlungsdienstleister, um die Navigation zu einer externen Zahlungsseite zu vermeiden.
• Scrollen Sie das Ansichtsfenster automatisch, wenn es nötig ist, um Formularfelder anzuzeigen.
• Validieren Sie Benutzereingaben so schnell wie möglich und geben Sie verwertbare Fehlermeldungen aus.
• Stellen Sie ARIA-Hinweise für Bildschirmleser bereit und ermöglichen Sie die Tastaturnavigation.

Eine verbesserte Leistung war das zweite Ziel des Projekts, denn sie hat messbare Auswirkungen auf die Kundenzufriedenheit und letztlich auf die Konversion. Leider sind viele Teile des Prozesses schwer zu optimieren, und wir wollten das Backend nicht zu sehr anfassen. Wir haben uns stattdessen darauf konzentriert, die wahrgenommene Leistung zu verbessern. Das bedeutet, dass das Grundgerüst der Website so schnell wie möglich geladen werden sollte und Anzeichen von Fortschritt zeigt, während die Daten im Hintergrund geladen werden. Das Frontend ist im Wesentlichen eine statische Website, die für eine optimale Leistung vollständig über ein Content Delivery Network (CloudFront) bereitgestellt wird. Dies ist das von Google geförderte App-Shell-Modell.

Komponentengesteuerte Entwicklung

Der Webshop, den wir für Intergamma entwickelt haben, ist ein Whitelabel, das von zwei Marken in zwei Ländern genutzt wird. Das bedeutet, dass Sie das visuelle Branding der Website ändern und sie in mehreren Sprachen anbieten können. Um die Komplexität in den Griff zu bekommen, wurden die verschiedenen Teile des Webshops als separate Webanwendungen entwickelt, darunter Shopfront, Checkout und MyAccount. Um sicherzustellen, dass diese Teile ein einheitliches Ganzes bilden, verwenden wir viele Komponenten zwischen den Anwendungen wieder. Diese gemeinsam genutzten Komponenten werden separat als Teil eines Designsystems erstellt, das Storybook für die Entwicklung, Zusammenarbeit und Dokumentation verwendet. Die Komponenten werden in einer privaten npm-Registry veröffentlicht, damit sie von einer zentralen Stelle heruntergeladen werden können. Jede Komponente wird dynamisch thematisiert, um dem Markenerlebnis zu entsprechen, und je nach Benutzerpräferenz übersetzt. Ein großartiger Aspekt von Storybook ist die Möglichkeit, Komponenten isoliert zu erstellen, so dass sich die Entwickler auf die Entwicklung der Benutzeroberfläche konzentrieren können, ohne dass sie eine voll funktionsfähige Anwendung benötigen. Zunächst konzentrieren wir uns auf die Erstellung einzelner Komponenten, dann fügen wir sie zu einem größeren Ganzen zusammen - zunächst Abschnitte der Benutzeroberfläche, dann ganze Bildschirme. Bei der Entwicklung arbeiten wir mit Fake-Daten, um schneller iterieren und jeden Anwendungsfall abdecken zu können. Dieser Ansatz wird als komponentengesteuerte Entwicklung bezeichnet.

Live-Schaltung

Ein Teil unserer Strategie bestand darin, die neue Anwendung so schnell wie möglich zu veröffentlichen, damit wir frühzeitig mit dem Sammeln von Kundenfeedback beginnen konnten. Die einsatzfähige Anwendungsshell ist vollständig statisch - nur eine Reihe von JavaScript-Dateien und statischen Assets. Das hat große Vorteile: Das Hosten von Dateien auf AWS S3 ist kostengünstig und die Dateien werden über das CloudFront CDN bereitgestellt, damit sie so schnell wie möglich geladen werden. Wir mussten jedoch Lambda@Edge einrichten, um CORS- und CSP-Header dynamisch hinzuzufügen. Glücklicherweise ist dies alles mit Terraform aus unserer CI-Pipeline automatisiert, so dass keine manuelle Arbeit erforderlich ist. Wir haben die neue Anwendung parallel zur bestehenden Anwendung bereitgestellt und dynamisches Routing verwendet, um Kunden zur neuen oder zur bestehenden Anwendung zu leiten. Dies geschah auf der Grundlage einer Reihe vordefinierter Regeln, wie z.B. der Art der Produkte im Einkaufswagen und ob der Kunde angemeldet ist oder nicht. Auf diese Weise konnten wir Kunden mit "komplizierten" Warenkörben zur bestehenden Kasse leiten, während Kunden mit "einfachen" Warenkörben die Möglichkeit hatten, zur neuen Kasse geleitet zu werden. Auf diese Weise konnten wir in sehr kurzer Zeit mit nur einer Teilmenge an Funktionen live gehen.