Grazie alla segnalazione di Stefano Ottaviani, ieri ho seguito quasi tutto il 16° workshop organizzato da DotNetMarche: “Applicazioni SOA con Silverlight: dal design al deploy”, all’Università di Ancona (Facoltà di Ingegneria).
Ho ascoltato le sessioni mattutine, mentre quelle pomeridiane si sono rivelate troppo tecniche, per me. Così ne ho approfittato per scrivere questo post.
Mi è sembrato che il seminario fosse rivolto perlopiù agli sviluppatori ma, anche questa volta, ho notato che le questioni di usabilità, interfaccia utente, architettura dell’informazione, feedback e test sono considerate parte dello sviluppo, al pari del resto del lavoro.
Devo confessare che non conoscevo diversi termini usati durante le presentazioni (al di là degli interventi tecnici)… a partire proprio dal titolo del workshop: da oggi, spero di ricordarmi i termini SOA e deploy. Magari non il loro significato preciso (roba da ingegneri…) ma almeno la loro esistenza. :)
Vorrei dare un consiglio a tutto il gruppo DotNetMarche e anche ai relatori: per favore, condividete le vostre slide (magari su SlideShare)! Durante il workshop ho dato per scontato che le avrei trovate online e ora non solo non trovo i titoli, ma non posso neanche inserirle in questo post. O forse sono io che non vi trovo.. quindi rendetevi più “trovabili”. :P
Le sessioni introduttive di Ricci e Servienti.
La prima sessione della giornata è stata di Gian Maria Ricci, che ha spiegato i motivi per cui il metodo waterfall non è più adatto a risolvere i problemi di sviluppo e ha introdotto il concetto di agile, spiegando motivi e metodi.
Mauro Servienti ha proseguito inquadrando alcune delle questioni centrali relative all’impostazione di una nuova applicazione, basandosi su problemi riscontrabili nel mondo reale: trovare il giusto interlocutore, fare le giuste domande, ricordarsi in tutte le fasi dello sviluppo che il focus è sull’utente, il dialogo all’interno del gruppo di lavoro e con il cliente (evitando i tecnicismi). Anche nel suo intervento, ho notato che il metodo agile viene dato per scontato, al punto che è ovvio che il gruppo di lavoro scriva, discuta e condivida le storie. Infine, anche per Mauro, le storie dovrebbero essere indipendenti tra loro e comportarsi quasi come se fossero microapplicazioni, perfettamente funzionanti al momento del rilascio.
Prototipi con Sketchflow di Scardova.
Alessandro Scardova ha presentato una sessione molto pratica. Inizialmente, ha spiegato l’importanza dei prototipi e la necessità di avere un feedback dagli utenti. Poi ha mostrato come usare Expression SketchFlow per avere degli “schizzi” interattivi online, utilizzabili dagli utenti che possono anche lasciare un commento. In questo modo, il gruppo di lavoro avrebbe un prototipo funzionante e pieno di appunti lasciati dagli utenti.
Il suo intervento è quello che mi ha aperto più domande, ma purtroppo non c’è stato il tempo di fargliele in diretta. Gli segnalerò questo post, sperando che abbia voglia e tempo per venire a rispondere qui.
Alla ricerca della parola giusta (cioè dello strumento e del metodo giusti).
In diversi (ormai tantini) anni di lavoro, ho sentito molte parole legate al concetto di schizzo / prototipo, ma ogni settore (dalla carta al web) sembra usarle senza una vera soluzione di continuità: perciò posso dire bozza, draft, menabò (o menabau), timone, mockup, wireframe… ogni volta avendo il sospetto che dev’esserci un modo “definitivo” di usare questi termini.
A naso, mi viene da dire che bozza e draft sono la stessa cosa. Una bozza mostra una proposta grafica che verrà usata come guida durante lo sviluppo. In un’ottica di sviluppo agile, la bozza potrà avere diversi dettagli variabili e dovrà mostrare il look&feel del sito. Fino a qualche tempo fa, la grafica mostrava tutte le funzionalità del progetto. Negli ultimi anni, però, i progetti sono diventati sempre più complessi e abbiamo visto che questo non è più possibile. Perciò in grafica si prevedono diversi ingombri che verranno approfonditi meglio in fase di sviluppo (o forse di prototipo, il giorno che capirò meglio come farne uno).
Il prototipo è una specie di schizzo (sketch.. altra parola da aggiungere all’elenco) interattivo che verrà usato come strumento per discutere con l’utente delle funzionalità e delle criticità legate al progetto. Individua le principali questioni d’uso e funzionalità, ma non le approfondisce. Anche qui, gli approfondimenti verranno fatti in fase di sviluppo.
Alessandro, all’inizio delle sue slide, ha detto anche che il prototipo è utile in fase di quotazione, perché mostra a grandi linee il funzionamento e le criticità del progetto.
Forse è solo una questione di parole, ma non ne sono molto sicura… Certo è che mi piacerebbe usare le parole giuste per le cose che faccio. :)
Le mie domande.
- dove collochiamo il wireframe? Per me ora il wireframe è utilissimo per decidere i pesi grafici e i principali contenuti del progetto. Spesso ci è servito per scrivere le storie, altre volte sono partita dalle storie e ogni elemento del wireframe ne soddisfa una. Mi piacerebbe creare un wireframe interattivo… Ma dovrei forse separare le due cose? cioè usare il wireframe più per un discorso grafico e il prototipo per un discorso di funzioni e usabilità?
- se il wireframe, il prototipo e la grafica non mostrano mai un prodotto definito, quand’è che lo vede il cliente? In teoria, durante i rilasci frequenti che verranno poi corretti in base ai feedback… Eppure, si è detto più volte che questo sarebbe un rischio per gli sviluppatori.
- il prototipo mostra necessariamente dei bottoni e dei contenuti impaginati, anche se a livello molto grezzo. Quanto cambiano queste impaginazioni dal prototipo alla grafica? se l’utente si è abituato a trovare nel prototipo un menù a sinistra e una scheda organizzata in un certo modo, quanto posso allontanarmi da questa impaginazione al momento di studiare la grafica?
- e infatti, quand’è che è giusto studiare la grafica? prima, durante o dopo il prototipo?
- 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? chi ci rimette è quello che ha investito il tempo a creare il prototipo e testarlo… Come si fa in questi casi? Finché il “prototipista” lavora in azienda, è comunque l’azienda che perde l’investimento; ma se il prototipista è un freelance (ehm… tipo me) alla fine è solo lui (o lei :P) che ci rimette… Forse andrebbe fatto sempre un accordo a monte tra prototipista e sviluppatori, per dividere onori e oneri?
Concludendo.
Una delle questioni che vorrei tentare di risolvere rimane sempre il ruolo della grafica, intesa anche come comunicazione. Continuo ad avere l’impressione che certi metodi funzionino su progetti molto tecnici o destinati a un uso riservato. Ma per quelle interfacce in cui la comunicazione gioca un ruolo fondamentale, mi sembra improbabile che il cliente (e in fondo anche l’utente quando testa) capisca un box grigio al centro della grafica e un prototipo in Comic Sans. Il proposito di creare un progetto davvero utile per l’utente è ineccepibile, ma spesso i progetti non sono fatti solo di funzionalità. È su questo confine labile tra uso e comunicazione che sto cercando l’equilibrio giusto per inserirmi nel flusso delle iterazioni, senza perdere di vista l’aspetto comunicativo ed emozionale che un’applicazione potrebbe contenere.
39 Commenti
Ciao Ilaria,
a quest’ora non ho la lucidità sufficiente per analizzare e rispondere completamente al tuo post, lo farò meglio da domani, ti posso mettere anche in contatto con Alle (Alessandro Scardova).
Intanto ti posso dire che si, come hai notato, DotNetMarche e DotDotNet si rivolgono principalmente a sviluppatori su una specifica tecnologia (il Microsoft .Net Framework), il fatto che oggi abbiamo avuto anche altre figure come quella del designer è stata una cosa particolare perchè abbiamo voluto mostrare appunto le varie fasi del ciclo di sviluppo (con gli ovvi limiti dettati dal tempo a disposizione).
Per quanto riguarda le slide, i workshop che facciamo sono di fatto tenuti da “volontari” che preparano il tempo libero, e come puoi immaginare non di rado capita di terminare il materiale all’ultimo, il giorno prima o anche il giorno stesso! Per questo le mettiamo a disposizione nel sito con calma i giorni successivi all’evento.
A presto!
L’attività di analisi / mockup ha un costo che non sempre può essere nascosto al cliente. Il mio consiglio, su progetti non banali, è quello di separare il progetto in due fasi (con due offerte separate): primo step realizzazione prototipo, secondo step realizzazione del progetto.
Per il resto credo che le tue domande vadano rivolte più ai designer che agli sviluppatori. Trovi qualche considerazione in merito sul blog di Daniela http://tech.piyodesign.it/archive/2009/07/13/agile-and-prototyping.aspx
Ilaria, prima di tutto grazie per quello che hai scritto sulla mia sessione. I tuoi questiti, non banali, mi hanno sollecitato almeno due ragionamenti: un primo sulle differenze tra prototipo digitale e “reale” (il menabò per esempio); il secodo sulla sovrapposizione tra funzionalità e comunicazione di un progetto software.
Ragionamenti che vedrò di esternare non appena avranno capo e coda…
Grazie ancora!
Grazie del suggerimento per quanto riguarda le slide. Vedremo di tenerlo presente per la prossima volta :) e pubblicarle prima dell’evento su slideshare.
Alk.
È normale pubblicare le slide dopo gli incontri, non volevo farvi così tanta pressione! :D È solo che non ho trovato il programma dell’evento né i vostri account (o quello del Gruppo DotNet) in giro, né su SlideShare né altrove.
Ciao Ilaria,
grazie per il feedback, i complimenti e gli interessanti spunti e quesiti che hai esposto, sarebbe interessante approfondire ed elaborare, speriamo ci sia l’occasione.
.m
Sulla pubblicazione, debbo dire però che l’idea che chi ha un portatile, o un netbook possa scaricarsi le slide il giorno prima, oppure magari direttamente all’evento è interessante. In questo modo è possibile seguire meglio, anche in situazioni dove magari il proiettore è più piccolino e si vede meno bene.
Mi associo a mauro nel farti i complimenti per i tanti spunti :) è bello vedere feedback di questo tipo.
alk.
Aggiungo anche che se siamo riusciti a coinvolgere, con evidente interesse, una figura professionale come la tua allora abbiamo centrato in pieno il nostro obiettivo che era, tra i tanti, proprio dimostrare come le sinergie del team siano vincenti rispetto ad un team di “solitari muti”.
.m
@mauro: non c’è dubbio! personalmente, trovo molto utili questi workshop così pratici. È mettendo le mani su un lavoro che si vedono meglio le situazioni, le criticità e le dinamiche, quindi grazie a voi!
@andrea: avevo letto il post che hai spedito e in effetti sembra uno dei pochissimi link in cui si parla di processi di design dell’interfaccia in un contesto di sviluppo agile… Ci sarebbe davvero tanto da scrivere e approfondire. Lo spunto di creare due preventivi separati (uno per il prototipo e uno per lo sviluppo) può essere valido, ma temo solo su progetti molto grandi. Ci sono altre scuole di pensiero che invece sostengono che queste lavorazioni devano essere incluse nel prezzo, altrimenti il cliente chiederà di tagliarle via come “costi non necessari”… Un esempio tipico è quello dei test con gli utenti: messo come costo a parte, è sempre il primo che salta. E se queste lavorazioni vengono tagliate via, che fa lo sviluppo senza il prototipo (che avete dimostrato essere molto molto utile)?
Riflettendo su quello che Ilaria ha scritto, a pelle mi viene da pensare che si possono distinguere due tipologie di progetti in base al livello di “grafica” richiesta (non saprei al momento come esprimerlo in modo migliore):
– quelli che Ilaria, se ho ben capito, definisce progetti “tecnici”, per capirsi quelli che spesso finisco praticamente per non avere una grafica vera e propria, hanno giusto quella specie di “scheletro” (mi piace definirlo così) realizzato dallo sviluppatore: un po’ come se al cliente fosse consegnato, come prodotto finito, quello che nel workshop avevano creato Mauro e Giorgio, senza alcun intervento del designer.
Questi progetti non li definirei propriamente “tecnici”, semplicemente li indicherei come quelli in cui il cliente richiede una funzionalità che viene soddisfatta in qualche modo da quello che produce lo sviluppatore, e ciò finora è stato fatto senza considerare più di tanto gli aspetti della UX.
Ora, vuoi perchè finalmente i tempi sono maturi (ed in questo apple ha probabilmente contribuito moltissimo), prima di consegnare il lavoro al cliente, si può introdurre una figura da designer che possa mettere una “skin” sopra allo scheletro (di fatto è questo che le tecnologie che abbiamo visto venerdì permettono di fare).
Però questo è un di più, finora il cliente avrebbe utilizzato (probabilmente con meno soddisfazione) il prodotto anche senza la presenza di questa veste grafica decente (oppure in presenza di più prodotti in concorrenza, questo poteva essere un parametro che faceva la differenza).
– l’altra tipologia di progetti è quella in cui invece la veste grafica è fondamentale, mi viene in mente come esempio più naturale un sito web vetrina.
Se ho capito bene, questo è proprio l’ambito in cui lavora principalmente Ilaria.
In questo contesto, dove invece io non ho molta esperienza, credo che il prototipo debba essere molto più focalizzato su quella che in precedenza ho definito “skin” del sito, la cui elaborazione sarà quindi eseguita molto prima nel ciclo di vita, per evitare di dover buttar via gran parte di ciò chè è stato realizzato.
Ciao, mi inserisco anche io :)
Dal mio punto di vista (sviluppatore/architetto) occorre prima di tutto analizzare il target a cui sarà diretto l’applicativo (grande pubblico/backoffice di azienda , etc etc…). Questo già in prima analisi indica che tipo di prototipo sarà necessario realizzare e le principali caratteristche che dovrà avere.
Comunque ritengo sempre prioritaria la necessità di avere un prototipazione di tipo ‘funzionale’ all’inizio coinvolgendo il maggior numero possibile di figure professionali che contriburianno alla realizzazione in primis: l’architetto (che decide sullla possibilità o meno di realizzare diverse feature), l’esperto di UX/Designer che decide come ‘esporle’ all’utilizzatore.
Poi, a seconda del tipo di applicazione, si decide quanto/come investire nel prototipo (il doppio preventivo come suggerisce Andrea sarebbe l’ideale).
Se l’applicazione è un backoffice e/o soluzione interna un prototipo minimalista ci sta..ed è anche consigliato (per non cadere nell’errore che il cliente lo scambi/consideri come l’applicazione definitva).
Se l’app è diretta al ‘grande pubblico’ l’impatto grafico e l’usabilità hanno sicuramete un peso maggiore e dovrebbero essere inseriti sia in fase di prototipazione che negli ‘early stage’ dello sviluppo (per prevenire/assorbire prima eventuali problemi derivanti dall’uso di ‘effetti particolarmente speciali e colori ultravivaci’ che magari non sono cos’ banali da implementare).
ahahah Stefano…abbiamo più o meno scritto le stesse cose contemporaneamente :D
La divisione che fai è più o meno corretta. Ci sono però dei casi intermedi (come sempre). Uno di questi è proprio l’esempio che ha fatto Mauro: supponiamo di lavorare sul sito di un’azienda che fa assicurazioni online. Su un progetto come questo, avremmo diversi prototipi oltre a numerosi test con gli utenti. Da un lato avremmo i preventivi / ordini che chiederà il cliente; dall’altro il controllo dei preventivi / ordini da parte dello staff, che avrà tutta un’altra gestione… Ma essendo di solito aziende grandi, non è che allo staff puoi dare uno scheletro… Anche quello dovrà essere fatto con una skin grafica in linea con il resto della comunicazione aziendale.
Lo specifico giusto per inquadrare i contesti non pensare di dividere tutto in bianco e nero.
La mia opinione a riguardo è questa, il prototipo di interfaccia serve principalmente a creare uno sketch che aiuta il cliente (persona non tecnica) a materializzare nella sua testa cosa verrà sviluppato.
A questo punto gli sviluppatori partono, e se si usano processi agili, il prima possibile il cliente deve avere i primi “deliverable” il cui scopo è implementare le prime user stories. A questo punto basta mettere nel backlog anche le attività “Grafiche” e non si hanno problemi. Se si segue l’approccio agile, è il cliente a prioritizzare le features del backlog, e se ritiene che l’aspetto grafico è realmente un aspetto importante lo prioritizza. Potrebbe essere questa un’idea.
alk.
@Gian Maria: è vero, sarà che i lavoro su progetti… chiamiamoli pubblici, dove la comunicazione c’è; ed è quindi per questo che trovo davvero difficile conciliare uno sviluppo agile con il mio lavoro. Ce la sto mettendo tutta e, quando si tratta di affinare il progetto o sistemarlo in base a piccole correzioni (piccole microstorie riviste, tolte o aggiunte) ci riesco. Ma ci sono clienti che non possono capire un progetto se non vedono la grafica. Semplicemente uno skecth non gli basta… e li posso capire. Anch’io avrei difficoltà. Cadremmo nell’errore che diceva Marco: evitare i tecnicismi. Al cliente non gliene frega niente ed è vero! Questo vale in particolare su progetti fatti con clienti nuovi… se il cliente ti conosce e ha fiducia, sono strade che si possono percorrere. Ma se lo devi conquistare, in progetti dove la comunicazione gioca la sua parte, se il cliente non vede la grafica o la comunicazione, non si convince… e hai voglia a dirgli che ora no, la grafica non conta, l’importante è capire che se l’utente clicca lì succede quello.
Ho almeno due tre lavori recenti su cui mi sono scontrata con questa cosa… dovrò parlarne con il coach Jacopo, al Campo Scuola di settembre.
E cmq, non per fare muro, per carità, però davvero, il rischio di spezzare i preentivi è che il cliente tagli via una parte di lavoro che per gli sviluppatori è fondamentale.
Sullo spezzare i preventivi, è difficile sono daccordo. Il mio approccio è molto più, da sviluppatore e a volte project manager, sulla raccolta requisiti. La mia esperienza mi porta a concordare con il Mitical Man Month, la parte più difficile di un software è capire cosa deve fare.
Il mio lavoro spesso si incontra con realtà industriali, dove la grafica è assolutamente in secondo piano, o comunque in progetti dove la parte più difficile è proprio capire le esigenze del cliente. Spesso mi sono sentito dire che il cliente guarda soprattutto la grafica ed è vero… però poi mi sono trovato a far si che il cliente fosse molto soddisfatto dell’aspetto grafico :) e poco del prodotto stesso.
Negli anni di esperienza che mi sono fatto, l’80% (e non scherzo) dei problemi non sono stati tecnici, o di comunicazione etc etc, ma sono stati causati da una analisi dei requisiti insufficiente, incompleta, o completamente errata.
Per questo mi sforzo sempre di capire come fare a capire quello che vuole il cliente, e quindi meglio non distrarlo con grafica o altri orpelli, per lo meno nella prima fase.
Poi è chiaro, che se il lavoro verte per l’80% sul dare un aspetto grafico ad un sito, li la grafica viene prima di tutto. Nei miei progetti l’80% del problema è legato a processi industriali, oppure di altro tipo. ;)
alk.
qui ci tocca organizzare una cena perchè questa discussione si sta facendo interessante… quando? :-P
Tornando in topic: parto da lontano, Ilaria ha parlato di biano e nero, è ovvio che non ci sono verità ed è ovvio che ogni volta il processo è da riadattare sul cliente e da calare nel contesto.
Condivido anche l’esperienza portata da Ilaria quando dice che con clienti che si fidano è facile approcciare in un modo mentre con altri bisogna conquistarsi la fiducia, stessa cosa vale anche con il cliente molto grosso che nonostante si fidi ha bisogno di molta burocrazia e carta intorno a tutto.
In Gaia ad esempio la parte di grafica ad oggi non è un processo Agile, lo vorrebbe diventare ma non seguo molto quella parte quindi non so Timothy, il mio collega responsabile per la parte di UX, come si stia muovendo.
.m
“Design Is a Process, Not a Methodology” [cit.]
;-)
@Cristiano: Cercando la tua citazione, ho trovato questo:
http://www.uxmatters.com/mt/archives/2010/07/design-is-a-process-not-a-methodology.php
O_o :)
@ilaria: esatto, era proprio quella la citazione. ed era dovuta al fatto che – mi era parso di percepire dalle tue parole – sei alla ricerca del “metodo perfetto” di design, mentre io personalmente sono convinto che si tratti più di una serie di “tool” (da cui il concetto di “toolbox”) da usare di volta in volta, a seconda dei casi, dei contesti, delle necessità (ma soprattutto, delle persone che hai di fronte come interlocutori).
sì, sono alla ricerca di un qualcosa del genere, ma ogni volta mi scontro con situazioni che sembrano davvero inconciliabili. Forse l’idea del toolbox è proprio quella che più si attaglia al nostro lavoro: un insieme di processi malleabili, da usare in modo intelligente di volta in volta. O almeno, un qualcosa del genere :)
Grazie!
Simone Economo (@eKoes) ha segnalato questa citazione, che trovo geniale (perché assolutamente corrispondente alla realtà):
“I think most programmers spend the first 5 years of their career mastering complexity, and the rest of their lives learning simplicity” – Buzz Andersen
http://quotesondesign.com/buzz-andersen/
@Cristiano +1000 sul concetto di toolbox. Non è solo per il design ma per tutto, penso che la bravura di un professionista (in tutti i settori) sia data dal suo toolbox che è un insieme di esperienze, processi, modi di approcciare i clienti etc etc, per cui alla fine penso che lo scopo finale di questi incontri e discussioni sia quello di confrontarci e scambiarci tool :D cosi da avere toolbox sempre più ampi.
alk.
@gian_maria agli incontri di “designer” ci si scambiano esperienza e opinioni, ma sui tool che ognuno di noi usa nella quotidianità (parlo di strumenti, di piccoli trucchi del mestiere, di metodo di lavoro e di processi di ideazione grafica) invece è raro scambiarsi informazioni, se non ad alto livello (abbastanza astratte, generali intendo).
potrebbe però essere l’idea per un prossimo incontro, dedicato non ai massimi sistemi, ma per illustrare nel concreto – ognuno di noi – come lavora, con quali strumenti, adottando quali strategie. insomma, aprire la propria “toolbox segreta” anche agli occhi altrui… :-)
@Cristiano: direi che questa “gelosia”, passami il termine, nel mondo dei developer, almeno quello che conosco io, non c’è e aggiungo fortunatamente non c’è, ma l’idea di un incontro, o serie di incontri, finalizzati alla “quotidinità” è proprio interessante.
.m
Ciao Ilaria, ho provato a buttare giù qualche risposta qua: http://tinyurl.com/2d58z7t
Io ho la fortuna (e sfortuna) di seguire tutti gli aspetti del progetto a 360 gradi (dalla richiesta alla fattura) e quindi ho più facilità ad indirizzare un cliente sulla strada che secondo me è congeniale usando le opportune leve (in base all’interlocutore).
In un mondo perfetto avremmo tutti contratti Agili che permetterebbero sia a noi che ai committenti di far crescere assieme il progetto. Nella nostra realtà il cliente si aspetta sempre la soluzione chiave in mano, e spesso ha anche difficoltà nell’esprimere le proprie esigenze.
Per evitare di perdere tempo dietro a progetti che non partono mai sto seguendo questo approccio:
a) il referente ha le idee chiare : i mockup statici li preparo io a costo mio per capire se sono stato in grado di inquadrare il problema con una soluzione funzionale (e se posso anche bella) -> serve a me per non sbagliare, il costo è mio.
b) il referente crede di avere le idee chiare (di solito è quello che da direttamente la soluzione mentre nel primo caso spiega il problema): gli chiedo di disegnare online con balsamiq il mockup e di inviarmelo. 9 volte su 10 si rende conto da solo che è completamente fuori strada.
Qui escono due casi:
1) il cliente abbandona il progetto perché non sa bene quello che vuole -> evitato bagno di sangue.
2) il cliente richiede un prototipo a pagamento per poter valutare bene il progetto ed evitare di buttare via i soldi.
La formula magica non l’ho ancora trovata, dipende sempre con chi ti relazioni. Poi quando ho la fiducia del cliente ho carta bianca ed è tutto più semplice.
Bella l’idea di far disegnare il prototipo al cliente! Mi immagino già il cliente che ti risponde: ” Ti ho detto quello che mi serve, non posso mica farti anche il progetto!” :P Ti sarà capitato, suppongo. Ad ogni modo, anche se non so quanto sia fattibile nel tipo di lavori che seguo io, è sicuramente una strada interessante.
Figuriamoci… già è difficile far capire al cliente cos’è e come usare il prototipo. Figuriamoci farlo fare a lui… :D
Chiedere al cliente di disegnare il prototipo ha solo lo scopo di renderlo consapevole che fare un mockup ha un costo e togliergli di testa l’idea “cosa ci vuole a buttar giù sue schizzi su carta..”. Se il cliente è consapevole del lavoro che c’e’ da fare (e soprattutto che da solo non può farlo) hai meno di difficoltà nel proporre qualche giornata di consulenza per le attività.
A prescindere dal far fare il prototipo o meno al cliente mi sto rendendo conto di quanto sia difficile, e altrettanto importante, stuzzicare il cliente nel modo giusto e trovare l’interloctore giusto.
Lo stiamo vivendo proprio in questo periodo, abbiamo lavorato per quasi un anno con un cliente che ci ha dato, l’ha selto lui (primo errore) l’interlocutore sbagliato che non era in grado di capire e rispondere alla domande, dal canto nostro non ci siamo resi conto che noi facevamo le domande sbagliate e le domande sbagliate mascheravno il fatto che l’interlocutore fosse quello sbagliato rivoltandosi comunque contro di noi.
Quindi secondo me l’idea di Andrea di spingersi fino a stimolare il cliente a fare il prototipo è sicuramente buona perchè magari non ottieni il prototipo ma scopri che l’interlocuotre è quello sbagliato e allora cambi rapidamente strategia, e prima lo fai meglio è per tutti.
Altrettanto diffcile è fare le domande giuste e impedire al cliente di mettere il naso in aree del progetto che non sono di sua competenza, quindi ad esempio rimbalzare immediatamanete ogni tentativo di invasione tecnologica da parte del cliente.
Infine vitale è far capire molto rapidamente al cliente chi comanda e dove, se noi siamo gli esperti di UX siamo noi ad imporci sulle scelte di UX, ascoltiamo i requisiti del cliente ma non dobbiamo accettare che il cliente faccia scelte per noi e dobbiamo essere in grado di sostenere le nostre scelte altrimenti addio credibilità all’istante e il cliente prende il sopravvento. Ovvio che questo comporta che il fornitore sia con i controca**i e sappia muoversi molto bene nel suo territorio.
.m
Una volta ho letto una frase che più o meno faceva così “Non dobbiamo rispondere alle domande sbaligate, ma dobbiamo fare in modo che ci vengano poste le domande corrette”.
@Alessandro: ho dei clienti che Balsamiq se lo sono pure comprato per quanto gli è piaciuto l’approccio.
@Mauro: il prototipo fatto dal cliente non è mai quello definitivo, c’e’ sempre bisogno di lavorarci sopra (a volte anche stravolgendolo completamente).
Non mi aspetto che il cliente abbia competenze non sue, ma che il cliente prenda coscienza di quello che chiede e del processo di prototipizzazione.
Non è sicuramente un lavoro che puoi fare con tutti. C’e’ anche chi non si è fatto più sentire (ma sono tutti progetti in cui sentivo l’odore del sangue… il mio).
@Alle: santo subito :-)
@Andrea: sono perfettamente d’accordo con te e l’idee dello stimolare il cliente in quel modo mi pace molto, ovvio che vada anche quella calata nel contesto. Neanche io mi aspetto che il cliente abbia competenze non sue l’inghippo è che spesso il cliente è convinto di avere competenze che proprio non dovrebbe sapere neanche dove stanno di casa… :-) e anche io credo di aver bisogno del mio sangue, e ci tengo :-)
.m
@Cristiano: mai avuti problemi nello scambio di trick o di conoscenze :), tra noi dev non ci sono segreti :) anzi, se trovi un supertrucco di qualche tipo la prima cosa che fai è bloggarlo :D
@tutti: quando facciamo un incontro informale per discutere a voce di tutti questi spunti? Anche una tavola rotonda nell’ambito di XPUG marche.
alk.
@Gian Maria: ovviamente quando vi incontrate lo voglio sapere perchè non posso mancare :-)
.m
Informazioni e licenza
Questo blog utilizza Wordpress è basato sul tema Gutenberg, modificato da me con i preziosi consigli di Nicolò e il fondamentale supporto di Luca
Eccetto dove diversamente specificato, i contenuti del mio blog sono pubblicati con Licenza Creative Commons Attribuzione Non commerciale - Condividi allo stesso modo 3.0 (Italia License).