“Metto su la Moka”, “Scrivilo su un Post-it”, “Metti un po’ di Scotch”, “Devo passare il Mocio”, “Dammi due fogli di Scottex” … eccetera eccetera.

Queste frasi sono esempi di volgarizzazione di un brand. Ovvero quando il nome di un prodotto entra a far parte del gergo di tutti i giorni e si sostituisce al sostantivo generico (caffettiera, nastro adesivo, carta da cucina ecc).

InVision

InVision ha subito un processo quasi istantaneo di volgarizzazione.

Da qualche anno ogni stakeholder di progetti digitali ha imparato a convivere con InVision (c’è chi lo chiama Invisio o Vision ma è sempre lui 😉 ). Questa convivenza non sempre è sinonimo di comprensione e spesso il termine, e con esso il concetto che si porta dietro, viene usato in modo improprio.

InVision, al contrario dei famosi prodotti citati all’inizio, è purtroppo vittima di cattiva interpretazione. Ovvero lo si è scambiato per un tipo di contenuto quando invece è un semplice contenitore. InVision è una scatola vuota.

Spesso chi fa design si sente dire frasi del tipo: serve un Invision, allega un InVision, potete disegnare un Invision?, possiamo mettere l’InVision su Word?. Queste frasi sembrano innocue, quasi di senso compiuto. Invece sono spesso l’origine di grandi problemi sui progetti e sui processi.

Perché succede questo? Sfiga, probabilmente.

Nel senso che non è colpa di nessunə in particolare. Des e dev hanno probabilmente iniziato a utilizzarlo per identificare i prototipi dando per scontato che chiunque sapesse come funziona, stakeholder (e non) non hanno compreso le logiche e non hanno notato (forse) che ogni cosa presentata, seppur diversa, fosse chiamata InVision.

Come ci insegna la retorica, raccontando una storia possiamo rendere i concetti più universali e memorabili. Ed ecco quindi qua sotto una storiella che può aiutare a capire il bias che si è creato con InVision.

---

Ristorante italiano, ora di cena. Una coppia si siede al tavolo numero sette e inizia a leggere il menu. Qualche minuto dopo arriva il cameriere.

🦋 Buonasera! Avete già scelto? Posso prendere l’ordine?

🐸 Buonasera a lei. Certamente. Allora, io parto con gli antipasti e vorrei un tagliere piccolo di legno e due ciotoline: una colorata e l’altra normale.

🦊 Per me niente antipasto

🦋 Bene. Di primo?

🐸 Per me una tazza con manico doppio.

🦊 Io invece gradirei un piatto fondo di quelli col bordo largo.

🦋 Purtroppo li abbiamo finiti… posso consigliarle una cocotte antica con sottopiatto in sughero?

🦊 Vada per quella. Mi ha convinto!

🦋 Bene. Di secondo gradite qualcosa?

🦊 Io soltanto un contorno leggero, direi un piattino di quelli quadrati che vedo a quel tavolo…

🦋 Ottima scelta, sono freschissimi. Per lei invece?

🐸 No, io prendo un bel piatto ovale della casa.

🦋 Benissimo. Per i dolci passo dopo e vi racconto la nostra produzione di coppe, tazze e bicchierini.

🐸 Sì, facciamo dopo, grazie. Ci consiglia qualcosa da bere?

🦋 Certamente. Vi lascio la nostra carta di bottiglie verdi e marroni.

🦊 Non avete niente della casa?

🦋 Si certo. Preferite una caraffa di terracotta o due calici di vetro?

🐸 Facciamo la caraffa.

🦋 Bene, arrivo subito.

---

Cosa manca?

… [pausa di riflessione]

Manca il contenuto. C’è solo il contenitore!

Ed ecco quello che succede quando usiamo il nome InVision per identificare gli output di progetto. E il dialogo diventa non-sense e suona ridicolo, adatto al palco di un cabaret più che a un meeting aziendale. Pronunciare (o scrivere) frasi come “In questa fase di progetto l’output atteso è un InVision” è come dire “Oggi a pranzo ho mangiato un piatto!”.

Un piatto di cosa? …o ti sei mangiato il piatto?

La catena negativa

Tutto sommato questo errore di interpretazione non sembrerebbe così grave. Dopotutto basterebbe dire prototipo al posto di InVision.

Sarebbe comunque un errore, perché di nuovo stiamo ragionando sulla forma e non sulla sostanza. Se in un progetto c’è una componente di design (inteso come tutta la catena di progettazione) è necessario che siano chiari tutti i tipi di output e il loro ruolo nel flusso di lavoro.

In caso contrario si crea una catena negativa di progettazione come questa:

confusione >  incomprensioni > attriti > inefficienza > cattivi output > cattive performance

Confusione

Nel mondo del visual design (ma non solo) esistono due tipi di file: i sorgenti e gli asset. I primi sono i file dove i e le designer creano, i secondi sono le versioni esportate, potremmo dire in sola lettura, non editabili.

Nel mondo del digital design esiste un livello in più: l’interazione. Quindi esiste un terzo tipo di output: il prototipo. Ovvero la simulazione dell’interazione tra gli asset. InVision è un tool che crea prototipi, quindi non fa (quasi) nulla di più che collegare tra loro degli asset grafici o dei file sorgenti. A questo punto diventa più semplice capire che non si può disegnare un Invision né tanto meno metterlo su Word? Spero di sì.

Incomprensioni

Se per ogni fase del progetto pensiamo che ci voglia un InVision significa che non abbiamo chiare le fasi della progettazione

Ad ogni fase corrisponde ovviamente un diverso output ed è importante conoscerne peculiarità e differenze per poterne apprezzare il valore e sfruttarlo totalmente.

Attriti

Se queste incomprensioni non vengono superate arrivano gli attriti tra i team poiché chi ha prodotto gli output ha la sensazione di non essere apprezzatə e di aver sprecato tempo, mentre chi riceve l’output può pensare di non avere le informazioni sufficienti/incomplete o addirittura di avere quelle sbagliate.

Inefficienza

Diventa semplice capire che a questo punto la strada sta franando sotto i nostri piedi. Ormai ogni stakeholder ha interiorizzato delle convinzioni e ha schematizzato i ruoli e le responsabilità di ognuno nel dover “maneggiare” un output inadatto.

Cattivi output e cattive performance

A conti fatti, se stiamo scivolando verso valle senza possibilità di tornare indietro (o almeno fermarci) non ci saranno molti pronostici da fare.

Il risultato sarà mediocre (perché poi, insieme, in qualche modo le cose le facciamo funzionare) e tuttə saranno scontentə, probabilmente per il motivo sbagliato o per l’errata convinzione che sia colpa di qualcun altrə.

E se l’output è mediocre lo saranno anche le performance. Certamente più difficili da misurare senza una spalla o una controprova. Ma se nessunə è soddisfattə del risultato è facile pensare che con una soluzione migliore si potrebbero avere migliori risultati.

Conclusione

Ora… non è che tutto dipenda dal fatto che usiamo il nome InVision a sproposito. I progetti vanno male (o anche bene) indipendentemente da questo e/o per mille altri motivi.

Però è interessante notare come un piccolo errore di valutazione come questo possa creare grandi fastidi. Un po’ l’effetto farfalla se vogliamo.

E se all’interno di un progetto ci sono cinque, o sette, o dieci farfalle… riuscire a neutralizzarne anche solo due o tre potrebbe migliorare molto la vita dei team.

Quindi se vedete una farfalla… aprite la finestra e fatela uscire! 🦋

NOTA: negli schemi non compare Figma perchè sono immagini del 2022, ma non ho più trovato i file sorgenti. 🤷

---