Headless winkel: welke klanttaak rechtvaardigt het werk?
Een eigen winkelinterface vraagt een concreet doel. Een voorbeeld scheidt merkuitstraling, bijzondere koopprocessen en dagelijks beheer.
De keuze voor een headless winkel hoort af te hangen van een concrete klanttaak. Als een passend thema het koopproces al ondersteunt, moet een eigen interface een extra voordeel rechtvaardigen. Een gewenste nieuwe merkuitstraling is aanvankelijk een ontwerpopdracht.
Wat de scheiding verandert
Headless scheidt de zichtbare winkelinterface van het achterliggende handelssysteem. De eigen interface gebruikt koppelingen, bijvoorbeeld voor producten en winkelmand. Eén handelsplatform kan deze functies nog steeds leveren. Het hele systeem uit gespecialiseerde diensten samenstellen is een verdere architectuurkeuze.
Ontwerpvrijheid brengt werk aan de eigen interface mee: ingebruikname, afhankelijkheden en wijzigingen vragen onderhoud. Shopify noemt daarom zowel de grenzen van bestaande thema’s en apps als de nodige ontwikkeling en het onderhoud als beslispunten.
Een overzichtelijke catalogus als uitgangspunt
Een fictieve kantoorartikelenhandelaar plant een nieuwe winkel. De aanvankelijk bekende behoefte omvat catalogus, productpagina’s en kopen; de merkuitstraling moet worden vernieuwd. Een projectlijst per ruimte is een aanvullende hypothetische eis, geen bevestigde behoefte.
Geval | Eerst uitzoeken | Gevolg voor de keuze |
|---|---|---|
Nieuwe merkuitstraling | Lettertype, beelden en navigatie in een passend thema proberen | Nog geen aangetoonde functionele leemte voor een afzonderlijke interface |
Projectlijst per ruimte | Artikelen per ruimte verzamelen, lijst opslaan en later kopen; bestaande uitbreidingen onderzoeken | Eigen interface verder onderzoeken als een relevante leemte aantoonbaar is |
Onderhoud slechts af en toe beschikbaar | Wie wijzigingen en storingen van de eigen interface oppakt | Vóór uitvoering betrouwbare ondersteuning regelen of het project uitstellen |
In het basisscenario is headless dus nog niet onderbouwd. Voor de projectlijst kan de afweging veranderen als standaardfuncties en passende uitbreidingen de beschreven taak onvoldoende ondersteunen. Een prototype moet dan laten zien welk deel de eigen interface beter oplost.
Het beheer gaat verder dan de productpagina
Ook een aparte interface moet gekozen artikelen juist in de winkelmand overnemen en de beoogde checkout bereiken. Klantinlog en de daar toegestane weergaven horen bij het hele proces. Als een koppeling verandert, kan een visueel ongewijzigde pagina toch verkeerd werken.
De handelaar moet daarom bepalen hoe productwijzigingen in voorbeeldweergave en gepubliceerde versie worden gecontroleerd en wie storingen bij de overdracht naar checkout onderzoekt. Deze architectuur voegt verantwoordelijkheid toe die een ontwerp niet aantoont.
Een vergelijkend prototype moet dezelfde klanttaak in thema en eigen interface tonen, inclusief een gewijzigd productgegeven. Verschillen alleen kleuren en afstanden, dan blijft het thema een passend uitgangspunt. Toont het prototype een nodige, eerder onvoldoende ondersteunde taak aan, dan is het extra beheerwerk tegen dat concrete voordeel af te wegen.
Bronnen
Verder lezen
Alle artikelen
E-commerce met ASES
Webshops, marktplaatsen en B2B-portalen