àˆ il problema che si pongono i web designer quando devono presentare un progetto a un cliente. Si tende a voler mostrare direttamente la soluzione grafica finale in una immagine statica, il classico mockup costruito in Photoshop, e poi si cerca di far capire come questi mockup dovrebbero funzionare nella realtà , nel loro essere interattivi. Di pagina in pagina, magari con l'ausilio di flowchart che descrivono i possibili processi di navigazione degli utenti. Molto spesso le incomprensioni fra committente e sviluppatore (o designer) sono da ricercarsi proprio nella difficoltà  di far comprendere attraverso prototipi statici l'evoluzione funzionale di una serie di pagine, se non dell'intero sito.

Per questo molti designer hanno dimostrato la potenza, espressiva e funzionale, dei prototipi interattivi, in pratica quelli costruiti in HTML e CSS (con magari l'aggiunta di metodi Ajax o codice JavaScript). Tali prototipi presentano indubbi vantaggi rispetto alle immagini statiche in Photoshop:

  • modifiche globali possibili cambiando poche righe di codice;
  • la possibilità  di sfruttare l'interazione mostrando così al cliente cosa fa/farebbe effettivamente la pagina in risposta a una determinata azione o comportamento dell'utente;
  • l'eventualità  di riutilizzare il codice già  scritto nel progetto finale.

Oggi realizzare prototipi interattivi è ancora più facile grazie alle numerose librerie e framework e tool a disposizione che ne velocizzano il lavoro mantenendo valida l'estetica di base delle pagine finali.

Mockup o prototipi interattivi?

16 CommentiDi' la tua

Il tuo indirizzo email non sarà mostrato pubblicamente. I campi obbligatori sono contrassegnati da *

Prototipo interattivo? solo se il cliente paga per averlo. Oltretutto spesso in progetti di medie/grandi dimensioni wireframe, concept grafico, html e implementazione sono fatti da agenzie diverse, la vedo costosa far lavorare 3 aziende al prototipo interattivo.

Michele
Michele

Creare un prorotipo interattivo?Solo se il cliente non ne ha l'accesso. In caso contrario c'é il serio rischio di rimenere fregati dal cliente che sparisce senza pagare o voler pagare il giusto....Aldilà  degli usi a cui é adibito e della buona fede di chi lo propone...

Simulacron
Simulacron

Grazie del commento @Konte, in effetti la tua esperienza é sintomatica: il prototipo interattivo permette meglio di far capire come dovrebbe FUNZIONARE un sito, poi i classici mockup in Photoshop dovrebbero mostrare come si vedrà  il sito.

Kiko
Kiko

Ciao a tutti, parlo per esperienza personale presso clienti bancari, dove ormai le nuove applicazioni interne web-based stanno sostituendo le vecchie applicazioni COBOL. La grande utilità  di usare un prototipo HTML+Javascript é quella di rendere molto più intuitiva la navigazione del sito, in particolare quando vai alle riunioni dove non hai un cliente che decide ma ben 10/15 persone della banca, e ognuno di loro ha una vaga e personale idea di cosa vogliono e di come lo vogliono. Di sicuro, in realtà  più piccole, l'utilità  di immagini statiche é probabilmente la soluzione migliore. Relativamente a riusabilità  del codice, questo probabilmente non é quasi mai possibile, ma sicuramente non ti impegna molto realizzare delle pagine in puro HTML e quindi se poi sono da buttare... non é un grosso problema! Ciao a tutti.

Konte
Konte

Infatti adotto da un po’ un approccio parallelo: prototipo interattivo grezzo per far capire come funzionerebbe un sito, modellino in Photoshop per far capire che tipo di soluzioni grafiche si adotteranno.
esatto! la grafica in genere la faccio a parte, dopo il mockup ma puo' anche essere in parallelo (a seconda dei progetti) e questa divisione aiuta a far capire al cliente che NESSUNO DEI DUE deliverable e' finale. Altrimenti (per la mancanza di capacita' di astrazione di cui sopra) ti fanno la classica critica " ma perche' il pulsante e' quadrato?" indicando un box placeholder... Comunque per quanto riguarda wireframe e mockup per me rimane un grande classico il libro Information Architecture for the World Wide Web di Peter Morville.

pbattino
pbattino

@Kiko Ti ha risposto liciof per me. In queste tipo discussioni leggo sempre tante cose belle che, in un mondo ideale, sarebbero perfette. Il problema é che dall'altra parte c'é il cliente che, il 99% delle volte, vuole vedere la grafica del sito e vuole che gli piaccia fregandonese altamente se é statica dinamica, se quello farà  così o colì, se quell'elemento é li per quello o quell'altro motivo, se gli utenti entrando agiranno in un modo o nell'altro e così via. Non so poi che tipo di cliente voi abbiate, ma se noi dovessimo fare layout strutturali, layout grafici e layout interattivi prima di ricevere un'approvazione dai clienti perderemmo 2 mesi e verremmo mandati a quel paese più volte dal cliente che vuole il sito in 3 giorni.

Delio
Delio

Io sono per un mockup interattivo, scritto col codice, ma che sia una simulazione: niente chiamate AJAX, quelle si possono semplicemente simulare E se uno si mantiene sull'essenziale, secondo me fa anche più veloce che con i vari Photoshop & Co. In più capisci già  cosa avrai difficoltà  a fare e cosa invece può essere migliorato con poco sforzo, e chiaramente parti già  con una base

Qwertj
Qwertj

E provocatorio lo doveva essere per forza. Commento autorevole @Fabio.

Kiko
Kiko

ll post é provocatorio e la risposta é: dipende dal progetto. Se il progetto é complesso alcune interazioni possono essere rappresentate con diversi metodi: schizzi, wireframe, prototipo interattivo, prototipo HTML. Se stiamo parlando di rappresentazione di un'idea, di un interazione, di un sito web, non escludo a priori nessuno dei metodi di rappresentazione, perché ognuno ha i propri vantaggi e svantaggi. L'obbiettivo dovrebbe essere come comunicare al cliente una certa idea, e non quale strumento usiamo. Alcune persone non hanno capacità  di astrazione e non sarebbero in grado di comprendere un prototipo realizzato con Foundation o altri framework. Inoltre i vantaggi elencati possono essere vantaggi solo durante fase di realizzazione del prototipo. Ma per progetti complessi é un illusione pensare di riutilizzare tutto il codice che andrebbe comunque riscritto (in parte o totalmente). Infine scrivere codice e debuggarlo — perché comunque sempre di codice si tratta — toglie energie e concentrazione a tutto ciò che serve per definire il progetto. Senza contare che nelle mani sbagliate l'utilizzo di framework per realizzare prototipi può produrre risultati discutibili. Fabio

Fabio Sirna
Fabio Sirna

Bella discussione. In effetti a seconda dei progetti va bene un tipo di approccio (wireframe e prototipo interattivo grezzo, senza cioé preoccuparsi della grafica in un primo momento) o un altro tipo di approccio (modellino del sito in Photoshop, cioé tutta la parte estetica). E' vero quello che dice @Paolo: se ben progettati, i prototipi interattivi risultano già  codice utile per il progetto finale. @erik a beneficio di nessuno, ma la lista é presto fatta, almeno la mia personale: Mockflow, Balsamiq, Fireworks e/o Photoshop e XMind (per la parte delle mappe mentali, flowchart e roba simile). Il mio armamentario. Ma servirebbero articoli a sé stanti per spiegare per bene una qualsiasi lista di software di questo tipo. @pbattino sottoscrivo quanto hai detto. Infatti adotto da un po' un approccio parallelo: prototipo interattivo grezzo per far capire come funzionerebbe un sito, modellino in Photoshop per far capire che tipo di soluzioni grafiche si adotteranno. Un doppio sì permette di velocizzare il tutto: al codice del prototipo aggiungo la grafica ed é finita! @liciof giusto, però alle volte, mi sto accorgendo soprattutto in progetti che DEVONO FUNZIONARE, la parte grafica viene realmente alla fine di un lungo processo per "capire come tutto deve funzionare".

Kiko
Kiko