Ci siamo ritrovati nuovamente – ne avevamo scritto tempo fa in questo post sul design system – a lavorare su un fronte comune a designer e sviluppatori per migliorare e ottimizzare le applicazioni del nostro cliente Sinapsi.
Questa volta l’ambito è stato prettamente quello del mobile. Sinapsi aveva necessità di estendere il lavoro fatto per la web app anche al mondo Android.
A differenza dell’applicazione web, le app Android non erano state toccate dal design system nonostante siano centrali nella consegna di valore del loro gestionale Logica. Essendo pensato per la cantieristica, è normale che le app siano un fulcro quando ci si trova sul posto: era quindi essenziale uniformare la parte mobile. Al problema di design si sommava l’esigenza – dei programmatori mobile – di avere dei pattern chiari con regole d’uso, per essere il più autonomi possibile e allo stesso tempo efficaci.
Per questo, abbiamo strutturato le attività in cinque punti:
- Interface inventory
- Interviste agli sviluppatori
- Declinazione del Design System su Android e Material Design con creazione di pattern dedicati al mobile
- Design di un’app white label che raccogliesse tutti i design pattern e li mostrasse nel loro uso pratico
- Talk finale sulla cultura della cross funzionalità all’interno del team
Interface Inventory
La prima attività è stata raccogliere e catalogare tutte le schermate che componevano le varie applicazioni.
Dopodiché siamo passati ad inventariare tutti gli elementi interni agli screen e… ne abbiamo viste delle belle!
Segno che l’esigenza era divenuta molto forte, sia lato sviluppo sia lato esperienza utente.
Dall’inventario è infatti emerso principalmente:
– incoerenza e discontinuità nell’utilizzo,
– applicazione di linee guida diverse: sia di Material Design (il framework di Android che detta le linee guida per la creazione delle interfacce) e sia del design system in essere, che negli anni ha portato ad avere applicazioni diverse fra loro. Per fare degli esempi: campi di input di colore giallo insieme ad altri di colore blu, moduli nativi e moduli customizzati a liste.
Essendo applicazioni con un alto livello di interazione, abbiamo trovato modi diversi di presentare uno stesso componente (come ad esempio i moduli e le liste) ed è qui che abbiamo messo maggiore focus nella riprogettazione. Il nuovo design system ha preso in esame principalmente i punti più critici emersi dall’inventario e allo stesso tempo ha dato una continuità a quanto già fatto lato design per il desktop.
Le interviste
Abbiamo intervistato gli sviluppatori che lavorano all’app (in questo caso un team di sviluppatori lato cliente, che utilizzano il design system) per avere informazioni su:
- loro bisogni, problemi e difficoltà, legati all’incoerenza a livello grafico e di esperienza utente (come detto sopra),
- frequenza di utilizzo dei vari pattern,
- loro desideri e aspettative rispetto all’attività di design system.
Prima di procedere a definire i design pattern del sistema Android, abbiamo fatto alcuni confronti con gli sviluppatori sui risultati emersi dall’interface inventory, al fine di creare un sentiment e una prospettiva comune sul problema, in modo che la soluzione fosse condivisa con chi poi la doveva mettere a terra.
Il Design System su Android e l’app white label
Le fondamenta (colori, font, icone, etc.) sono rimaste le stesse, mentre i componenti sono stati calati ad hoc su device Android.
Per raccogliere e spiegare i design pattern di Android, è stata creata un’applicazione specifica (Logica componenti) dove sono stati raccolti tutti gli elementi riprogettati e mostrati come esempio nel suo aspetto più pratico, già declinati nell’uso. In questo modo gli sviluppatori hanno anche già a disposizione il codice dei componenti per come dovrebbe essere scritto.
La cultura della cross funzionalità
Un design system rimane fine a se stesso se non è iscritto in una sana cultura della collaborazione continua di team. Collaborazione che non è in un solo momento e non può essere definita con una checklist, ma, piuttosto cambiando prospettiva e abbracciando una visione sistemica del proprio lavoro.
Per questo, come ultimo step, abbiamo fatto un momento di riflessione comune su come la user experience influisca sullo sviluppo e viceversa. Questo ci ha permesso di esplicitare i punti critici e definire un modus operandi comune, ancora più solido, per il futuro.
