Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

dicembre: 2018
L M M G V S D
« Ott    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Categorie


Wireframe e prototipi: perché servono

AlbertoAlberto

Oggi il buon caro Jacopo ha riesumato un post di quattro anni fa con un commento che mi ha fatto ripensare a come oggi lavoriamo su wireframe e prototipi. È un tema di cui ha parlato anche Ilaria sollevando delle domande interessanti in coda al suo post.

A proposito di wireframe e prototipazione ho scritto nel tempo diverse cose:

Sebbene potrei fare alcune correzioni, credo che questi pensieri siano ancora validi. Solo una precisazione: spesso parlo di wireframe e prototipi intendendo sostanzialmente la stessa cosa. Per me oggi la differenza tra wireframe e prototipo è solo nell’interattività: il wireframe è statico, il prototipo è interattivo, ma valgono le stesse regole (flessibilità, modificabilità, bassa fedeltà).

Per fare un esempio, se si utilizzano software come Omnigraffle, Visio o Axure è possibile creare wireframe interattivi, che io chiamo prototipi. Si può anche rendere interattivo un wireframe con tecniche di paper prototyping, ma in ogni caso i tool oggi consentono una buona flessibilità.

Voglio essere ancora più specifico: quando parlo di prototipo intendo un artefatto del design che non interagisce in alcun modo con un server, ma è semplicemente un’evoluzione dei wireframe verso una forma più interattiva (link tra pagine, pulsanti funzionanti, menù a tendina, overlay, box che si espandono/contraggono, etc).

Detto questo, vorrei ribadire i due motivi principali per cui si utilizzano wireframe o prototipi per il lavoro nel design dal punto di vista dei benefici che portano al progetto e al committente:

Detto questo, ritorno alle domande di Jacopo e Ilaria e cerco di rispondere.

L’ultimo punto è veramente cruciale, perché segna una milestone per lo sviluppo del design nel nostro belpaese.

Dobbiamo abituare i clienti a lavorare in modo diverso, nuovo: prima si fa il progetto, poi si sviluppa. In fondo non succede lo stesso quando costruiamo una casa? Qualcuno ha mai costruito un palazzo senza prima chiedere a un architetto di fare il progetto?

Comments 18
  • odino
    Posted on

    odino odino

    Author

    sacrosante parole, quelle racchiuse alla fine. Nelle ultime settimane ho dovuto lottare spiegando che un lavoro, che sia di stima, progettazione o implementazione, è sempre un lavoro…


  • Ilaria Mauric
    Posted on

    Ilaria Mauric Ilaria Mauric

    Author

    Ciao Alberto,

    sono qui con Jacopo, durante la due giorni di coaching agile presso e-xtrategy. Abbiamo letto insieme questo tuo post e abbiano notato alcune differenze rispetto a quanto stiamo ipotizzando di fare, ragionandoci insieme. Spero che Jacopo venga qui a commentare, anche se probabilmente te ne parlerà anche dal vivo.

    – il wireframe e il prototipo possono essere realizzati in momenti diversi. Io posso proporre un wireframe, suggerendo alcune funzioni da studiare meglio con un prototipo interattivo. E poi posso passare al visual. Altre volte posso trovarmi il prototipo inserito dentro al visual (quindi un’alta fedeltà con dentro un pezzo in bassa fedeltà, per capirci).
    – tu dici che prima si progetta, poi si sviluppa. Quello che invece stiamo ipotizzando di fare in questi giorni è di avvicinare il momento dello sviluppo a quello del progetto. Per esempio: un wireframe approvato dal cliente può passare allo sviluppo, mentre io passo alla fase di visual. Questo perché, sempre in ottica di change request, ci potrebbero essere variazioni in ogni fase del lavoro. Se invece prima ho il progetto e poi passo allo sviluppo, le change request rischiano di non essere assorbite a dovere.
    – con Jacopo stiamo provando a capire quanto sia fattibile lavorare su grafiche incrementali, in modo da non avere salti troppo netti tra wireframe e proposta grafica.

    Un’ultima nota: ci capitano spesso progetti piccoli, dove le funzionalità sono definite e standard (per esempio: il sito di un’azienda che contiene una vetrine di prodotti e poco altro). In questi casi, il “prodotto finito” c’è… Questo per dire che, a mio parere, non tutti i progetti sono adatti ad essere affrontati in modo così graduale. Anche perché spesso il cliente non è pronto e, parlando fuori dai denti, il progetto non merita l’investimento di fare “formazione culturale” all’interlocutore. E qui si entra in un discorso di progetti, clienti e interlocutori giusti… mi fermo qui.

    Davvero notevole il punto in cui suggerisci che un progetto andrebbe pagato anche se non passa. In Italia, sarebbe una grossa sfida culturale… Dobbiamo tentare, se vogliamo collocarci in un mercato di vera qualità e non nel macero del “ti do tutto quello che vuoi”.

    Grazie per le risposte!


  • Alberto
    Posted on

    Alberto Alberto

    Author

    prima che sfida culturale è una sfida di mercato. comunque la nostra piccola esperienza dimostra come si possa stare sul mercato facendo SOLO il lavoro di progettazione.

    quindi si può fare. bisogna iniziare a dire no a un sacco di cose, però ne vale la pena, imho.

    ps: giuro che non sapevo che eravate in pair. poi dice che non esiste la telepatia…


  • Jacopo Romei
    Posted on

    Jacopo Romei Jacopo Romei

    Author

    Parto dal fondo e confermo che il percorso di Doralab è dei più affascinanti e ovviamente io sto qui da 2 anni a fare il tifo, come sai.

    Sul tema discusso sottoscrivo quasi tutto quello che ha scritto Ilaria, ribadendo la sostanziale bipartizione che soggiace a tutta la mia analisi, da ieri condivisa con Ilaria:

    – Il wireframe è un contratto? Bene facciamolo agire come tale per tutti, sviluppatori compresi. Il wireframe approvato è – come le user story – un artefatto già utile *a tutti*. Esiste? È approvato? Bene, che sia usato da tutti dal primo istante.

    – La progettazione visuale è sequenziale per natura? Io voglio spingermi oltre, io credo che la grafica possa essere trattata in maniera *più* concorrente, meno sequenziale. Occhio: “più”, “meno”. Sto evitando concetti “tutto o niente”. Sto cercando di capire se mitigare problemi, in qualsiasi misura. Per poi magari scoprire che questa misura potrebbe essere superiore alle aspettative che percepisco di questi tempi. Io ci credo di brutto.


  • Simone Economo
    Posted on

    Simone Economo Simone Economo

    Author

    Io ultimamente ho sperimentato un approccio che (credo) sia un po’ un ibrido fra wireframing, prototipazione e design visuale.

    Come dicevi tu Alberto, nel tuo post, in certi casi si può pensare di lavorare direttamente su HTML & CSS. In questo modo si ottiene immediatamente un wireframe a bassa fedeltà che, al tempo stesso, è anche un prototipo perché può essere facilmente reso interattivo. Il vantaggio di questa tecnica è che, usando “framework” (che brutto termine!) come 960.gs o simili, è possibile disporre gli elementi sul layout con estrema facilità, di fatto riducendo di molto tempi e fatica.

    Se il prototipo riceve l’approvazione del cliente si può procedere alla fase visuale, che in realtà è già iniziata nel momento in cui si usano HTML & CSS per lavorare, secondo il mio punto di vista.

    Secondo me, più che inventare nuovi modi di lavorare, il vero problema è, sempre come dici tu, “abituare i clienti a lavorare in modo diverso”. Ho presentato il prototipo (quello in HTML & CSS) a un cliente che non l’ha capito affatto. Perché in tutti gli altri settori i progetti vengono compresi e nel nostro no?

    Educare il cliente, questa dev’essere un’altra delle competenze dello User Experience Designer.

    Ciao!


  • Alberto
    Posted on

    Alberto Alberto

    Author

    @ jak / ilaria: potremo discuterne (eternamente), ma nella mia esperienza il design e lo sviluppo assieme non sono facilmente integrabili (tranne rari casi tipo Apple, per fare un esempio comprensibile a tutti). La realtà è che oggi a noi serve un po’ di distanza tra le due aree di competenza, per poter riuscire a riavvicinarci in futuro. Detto questo io mi riferisco a progetti piuttosto complessi e di una certa entità. Per il resto va bene tutto. E ognuno è liberissimo di integrare/modificare i metodi come meglio crede.


  • Alberto
    Posted on

    Alberto Alberto

    Author

    @simone: 960gs è ok, lo usiamo anche noi. sulla questione dei wireframe in html/css è una contraddizione in termini. il valore del wf è nella sua modificabilità (da parte di chiunque, anche dell’IA o del cliente), quindi per me usare codice è sempre un rischio. se poi per te funziona, va bene 😉

    sul fatto che “i clienti non capiscono” è una condizione normale: dobbiamo abituarci al fatto che dobbiamo spiegare le cose, fa parte del nostro lavoro (!). mi sa che ne avevo parlato in un altro post, ma adesso non lo ritrovo…


  • Jacopo Romei
    Posted on

    Jacopo Romei Jacopo Romei

    Author

    “La realtà è che oggi a noi serve un po’ di distanza tra le due aree di competenza, per poter riuscire a riavvicinarci in futuro.”

    E questo futuro quando sarà?
    E chi deciderà che sarà giunto?
    E soprattutto: chi saprà riavvicinarsi dopo il consolidamento di know-how *mantenuti distanti*?

    Mi convince davvero poco.

    Io devo rilasciare progetti ben progettati adesso.
    Io devo far lavorare interaction designer, grafici e sviluppatori adesso.
    Io insomma ho problemi adesso, intendo risolv… mitigarli adesso.

    Se i fratelli Wright avessero aspettato la fine della forza di gravità – lamentandone per giunta ogni giorno i nefandi effetti sull’industria delle mongolfiere – ora voleremmo?


  • Simone Economo
    Posted on

    Simone Economo Simone Economo

    Author

    Solo una precisazione sul discorso dei wireframe: per me HTML & CSS funzionano perché sono stato abituato a lavorarci fin dall’inizio della mia “carriera” e riesco ad apportare le modifiche con estrema facilità. Conosco tante altre persone come te che, tuttavia, non ci si trovano ed è normale perché ovviamente non esiste un approccio che funziona per tutti.

    Quello che volevo dire è che soffermarsi su come ognuno di noi lavora va bene fino a un certo punto. Provocatoriamente dico: perché non spendere più tempo e più parole, invece, per capire in quali modi comunicare in maniera più efficace col cliente?

    Premetto che non ho molta esperienza sul campo, però non credo che, oggi come oggi, il problema sia la mancanza di strumenti per progettare. Io credo che la vera sfida sia far percepire appieno il valore di questo sforzo.


  • Alberto
    Posted on

    Alberto Alberto

    Author

    ok parlavo di massimi sistemi, ma sapevo che ti saresti scaldato.

    al momento io non ho grandi risposte: se vuoi far lavorare interaction designer, grafici e sviluppatori assieme, la mia risposta è “buona fortuna”.

    nel senso che è difficile, specie in un mercato che già confonde ampiamente competenze e attività. se non riusciamo a comunicare bene competenze e attività degli interaction designer, difficilmente riusciremo a capire come integrarli nei team. e probabilmente per ottenere questa conoscenza io dico che serve un po’ di “distanza” (intesa come “distacco” per capirci). qualsiasi cosa voglia dire.

    detto questo, in tutto il mondo design e sviluppo procedono in track parallele, quindi quello che state facendo voi forse è molto difficile da realizzare (oppure non ci ha ancora pensato nessuno, ma ne dubito).


  • Jacopo Romei
    Posted on

    Jacopo Romei Jacopo Romei

    Author

    Sì… magari il mio commento era un po’ meno “contro” e un po’ più costruttivo, ma il punto è chiarissimo 🙂


  • Alberto
    Posted on

    Alberto Alberto

    Author

    perdono, a volte sono un po’ tranchant. e ho dimenticato un 😉 alla fine della prima frase 😉

    mi spiego meglio: è difficile mettere assieme tutto come vorreste voi, ma non impossibile (“l’impossibile non esiste, necessita solo un po’ più di tempo”, diceva un mio prof).

    quindi, ripeto, fate bene a provarci, ma nel mio caso (parlo della mia azienda) al momento non ha molto senso, perché facciamo sostanzialmente solo up-front design.

    per il resto, mentre facevo la mia pedalatina serale, pensavo che il cuore è sempre il “deliverable attuale”. se siete ormai oltre i wf e state ormai lavorando a un prototipo evoluto, è chiaro che non ha senso utilizzare i wf, se non per comunicare modifiche o evoluzioni o nuove pagine. insomma, mi “staccherei” dal pensare solo ai wf e ragionerei su come documentare l’incrementalità.

    ok, è quello che dicevi tu, ma attenzione che non ho una risposta certa, posso solo dire che i wireframe non sono adatti a tutte le fasi di un progetto e non possiamo pretendere che comunichino alla stessa maniera in ogni fase… (ma anche queste cose le avevo già dette).


  • Davide ‘Folletto’ Casali
    Posted on

    Davide ‘Folletto’ Casali Davide ‘Folletto’ Casali

    Author

    Aggiungo qualche considerazione ulteriore ai discorsi che stavate facendo, che mi è venuta in mente lavorando in questi mesi in modo molto agile e su progetti sia dove c’era il tempo di fare progettazione sia no.

    1. Comprensione Agile: lavorare con il wireframe in modo davvero agile permette al cliente di meglio capire cosa poi significa un wireframe, perché più il processo è agile più vede come un wireframe diventa grafica e poi codice: così facendo il wireframe successivo viene compreso molto meglio.
    —Ovvero—
    Anche questa è cultura, semplicemente l’aggiunta qui è che il design beneficia delle metodologie agili proprio per il boost di comprensione che si ottiene.

    2. Olismo: credo lo stiate dando tutti per sott’inteso, ma un processo di design *non* può essere frazionato come le user story. Quindi una fase iniziale “waterfall” di UXD è imprescindibile.
    —Ma—
    Se astraiamo per un secondo (nonostante sia pericoloso) in realtà il nostro lavoro è ottenere un prodotto finale X.

    Questo significa che dopo la fase iniziale di obbiettivi, strategia, metriche, kpi, etc, il wireframe di alto livello è PROPRIO il prodotto finale X.

    In altri termini, si tratta di un gradiente, dove il passaggio fra wireframe, visual design, sviluppo e prodotto finale è puramente concettuale dovuto alle diverse competenze che si esprimono meglio nelle varie fasi.

    E’ quindi da intendere che il primo wireframe del prodotto X è proprio la prima iterazione agile. E’ fatta da una persona che fa UX? Bon, che importa?
    Poi pian piano si raffina e sono tutte iterazioni. Poi c’è il “salto” quando si passa al prototipo perché si aggiunge un pezzo.
    Poi c’è un altro “salto” quando diventa visual design. Ma è ancora il nostro prodotto X, solo che si è ancora più rifinito.
    E così arriviamo allo sviluppo, dove il prodotto raggiunge un grado di rifinitura ancora maggiore – così rifinito che è ora funzionante – fino al rilascio finale.

    Il “problema” nasce dal fatto che le varie fasi sono in mano a persone differenti e che ci sono dei “salti” che a volte creano dei passi indietro (un po’ come se si rompesse la test suite: “ops, ora sono passato in visual design e il click sulla pagina X non funziona più”).

    Luca diceva tempo fa che è essenziale una fase iniziale di design per poi passare allo sviluppo agile vero e proprio.

    Ma oggi, con più esperienza, ho maturato l’idea che l’UX è già di per sé agile: è *fondamentale* nel nostro lavoro produrre materiale, fare iterazioni veloci, produrre qualcosa di “funzionante” e farlo “testare” la cliente in modo che possa darci un feedback e modificare rapidamente il prodotto per rifinire ulteriormente l’interazione.

    Quindi:
    a. siamo agile dall’inizio alla fine, la separazione in fasi è puramente funzionale per esprimere meglio le competenze dei singoli
    b. le iterazioni UX sono molto più rapide (potrei dire che io idealmente faccio “sprint” di due giorni: 1 giorno design + 1 giorno workshop con il product owner).


  • Alberto
    Posted on

    Alberto Alberto

    Author

    davide, grazie per il tuo contributo. e dico sul serio. sottoscrivo tutto.

    però faccio un’osservazione, visto anche il post di Jacopo “Sviluppo Agile” Romei.

    davide alla fine dice:

    “siamo agile dall’inizio alla fine, la separazione in fasi è puramente funzionale per esprimere meglio le competenze dei singoli.”

    insomma, possiamo sempre considerare il lavoro a cicli (in effetti è quello che facciamo anche nella mia azienda), ma le competenze durante i cicli possono cambiare.

    per esempio si può fare un ciclo di IA (che produce un low-fi wireframe con le sole informazioni), uno o più cicli di IxD (che produce wf con interazioni), si può passare al visual, al codice, etc. ma rimane quello che ho detto: il wf/prototipo è il centro del progetto, che si evolve continuamente.

    ma il senso del lavoro di jacopo è come mettere assieme sviluppatori e designer. rispetto alle oservazioni di davide, la soluzione è che quando si passa a un prototipo si procede sempre a iterazioni, ma cambiano le competenze interne al team. per esempio l’interaction designer rimane dentro il team e lavora con sviluppatori.

    si può fare, non vedo perché no, non ci sono controindicazioni.

    nel mio caso però non è possibile, per un semplice fatto commerciale/strategico, se volete. ma in altre agenzie probabilmente ha senso e funziona.


  • Alberto
    Posted on

    Alberto Alberto

    Author

    ps: davide, ma “luca” sarebbe mascaro? no perché messo così “Luca diceva tempo fa…” si potrebber confondere con quello del vangelo ;-D