Headless-Shop: Welche Kundentätigkeit rechtfertigt den Aufwand?
Eine eigene Shopoberfläche braucht einen konkreten Zweck. Ein Beispielszenario trennt Markenauftritt, besondere Kaufwege und laufenden Betrieb.
Die Entscheidung für einen Headless-Shop sollte an einer konkreten Kundentätigkeit hängen. Wenn ein passendes Theme den Kaufweg bereits abbilden kann, muss eine eigene Oberfläche einen zusätzlichen Nutzen begründen. Ein gewünschter neuer Markenauftritt ist zunächst ein Gestaltungsauftrag.
Was die Trennung verändert
Headless trennt die sichtbare Shopoberfläche vom Handelssystem im Hintergrund. Die eigene Oberfläche nutzt Schnittstellen, etwa für Produkte und Warenkorb. Dafür kann weiterhin eine gemeinsame Handelsplattform zuständig sein. Ein vollständig aus mehreren Spezialdiensten zusammengesetztes System ist eine weitere Architekturentscheidung.
Die Gestaltungsfreiheit bringt Arbeit an der eigenen Oberfläche mit sich: Bereitstellung, Abhängigkeiten und Änderungen müssen betreut werden. Shopify nennt deshalb sowohl Grenzen vorhandener Themes und Apps als auch die nötige Entwicklung und Wartung als Entscheidungspunkte.
Ein überschaubarer Katalog als Ausgangspunkt
Ein fiktiver Bürobedarfshändler plant einen neuen Shop. Der zunächst bekannte Bedarf umfasst Katalog, Produktseiten und Einkauf; der Markenauftritt soll erneuert werden. Eine raumbezogene Projektliste ist eine zusätzliche hypothetische Anforderung, kein bereits bestätigter Bedarf.
Fall | Zuerst klären | Folge für die Entscheidung |
|---|---|---|
Neuer Markenauftritt | Schrift, Bilder und Navigation in einem passenden Theme erproben | Noch keine belegte Funktionslücke für eine getrennte Oberfläche |
Raumbezogene Projektliste | Artikel je Raum sammeln, Liste speichern und später kaufen; vorhandene Erweiterungen prüfen | Eigene Oberfläche weiter untersuchen, wenn eine relevante Lücke belegt wird |
Wartung nur gelegentlich verfügbar | Wer Änderungen und Störungen der eigenen Oberfläche übernimmt | Vor Umsetzung verlässliche Betreuung schaffen oder Vorhaben zurückstellen |
Damit ist Headless im Basisszenario noch nicht begründet. Für die Projektliste könnte die Bewertung anders ausfallen, wenn Standardfunktionen und geeignete Erweiterungen den beschriebenen Vorgang nicht ausreichend unterstützen. Dann wäre an einem Prototyp zu zeigen, welchen Teil die eigene Oberfläche besser löst.
Der Betrieb reicht über die Produktseite hinaus
Auch eine getrennte Oberfläche muss ausgewählte Artikel richtig in den Warenkorb übernehmen und den vorgesehenen Checkout erreichen. Kundenanmeldung und die dort erlaubten Ansichten gehören zum Gesamtvorgang. Ändert sich eine Schnittstelle, kann eine optisch unveränderte Seite trotzdem fehlerhaft arbeiten.
Der Händler müsste deshalb festlegen, wie Produktänderungen in Vorschau und veröffentlichter Ansicht kontrolliert werden und wer eine Störung an der Übergabe zum Checkout untersucht. Das ist zusätzliche Zuständigkeit für diese Architektur; sie lässt sich nicht aus einem Designentwurf ablesen.
Ein Vergleichsentwurf sollte denselben Kundenvorgang in Theme und eigener Oberfläche zeigen, einschließlich einer geänderten Produktangabe. Liegt der Unterschied nur in Farben und Abständen, bleibt das Theme ein passender Ausgangspunkt. Belegt der Prototyp dagegen eine benötigte, bisher nicht ausreichend unterstützte Tätigkeit, lässt sich der zusätzliche Betrieb gegen diesen konkreten Nutzen abwägen.
Quellen
Weiterlesen
Alle Beiträge
E-Commerce mit ASES
Onlineshops, Marktplätze und B2B-Portale