Wireframe

Spesso c’è un fraintendimento: le fasi di progettazione non sono per il cliente finale o il portfolio. Servono principalmente al team: aiutano a capire cosa fare e come procedere.

Con i miei studenti capita spesso questa cosa. Chiedo loro di esplorare un nuovo progetto partendo da una site-map, da uno user-flow e da alcuni wireframe. Spesso fanno prima il visual design e poi “ricostruiscono” a posteriori wireframe e flussi. Si nota subito. I wireframe sono super ordinati, puliti e allineati al design finale. Una cosa che non succede mai in un progetto reale. Anche perché le cose cambiano, continuamente.

In the history of design there has never been a project where all the requirements were known before design started. – Dan Saffer

Nella fase iniziale di un progetto si parte spesso da una bozza grezza di sitemap, user-flow e wireframe. Questa fase serve a ragionare e allineare il team. Negli ultimi anni i wireframe sono considerati, da alcune persone, superati. Recentemente, un post su LinkedIn del CEO di Duolingo diceva: basta wireframe.

Il post ha generato varie reazioni e, come al solito, in un attimo tutto diventa un posizionamento tra pro e contro, tra chi li ha abbandonati “fin dal 1985” e chi li difende a prescindere.

In realtà, come sempre, non c’è una risposta che vale per tutti. Dipende. Dipende dal team, dipende dalla fase in cui si trova il progetto, dipende dal design system, dipende dalle esigenze del progetto in sé.

Nel primo capitolo del libro Wireframe for everyone (2023), scritto da Michael Angeles, Leon Barnard e Billy Carlson di Balsamiq¹, si parla di tre fasi del wireframe. Una fase iniziale, dove si trasferiscono idee su un foglio; una fase intermedia, focalizzata su flussi e interazioni; una fase avanzata, in cui il wireframe diventa uno strumento per comunicare idee e stimolare la discussione, con annotazioni e contenuti di esempio.

In un articolo del 2016, il team di design di Airbnb raccontava di come avessero declinato queste fasi, evolvendo e superando i wireframe low-fi, grazie a una “foundation”: una guida base con tipografia, palette colori, icone, spaziature e regole di architettura dell’informazione.

Invece di affidarci a singoli atomi, abbiamo iniziato a considerare i nostri componenti come elementi di un organismo vivente. Hanno una funzione e una personalità, sono definiti da un insieme di proprietà, possono coesistere con altri e possono evolversi in modo indipendente. Un linguaggio di design unificato non dovrebbe essere solo un insieme di regole statiche e atomi isolati; dovrebbe essere un ecosistema in evoluzione².

A partire da quella foundation, Airbnb ha definito quattro principi di design:

1. Unified: ogni elemento appartiene a un ecosistema coerente, senza componenti isolati.
2. Universal: il linguaggio deve funzionare a livello globale, quindi accessibilità e inclusività sono fondamentali.
3. Iconic: chiarezza e sintesi, perché il design comunichi in modo deciso.
4. Conversational: il motion diventa “voce” per comunicare in modo intuitivo con l’utente.

In questo modo, i designer non costruiscono più wireframe a blocchi da zero, ma assemblano direttamente i componenti, generando prototipi con la UI reale.

Con un design system maturo, se un pattern è già presente nella libreria (per esempio bottone, card, modale), non serve un wireframe low-fi: basta montare il componente e verificarne subito l’impatto. All’epoca il team di design di Airbnb condivise anche un video che mostrava come da un wireframe a bassa fedeltà generavano la UI con i loro componenti, un’operazione che oggi è diventata alla portata di tutti (in questo momento sto pensando ad esempio a Relume).

Tornando a Duolingo, vista così potrebbe avere senso quel “basta wireframe”. Il loro design system è sicuramente maturo, ma c’è un altro aspetto da considerare: le microinterazioni. Per Duolingo, animazioni e timing sono centrali ed è complicato rappresentarli in un wireframe statico.

Per eliminare del tutto i wireframe, oltre a una solida foundation, e a una libreria di componenti ben definita, testata e aggiornata, è necessaria una solida cultura di collaborazione tra product manager, designer e sviluppatori.

Nel quinto capitolo di Wireframe for everyone c’è un elenco dei cinque ruoli chiave di un wireframe in un processo collaborativo:

• Articolazione: per visualizzare chiaramente il problema, in modo che diventi un riferimento facilmente condivisibile durante tutto il ciclo di progettazione.
• Generazione: per esplorare rapidamente idee senza giudizio.
• Iterazione: poiché sono facili da modificare e rivedere, i wireframe sono fondamentali per costruire e migliorare le idee iniziali e per tutto il ciclo di vita del prodotto, permettendo di scartare rapidamente soluzioni inadeguate e di arrivare a una MVP (Minimum Viable Product) velocemente.
• Comunicazione: per mostrare e concentrare l’attenzione su flussi e struttura che sono difficili da cambiare successivamente, anziché sui dettagli di stile (colori, font), che possono evolvere
• Validazione: per condividere con utenti reali o con il team di sviluppo per test d’usabilità, revisione tecnica o QA, prima di passare alla produzione; in questo modo si catturano eventuali errori o lacune di progetto in anticipo.

Il valore dei wireframe non è il documento in sé – a bassa o alta fedeltà – ma il processo collaborativo che avviano. Coinvolgere ruoli diversi attraverso un linguaggio visivo semplice, con passaggi di consegna espliciti e fiducia reciproca, porta a un migliore allineamento e a un flusso di lavoro più fluido. Il design system, a un certo punto, aiuta, come scrivono in quel noto articolo di Airbnb, abbreviando alcune fasi, perché gran parte del processo di esplorazione, comunicazione e validazione è già integrata nei componenti.

In più, vorrei aggiungere che oltre al valore collaborativo, il wireframe – di qualsiasi tipo – è anche un modo per pensare. (In un altro numero raccontavo delle fasi che di solito seguo io, che mi aiutano sopratutto a pensare).

Oggi, i vari strumenti di AI stanno cambiando il ritmo delle fasi di design, tutto è sempre più accelerato, ma non ho la sensazione che qualcosa venga saltato. Di sicuro viene fatto più velocemente. Di sicuro le fasi sono presenti, anche in maniera didascalica, in strumenti di supporto al workflow, come Relume o Flowmapp. In strumenti di generazione (Lovable, Slitch, Figma Make, etc.) non considerare l’organizzazione e la definizione di uno schema generale potrebbe non essere una buona idea. In ogni caso, volendo, alcune fasi si saltavano anche prima delle AI. Oggi con le AI il problema potrebbe essere un altro, quello di accontentarsi e saltare la fase legata al pensiero, al ragionamento. E, come ricorda, Craig Abbott in un recente post, «AI doesn’t need to think, noi invece sì».³