La nostra esperienza nel design di applicazioni del mondo bancario: alcuni pattern di processo

In alcuni dei progetti a cui lavoriamo, oramai da anni ci imbattiamo in una bella sfida progettuale: facilitare la consulenza e la vendita, da parte di broker finanziari, di prodotti e servizi bancari attraverso un applicativo. Ed è così che nel tempo abbiamo raggiunto una buona preparazione per far fronte ad un iter che non si presenta sempre allo stesso modo.

Essendo situazioni eterogenee fra loro, l’approccio che ci aiuta in ogni caso si basa sull’interazione continua con il cliente Banca (quando possibile) o in alternativa con il loro diretto fornitore, che, di volta in volta, ci dà feedback e le dovute dritte per portare a completamento il progetto.

Un altro caposaldo su cui fare affidamento in ogni progetto bancario è l’analisi funzionale che ci viene consegnata ad avvio lavori.
Qui vengono trattate, a volte molto nel dettaglio, tutte le peculiarità del progetto:

  • fissati gli obiettivi;
  • messe a terra le funzionalità che l’applicativo dovrà contenere;
  • formalizzati i servizi lato backend che saranno messi a disposizione a completamento delle richieste.

Successivamente, rivediamo l’analisi funzionale in chiave progettuale: il team interno di design, insieme a noi, prende in esame le esigenze e i bisogni dell’utente che dovrà utilizzare l’applicativo. Ed è in questo momento che decidiamo cosa produrre come primo outcome.

La progettazione può iniziare con un’attività sull’architettura dell’informazione oppure andare dritti al flusso. Altre volte può verificarsi anche il caso in cui si ha necessità di analizzare in profondità un’interfaccia chiave, chiara nei dettagli ma asciutta nella presentazione (wireframe) che ci permette di capirne le sue potenzialità e criticità.
L’obiettivo è sempre quello di ottenere feedback nei punti più nevralgici, in modo da poter iniziare a gettare le basi dell’applicativo rispondendo alle richieste della Banca.

Qual è la differenza fra questi due approcci? L’architettura dell’informazione porta di per sé nozioni importanti all’ideazione e realizzazione della struttura interna all’applicativo. Una buona architettura dell’informazione lavora anche sull’esperienza utente in modo tale da mapparne i bisogni e le esigenze. La trovabilità, l’usabilità e l’interagibilità sono le caratteristiche evidenti post-lavoro sull’architettura dell’informazione.

La progettazione del flusso permette invece un’accurata analisi degli step necessari, vincolanti e non, per poter raggiungere lo scopo prefissato dell’applicativo. Riuscire a mantenere il focus su ciò che si sta facendo, avere le informazioni al momento giusto, riuscire a completare il task senza intoppi, sono alcuni aspetti che il flusso di navigazione prende in considerazione.

Quando invece realizzare un wireframe? Il wireframe è un fermo-immagine: uno zoom su uno step del flusso e un check sull’architettura dell’informazione. Se si predilige un’interfaccia schizzata alle due attività precedenti, di certo aspettiamoci di avere e ricevere molte domande: in questo caso manca un quadro più ampio e completo della situazione.

Le prime due attività, in alcuni casi, potrebbero essere implicite nella terza, mentre in altri casi è necessario mantenerle separate per poter avere una maggiore consapevolezza di ciò che si andrà a fare prima, dopo e durante.

Abbiamo poi avuto casi in cui la Banca ha richiesto espressamente di iniziare con attività più “marginali” come la rifattorizzazione delle icone o l’impostazione dei template per i report.

Per la rifattorizzazione delle icone abbiamo strutturato una ricerca degli stili iconografici, assunti proprio da questi asset, cercando di far percepire al committente quali erano i vantaggi e gli svantaggi nell’adottare gli uni rispetto agli altri. Da lì siamo andati avanti con un vero e proprio studio della tipografia e dell’uso dei colori istituzionali in modo da mostrare non solo l’impatto che il redesign delle icone avrebbe generato, ma anche un contesto più “pesato” e armonico in cui le icone stesse sarebbero state ospitate.

Per l’impostazione dei template per i report, invece, una volte ricevute le indicazioni sull’utilizzo del brand bancario e la creazione dell’immagine coordinata, le abbiamo declinate sulla reportistica. Perché nel caso della reportistica vanno tenuti presenti i vincoli e i parametri derivanti dalla visualizzazione online e dallo sviluppo digitale dei documenti. Inoltre, quando l’identità di brand è forte, è richiesta molta attenzione nell’adozione delle linee guida e l’approvazione dipende da più figure professionali. Ancora una volta, l’interfacciamento diretto con tali professionisti ci ha portato a ricevere feedback frequenti e puntuali, a cominciare dal far chiarezza sulla font da utilizzare e sulle diverse cromie da applicare ai vari mercati di riferimento.

Come sappiamo, seppur ogni lavorazione fornisce e rilascia un documento funzionale o progettuale, non sempre può essere esaustivo quanto un confronto diretto con chi tutti i giorni coordina e prende decisioni proprie del settore.