Il progetto esplora come una barra di ricerca conversazionale possa aiutare gli utenti a passare da un bisogno espresso in linguaggio naturale alle informazioni BdM più pertinenti, senza sostituire il catalogo e senza trasformare il sito in un’esperienza chatbot-first.
Il prototipo interattivo si aprirà in una nuova scheda, così potrai esplorarlo senza perdere il case study.
L’ipotesi centrale è che il problema di accesso all’offerta non richieda necessariamente una nuova tassonomia. Il layer viene concepito come Single Page Application: l’utente resta nella stessa esperienza mentre contenuti, contesto e alternative vengono aggiornati dinamicamente, evitando una sequenza di ricaricamenti e cambi di pagina. La navigazione tradizionale, la documentazione e il supporto umano restano comunque disponibili.
Un access layer conversazionale tocca contenuti, processi, dati e canali di assistenza. Prima del design ho quindi esplicitato tempi, dipendenze e criteri di consenso: la soluzione doveva migliorare l’orientamento dell’utente senza promettere consulenza automatizzata o aggirare la governance bancaria.
Quattro sprint per passare dall’audit dell’ecosistema a un concept prototipato e a un piano di validazione comparativo.
Il layer è credibile solo se ogni attore mantiene il proprio perimetro: l’utente orienta la ricerca, la banca governa fonti e regole, le persone presidiano le decisioni complesse.
Il concept procede solo entro tre guardrail condivisi: contenuti ufficiali come unica fonte, domande limitate a ciò che cambia l’esito e passaggio a una persona quando la richiesta supera l’orientamento informativo.
L’audit del sito pubblico BdM non parte dall’idea che la struttura sia sbagliata. Segmenti, categorie e pagine prodotto sono necessari per organizzare un’offerta bancaria ampia. La frizione emerge quando il linguaggio dell’utente deve essere convertito autonomamente nella struttura del sito.
Privati, Partite IVA, Imprese, Corporate ed Enti e PA organizzano l’accesso per tipologia di cliente; all’interno, conti, carte, mutui, prestiti, risparmio e assicurazioni espongono l’offerta.
Pattern come “Vorrei…” e i strumenti di selezione prodotto indicano che l’intenzione dell’utente è già riconosciuta come punto di accesso. Il concept rende questa logica più continua e contestuale.
Invece di ridisegnare l’intera information architecture, il concept introduce un livello intermedio che traduce l’intenzione dell’utente nella struttura già esistente.
Un bisogno concreto, ancora privo di categorie e nomi prodotto.
Prima casa, green, ristrutturazione, tasso, priorità o necessità di consulenza.
Il sistema collega il contesto a prodotti, pagine informative e documenti esistenti.
Approfondire, confrontare, leggere condizioni o parlare con una persona.
Il progetto evita un modello centrato esclusivamente sulla chat. L’utente può esplorare autonomamente, chiedere aiuto quando serve e passare a un consulente quando la decisione richiede competenza o valutazione personale.
La navigazione tradizionale resta disponibile per chi conosce già il prodotto o vuole esplorare in autonomia.
La barra di ricerca apre una conversazione che interpreta il bisogno, pone poche domande e restringe progressivamente l’offerta.
Quando serve una valutazione personale, la conversazione prepara il contesto e indirizza verso i canali umani appropriati.
La proposta usa un modello SPA per aggiornare dinamicamente la stessa interfaccia invece di spostare l’utente attraverso una lunga catena di pagine. Questo permette di mantenere visibili il contesto della richiesta, le alternative già esplorate e il prossimo passo, riducendo interruzioni e ripartenze cognitive. Dal punto di vista tecnico, MDN definisce una SPA come un’applicazione che carica un singolo documento web e ne aggiorna il contenuto senza ricaricare intere nuove pagine.
Questo sostiene la scelta architetturale di mantenere l’utente nello stesso ambiente e preservare lo stato dell’interazione mentre cambia il contenuto mostrato.
MDN · Single-page application ↗Lo studio “Milliseconds Make Millions”, riportato da web.dev, ha osservato migliori tassi di progressione nel funnel mobile dopo miglioramenti di 0,1 secondi nelle metriche di velocità misurate. Non dimostra che una SPA sia sempre più veloce, ma rafforza l’importanza di limitare attese e ricaricamenti percepiti.
web.dev · Milliseconds Make Millions ↗Nella ricerca “Battle to Onboard 2022”, Signicat riporta che tra le principali ragioni di abbandono delle richieste di prodotti finanziari figurano il tempo necessario e la quantità di informazioni richieste. È un contesto diverso dalla semplice product discovery, ma rende credibile l’ipotesi che ridurre attrito e durata percepita possa incidere sul drop-off.
Signicat · Battle to Onboard ↗McKinsey sottolinea che le iniziative digitali funzionano meglio quando progettano il journey end-to-end sulla base dei bisogni del cliente, invece di ottimizzare singoli touchpoint. In un altro benchmark, lo “shopping” di nuovi prodotti bancari risultava tra i journey meno soddisfacenti.
McKinsey · Consumer banking journeys ↗In un contesto bancario, il valore non è generare testo libero. È decidere quali contenuti mostrare, in quale ordine e con quale livello di dettaglio, mantenendo le fonti BdM come riferimento.
“Comprare casa”, “gestire le spese”, “finanziare un progetto” o “mettere da parte risparmi” diventano intent più utili dei nomi commerciali.
Ogni domanda deve modificare la shortlist, la spiegazione o il prossimo passo. Niente profiling non necessario.
Prodotti, servizi, condizioni e documenti vengono recuperati dal catalogo BdM e ordinati per pertinenza.
Approfondire, confrontare, consultare il documento, prenotare un contatto o continuare la conversazione.
La strategia estende il layer oltre la semplice ricerca conversazionale. Nei momenti in cui l’utente sta valutando un prodotto parametrico, ad esempio mutuo o prestito, la conversazione può proporre un simulatore direttamente nella stessa Single Page Application. L’utente ottiene una risposta più concreta; la banca, in forma aggregata e nel rispetto della privacy, può osservare quali bisogni vengono esplorati con maggiore frequenza e dove si concentra l’interesse.
Un simulatore riduce la distanza tra “mi interessa un mutuo” e “quale scenario dovrei approfondire?”. Importo, durata, finalità o preferenza di tasso possono essere esplorati senza uscire dalla pagina e senza trasformare subito l’interesse in una richiesta commerciale.
Il numero di simulazioni avviate, le categorie selezionate, gli scenari completati e il passaggio successivo possono diventare indicatori aggregati dell’interesse verso famiglie di prodotto o servizi. Non equivalgono alla domanda commerciale effettiva, ma possono integrare altri dati per capire dove approfondire offerta, contenuti e campagne.
L’utente manifesta un bisogno: casa, liquidità, risparmio, carta, protezione.
Il layer propone solo i parametri utili a costruire uno scenario informativo.
Gli eventi di utilizzo vengono analizzati per categoria e comportamento, non come profilo individuale.
La banca può individuare aree di interesse da approfondire con ricerca, contenuti o iniziative commerciali.
Esempi di segnali aggregati che possono supportare analisi UX, contenuto e prodotto senza essere interpretati automaticamente come intenzione di acquisto.
I dati dei simulatori dovrebbero essere interpretati come segnali comportamentali aggregati, da incrociare con ricerca qualitativa, richieste commerciali e dati di conversione. Non sarebbe corretto concludere che il prodotto più simulato sia automaticamente quello con maggiore domanda reale. La strategia serve a generare evidenze e ipotesi migliori, non a sostituire l’analisi di mercato.
Banca d’Italia rileva investimenti degli intermediari in strumenti digitali e in soluzioni che consentono l’analisi di grandi quantità di dati relativi alla clientela per personalizzare prodotti e servizi. Questo sostiene l’idea di trattare le interazioni digitali come input strategico, con adeguata governance.
Banca d’Italia · Indagine Fintech 2025 ↗Il rapporto congiunto delle Autorità europee sui Big Data identifica tra i benefici per il settore finanziario prodotti e servizi più personalizzati e procedure interne più efficienti, sottolineando allo stesso tempo la necessità di gestire i rischi per i consumatori.
EBA · Big Data nel settore finanziario ↗Le pagine ufficiali BdM espongono parametri come durata, importo finanziabile, tasso e finalità. Un simulatore può tradurre queste variabili in scenari progressivi senza costringere l’utente a leggere e confrontare ogni configurazione manualmente.
BdM · Mutuo con CAP ↗My Credit Sprint presenta ufficialmente intervalli di importo e durata. Queste variabili possono alimentare un simulatore informativo e, in forma aggregata, fornire segnali su quali scenari interessano maggiormente gli utenti.
BdM · My Credit Sprint ↗Ogni turno deve ridurre ambiguità o portare l’utente più vicino a un’azione utile.
Partire da ciò che l’utente vuole ottenere, non dal prodotto che pensa di dover cercare.
Una domanda è giustificata solo se cambia la shortlist, la spiegazione o il prossimo passo.
Ogni opzione mostrata deve includere una breve motivazione comprensibile.
Catalogo, confronto e ritorno indietro restano sempre disponibili.
Orientamento informativo e consulenza personale devono essere distinti nel linguaggio e nelle CTA.
Quando serve una persona, il sistema sintetizza obiettivo, contesto e ciò che è già stato esplorato.
La trasparenza su fonti, limiti e passaggio al supporto umano deve essere una proprietà dell’esperienza, non una nota aggiunta alla fine.
Usare contenuti provenienti da pagine, schede prodotto e documenti ufficiali BdM.
Non generare condizioni, costi, disponibilità o requisiti mancanti.
Raccogliere solo il contesto necessario alla discovery.
Non simulare accesso a saldo, movimenti o profilo cliente senza autenticazione.
Presentare alternative, differenze e documentazione.
Non trasformare una shortlist informativa in raccomandazione finanziaria automatica.
Preparare un handoff contestualizzato verso filiale, telefono o consulente.
Non simulare appuntamenti o tempi di risposta non realmente integrati.
La validazione combina una survey esplorativa sui comportamenti recenti e cinque sessioni qualitative sul prototipo. Sentimento, bisogni e journey vengono messi in relazione con ciò che le persone fanno durante i task.
Nota metodologica: campioni, risposte, citazioni, tempi e risultati qui riportati sono interamente fittizi e costruiti per illustrare il metodo. Non sono ricerche svolte né risultati di business misurati.
Come passano gli utenti da un bisogno quotidiano a un prodotto bancario pertinente, e dove perdono chiarezza su documenti, condizioni e contatto umano?
Questionario esplorativo di 8–10 minuti, prima di mostrare il concept. Una domanda per volta, linguaggio semplice, opzioni bilanciate e “Altro”, “Non ricordo” o “Non applicabile” dove pertinenti. Due compilazioni pilota simulate verificano comprensione e ordine delle domande.
Campione simulato: 40 persone che hanno cercato informazioni bancarie online negli ultimi 3 mesi: 16 clienti BdM e 24 non clienti; 12 con bassa, 18 con media e 10 con alta familiarità digitale. Reclutamento ipotetico tramite community locali e panel; campione di convenienza, non rappresentativo.
| Domanda neutrale | Formato |
|---|---|
| Quali informazioni bancarie hai cercato l’ultima volta e quando? | Risposta aperta + filtro ultimi 3 mesi |
| Da quale canale sei partito e quali passaggi hai seguito? | Sequenza di touchpoint + Altro |
| In quale passaggio hai incontrato la maggiore difficoltà? | Scelta singola + Nessuna difficoltà |
| Hai trovato ciò che cercavi, interrotto o contattato una persona? | Scelta singola |
| Quanto ti sei sentito incerto durante la ricerca? | Scala 1 = per nulla, 5 = molto |
| Quanto erano comprensibili le informazioni su costi e condizioni? | Scala 1 = per nulla, 5 = del tutto |
| Quali informazioni o possibilità ti mancavano? Seleziona al massimo tre opzioni. | Scelta multipla, massimo 3 + Altro |
| Che cosa hai fatto dopo la difficoltà? | Scelta singola + Altro |
| Racconta un episodio concreto: cosa volevi capire e cosa ti ha ostacolato? | Risposta aperta facoltativa |
Opzioni Q3: ricerca, categorie, pagina prodotto, documentazione, contatto. Q7: costi comparabili, requisiti, glossario, documenti ufficiali, contatto umano. Q8: altra pagina, motore di ricerca, telefono/filiale, rinuncia.
| Dimensione | Conteggio e quota | Lettura |
|---|---|---|
| Sentimento | 25/40 (62,5%) | Incertezza 4–5 su 5 durante la ricerca precedente. |
| Bisogni · risposte multiple | 29/40 (72,5%); 27/40 (67,5%) | Costi comparabili; contatto umano. I gruppi possono sovrapporsi. |
| Journey · punto di attrito | 21/40 (52,5%) | Pagina prodotto come passaggio più difficile. |
| Journey · esito | 18 + 9 + 13 = 40 | 18 trovano informazioni, 9 interrompono, 13 contattano una persona. |
Analisi prevista: frequenze delle risposte chiuse, codifica tematica delle risposte aperte e ricostruzione dei touchpoint. I conteggi descrivono soltanto il campione simulato: nessuna inferenza sulla popolazione o sulla superiorità del concept.
Cinque partecipanti fittizi, selezionati per varietà di esperienza e familiarità digitale, non per rappresentatività statistica. Sessioni individuali moderate da 60 minuti: 5 min di introduzione e consenso; 10 min di intervista sull’ultimo episodio; 30 min di task; 10 min di ricostruzione della journey e approfondimento; 5 min di chiusura.
Protocollo: domande aperte e non suggestive, pensiero ad alta voce, nessuna indicazione sul bottone da usare. Un moderatore conduce e un osservatore annota azioni, errori, esitazioni, aiuti e citazioni. Usare solo dati di prova; registrare solo con consenso. Distinguere fatti osservati, interpretazioni e idee di soluzione.
Criterio di completamento: raggiungere l’obiettivo e spiegarlo correttamente. A = autonomo; H = completato con aiuto del moderatore; F = non completato entro il tempo assegnato. Tempi in minuti; includono esitazioni. Tutti gli esiti della tabella sono simulati sul concept, senza confronto A/B.
| Profilo | T1 · esito/min | T2 · esito/min | T3 · esito/min | T4 · esito/min |
|---|---|---|---|---|
| P1 · 25 anni, non cliente, alta familiarità | A · 4 | A · 6 | A · 5 | A · 3 |
| P2 · 34 anni, cliente, media familiarità | A · 5 | A · 7 | H · 7 | A · 4 |
| P3 · 48 anni, non cliente, bassa familiarità | H · 7 | H · 8 | F · 8 | A · 5 |
| P4 · 39 anni, non cliente, media familiarità | A · 4 | A · 6 | A · 6 | A · 4 |
| P5 · 61 anni, cliente, bassa familiarità | A · 6 | F · 9 | H · 8 | H · 6 |
P2, P5 · non riconoscono subito il collegamento ai documenti su T3; P3 non li trova.
P3 · richiede aiuto sul mutuo; P5 scambia il risultato simulato per una condizione garantita.
P5 · cerca il contatto nella conversazione; T4 richiede un aiuto.
P5: “Questo importo è già quello che mi darà la banca?”
Bisogno → motore di ricerca/sito → categorie o domanda → prodotto → documenti → consulente. L’incertezza cresce tra proposta e condizioni; il passaggio umano deve mantenere il contesto della ricerca.
Dopo ogni sessione: sintesi immediata, note indicizzate per partecipante e task, clustering tematico e revisione dei casi contrari. La triangolazione collega survey, osservazioni e journey senza sommare campioni o confondere preferenze con prestazioni.
| Priorità | Evidenza | Iterazione e verifica |
|---|---|---|
| Alta · documentazione | Survey: 29/40 chiedono costi comparabili; T3: 2 autonomi, 2 con aiuto, 1 fallisce. | Affiancare documenti ufficiali e dati mancanti alle schede; ritestare reperibilità e comprensione. |
| Alta · limiti della simulazione | T2: P3 necessita aiuto; P5 non distingue stima e condizioni effettive. | Esplicitare ipotesi e limiti vicino al risultato; verificare la comprensione con una domanda aperta. |
| Media · passaggio umano | Survey: 27/40 desiderano contatto umano; T4: P5 necessita aiuto. | Rendere persistente il contatto e mostrare un riepilogo del bisogno; ritestare il prossimo passo. |
Limiti e seguito: cinque sessioni servono a esplorare criticità, non a stimare tassi di successo della popolazione. Le modifiche sopra sono proposte, non miglioramenti già misurati. Il ciclo successivo richiede partecipanti reali, consenso, un prototipo aggiornato e un confronto controllato per valutare eventuali differenze rispetto al percorso attuale.
Riferimento metodologico: This is Service Design Doing, schede “Interview Guidelines” (p. 23), “In-depth Interview” (pp. 24–26) e “Interactive Click Modeling” (pp. 143–145), numerazione stampata. La survey è un adattamento progettuale: il documento non contiene un questionario standard da replicare.
Il contributo del concept è collegare linguaggio dell’utente, struttura informativa della banca e supporto umano in un percorso più continuo, senza perdere trasparenza e controllo.
L’utente può partire dal proprio obiettivo senza conoscere prima categorie, nomi commerciali o percorsi interni.
La banca può comprendere meglio il motivo della visita, osservare in forma aggregata quali simulazioni e categorie generano maggiore interesse e preparare passaggi al supporto umano più contestualizzati.
Il sistema aggiunge una modalità d’accesso complementare e single-page: ricerca, chiarimento e contenuti pertinenti restano nello stesso ambiente, senza sostituire il sito esistente.