Coerenza tra prototipo e software

Chi si occupa di web design e di progettazione di software in generale, conosce bene quel problema di “fedeltà” che si presenta ogni volta che il prototipo di un’interfaccia grafica deve essere tradotto in codice dal programmatore. Il segreto? Probabilmente non è un vero problema.

Il passaggio dal prototipo al software vero

Lo UI designer si occupa della progettazione delle interfacce e per farlo utilizza software di grafica dedicati, come i moderni Sketch o Adobe XD, o il più datato e sconsigliabile Adobe Illustrator (per queste mansioni Photoshop ormai è preistoria).
Il passaggio dalla prototipazione alla programmazione di una versione funzionante è un momento cruciale di ogni progetto di software (come una web app, ad esempio) ed è una delle fasi in cui è più facile riscontrare ostacoli che rallentano i lavori.

È il momento in cui le scelte più eccezionali – non nel senso di incredibili, ma semplicemente meno consuete – del designer vengono imbrigliate dai programmatori adattandole alle librerie di componenti già disponibili, preventivamente selezionate per il progetto in base a criteri di varia natura. Non si tratta mai di cambiamenti sconvolgenti. Piuttosto, nel concreto, alcuni piccoli dettagli possono subire delle modifiche, presentandosi nella loro forma finale diversi da come erano stati concepiti da principio.

Se le fasi di analisi e prototipazione sono state curate a dovere, designer e programmatore hanno già escluso le soluzioni grafiche più impraticabili in partenza, pertanto il software che passa da prototipo a strumento effettivo non viene minato nella sua integrità e nei suoi aspetti funzionali fondamentali.
Le modifiche che intercorrono tra prototipo e software sono di natura più sottile, quali margini più o meno larghi, dimensioni di font leggermente più piccole o più grandi, icone con un colore diverso e così via.
Ma perché si verifica questa discrepanza tra prototipi e interfacce reali?

Perché prototipi e software talvolta differiscono

A questo punto viene da chiedersi: se le librerie sono selezionate a inizio progetto e se ne conoscono le caratteristiche, perché il design non segue semplicemente quanto stabilito dai componenti disponibili?
E ancora: dato che il design delle interfacce finisce immancabilmente per adeguarsi alla programmazione, tradendo l’identità dei prototipi, perché non vincolarlo già in prima battuta?

La verità è che mentre gli strumenti del designer già citati rimangono quasi sempre gli stessi e gli concedono ampia libertà progettuale, quelli del programmatore possono variare da progetto a progetto (magari non in termini di linguaggio di programmazione, ma di framework utilizzato) e di conseguenza cambiano anche le librerie a disposizione che devono essere impiegate.

Le librerie open source disponibili online sono quasi sempre amministrate da team diversi, con obiettivi e filosofie più o meno distanti; ciò può comportare tante piccole variazioni grafiche e funzionali, anche laddove due librerie dispongono di uno o più componenti a prima vista apparentemente simili.

Quindi, per evitare le problematiche derivanti dall’uso di troppi set di componenti grafici specifici (tempo di realizzazione e di aggiornamento), è necessario adottare un approccio più generico e polivalente, adeguato al raffronto con le librerie ma svincolato per quanto possibile dalle specificità troppo marcate.
Questo compromesso progettuale determina alcuni degli inconvenienti minori già citati in favore di altri vantaggi lavorativi ben più significativi, tra i quali poter sgravare il cliente dei costi annessi alla realizzazione e manutenzione di svariati componenti da prototipazione estremamente specifici.

Un altro aspetto non meno significativo è legato all’aderenza dei prototipi alle linee guida di design (la nostra è Material Design di Google) che non trovano mai perfetta corrispondenza nei componenti delle librerie. Il motivo? Le linee guida sono “cose da designer”, spesso emanate da realtà aziendali specifiche (Google, ad esempio) mentre i componenti reali, come già detto, sono sviluppati da team indipendenti meno attenti ai dettagli e che lavorano a librerie diverse da framework a framework.
Queste linee guida sono inestimabili per aderire a uno standard di qualità e consistenza visiva delle interfacce, trattando di ciò che si vede e si percepisce, ma sono solo una traccia che appartiene a un mondo ideale/teorico. Come ci ha insegnato l’esperienza, spesso questa teoria si piega alle molto meno condiscendenti necessità reali, tanto che persino i servizi web di Google non vi aderiscono sempre al 100% e contemplano componenti non previsti dal manuale di Material Design.

La fedeltà 100% al prototipo spesso è una perdita di tempo

Per alcuni clienti questi dettagli rappresentano un elemento di frizione: siccome sono stati presentati e approvati in un certo modo, quando accade, è legittimo chiedersi perché arrivati alla fase di programmazione debbano cambiare. Tanto più se pensiamo a quanto sembrano banali e di conseguenza semplici da modificare (a tal proposito, ti suggerisco di approfondire anche il tema più generale dei veri tempi del web development).
A volte ciò accade solo perché il tema appare intuitivo quando in realtà risulta particolarmente articolato e tocca aspetti spiccatamente tecnici che non consentono di argomentarlo a tutti con semplicità.

Tuttavia non si possono fare a meno di rilevare due errori significativi che dovrebbero spingere a una riflessione in merito all’opportunità di investire – diremmo quasi sprecare – tempo nel tentativo di aderire in tutto e per tutto all’aspetto dei prototipi.

Il primo è ritenere che minuzie così marginali siano sempre fondamentali e imprescindibili per una resa ottimale del software. Non è così.
Al netto di tutti gli aspetti cruciali che determinano la costituzione di una struttura di questo tipo e la sua efficacia in termini di usabilità (come la user experience, per esempio), queste restano sempre finezze di contorno.
Il tempo speso per l’implementazione e i relativi problemi di manutenzione spesso non valgono la piccola soddisfazione “estetica”.

Il secondo è una incomprensione sul ruolo dei prototipi e della fase di prototipazione (se non lo hai fatto prima, ti invito ancora ad approfondire il tema con questo articolo). Questa tappa del workflow di progetto è propedeutica alla programmazione del software e principalmente serve, ai progettisti come al cliente, per prefigurare, studiare e comprendere la struttura, la disposizione e le dinamiche che lo definiranno nella sua forma finita. Definisce le caratteristiche strutturali e interattive e solo secondariamente quelle formali, laddove è possibile.

È doveroso far presente che la problematica riscontrata non è un tema esclusivamente legato alle aspettative del cliente, anzi: pur con un grado di competenza differente, il desiderio legittimo di definire le caratteristiche del software in ogni minuzioso dettaglio lo accomuna allo UX/UI designer e all’art director.
Questo è un limite con il quale molte volte, tutte queste figure chiave del progetto, devono scendere a patti.

Per fare un paragone, in altri settori in cui l’aspetto grafico è preponderante – come la progettazione del packaging o la comunicazione pubblicitaria – il livello di libertà e di fedeltà del prodotto finito spesso è effettivamente maggiore, perché privo di vincoli informatici. Sussistono limiti fisici di altra natura (risoluzione delle immagini, materiali, resa dei colori, ecc.) ma, tendenzialmente, tutto il processo di progettazione e revisione che porta alla produzione può scorrere senza frizioni altrettanto dispendiose in termini di tempo e quindi con costi più contenuti.
Siccome accade più spesso che le persone entrino in contatto con esperienze di grafica più tradizionali, è normale che si aspettino questa flessibilità anche nel mondo del software, sebbene il parallelo risulti in parte fuorviante e non completamente corretto.

Aderenza ai prototipi sì o no?

Per concludere, quando le interfacce vengono passate al programmatore, fino a che punto art director, UI designer e cliente dovrebbero esigere aderenza del codice a quanto delineato dai prototipi? La risposta che ci sentiamo di dare è: il giusto.

Nell’esperienza di Dreamonkey e confrontandoci con il parere di altre realtà aziendali del nostro settore, per il momento siamo arrivati alla conclusione che ogni modifica è lecita fintantoché non compromette significativamente il workflow di progetto o la manutenibilità del codice sul lungo periodo. Tra le varie, la compromissione di solito prende la forma di tempo eccessivo per adeguare i prototipi alla nuova richiesta, per modificare o programmare un nuovo componente o il dubbio che dalla pretesa avanzata possano nascere incompatibilità con gli aggiornamenti futuri delle tecnologie di sviluppo, problematici da gestire. Certamente l’ultima parola a riguardo – in teoria – dovrebbe spettare ai professionisti in virtù della loro competenza in materia.

Cosa ne pensi? Hai trovato modalità per aggirare questo ostacolo in modo efficace o sei arrivato anche tu alle nostre conclusioni? Se vuoi parlarne, contattaci.