Fin dall’inizio, il lavoro è stato impostato come un programma pluriennale con una governance chiara, anziché come una serie di iniziative isolate. Il cliente ha nominato un team centrale di sei membri provenienti da operations, digital product, engineering e finance. Si occupavano di coordinare le questioni quotidiane, gestire l’accesso alle stazioni e allineare i responsabili locali.

Al di sopra di questo gruppo, un comitato di indirizzo composto da cinque dirigenti si riuniva in corrispondenza di milestone definite. Il gruppo esaminava i risultati della ricerca, prendeva decisioni sulla direzione architetturale e risolveva i compromessi tra efficienza operativa, conformità normativa e strategia tecnologica di lungo periodo. Il loro coinvolgimento ha garantito che le decisioni sui flussi POS, sui terminali esterni e sull’integrazione in-vehicle non fossero trattate come semplici aggiustamenti locali.

Il programma è stato suddiviso in stream con una sequenza chiara. Il redesign dei workflow POS è durato sei mesi e ha costituito la base per il lavoro successivo. Lo stream dedicato ai terminali di pagamento esterni si è esteso per sette mesi e si è basato sulle lezioni apprese dalle modifiche al POS. L’applicazione CarPlay è stata progettata in due mesi, una volta testate le ipotesi di integrazione. Altre attività come il journey mapping, la definizione del concept mobile e il consolidamento del Design System si sono svolte trasversalmente a questi stream.

Questa struttura ha creato punti di revisione prevedibili e ha permesso al cliente di pianificare le risorse di sviluppo. Ha inoltre reso più semplice garantire che le decisioni prese per un canale non fossero in contrasto con quelle di un altro. In pratica, questo è essenziale per una multi-channel user experience che possa essere governata, anziché semplicemente rattoppata.

Il programma è iniziato con attività sul campo in sette stazioni dell’area di Zurigo attraverso Sandbox Experiments. Nell’arco di una settimana, il team ha svolto quaranta ore di osservazione strutturata e ha documentato 532 transazioni in diversi momenti della giornata e condizioni di traffico. L’obiettivo era comprendere come il lavoro venga svolto realmente e dove i sistemi digitali aiutino o ostacolino.

I ricercatori hanno osservato trentasei cassieri durante le operazioni dal vivo. Si sono concentrati sulla frequenza con cui il personale passava dalla modalità carburante a quella negozio, su come navigavano la logica di sconti e fidelizzazione e su dove si affidavano alla memoria invece che alle indicazioni a schermo. Questo lavoro è stato integrato da ventiquattro interviste con cassieri, responsabili di turno e tirocinanti. La ricerca si è svolta in tedesco, favorendo una comunicazione diretta e una raccolta precisa della terminologia specifica del settore.

Le transazioni sono state codificate per tipologia e complessità. Il team ha individuato pattern in cui il personale saltava regolarmente dei campi, reinseriva i dati per correggere errori o attendeva le risposte del sistema mentre le code aumentavano. Questi pattern sono stati poi utilizzati come evidenza per cambiamenti architetturali.

L’approccio ha combinato interviste, contextual inquiry e codifica quantitativa. L’intento non era raccogliere storie, ma costruire un dataset strutturato per la user research nelle retail operations. Questo ha creato una base per una evidence based UX nel retail, discutibile in modo trasparente con gli stakeholder di operations ed engineering.

Una volta definito il corpus di ricerca, il team ha costruito modelli di journey che descrivevano il comportamento sia dei clienti sia del personale attraverso i diversi canali. L’attenzione non era rivolta ai journey di marketing, ma a sequenze operative rilevanti che iniziano con l’arrivo alla stazione e terminano con il pagamento completato e l’assegnazione della fidelizzazione.

Per i clienti, la mappatura ha rilevato come gli automobilisti sceglievano la stazione, come si avvicinavano al piazzale, come selezionavano la pompa e come combinavano il rifornimento con gli acquisti in negozio. Per il personale, la mappatura ha documentato la gestione delle code, delle transazioni miste, delle eccezioni come le carte rifiutate e della riconciliazione di fine turno.

Ogni journey è stato suddiviso in passaggi discreti con i relativi trigger, stati di sistema e condizioni ambientali. Questo ha permesso al team di individuare dove la logica dei sistemi digitali divergeva dalla logica del lavoro reale. Ad esempio, alcuni flussi richiedevano ai cassieri di passare più volte da una schermata all’altra per tipologie di transazioni che si verificano spesso nei momenti di punta.

I modelli descrivevano anche le transizioni tra i canali. Un conducente poteva arrivare tramite la navigazione in-vehicle, autorizzarsi al terminale esterno e poi entrare in negozio per completare un acquisto combinato. Il personale aveva bisogno di informazioni coerenti lungo tutte queste fasi. Definendo chiaramente queste strutture, il team ha preparato il terreno per il redesign del sistema POS e ha garantito che le modifiche in un canale non creassero nuove incoerenze in un altro.

Lo stream POS si è concentrato sui sistemi di cassa, poiché supportano il carico operativo più elevato. Partendo dai modelli di journey, il team ha catalogato i tipi di transazione e li ha raggruppati in base a frequenza e complessità. Questo includeva percorsi separati per solo carburante, carburante combinato con acquisti in negozio, riscatti di voucher, operazioni di fidelizzazione e gestione delle eccezioni.

Sedici architetture POS alternative sono state modellate tramite option space mapping. Ogni opzione riorganizzava il modo in cui le azioni venivano raggruppate e le informazioni presentate in relazione alle sequenze di attività. L’obiettivo era ridurre la navigazione superflua, limitare i cambi di modalità e rendere più coerente la gestione degli errori. Il team ha confrontato ogni opzione con il dataset osservato di 532 transazioni per valutare quanto spesso una determinata struttura coprisse i percorsi più comuni.

Sei concept sono stati selezionati per la prototipazione. Questi prototipi sono stati realizzati a livello di wireframe su schermi che rispecchiavano il layout a 1920 x 1080 pixel dei registratori di cassa reali. Ventinove sessioni di test, distribuite sui vari stream, hanno incluso una valutazione strutturata dei prototipi con cassieri e supervisori. Il feedback si è concentrato su velocità, chiarezza nell’ordine delle attività e allineamento con le routine di riconciliazione.

La soluzione risultante non puntava sulla novità. Ha riorganizzato i flussi in modo che le operazioni più comuni richiedessero meno passaggi e meno transizioni mentali, rispettando al contempo i vincoli dell’hardware esistente attraverso il constraint respecting. È qui che il point of sale UX conta davvero per il retail operations UX, non in elementi di interfaccia isolati.

Il lavoro di test ha prodotto diversi insight concreti che spiegavano perché le configurazioni precedenti faticassero sotto carichi di punta. I cassieri avevano sviluppato scorciatoie personali per compensare i problemi di layout. Queste scorciatoie funzionavano per il personale esperto, ma rendevano più difficile la formazione dei nuovi dipendenti. Le sequenze di correzione degli errori osservate hanno mostrato che piccole incoerenze nell’ordine dei campi causavano ritardi sproporzionati quando le code erano lunghe.

Durante i test, i cassieri hanno reagito positivamente quando le sequenze seguivano la logica interna del loro lavoro piuttosto che la struttura dei software legacy. Hanno evidenziato i miglioramenti nei casi in cui il sistema rispecchiava il modo in cui pensano alla combinazione di carburante, articoli di negozio e azioni di fidelizzazione. I supervisori hanno sottolineato che flussi più prevedibili rendono più facile mantenere il controllo nei periodi di maggiore affluenza, riducendo il numero di casi speciali che richiedono interventi.

Il team ha utilizzato questo feedback per perfezionare l’architettura finale attraverso il tension-driven reasoning. Sono state apportate modifiche al raggruppamento delle azioni, al posizionamento delle informazioni chiave e alla gestione delle rare eccezioni che comportano alti costi operativi se gestite in modo scorretto. Queste decisioni sono state documentate in modo da poter essere discusse con il team di engineering in termini precisi.

Attraverso questo processo, il redesign del POS ha stabilito un modello affidabile per i cassieri e ha creato un riferimento per i canali correlati. Ha inoltre fornito al comitato di indirizzo del cliente una dimostrazione concreta di come decisioni strutturate possano derivare dall’evidenza sul campo e tradursi in cambiamenti a livello di sistema nel retail operations UX.

Sia per le casse interne sia per i terminali esterni, il progetto doveva operare entro i limiti dell’hardware esistente. Il cliente non stava sostituendo i dispositivi, quindi il lavoro di progettazione non poteva basarsi su upgrade come schermi più grandi o processori più veloci. Questo ha reso l’embedded system UX una considerazione esplicita, anziché un dettaglio secondario.

Le risoluzioni dei display di 1920 x 1080 pixel per le casse e di 1024 x 768 pixel per i dispositivi esterni sono state trattate come parametri fissi. Il team ha misurato i tempi di risposta tipici delle operazioni principali e ha individuato sequenze specifiche in cui la latenza del sistema influenzava i modelli di interazione. Ad esempio, i ritardi tra autorizzazione e conferma hanno portato i cassieri a utilizzare workaround che hanno reso più complessi la formazione e la documentazione.

Le decisioni di design miravano a ridurre la dipendenza da sequenze sensibili alla latenza. Quando le schermate richiedevano informazioni più estese, la struttura privilegiava la chiarezza rispetto alla densità. Per l’hardware embedded non si tratta di una scelta estetica, ma di un modo per evitare di superare i limiti pratici di interazione sotto carico.

Queste considerazioni sono state documentate per i team di engineering, in modo che potessero comprendere perché determinate configurazioni o pattern di interazione fossero raccomandati. L’obiettivo era garantire che l’implementazione non reintroducesse modelli che sembrano efficienti in teoria, ma causano problemi in condizioni operative reali.

Con la maturazione degli stream, il team ha consolidato i pattern in un unico Design System che copriva casse, terminali esterni, CarPlay e il concept mobile. Il sistema includeva definizioni dei componenti, regole di interazione e note d’uso, strutturate per canale e per pattern condiviso. L’obiettivo era supportare sia l’implementazione attuale sia l’evoluzione futura.

La documentazione chiariva quali elementi fossero comuni tra i dispositivi e quali specifici per una determinata piattaforma. Ad esempio, gli stati dei pulsanti, le scelte tipografiche di base e alcuni pattern di presentazione dei dati rimanevano coerenti. Altri aspetti, come le griglie di layout e i modelli di interazione, si adattavano ai vincoli di ciascuna classe di dispositivo e al contesto d’uso.

Gli sviluppatori hanno ricevuto asset allineati alla loro toolchain esistente. Il team di design ha partecipato alle sessioni di implementazione regolari per chiarire i comportamenti e risolvere le domande sugli edge case durante l’Implementation Partnership. Questo ha ridotto il rischio di divergenze tra il comportamento previsto e quello effettivo, soprattutto nella gestione degli errori e nelle transizioni di stato.

Il Design System può essere descritto come un Design System per applicazioni retail che devono operare su terminali embedded e in ambienti connessi. Il suo scopo non è solo il branding visivo, ma un processo decisionale ripetibile che i team di prodotto ed engineering possono applicare quando estendono o adattano l’ecosistema.

L’applicazione CarPlay copriva una parte diversa del journey. Doveva supportare la scoperta delle stazioni vicine, la guida verso il piazzale e l’identificazione della pompa corretta dopo l’arrivo. Allo stesso tempo doveva rispettare le regole della piattaforma che limitano la distrazione del conducente e le normative locali sul comportamento durante il rifornimento.

Il team ha definito scenari d’uso in cui i conducenti si avvicinano alla stazione, ricevono indicazioni entrando nel piazzale e confermano la pompa presso cui si fermano. Le sequenze di interazione sono state mantenute brevi. Dove possibile, il design ha privilegiato comandi vocali e semplici conferme rispetto a una navigazione complessa nei menu. Questo riflette la disciplina richiesta dall’automotive UX design, piuttosto che i pattern tipici delle app consumer.

Il lavoro di integrazione si è concentrato sull’identificazione coerente delle pompe e sull’autorizzazione sicura. L’applicazione doveva comunicare con il back end esistente affinché lo stato delle pompe e dei pagamenti rispecchiasse la realtà del piazzale. Le sessioni di test con i conducenti hanno analizzato quanto chiaramente l’app comunicava questi stati e quanto la logica corrispondesse alle aspettative.

La struttura risultante ha costituito la base dell’UX dell’app CarPlay per questo cliente. Era allineata, in linea di principio, ai flussi definiti per i terminali esterni e le casse, rispettando al contempo i vincoli più rigidi delle interfacce in-vehicle. Questo canale ha poi influenzato altre parti dell’ecosistema ogni volta che i conducenti si avvicinavano alla stazione tramite il veicolo anziché tramite strumenti di navigazione indipendenti.