In questo caso volevo segnalare un buon servizio fornito dall’azienda: Viaggia Treno. Si tratta di un’applicazione online che tiene traccia dei treni in tempo reale. Dal computer, l’interfaccia è chiara: c’è una mappa che permette di effettuare uno zoom sulla zona interessata (a sinistra) e abbiamo un pannellino di ricerca da cui posso cercare il mio treno per numero, stazione o dati di viaggio (a destra). Il sito fornisce davvero le risposte sui treni ed è curioso doverlo specificare: spesso si fa tanta fatica per costruire un mostro di sistema e poi alla fine c’è qualcosa che non lo fa mai funzionare a dovere. Qui, a prima vista, tutto sembra essere a posto….

E quindi, cosa c’è che non va?

(grazie a Nick Fink per queste ottime slide che spiegano il concetto di “Design Contestuale”)

Flash.

Tutto questo sistema è stato costruito in flash. Ora: ultimamente, anche sparare a zero su Flash sembra diventato un po’ troppo facile, quindi invito a leggere questo post di Antonio D’Alessio, che condivido.

In questo caso, però, la scelta di Flash mi sembra un errore clamoroso.

Dicevo che, a prima vista, tutto sembra funzionare… e questo mi ricorda l’ultimo libro che ho letto di Norman “Il design del futuro”. A un certo punto Norman cita un episodio in cui il suo collega Nielsen descrive la sua esperienza d’uso con una macchina per fare biglietti dell’autobus. Nielsen si trovava in Svezia, verso maggio. La macchina aveva funzionato bene e l’unica domanda che si era fatto era stata: “Chissà perché i bottoni sono così sproporzionatamente grandi rispetto alle vere dimensioni delle dita?”… Poi Nielsen tornò in Svezia d’inverno e riutilizzò la stessa macchinetta, con indosso un paio di guanti: ed ecco svelato il mistero.

Cosa mi ha ricordato questo piccolo episodio?
Che nel progettare un’interfaccia, lo studio del contesto di utilizzo è fondamentale. Senza quello, l’interfaccia (e quindi tutto il sistema, magari funzionante) può risultare inutilizzabile.

Viaggia Treno per me oggi funziona al 50% perché uno dei più naturali contesti di utilizzo di un servizio come questo è proprio durante un viaggio. Se ho una coincidenza a Bologna e sono già sul treno, posso collegarmi con il mio smartphone e interrogare il sistema per sapere se tutto è in orario… Ma se il tutto viene realizzato in Flash, da telefonino diventa inaccessibile o di difficile lettura. Flash è disponibile solo sugli iPhone e gli Android più nuovi (anche se da parte di Apple bisogna vedere come e per quanto, visto le recenti diatribe tra l’azienda di Jobs e Adobe). Il risultato è che potrei disporre di un’informazione davvero utile, ma il modo in cui il sistema è costruito, quando non mi impedisce arrivarci, mi rende tutto molto lento e macchinoso.

Consiglio a Trenitalia di fare un ultimo sforzo e pensare a una versione mobile, molto più light. Hanno costruito un ottimo servizio, ora si tratta solo di renderlo accessibile a tutti e soprattutto a chi potrebbe usarlo di più.

Due note a margine.

• il sito è del 2006, quindi mi auguro che Trenitalia stia lavorando alla nuova versione. Questo può spiegare un po’ perché sia stato realizzato in Flash, anche se già nel 2006 si poteva intuire che avrebbe potuto essere una scelta inopportuna.
• i contenuti sono protetti da copyright… O almeno da copyright per l’anno 2006. Mi è venuta spontanea questa domanda: che senso ha mettere il copyright in un sito del genere, quando qui le informazioni dovrebbero essere di pubblico dominio / utilità? Se un treno è in ritardo e lo scopro grazie a questo servizio, significa che non posso avvisare nessuno perché Trenitalia è proprietaria di questo contenuto? Una distribuzione copyleft sarebbe di gran lunga auspicabile e opportuna, per non dire obbligatoria. Almeno per un servizio come questo.

Post Scriptum.

Ho scritto questo post qualche giorno fa e l’ho tenuto saggiamente in bozza. Proprio ieri ero in viaggio verso Milano con Michele. Guarda caso, il nostro treno era “insolitamente” in ritardo e così gli ho raccontato di questo post. Con mia grande sorpresa, mi ha risposto che la versione mobile del sito viaggiatreno.it esiste e me l’ha mostrato in diretta. Il servizio funzionava e ci ha risposto correttamente in merito al ritardo del nostro treno… Peccato che ci siano questi due problemi:

• se provo a caricare viaggiatreno.it, succede esattamente quello che ho mostrato e sulla pagina non c’è nessun richiamo (manuale o automatico) a una versione mobile molto semplificata del servizio;
• se carico la pagina mobile.trenitalia.com, scopro che esiste una versione molto ridotta del sito Trenitalia, in cui una delle pochissime opzioni disponibili è proprio quella di cercare l’”Andamento dei treni”. Basta conoscere il numero del treno e il sistema risponde correttamente (è appunto quello che ha fatto Michele dal suo Android). Ma anche qui, digitando trenitalia.com da telefonino, non esiste alcun redirect alla versione mobile del sito. Si dà per scontato che i viaggiatori conoscano la url.

In bocca al lupo a Trenitalia, ne ha decisamente bisogno.
Ma soprattutto, ne abbiamo bisogno noi quando prendiamo un treno.

il primo wireframe della pagina elenco, troppo piena di informazioni non “toccabili” o poco leggibili.

Questo è il primo wireframe per la pagina elenco: lo stavo impostando praticamente come una pagina web. Titolo abstract, immagine…. tutte cose che su telefono sarebbero state davvero troppo. Lo schermo è oggettivamente piccolo, perciò il testo avrebbe dovuto essere in proporzione più rilevante rispetto a una pagina web. E poi immagine e abstract non servono. Avrei potuto aggiungere qualche icona più utile, come il numero dei partecipanti, la possibilità di contrassegnare un elemento come preferito, le etichette.

Su developer.android.com non ci sono purtroppo indicazioni riguardo a risoluzione e font di sistema, perciò ho dovuto spulciare un bel po’ la rete per trovare qualche informazione a riguardo.

Gli smartphones leggono le immagini (e quindi la grafica) sia nel formato jpg che png: questo mi è stato confermato sia da Alfredo che dalla documentazione su Developer Android. I png possono anche essere a 16 bit e visto che gli attuali device stanno evolvendosi molto rapidamente, ho impostato il mio file psd a 16 bit, salvando per ora i png a 8 bit (seguendo la famosa regola “a togliere si fa sempre in tempo”). Per la risoluzione, devo dire che mi sono fatta molte domande e leggendo qui e là, sembrava che la risoluzione fosse 160 dpi… Poi online ho trovato questo tool che permette di calcolare i dpi di uno schermo. Ho provato a usarlo, ma anche qui non ero sicura che il risultato fosse esatto: avrei dovuto riadattare l’interfaccia grafica per ogni modello di telefono, perché ognuno ha la sua risoluzione? Ancora adesso non mi sembra così illogico. Del resto, mentre gli iPhone sono tutti uguali, Android gira su vari modelli, quindi questa ipotesi non è neanche così sbagliata. Già solo per questo motivo, avrei dovuto usare grafica adattabile, come consigliava Alfredo. Forse sono io che non colgo il succo della risoluzione dpi… o forse continuo a perdermi in un bicchiere d’acqua. Se qualcuno ha una risposta chiarificatrice e definitiva su questo argomento gli sarei molto grata. Nel frattempo, ho impostato il file a 180,9 dpi, risoluzione dichiarata nella scheda tecnica dell’HTC (tra l’altro vedo che questo schermo ha una profondità di 16 bit… ma i png venivano troppo pesanti, perciò confermo di averli salvati a 8). Curiosamente, se uso il tool PXCalc che vi ho segnalato prima, con le misure dichiarate nella scheda HTC, la risoluzione mi viene diversa Questa cosa della risoluzione mi continua a mandare in panne il cervello. Ma andiamo avanti.

Per quanto riguarda i font di sistema Android, è davvero curioso che su Android Developers non si dica che il font di sistema è il Droid, almeno fino a quest’estate… O_o

Nella prima versione grafica per Dolcevita avevo scelto colori molto simili a quelli usati dal sistema: questa cosa mi era venuta spontanea… e ovviamente l’ho corretta, creando una nuova palette, sicuramente più adatta e ispirata alle grafiche degli anni ‘50 (del resto, la parola Dolcevita ha proprio quel sapore). Il colore aragosta indica un elemento selezionato, il colore turchese e crema sono quelli di base dell’applicazione. Esiste una differenza logica tra i due, che in futuro vedremo se confermare, dato che l’applicazione è in fase di evoluzione. Ho eliminato le freccine, che ci sono sembrate ridondanti; e aggiunto qualche piccolo dettaglio per dare più respiro. Ed ecco qui la schermata di elenco, in versione verticale e orizzontale.

Devo ammettere di amare molto gli spigoli arrotondati: mi sembrano molto più amichevoli, come gli spigoli morbidi di un mobile.

È un po’ faticoso spiegare i vari ragionamenti e passaggi fatti, ma chissà che non possa essere utile per qualcuno che voglia cimentarsi in un’esperienza del genere. O magari qualcuno vorrà chiarirmi qualche dubbio che ho avuto. Per ora è tutto, vi auguro buone vacanze!

Quando progetto un’interfaccia per il web, le risposte a queste domande tecniche di base sono scontate: la mia prima decisione riguarda il tipo di layout (fisso o fluido), poi studio la pagina conoscendo le risoluzioni più usate (1024 x 768 e 1280 x 1024) e dando per scontata la risoluzione video (72 dpi). Ormai uso abitualmente le griglie per avere un migliore controllo degli spazi e del ritmo. E faccio uso di zone di respiro, spazi vuoti che guidano l’utente nella lettura. Almeno, questa è lo sguardo che cerco di avere.

Su telefonino, la storia cambia.

Inquadrare questo nuovo contesto è stata la fase più impegnativa del lavoro. La trovo interessante anche ora, a distanza di qualche mese, perché rileggendo le domande che facevo ad Alfredo, riflettendo sulle sue risposte e guardando come cambiava il design dell’interfaccia si vede chiaramente che c’è stato un passaggio nella mia testolina: da interfaccia per il web a interfaccia per applicazione mobile. E sì, perché il nostro Dolcevita è appunto un’applicazione e non un sito. La differenza sembra sottile, ma in realtà non lo è. Evito di riscrivere qualcosa che ha già detto bene Maurizio Boscarol nel lontano 2001. Altre considerazioni sono ben spiegate in questa presentazione di Luca Mascaro, in cui il discorso viene contestualizzato nel 2009: il panorama è molto sfumato, comanda il device più che le differenze tra web e applicazione, tanto più ora che siamo sempre più connessi, che parliamo più di web applications che di siti web… da sola, questa riflessione meriterebbe un post a parte.

Dato che fino a quest’estate non avevo ancora uno smartphone, per capire che tipo di interazione ha l’utente con un’applicazione mobile mi sono guardata alcuni video sulle applicazioni Android più diffuse:

• Google Contacts
• Google Calendar
• Google Talk
• Gmail
• YouTube per Android

Ho anche sbirciato le interfacce grafiche più belle per iPhone, leggendo qualche articolo qui e là. Su tutti, segnalo “30 iPhone Apps with Sexy Interfaces”: vedrete che alcune sono meravigliose, ma anche piuttosto complicate da tradurre in codice.

Dal punto di vista grafico e funzionale, Dolcevita restituisce le informazioni in modo classico: schermata di avvio, elenco eventi e scheda di un singolo evento. Ma dato che l’applicazione permette di filtrare un po’ tutti i contenuti secondo vari criteri (per amico, per popolarità, per network, per vicinanza…), ho fatto molta fatica a capire dove avrebbe dovuto toccare l’utente per poter filtrare i contenuti. Su developer.android.com non ci sono molte spiegazioni sull’uso logico del menù globale e dei menù contestuali, perciò ci siamo dati noi le nostre regole, cercando di rendere l’uso dell’applicazione fluido, semplice e cercando di seguire quelli che stanno già diventando standard per le interfacce mobile. Sempre sul sito ufficiale degli sviluppatori per Android, si dà per scontato che il grafico sappia come dev’essere impostato il file Dato che così non è, mi sono confrontata con Alfredo:

• A che risoluzione lavoro?
  (Alfredo) La programmazione di interfacce per mobile segue il principio secondo il quale di spazio disponibile ce n’è sempre poco, quindi occorre sfruttarlo tutto al massimo. Inoltre, in circolazione ci sono solamente due dispositivi con Android, il G1 e il G2, e per entrambi la risoluzione dello schermo è 320×480 (HVGA). C’è da considerare anche il landscape, dato che il G1 ha la tastiera hardware e per usarla si passa in modalità landscape. A queste risoluzioni, ovviamente, va tolto lo spazio usato dagli elementi di sistema come la barra principale in alto. Direi quindi di prevedere un layout fluido e dinamico che si basa su un minimo comune denominatore di 320×320 pixel. Tutto si dovrebbe poi adattare dinamicamente ad una maggiore larghezza o altezza. Nelle liste di elementi come gli eventi o i contatti, quello che non entra a schermo in altezza sarà gestito tramite scrollbar, comunque già implementate da questo controllo. I singoli elementi delle liste avranno invece un layout che permetterà la visibilità degli elementi principali con una larghezza di 320 pixel, ma si adatterà bene anche ai 480 pixel. Utilizzando gli elementi del sistema operativo (menù principale, menù contestuale ed altro), la maggior parte di questa gestione fluida verrà realizzata automaticamente, senza codice aggiuntivo.

• In alcuni filmati che ho visto sul canale Android di YouTube, si parla dei 9 Patch: non ho capito cosa sia.
  (Alfredo) Tutto parte da una considerazione fondamentale nella progettazione di interfacce per il mobile: lo spazio è poco, variabile come dimensione, e occorre sfruttarne il massimo possibile ogni volta. Ad esempio, un bottone potrebbe dover riempire dinamicamente una certa area dello schermo, crescendo e riducendo le sue dimensioni a seconda dello spazio a sua disposizione. Con un semplice ridimensionamento dell’immagine del bottone si otterrebbero bordi sgranati o troppo compressi a seconda della dimensione, e ridisegnarlo ogni volta in maniera vettoriale potrebbe non sempre essere il massimo per le performance dell’applicazione, soprattutto se l’elemento è complesso o ce ne sono molti in gioco. Per questo motivo si è pensato di dividere l’immagine che il sistema disegnerà durante il render del controllo in 9 parti: i quattro angoli che non verranno mai ridimensionati, due aree in alto che verranno ridimensionate solo il larghezza, due aree laterali che verranno ridimensionate solo in altezza e un’area centrale che verrà ridimensionata sia in larghezza che in altezza. In questo modo, si riescono ad ottenere controlli che possono crescere senza grossi problemi di visualizzazione, con una sola immagine che li descrive, basta solo che questa immagine sia di tipo 9 patch. Per realizzarla praticamente, si prende l’immagine normale, con un apposito programma la si “seziona” e il risultato di questo lavoro viene salvato come file .9.png

• Oggetti di sistema come menù a tendina, bottoni, checkbox, radio button, loader ecc: usiamo quelli di sistema?
  (Alfredo) Direi che finché non abbiamo bisogno di fare diversamente per particolari motivi, la riusabilità di quanto già esiste è sempre buona cosa. Considera che, pur continuando ad usare un listview standard, posso ridefinire senza problema l’aspetto di un elemento che compare in questa lista (in gergo, view), magari per mostrare tutte le informazioni necessarie ad un evento o un contatto, oppure un colore di sfondo diverso in base alla fonte dal quale proviene l’elemento.

• Il menù globale è sempre agganciato in fondo? Alcune applicazioni lo lasciano aperto altre lo fanno aprire cliccando sull’icona.
  (Alfredo) beh, direi che il menù in fondo è un’abitudine ormai consolidata. Dato il poco spazio a disposizione e la quantità di dati da visualizzare (eventi, contatti ecc), direi che più spazio a schermo abbiamo a disposizione, meglio è. Quindi lo terrei chiuso.

Dopo questo scambio di domande e risposte, ho iniziato a lavorare su wireframe e grafica.

Tutto è nato da questo post di Alfredo. Lo leggo, mi imbarco in questo progetto e scopro un po’ di cose nuove: Google sta lavorando su un sistema operativo open source per mobile devices che si chiama Android. Per ora questo sistema è ancora un po’ acerbo (almeno, così mi dicono), ma sta facendo grandi passi avanti. Gira su pochi modelli di cellulari e ha come obiettivo quello di diventare il vero concorrente di iPhone Os. Se Android avesse (magari ce l’ha) una mission, mi ricorderebbe la Nike degli anni ‘80: “uccidere iPhone”
L’esperienza Apple insegna che le applicazioni sono uno dei punti chiave del fenomeno iPhone, così Google invita gli sviluppatori a partecipare a un contest a premi, l’ADC (Android Developer Challenge). Lo scopo è quello di creare un’applicazione, sempre open-source per Android. Tema libero.
Lorenzo, Michele e io raccogliamo l’invito di Alfredo e ci incontriamo una sera di giugno a Numana. È così che conosco anche Sergio e Andrea, siamo un bel gruppetto.
Scopro che Alfredo è estremamente competente in materia “mobile”, ed è anche una persona appassionata e vulcanica. Ci spiega la sua idea per l’applicazione e a tutti noi sembra ottima: deve rispondere alla domanda “Che faccio oggi/stasera? che fanno i miei amici?”. Le risposte sarebbero arrivate interrogando i vari social network usati dall’utente e dai suoi contatti. Una sola applicazione invece che infiniti social network.
A fine serata, ridendo e scherzando, siamo riusciti anche a battezzareil progetto: “Dolcevita” – nome che mi convince ancora, dopo tanti mesi
Durante le successive settimane di lavoro, il problema grosso non è stato quello di scrivere codice per Android (ricordo diversi tweet di Alfredo in cui esprimeva pura soddisfazione a riguardo); bensì quello di prendere gli eventi dai vari network, usando web services, API e non so cos’altro. In tutto questo, abbiamo (hanno) dovuto fare i conti con diverse restrizioni e sbarramenti, per via di tutele varie della privacy. Per questi motivi, nonostante varie tirate notturne, non siamo riusciti a consegnare Dolcevita in tempo per l’ADC. Tra impegni, ferie, traslochi e cambi di vita vari, stiamo (dovrei sempre dire “stanno”) cercando di andare avanti.

Io, invece, il grosso del mio lavoro l’ho finito quest’estate. Anche se… chissà, potrebbero esserci nuovi sviluppi e quindi nuove frontiere per l’interfaccia “dolcevitosa”. Mi ci è voluto diverso tempo per capire come muovermi, anche perché fino a quest’estate avevo un Motorola… e sì, Dolcevita è stata la mia buona scusa per comprare un iPhone . Fino ad agosto, non avevo ancora mai usato uno smartphone e quindi non potevo neanche immaginare quali fossero le peculiarità di un’interfaccia mobile. Il mio ruolo in tutta questa faccenda consisteva nel trovare un’icona giusta per l’applicazione (la launcher icon), seguendo le regole dettate da Google; e, soprattutto, capire come un utente usa un’applicazione su telefono, in modo da riuscire a disegnare i template dell’interfaccia.

Dopo aver scartato altre idee confrontandomi col team di sviluppo, questa è l’icona / logo che è uscito fuori: un mondo connesso, con ombrellino e olivetta, come se fosse un aperitivo da bere.

(a sinistra, la launcher icon; a destra il logo completo Dolcevita)

Nelle prossime settimane mostrerò i template (provvisori) dell’interfaccia e i passaggi che ho fatto per capire come disegnarli. Scrivo “provvisori” perché dobbiamo vedere quanti altri ritocchi dovrò fare in base alle cose che riusciranno a far funzionare e agli sviluppi futuri.

Eh?

(grazie a Daniele Canonici per il disegno!)

È passato qualche mese, ho sbattuto il naso su questa parola diverse volte, ho fatto domande a Lorenzo, scritto a Jacopo, riflettuto su alcuni aspetti di questa metodologia di lavoro e… sono appena agli inizi. Mi ci vorrebbe un personal coach!

Però, qualcosa è cambiato. Dopo quella famosa riunione a sorpresa, per quello che mi riguarda e in questi pochi mesi, è cambiato tutto l’approccio al progetto grafico per un sito web. In generale, le fasi ora sono più o meno queste: 1. spiegazione delle storie precedentemente definite con il cliente insieme al team di lavoro; 2. veloce schizzo dell’homepage per individuare gli ingredienti principali; 3. wireframe delle pagine più critiche; 4. sviluppo grafico delle pagine wireframizzate. E poi riunioni, correzioni, riunioni…

Il giorno che avrò imparato qualcosa di più sui primi due punti, dovrò scriverci un post. Sui punti 3 e 4, invece, anche se sono passati pochi mesi, mi sento di poter spendere parole di pura soddisfazione. In breve, il wireframe sta cambiando il mio modo di pensare a un progetto web dal punto di vista funzionale, così come il sistema a griglia sta cambiando l’aspetto visuale.
Prima di lavorare con i wireframe, grafica e interfaccia per me erano un tutt’uno. Il wireframe era uno schizzo veloce che facevo su carta e poi passavo direttamente alla grafica… È curioso, perché il wireframe in realtà è come un uovo di Colombo, una soluzione tanto semplice e funzionale quanto utile per dialogare con gli sviluppatori e discutere per tempo gli aspetti critici di un’interfaccia. In un caso abbiamo potuto usarlo per discutere in modo molto costruttivo con il cliente e spero che possa ricapitare. Dal giorno in cui ho iniziato a progettare usando i wireframe, le pagine che produco in questo modo diventano un supporto alla grafica: mentre la grafica risolve l’aspetto visivo, il wireframe permette di valutare vari aspetti funzionali del sito e lo studio della navigazione; in più apre le porte a una discussione con gli sviluppatori, che possono decidere fin dall’inizio dove e come risolvere eventuali criticità.

Secondo alcuni il wireframe è solo il disegno a matita, che può essere fatto durante la riunione di riepilogo delle user stories, dopodiché si passa alla grafica. Io non la penso così. Il gruppo Information Architects, in questo articolo sul redesign per Internazionale lo chiama “sweet spot“: in italiano potremmo definirlo come dolce equilibrio tra gli elementi, anche se “dolce equilibrio” non è la traduzione letterale esatta. Da quando uso questo nuovo metodo di progettazione, mi viene spontaneo cercare quello “sweet spot” proprio durante la fase di wireframing, perché è in quel tipo di visualizzazione che vengono fuori i buchi, si avverte una mancanza, un’incomprensione, un’ambiguità nell’interfaccia.
Ci sono altri due aspetti impliciti nei wireframes, che mi piacciono in modo particolare, che vanno sfruttati e che non possono quindi risolveresi in uno schizzo al volo: la loro trasparenza e versatilità. Trasparenza perché mostrano lo scheletro della navigazione, senza grafica, che in questa fase potrebbe avere un effetto simile al fumo negli occhi; versatilità perché sono comprensibili, pur essendo nudi. Per ipotesi, si potrebbero usare per discutere non solo con il team, ma anche per fare test con gli utenti o per fare le prime valutazioni con il cliente.
In definitiva, il wireframe è lo strumento chiave, che può davvero semplificare le successive iterazioni di un progetto e dar vita a un’esperienza di navigazione decisamente più approfondita.

Il metodo che uso attualmente è questo:
schizzo a matita l’homepage ed eventualmente una o due pagine interne, mettendo a fuoco tutti gli elementi richiesti nelle storie e individuando il tipo di griglia più adatto.

Poi passo ai wireframe delle singole pagine: dato che ormai lavoro su pagine costruite tenendo conto di griglie e ritmo, mi preparo un file in Photoshop con le griglie visibili: questo file è il livello base per tutti i miei wireframe, che costruisco in Illustrator, in modo asciutto, senza grafica: solo contenuti e link, bottoni, etichette. Su questi wireframes aggiungo un livello con tutti i dubbi, note e ipotesi di funzionamento. Li discuto con il team di sviluppo e li correggo secondo tutte le valutazioni fatte insieme.

Infine, esporto il file Illustrator come psd e inizio a lavorare sulla grafica.

Forse questi passaggi Photoshop-Illustrator-Photoshop possono sembrare un po’ macchinosi, ma per ora mi ci trovo bene. Nel frattempo, sul sito http://wireframes.linowski.ca, ho trovato molte risorse per cominciare a ragionare la progettazione usando i wireframes. Ho iniziato a provare uno dei tool suggeriti, ma lo trovo un po’ legnoso. Ci proverò ancora, perché vorrei trovare un modo più rapido di produrre il wireframe. In fase di wireframing, credo di poter evitare di pensare alle griglie, così da recuperare tempo e freschezza durante la fase creativa, cioè il momento in cui passo a vestire di grafica il progetto.

Segnalo un ulteriore approfondimento in questa slide di Alberto Mucignat che giustamente definisce il wireframe come tool definitivo per la progettazione di una user experience.