Een voorwaardelijke configurator mag nooit eindigen met een verplichte keuze die de klant niet kan zien of bereiken. Bereken zichtbaarheid uit de actuele antwoorden, valideer alleen zichtbare vereisten en ruim waarden op die door een latere keuze ongeldig zijn geworden.
Voorwaarden maken een configurator korter en relevanter: pas bij “met verlichting” verschijnen kleurtemperatuur en bediening. Maar iedere verborgen afhankelijkheid creëert ook een risico. Een eerder gekozen optie kan verborgen blijven meetellen in prijs, of de server kan een onzichtbaar verplicht veld afkeuren. Beide breken vertrouwen.
Teken voorwaarden als beslisboom
Schrijf per groep op door welke eerdere antwoorden hij zichtbaar wordt. Houd regels eenvoudig: één of enkele expliciete voorwaarden zijn beter te testen dan een lange formule met uitzonderingen. Controleer of iedere route tot een geldig eindpunt leidt en of een klant terug kan zonder vast te lopen.
| Gebeurtenis | Verwacht gedrag | Niet doen |
|---|---|---|
| Groep wordt zichtbaar | Leg uit waarom en vraag keuze indien nodig | Automatisch dure standaardoptie kiezen |
| Groep wordt verborgen | Ongeldige waarde verwijderen of duidelijk bewaren | Verborgen prijs laten meetellen |
| Voorwaarde wijzigt terug | Veilig herstel volgens gedocumenteerde regel | Oude keuze willekeurig terugzetten |
| URL of browser manipuleert input | Server herberekent zichtbaarheid | Frontendstatus vertrouwen |
Beslis bewust of een verborgen keuze wordt gewist of tijdelijk onthouden. Onthouden kan prettig zijn wanneer iemand even terugklikt, maar mag prijs en order niet beïnvloeden zolang de groep verborgen is. Wis gevoelige of onverenigbare invoer direct. Zet deze regel in de productspecificatie, niet alleen in JavaScript.
Voorkom cirkels in beheer. Groep A mag niet via B uiteindelijk weer van A afhangen. Controleer nieuwe regels bij opslaan en geef een leesbaar pad van het conflict. Laat beheerders een productroute voorvertonen met voorbeeldantwoorden, zodat zij vóór publicatie zien welke groepen verschijnen en verdwijnen.
Valideer dezelfde boom op de server
De browser helpt de klant navigeren, maar de server bepaalt welke groepen voor de ingediende configuratie zichtbaar en vereist zijn. Bouw de zichtbaarheid opnieuw op uit bekende optie-ID’s. Negeer onbekende velden en wijs een zichtbare vereiste zonder geldige keuze af met een specifieke melding.
Laat foutmeldingen naar de juiste stap springen en de ontbrekende groep aankondigen. “Configuratie ongeldig” is onvoldoende. Benoem bijvoorbeeld: “Kies een bediening voor de geselecteerde verlichting.” Als een productregel inmiddels is gewijzigd, leg uit dat de configuratie opnieuw moet worden gecontroleerd.
Gebruik stabiele optie-identificaties onder de zichtbare labels. Een redacteur kan “Elektrisch” later wijzigen in “Motorbediening”, maar oude carts en orderregels moeten nog begrijpelijk blijven. Sla voor historische weergave naast de identificatie ook het label op dat tijdens bestellen zichtbaar was. Bij herstel blijft de actuele regel leidend.
Fictief voorbeeld: zonwering met motoroptie
Zonweringsbedrijf Lichtlijn vraagt eerst bediening: handmatig of elektrisch. Alleen bij elektrisch verschijnen motortype, stroomaansluiting en optionele afstandsbediening. Klant Mila kiest elektrisch en een afstandsbediening, maar gaat daarna terug naar handmatig.
De configurator verbergt de elektrische groepen en verwijdert motor en afstandsbediening uit de berekening. In de samenvatting staat alleen de handmatige uitvoering. Wanneer Mila opnieuw elektrisch kiest, moet ze de motor bewust bevestigen; de oude afstandsbediening verschijnt niet stil als betaald onderdeel. De server herhaalt dezelfde zichtbaarheidsberekening wanneer de cart wordt toegevoegd.
Als de definitieve onderdelen als aparte SKU’s naar voorraad of productie gaan, moet alleen de actuele zichtbare keuze worden doorgezet. Yindle Connect kan helpen die orderstructuur gecontroleerd naar andere systemen te vertalen.
Lichtlijn bekijkt na livegang welke routes vaak worden afgebroken. Een hoge uitval direct na het verschijnen van stroomaansluitingsvragen kan betekenen dat uitleg ontbreekt, niet dat klanten die optie niet willen. Het team verbetert eerst voorbeelden en hulptekst voordat het de technische voorwaarden verandert.
Routegerichte testset
- Test iedere hoofdroute van begin tot geldige samenvatting.
- Ga na iedere keuze één en meerdere stappen terug.
- Maak een zichtbare vereiste leeg en controleer focus en melding.
- Verberg een groep met een gekozen, geprijsde optie.
- Manipuleer onbekende of verborgen waarden in het request.
- Open een oude configuratie nadat voorwaarden zijn aangepast.
- Test mobiel, toetsenbord en schermlezer bij dynamisch verschijnen.
- Vergelijk zichtbare samenvatting, cartregels en orderdata.
Beperk het aantal uitzonderingen per release. Wanneer beheerders willekeurige voorwaarden kunnen stapelen, is een automatische cycluscontrole en een voorvertoning nodig. Begin liever met een klein ondersteund regelmodel dat volledig testbaar is. Voor afwijkende productlogica kan maatwerksoftware een stabieler alternatief zijn.
Bespreek met Yindle hoe jouw configurator iedere beslisroute geldig houdt.