Microsoft, la UX e lo sviluppo: un tentativo di unificazione

Vista la presentazione alla fine non ho visto queste grandi innovazioni, ma ho notato che comunque l’impegno di Microsoft (e la maturità dei prodotti) per integrare al meglio gli strumenti progettuali nei tool di sviluppo (visual studio in primis) è notevole. Si può tranquillamente affermare che oggi la suite produttiva di Microsoft sia quella maggiormente integrata nel ciclo di vita di sviluppo di un software (analisi > design > sviluppo > produzione) e personalmente ritengo che questa scelta sia vincente.

Infatti sembra che MS abbia capito uno dei problemi fondamentali che affliggono il mondo della progettazione: la difficoltà nel trovare degli standard a livello di formalizzazione (e formati) nei passaggi che avvengono tra designer e sviluppatori (html a parte chiaramente). L’integrazione di strumenti permette di fatto una maggiore efficienza ed efficacia nella condivisione del progetto e sulla carta semplifica il tutto.

Altra esigenza identificata e ben risolta da MS è quella di dover/poter creare in maniera estremamente rapida dei prototipi interattivi. Questa esigenza è risolta egregiamente da Sketchflow che permette di realizzare molto rapidamente una bozza di struttura e interfaccia (purtroppo non wireframes ad una qualità accettabile) e di dinamicizzarla in un prototipo utilizzabile nell’arco di pochi minuti.

Queste novità sono di fatto esempio di come Microsoft si stia impegnando sul tema della UX (come anche il rilascio delle nuove UX guidelines per windows 7) e stia semplificando la vita dei designer quando si affrontano progetti di medio-piccole dimensioni (Sketchflow non scala su grandi progetti)… purtroppo è solo per progetti .Net oriented :(

  1. “nell’arco di pochi minuti”… non esageriamo.
    Esco or ora da una full-immersion su Sketchflow per la protipazione di una web-application mediamente complessa (60 screen), e mi ci sono voluti 2 giorni di lavoro. Il risultato però è eccezionale. Concordo con te che al momento alcune applicazioni Microsoft danno la paga a quelle dell’unica controparte ormai rimasta sul mercato, Adobe: Blend/Sketchflow ad esempio è una applicazione talmente bella (anche dal punto di vista dell’interfaccia, unico neo la proliferazione delle palette) che non sembra nemmeno fatta da Microsoft.
    E anche io ho notato che l’attenzione di MS verso i temi della UX è decisamente crescente, come ho già detto un po’ di tempo fa, dopo la partecipazione al REMIX 09 a Milano:
    http://www.didoo.net/rssarchive.php?newsID=389
    http://www.didoo.net/rssarchive.php?newsID=390

  2. Dimenticavo: perchè dici che Sketchflow non scala su grandi progetti? Certo, se hai bisogno di behaviour complessi per simulare certe interazione, hai bisogno di un programmatore che te li prepara. Però secondo me la logica e la filosofia di fondo del progetto Sketchflow è proprio questa: rappresentare un “ponte” fra sviluppatori e designer, in modo che comincino a parlare fra loro in una lingua comune. Tantopiù che una volta approvato dal committente, il progetto Sketchflow può passare di mano, dal designer al developer, e molto del lavoro fatto viene riutilizzato. A quel punto il developer scrive il codice definitivo, e il designer realizza gli skin e i template e gli stili definitivi. Metti assieme il tutto, agita un po’, e servi ghiacciato, magari con una fetta di limone (semplifico, ovviamente).

  3. Intendevo pochi minuti di assemblaggio partendo da sketches scannerizzati o wireframes già pronti o cose molto semplici… è chiaro che se bisogna fare 60 schermate ci vuole il suo tempo :)

    Sulla scalabilità ne ho parlato largamente con Roberto Cavallini, UX Evangelist di MS, nei termini che se ho da fare un grande portale con qualche centinaio di funzionalità e relativi form più qualche decina di sezioni, ogniuna con le sue logiche, purtroppo per gestire il tutto con sketchflow sono costretto a spaccare il progetto in tanti micro-progetti non avendo un prototipo omnicomprensivo.

    Per tutto il resto concordo con te :)

  4. “un grande portale con qualche centinaio di funzionalità e relativi form più qualche decina di sezioni, ogniuna con le sue logiche” = Facebook!

    OK, concordo che non puoi progettare Facebook con Sketchflow! :-)

  5. emh… non solo facebook ma per esempio il progetto di un grande portale di una corporate italiana (me ne sono capitate un paio quest’anno dove si arriva tranquillamente a 3-400 wireframes)

  6. Non è un abuso fare 400 wireframe? Intendo, non va al di là dello scopo dei wireframe, che è non è quello di progettare nei dettagli ed ex-ante un intero sito / portale / applicazione / ([\w\s]+) bensì quello di definirne gli aspetti funzionali, di usabilità, di flusso logico fra le diverse pagine/sezioni? Ad ogni wireframe dovrebbe corrispondere un “tipo” di pagina, non una pagina. Se un portale ha 400 “tipi” diversi e distinti di pagina, allora forse c’è qualcosa che non va, sia dal punto della IA che da quella della progettazione (IMVHO, ovviamente… lungi da me voler mettere in discussione il Luca Mascaro! ;-)

  7. Dai cristiano non mi prendere in giro… la risposta comunque come sempre è dipende.

    In genere se consideriamo i wireframes come uno strumento di esplorazione del design hai perfettamente ragione ma se per caso all’interno del progetto il sistem integrator di turno ti richiede un uso a scopo specifiche/documentazione dell’intero sistema è facile arrivare a quei numeri (ti richiedono di simulare tutte le interfacce in tutti gli stati con relativa documentazione).

    Ipotizziamo di avere un portale con 15 macrosezioni che trattano contenuti differenti (magari riciclando alcuni pattern di UI) e su queste si incastrano qualcosa come 80-90 funzionalità con interazioni particolari o formulari in più step o stati… è facile arrivare a 400 wireframes (tra l’altro revisionati più di 10 volte in maniera evolutiva ed iterativa).

    In questo caso purtroppo l’unico strumento resta il buon vecchio omnigraffle/visio.

  8. Ci devo riflettere. C’è ancora qualcosa che non mi torna nella richiesta di 400 wireframe da parte di un sistem-integrator. Mi sembra il vecchio “voglio un documento di specifiche di 800 pagine del progetto” riportato al giorno d’oggi, solo con un paio di buzzword in più (wireframe e agilita). Avrei provato a convincerlo che non è “cosa buona e giusta”. Però, non essendomi mai trovato in quella situazione, e non lavorando su progetti _così_ grossi, probabilmente “la faccio semplice”… :-)
    In ogni caso, se devi fare documentazione Skethflow esporta in un file di Word gran parte del lavoro (non gli stati, purtroppo, e nemmeno le storyboard/timeline) e lo fa in maniera egregia, credimi, risparmi un sacco di tempo! Poi ovviamente a te sta il compito di descrivere cosa accade nelle diverse immagini/sketch. Anche se, nel tuo caso, avendo una applicazione prototipo interattiva e funzionante, non occorre più la documentazione testuale: il codice parla per sè, giusto?

  9. Ma infatti è il vecchio documento di specifiche da 800 pagine e attenzione, non vi ho mai associato la parola agilità!

    Ci sono ancora oggi tanti progetti che sono gestiti da grandi agenzie che organizzano i grandi progetti sull’arco di un anno con un approccio totalmente waterfall subappaltando i vari pezzi.

    In pratica ti trovi a dover progettare e testare qualcosa in ambiente simulato che verrà vestito e sviluppato qualche mese dopo da attori che vogliono una copertura completa delle specifiche (su carta… di intepretare prototipi non se ne parla proprio :( )

    Fosse per me gli stessi progetti li gestirei in 12 iterazioni da 40 wireframe l’una (oddio mi sembra il mercato del pesce :D )

  10. Ok. Capisco.