Banca Widiba, una delle 10 migliori banche online italiane, è una piattaforma completa che offre prodotti e servizi per la gestione quotidiana del risparmio e degli investimenti.
L’applicazione dall’anima conversazionale
Tuttavia, il design appariva ormai obsoleto rispetto ai concorrenti e agli standard richiesti dal mercato, così come l’esperienza utente, che necessitava di nuove modalità di interazione.
Per mantenere alta la promessa di un’esperienza paperless senza frizioni, il redesign dell’applicazione ha introdotto un nuovo sistema di interazione, trasformando l’esperienza utente da un modello transazionale a uno conversazionale.
Tipo di progetto
App per mobile
Il mio Ruolo
Sr. UX Designer | Doing come Design Consultant presso il cliente
Cliente
Attività
All’interno del processo di sviluppo dell’applicazione mi sono occupato di: Concept Design, UX Design, Product Design, Design System, Prototipazione, Testing e Architettura dell’Informazione.
Anno di progetto 2019. Ultimo aggiornamento del case study gennaio 2025.
Il contesto
Il progetto è stato definito da due macro fasi che si sono susseguite nella realizzazione del prodotto: (1) una fase principale che prevedeva la realizzazione core dell’applicazione che avrebbe dovuto contenere le funzionalità esenziali e (2) una fase secondaria nella quale si sarebbero implementate le funzionalità rimaste ma in un contesto progettuale già definito.
Questo case study descrive principalmente le attività relative alla prima macrofase del progetto, fondamentale per la creazione della nuova applicazione, durante la quale sono state prese tutte le decisioni di sviluppo, design ed esperienza in modo fortemente sinergico, definendo così il progetto nella sua totalità. Il contesto metodologico si basa sullo User-Centered Design, attraverso un processo che ha visto un primo momento inclusivo e di analisi, seguito da un secondo momento esclusivo e decisionale. Questo ha dato origine a quello che possiamo definire il cuore progettuale e scalabile dell’applicazione, nonché il perimetro di progetto.
La seconda fase invece è stata caratterizzata da un unico grande momento di implementazione e di declinazione seguendo le linee guida precedentemente definite.
La sfida
La progettazione di un’applicazione è di per sé impegnativa, ma, a mio avviso, non costituisce la vera sfida. Al contrario, sono le caratteristiche che si vogliono attribuire al progetto a definire le sfide da affrontare. In questo senso, ho individuato diverse sfide, che si sono manifestate in momenti ben definiti durante il processo di design.
Livello “superiore”
Lo potremmo definire anche come ciò che vediamo del prodotto, ovvero la parte “tangibile” che influenza direttamente l’esperienza d’uso, quella con la quale si interagisce. Questo ha comportato due sfide fondamentali.
Una nuova modalità di interazione con la banca.
Ha reso necessario il ripensamento della fruibilità del prodotto e dei servizi offerti.
Un’alta qualtià del design delle interfacce.
Un look and feel consistente cross device per avere alti standard qualitativi.
Livello “inferiore”
Si potrebbe definire come ciò che non vediamo del prodotto, l’elemento “intangibile” che, tuttavia, rende possibile l’esistenza del livello “superiore”. Senza di esso, infatti, il livello visibile non esisterebbe.
Una soluzione tecnologica per ridurre lo sviluppo nativo
Una codebase che possa garantire ottime performance e sinergia nell’implementazione.
Il Processo Metodologico e la definizione del “MUP”
Come descritto precedentemente, il progetto inizia con quella che è stata definita come la macro fase principale caratterizzata da momenti decisionali fondamentali per dare struttura all’applicazione.
Il processo
La macro fase principale ha portato alla definizione di un processo a tre fasi decisionali che si sono sviluppate in modo successivo, ma con frequenti punti di contatto tra loro, alle quali ho partecipato attivamente con un ruolo di responsabilità o di supporto a seconda delle necessità di ogni fase.
Fase (di)
Experience
L’implementazione della modalità di interazione.
Fase (di)
Sviluppo
La scelta del linguaggio di programmazione.
Fase (di)
Design
Il modello strutturale per la progettazione del Design.
Il Perimetro di Progetto
Per supportare i processi decisionali (sopra descritti) e intercettare il prima possibile eventuali macro criticità, si è reso necessario stabilire, fin da subito, un perimetro dell’applicazione. Questo perimetro includeva tutti gli elementi, le caratteristiche e le funzionalità principali che avrebbero definito l’applicazione e che, successivamente, sarebbero state scalate e replicate per completare la prima versione destinata al pubblico.
Durante la fase (decisionale) di experience, si è definito quali pagine realizzare, quali funzioni sviluppare e quali servizi rilevanti integrare. Inoltre sono state individuate le caratteristiche di interazione principali, come le animazioni utili alla navigazione e alla presentazione dei contenuti.
La definizione di un Perimetro di Progetto è stato importante anche per programmare attività fondamentali come i Test di Usabilità durante il processo di sviluppo, avendo già chiaro in quali macro aree andare a identificare le future attività del test.
Vuoi saperne di più sui Test di Usabilità dell’App Widiba?
Guarda il progetto.
Il MUP
Durante la definizione del Perimetro di Progetto è stato preso in considerazione anche un parametro fondamentale: il MUP (Minimum Usable Product). Ovvero, ciò che fa parte di questa selezione avrebbe dovuto fornire all’utente, in termini di usabilità, una buona esperienza minima di utilizzo.
Fase (di)
Experience
Concept, Struttura, Livelli di Navigazione, Linee Guida per definire dei Template, Gerarchie Visive, Funzioni, Interazione tra le pagine, Pulsanti, Flussi di Navigazione e Wireframe! In questa fase, iniziata temporalmente per prima, mi sono occupato di ognuno di questi aspetti che, tutti insieme, hanno contribuito in maniera significativa a determinare quella che sarebbe stata l’esperienza utente durante l’utilizzo di questa nuova applicazione.
Concept
Sfida – Modalità di interazione
Tutto è iniziato dal concept. Tutto si è concluso con il concept. Una provocazione, forse, ma fino a un certo punto, il concept è stato l’anima del progetto, quello che ha dato forma all’idea, quello che ha richiesto di ripensare tutta l’architettura informativa perché se si decide di cambiare la modalità di fruizione dei servizi, delle funzioni, da parte dell’utente, cambia molto, cambia tutto. Non solo a livello di Design, di Experience, ma anche di Sviluppo, nel profondo del Backend, perché si fa presto a dire “allora facciamo che tappo qui, succede così, cambio lì, si aggiorna questo e confermo!”.
Il concept ha portato con sé la prima, grande, sfida del progetto: passare dalla modalità transazionale a quella conversazionale. Una prima considerazione sommaria poteva asserire che già lo facevano alcuni (molto pochi) competitor di banche on-line: in fondo la modalità di proporre l’inserimento di un’informazione alla volta non era più qualcosa di nuovo, ma semplicemente qualcosa di consigliato, da seguire perché metteva l’utente nella condizione di portare a termine, il flusso che decideva di compiere, più “facilmente”.
Si poteva fare un passo in più? L’idea non era solo quella di “inserire un campo alla volta” ma che nel farlo si potesse replicare, a tutti gli effetti, un pattern di utilizzo già conosciuto: quello della chat. Gli elementi che vengono inseriti, rigorosamente uno alla volta, vanno a comporre una conversazione, proprio come succede nella chat, dove restano visibili ma allo stesso tempo il focus rimane sempre sul prossimo passo da fare. Questa modalità, ovviamente, avrebbe dovuto essere utilizzata per ogni funzione e/o operazione fosse stata compiuta all’interno dell’applicazione.”
Struttura
Definito il concept conversazionale, l’attività successiva che ho svolto è stata quella di definire alcuni aspetti fondamentali per creare la struttura dell’applicazione, vediamoli un po’ più nel dettaglio.
Livelli di Navigazione
La definizione di questi livelli mi ha portato a stabilire la profondità di navigazione verticale, creando delle basi progettuali che sono non solo a livello strutturale ma anche di significato, con un conseguente impatto, come poi vedremo, sull’organizzazione dei contenuti e sulle tipologie di interazione. Insieme al team di lavoro abbiamo individuato 3 livelli di navigazione, dall’alto verso il basso, il +1, lo 0 e il -1. La denominazione di questi livelli è stata una scelta progettuale interna e funzionale al significato strutturale al quale ci volevamo attenere, dove è stato considerato il livello 0 come quello base e i livelli +1 e -1 come quelli con una relazione gerarchica di posizione rispetto a quello base. Successivamente alla definizione dei livelli è stato deciso che ciascuno sarebbe stato caratterizzato da un determinato template.
Template e linee guida
La definizione dei template è stata una conseguenza diretta o “a cascata”, dell’individuazione dei livelli, poiché ad ogni livello doveva corrispondere un template specifico. Essendo tre i livelli di navigazione, ho definito tre template, ognuno con caratteristiche strutturali, di contenuto e di interazioni proprietarie.
Se nella definizione dei Livelli di Navigazione era stata stabilita la relazione tra livelli e template, in questa fase avevo iniziato a definire la relazione successiva, ovvero quella tra i template e le pagine: ogni pagina presente nel Perimetro di Progetto doveva essere associata a uno dei tre template disponibili. Questo è stato anche il primo step di quelle che potremmo considerare delle linee guida che vanno a definire i template stessi.
Individuate le tipologie ho definito le caratteristiche principali dei template:
Struttura
Ogni template avrebbe potuto avere 1, o al massimo 2, versioni di layout e delle aree strutturali definite in base alla tipologia di contenuto , ovvero a cosa è destinata ciascua area.
Gerarchia visiva
Questa gerarchia definisce l’ordine sequenziale delle aree strutturali che non determina esclusivamente quella di tipo visivo ma stabilisce anche una relazione funzionale: l’area superiore influisce direttamente su quella a lei sottostante.
Funzionamento
Viene esplicitata la modalità con cui vengono caricati i contenuti di ciascuna Area Strutturale e come questi contenuti cambiano in relazione a un aggiornamento di un’area gerarchicamente superiore.
Aree Strutturali che definiscono una tipologia di Template.
Gerarchia Visiva e Funzionale del template.
Interazioni e navigazione
Anche la definizione delle interezioni (in pagina) e della navigazione (all’interno dell’applicazione) deve tenere in considerazione la presenza dei tre livelli in modo da restituire un’esperienza consistente all’utente, consentendogli di capire sempre dove si trova durate l’utilizzo dell’applicazione stessa.
Pagine
Ho definito le interazioni e i comportamenti di una pagina con quella successiva nel caso in cui si trovino sullo stesso livello e in due livelli differenti. Per esempio, nel caso in cui la pagina di destinazione sia al livello -1 viene mostrata con una transizione a foglia, mentre la pagina che si trova al livello 0, dalla quale è partita l’azione, eseguirà uno spostamento laterale per uscire dalla viewport.
Pulsanti
Definite le varie interazioni e comportamenti di navigazione (tra le pagine), ho individuato differenti icone in modo da creare un’associazione tra l’oggetto su cui veniva eseguito il tap (l’icona), la posizione del contenuto (il livello) e la modalità di fruizione del contenuto (il comportamento).
Flussi (di navigazione)
Per chiarire ancora meglio il passaggio da una pagina all’altra, su uno stesso livello o fra di essi, la funzione dei pulsanti a seconda della posizione che occupavano in una schermata e dell’azione ad essi associata ho realizzato una serie di tavole riportanti i flussi di navigazione più rappresentativi.
– – – > Inizio delle definizione del Perimetro di progetto < – – –
Wireframe
I wireframe sono uno di quegli strumenti che uso per dare un primo senso di concretezza e che aiutano, anche i meno esperti, a “iniziare a vedere le cose” come potrebbero essere, fornendo un significato a quanto progettato, pensato e ipotizzato fino a quel momento.
Se invece guardiamo questo strumento dal punto di vista dello UX Designer, è un‘ottima base, molto solida, da cui partire per lo sviluppo del progetto. Avendo già definito moltissimi aspetti di progettazione, mi ha permesso di concentrarmi su un altri aspetti molto importanti, arrivati a questa fase del progetto: come la modalità conversazionale e la struttura in generale andranno ad impattare sulla ridistribuzione dei contenuti esistenti e quali potrebbero essere i contenuti nuovi e necessari da aggiungere.
Ho potuto così, a titolo di esempio, lavorare sul flusso dispositivo convertendo quello che allora era l’esistente in modalità transazionale a quella conversazionale. Questa si è confermata, fin da subito, una modalità molto più veloce per completare una richiesta dispositiva: oltre a mantenere l’inserimento singolo dell’informazione e a riproporla, proprio come in una conversazione all’interno di una chat, mantiene il focus sullo step contestuale e agevola il progredire dell’utente verso la conclusione del flusso.
Vuoi saperne di più su come realizzo i wireframe in un progetto?
Punto di contatto con la fase successiva
Mentre lavoravo sui Wireframe un team di sviluppatori dedicato stava verificando pro e contro delle diverse soluzioni tecnologiche con cui potere sviluppare le caratteristiche dell’applicazione.
Fase (di)
< – – – – – >
Experience
Fase (di)
Sviluppo
In questa fase, iniziata poco dopo quella di Experience, ho supportato e collaborato con i diversi team di sviluppo, in due momenti fondamentali: individuare quale fosse la tecnologia migliore per sviluppare l’intera applicazione e, successivamente, la “scrittura” di un linguaggio di programmazione che è stato realizzato in simbiosi con il design in modo da creare una reciprocità progettuale.
Quale Tecnologia?
Sfida – Soluzione tecnologica
La scelta della tecnologia con cui sviluppare l’applicazione è avvenuta durante la definizione del Perimetro di Progetto e della modalità conversazionale. Affiancando un team di sviluppatori dedicato, li ho supportati nella realizzazione di alcune specifiche caratteristiche fondamentali per l’applicazione, utilizzando i diversi linguaggi che si erano decisi di testare per valutare le possibili potenzialità, i pro e i contro di ciascuna tecnologia. Questo ha permesso, non solo di scegliere la tecnologia migliore per sviluppare le caratteristiche fondamentali del progetto, ma anche ai vari team coinvolti, come UX, UI, FrontEnd, BackEnd e Analisti, di conoscere in “anteprima” le caratteristiche sostanzialidella tecnologia, in modo da progettare mantenendo elevati gli standard di fattibilità e riducendo i rework.
La scrittura del Codice
Scelta la tecnologia con cui sviluppare l’applicazione, viene inserito nel progetto un team FrontEnd, il quale si è occupato, definiti anche gli standard qualitativi di design, di sviluppare un codice progettato in simbiosi con il design stesso, in modo da creare una forte reciprocità e traguardare gli obiettivi.
In questa fase, il mio ruolo è stato di fondamentale importanza perché ho iniziato a svolgere una funzione di raccordo tra il team di sviluppo e il team di UI (che sarebbe entrato nel progetto successivamente), assicurandomi di comprendere al meglio le modalità con cui il linguaggio di programmazione veniva definito e come trasferirlo in una modalità di progettazione complementare, che garantisse reciprocità.
Ho quindi, inizialmente, supportato il team di sviluppo per capire insieme a loro come raggiungere gli obiettivi qualitativi target di design e quali strumenti implementare durante la progettazione delle interfacce per fare in modo che ci fosse una piena corrispondenza tra il progettato e lo sviluppato, non solo in termini di risultato finale, ma anche di processo di realizzazione delle interfacce stesse.
La Griglia di progetto
Sfida – Qualità del Design
Se volessimo individuarne uno questo è, molto probabilmente, un punto di contatto fondamentale tra ciò che è stato sviluppato e ciò che è stato disegnato. La definizione di questa griglia mi ha permesso di trasformare la flessibilità del codice in flessibilità di progettazione e definizione del design delle interfacce. Un luogo fisico, tangibile, che ha permesso lo scambio reciproco, tra chi sviluppa e chi progetta, attraverso l’utilizzo di un linguaggio comune: una griglia di progetto, dove ciascuno legge l’informazione necessaria per realizzare la propria parte di lavoro.
Tier
Prima di passare alla definizione di una griglia di progetto, avevo la necessità di individuare un perimetro entro il quale svilupparla. Dopo una breve ricerca, più per confermare l’ovvio, ho constatato che gli smartphone e di conseguenza le loro viewport erano moltissime, e questo significava anche che erano tutte diverse tra di loro. Quindi, come individuare un perimetro, in questo caso assimilabile alle dimensioni di una viewport, che vada bene per tutti gli smartphone in commercio? Questo non è possibile, in quanto sono troppe le differenze, non tanto in valore dimensionale, ma su quello proporzionale. Se una delle sfide era quella di avere una qualità del design elevata, e quindi un look & feel che fosse sempre lo stesso anche cambiando device, l’aspetto proporzionale è quello più importante.
Non essendo stato possibile individuare una viewport unica, ne ho identificato una serie che potessero coprire tutte quelle presenti nei device sul mercato attraverso l’attributo della proporzionalità. Ho iniziato a raggruppare le viewport dei vari device in gruppi, ciascuno caratterizzato da un diverso valore di proporzionalità. Ovviamente, non è stato necessario raggruppare tutte le viewport di tutti gli smartphone in commercio ma è stato sufficiente definire una tendenza: cioè un numero giusto di gruppi che potesse contenere le possibili casistiche riscontrate.
L’ultimo passo per definire i Tier di Progetto è stato quello di individuare una convenzione: a cosa corrisponde il gruppo 1? E il 4? In questo è venuta in aiuto un’altra ricerca che ho eseguito sul mercato degli smartphone, ovvero quelli più venduti. In questo modo ho potuto assegnare ad ogni tier un modello di smartphone come riferimento.
Ora tutto era pronto per passare alla definizione della griglia!
Flex
Avendo definito, nello step precedente, una serie di tier con dimensioni proporzionali, a questo punto non mi restava che individuare una griglia che avesse valori relativi e che permettesse al design di riadattarsi seguendo la stessa logica del riproporzionamento.
Il primo passo è stato quello di dividere le due dimensioni della viewport, altezza e larghezza, in righe e colonne, assegnando loro una dimensione relativa. Questo vuol dire che il numero delle une e delle altre sarebbe stato sempre lo stesso per ogni tier:sarebbe cambiata solo la larghezza (per le colonne) e l’altezza (per le righe).
Ok, ma quante righe e colonne fare? Anche se nell’esporre questo case study le attività vengono raccontate in modo successivo, è bene ricordare che, nella realtà, non avviene sempre questo e, come menzionato poco più su, la fase di Sviluppo ha avuto continui momenti di scambio con le altre fasi (Experience e Design). Fatta questa doverosa premessa, la definizione di questa griglia e, più nello specifico, del numero di righe e colonne in cui doveva essere suddivisa, è stato possibile farlo in modo molto accurato perché alcuni componenti avevo già iniziato a progettarli nei Wireframe e poi in una prima versione (basica) di UI. Il risultato è stato quello di ottenere un numero (di righe e colonne) che tra i vari tier non andasse a deformare i componenti ma li riproporzionasse in modo armonico, anche rispetto ai componenti vicini.
Punto di contatto con la fase successiva
Mentre si sceglie la modalità di scrittura del codice si inizia a lavorare sulla UI per definire un primo Design System.
Fase (di)
< – – – – – >
Sviluppo
Fase (di)
Design
All’interno di questa fase, temporalmente iniziata per ultima rispetto alle prime due, ho avuto un ruolo da Product Designer affiancando il team di UI, favorendo l’inserimento delle figure all’interno del progetto condividendo con loro il metodo di lavoro e supportandoli nella comprensione delle modalità di progettazione, neccessaria, per implementare al meglio il design che avrebbero progettato.
Design System
Chiariamo subito un aspetto molto importante, per non creare equivoci: non mi sono occupato di UI Design. Più nello specifico, non ho progettato la grafica dell’applicazione, non ho scelto lo stile, i colori, le forme e così via… Quindi, perché ho incluso la parte di Design in questo Case Study? Di cosa mi sono occupato effettivamente? In due parole: Design System. Vediamo di cosa si tratta, o meglio, cosa ho fatto.
Libreria
Ho creato, manutenuto, aggiornato, la Libreria del progetto affiancando gli UI Designer nella creazione dei componenti una volta che il loro design era completo, una sorta di ingegnerizzazione dell’elemento in modo che potesse adattarsi al sistema progettato e che rispettasse alcune regole di costruzione, affinché queste ultime potessero essere insegnate, spiegate e condivise a qualsiasi UI Designer che avesse dovuto entrare nel progetto successivamente.
Sistema proporzionale
Un altro aspetto fondamentale da conoscere, anche per il Team di UI, come ho accennato poco sopra, era come utilizzare il sistema proporzionale progettato attraverso i Tier e i Flex (verticali e orizzontali). Ne ho spiegato il funzionamento, le logiche progettuali, il motivo per cui era stato realizzato e sì… anche come andava utilizzato! Quindi, oltre a contribuire alla costruzione dei componenti, alla loro ingegnerizzazione, ho anche trasferito le regole necessarie affinché quegli stessi componenti venissero utilizzati nel modo corretto. Mai come in questo caso la UX è stata l’interfaccia di comunicazione tra Sviluppo e UI.
– – – > Fine delle definizione del Perimetro di progetto < – – –
Modello organizzativo
Dovendo trasferire parte della mia conoscenza acquisita durante lo sviluppo del progetto, due problemi che ho dovuto affrontare sono stati quelli di trovare: un modello di organizzazione che rendesse efficace il passaggio di informazioni e una modalità di lavoro efficiente che, esaurita la curva di apprendimento, permettesse al Team di UI di procedere nella progettazione autonomamente. Per risolvere il primo problema, ho scelto un modello organizzativo ispirato a quello di tipo centralizzato, mentre per il secondo ho definito poche e semplici procedure da eseguire durante tutto il flusso di progettazione di un componente e/o di un’intera pagina.
Fase (di)
< – – – – – >
Design
L’applicazione
Due anime: codice ed esperienza. Lo sviluppo del codice e la progettazione dell’esperienza, attraverso il design, si fondono in maniera sinergica senza un’evidente prevalenza dell’una sull’altra ma entrambe pensate e progettate per lavorare insieme verso lo stesso traguardo.
Il risultato finale è stato quello di un’applicazione visivamente bilanciata e graficamente proporzionata, dove distanze e dimensioni (non solo dei componenti) si adattano alla viewport del device con cui viene utilizzata.
Ha una struttura consistente, organizzata gerarchicamente nelle sue aree principali le quali hanno una relazione di interdipendenza (evidente) tra di loro.
Durante il suo utilizzo, un comportamento atteso viene sistematicamente confermato e anticipato dall’elemento che lo andrà a generare, rispettando i livelli di navigazione e le relazioni “oggetto / azione”.
La modalità conversazionale è stata opportunamente integrata e declinata per tutti i flussi di azione presenti all’interno dell’applicazione: da quello dispositivo, come ad esempio pagare un bollettino, a uno dedicato all’aggiornamento di un’impostazione, fino a uno molto semplice come il settaggio di un filtro.
Log In
Applicazione della griglia proporzionale.
Fin dalla schermata di Log In i device, anche se con dimensioni delle viewport decisamente diverse tra di loro, presentano visivamente un design bilanciato e armonico grazie applicazione della griglia proporzionale.
Home Conti e Carte
Attuazione della struttura gerarchica
Le schermate di atterraggio delle voci del menu, di primo livello, presentano una struttura di dipendenza gerarchica delle aree di contenuto mentre un (evidente) pulsante è dedicato alle azioni contestuali che è possibili eseguire.
Dispositiva Bonifico e Ricarica
Implementazione della modalità conversazionale
Nell’eseguire un flusso dispositivo, per esempio come quello di un bonifico, la schermata che si presenta all’utente si compone con l’inserimento successivo dei dati necessari e, proprio come in una chat, quelli inseriti precedentemente rimangono visibili con la possibilità di essere modificati in qualsiasi momento.
Questa modalità è stata utilizzata in qualsiasi punto dell’applicazione dove vi fosse la necessità di inserire e/o modificare dei dati.
Le sfide principali e cosa ho imparato
E tutto quello che un progetto porta sempre con se! 🙂
Meno wireframe: un diverso iter progettuale
Realizzare il Design System sin dalle prime fasi del processo ha significato progettare con consapevolezza: sapere esattamente cosa fare e come farlo. Di conseguenza, ho ridotto il volume di wireframe rispetto al mio approccio tradizionale. La struttura proporzionale creata insieme al Team di Sviluppo, con caratteristiche di scalabilità e modularità, la definizione chiara di concept, livelli e flussi di navigazione, e il costante scambio tra i team, mi hanno permesso di superare facilmente questo ostacolo. Così facendo, sono riuscito a “continuare a progettare” anche senza il supporto dei wireframe, lavorando in stretta collaborazione con il Team di UI o, quando necessario, autonomamente.
Vuoi saperne di più su come realizzo i wireframe in un progetto?
Un ringraziamento
Un grazie speciale a Giuseppe e Gianvito, che mi hanno coinvolto in questo straordinario progetto, dando inizio alla mia avventura in Widiba e offrendomi l’opportunità di applicare e perfezionare le mie competenze. Un progetto che è durato mesi, che ha toccato ogni aspetto della progettazione e che mi ha arricchito immensamente.
Un altro grazie va a Crispy Bacon e a tutto il Team di Sviluppo, per aver reso possibile una sinergia unica tra codice e design, dove il continuo scambio di conoscenze e l’implementazione delle capacità reciproche ha portato alla realizzazione di qualcosa che posso senza dubbio definire “fuori dagli schemi”.