Le mie risposte a Ilaria Mauric

Dopo il workshop DotNetMarche di ancona è nato un interessante dibattito sul blog di Ilaria Mauric che di mestiere fa il “desinger di interfacce”. Cercando di non perdere la mia, di faccia, cerco di dare qualche risposta alle domande che Ilaria mi pone nel suo post.

D: dove collochiamo il wireframe?
R: stiamo andando sempre più verso uno scenario in cui esigenze di funzionalità e comunicazione si mescolano nello stesso “software-intensive system” come viene definito nella ANSI/IEEE 1471. Se stiamo affrontando un progetto in cui l’obbiettivo principale è la comunicazione, credo che dovremmo partire dal wireframe, ed una volta definito l’aspetto più critico del nostro sistema affrontare quello funzionale. Se al contrario l’aspetto critico sono le funzionalità, dovremmo concentrarci maggiormente su quelle e sull’usabilità del sistema. Ciò non toglie che ad esempio un tool come Expression SketchFlow permetta di sviluppare entrambe le fasi, oppure se preferiamo usare tool diversi, possiamo realizzare i wireframe con gli strumenti a cui siamo abituati e includerli nello sketch dove implementeremo la parte interattiva.

D: se il wireframe, il prototipo e la grafica non mostrano mai un prodotto definito, quand’è che lo vede il cliente?
R: una delle cose che abbiamo cercato di dire ad Ancona è che il cliente va coinvolto nel processo: se arrivassimo a mostrare al cliente solo il sistema ad uno stato “funzionante”, in cui abbiamo incastrato grafica e funzionalità rischiamo di dover tornare sui nostri passi, e probabilmente lo dovremmo fare a nostre spese. E’ quindi necessario coinvolgere il cliente sia nella discussione (e approvazione) del wireframe, del prototipo e della grafica e di tutti quegli artefatti che permettono di avere un quadro teorico del funzionamento del nostro sistema prima di affrontare il processo di sviluppo, nel quale il cliente andrà comunque coinvolto periodicamente.

D: il prototipo mostra necessariamente dei bottoni e dei contenuti impaginati, anche se a livello molto grezzo. Quanto cambiano queste impaginazioni dal prototipo alla grafica?
R: Il prototipo serve a rappresentare sia le funzionalità del nostro sistema, sia la sua usabilità. E’ importante che in questa fase vengano definiti il posizionamento dei controlli che la loro dimensione, con un margine di tolleranza tale da non inficiare il livello di usabilità che abbiamo rappresentato nel prototipo dinamico. Il cliente si aspetterò di trovare le cose più o meno dove le abbiamo messe nello sketch.

D: quand’è che è giusto studiare la grafica? prima, durante o dopo il prototipo?
R: come ho detto nella prima domanda non c’è una regola, dipende da quanto e cosa la grafica deve comunicare all’utente. Se stiamo sviluppando un chiosco interattivo per bambini, probabilmente la grafica sarà la prima cosa a cui pensare, mentre in un classico gestionale, dove spesso l’aspetto emozionale è sottovalutato, probabilmente penseremo prima al prototipo.

D: il prototipo serve per la quotazione e questo è un sogno per gli sviluppatori. Loro possono quantificare un progetto su una base piuttosto chiara, ma se poi il progetto non passa?
R: il prototipo può essere utilizzato per capire il “peso” del sistema che ci hanno chiesto di progettare. In questa fase non ci preoccuperemo delle funzionalità in modo approfondito. Normalmente in 4 o 5 screen al massimo si è in grado di capire la complessità del sistema: poco più di un’ora di lavoro. Inviando uno Sketch interattivo al cliente, però è maggiore l’efficacia della nostra comunicazione ed è abbastanza raro (per la mia esperienza) che il progetto non venga approvato. Diverso è il prototipo che possiamo realizzare per discutere in modo approfondito le funzionalità dell’applicativo e che deve essere quotato come tutte le altre fasi dello sviluppo.
Nel mondo della carta stampata il costo della stampa è tale che la fase di pre-press spesso arriva a costruire un prototipo pressoché identico a quello che verrà stampato sul quale si chiede l’approvazione finale del cliente: è il famoso “visto si stampi”. Nel mondo digitale la fase di stampa non esiste,  e quindi arrivare dal cliente con un oggetto in stato di sviluppo avanzato significa rischiare di sprecare risorse economiche e umane, magari non saremo noi a dover pagare, ma sicuramente chi dovrà farlo non ne sarà felice.à

Senza la pretesa di aver in tasca la verità assoluta, spero di aver portato il ragionamento sui giusti binari. Alla prossima!

Print | posted on sabato 24 luglio 2010 00:36

Comments on this post

# re: Le mie risposte a Ilaria Mauric

Requesting Gravatar...
L'ultima risposta è mooooolto ottimistica. andrebbe bene per un'applicazione tipo apple marketplace, ma nelle applicazioni mediamente enterprise in un'oretta forse cpisco di che cosa sta parlando il cliente...
Left by Roberto Messora on lug 23, 2010 11:04

# re: Le mie risposte a Ilaria Mauric

Requesting Gravatar...
Roberto, in un'applicazione enterprise relizzeremo il prototipo dei 4 o 5 screen core che dovrà avere il sistema, non entreremo certo nei dettagli.
Left by Alessandro Scardova on lug 23, 2010 11:54

# re: Le mie risposte a Ilaria Mauric

Requesting Gravatar...
@Roberto: stiamo parlando di cose diverse. una cosa è lo scheth usato per comunicare al cliente i costi che dovrà circa circorum sostenere. Un conto è un prototipo, realizzato a spese del cliente, nel quale si analizzano in profondità i rquisiti.
Left by Alessandro Scardova on lug 24, 2010 10:54

# re: Le mie risposte a Ilaria Mauric

Requesting Gravatar...
In un progetto con 6 mesi solari del team, una settimana di elicitazione dei requisiti spesso non basta, direi una settimana iniziale per costruire il primo backlog, poi ogni mese un ricontrollo requisiti e prioritizzazione ancora.

Comunque per esperienza, i mockup di interfaccia aiutano molto anche per i requisiti.

alk.
Left by Gian Maria on lug 24, 2010 11:10
Comments have been closed on this topic.