Design concorrente per team distribuiti con Google Drawing

Dai tempi della fine dello storico PowWow – esempio quintessenziale del fenomeno dot-com anni ‘90 – cioè dal 2000, attendevo il ritorno di uno strumento per disegnare cooperativamente online in tempo reale. C’erano sì stati alcuni strumenti alternativi anche su piattaforme molto diffuse come MSN o Skype, ma mai con i miei clienti ero riuscito a trovare un modo comodo e facilmente accessibile per disegnare al volo durante una conference call. Beh, finalmente oggi è possibile tornare ai vecchi fasti.

Nella suite Google Docs infatti è stata recentemente aggiunta Drawing, l’applicazione per creare e modificare diagrammi. Con la consueta grammatica di interazione gli utenti possono condividere i loro diagrammi con altri utenti e collaborare interattivamente sugli stessi diagrammi esattamente come Google Spreadsheet ci aveva già abituato a fare con i fogli elettronici. In pratica abbiamo tutti noi finalmente a disposizione una whiteboard (quasi) gratuita da condividere con chiunque, ovunque ed in qualsiasi momento.

Per me questo rappresenta l’abbattimento di una barriera molto scomoda, vincolante buona parte della mia attività lavorativa. Ogni volta che mi sono trovato costretto a fare una riunione in remoto o a fare pair programming via Skype, è sempre mancata la possibilità di disegnare. Non so tu, ma io quando condivido e discuto concetti al di sopra di una complessità minima ho bisogno di fare schizzi ed esempi grafici. Negli ultimi anni avevo fatto grandi sforzi per ovviare a questa vera e propria amputazione mediatica, sforzandomi di raffinare la capacità di rimuovere le ambiguità dai discorsi e di comunicare in modo più verbale e meno visuale. Lo strumento di Google rende finalmente questa traduzione non necessaria e, soprattutto, non richiede grandi iniziative da parte dei miei clienti: un account Google. Punto. Niente plug-in, niente applicazioni, perfino niente Flash Player!

La conseguenza più importante per tutti di questo lancio è la nuova abilitazione ad un processo di design concorrente, tipicamente desiderato nel contesto lean, poiché concorrenza significa feedback più immediati. D’ora in avanti quindi niente più ostacoli per tracciare un po’ di UML durante un pair programming in remoto, più nessun problema per tracciare semplici grafici durante una conference call e, arrivo a pensare, d’ora in avanti avremo anche aperta la possibilità per i nostri interaction designer di prototipare (parti di) interfacce anche con collaboratori e clienti lontani!

Certo, questo non dovrà mai significare la rinuncia ad ogni tentativo possibile di incontrarsi de visu, e non tanto per un mio inguaribile romanticismo neo-luddista, quanto invece per l’oggettiva qualità della comunicazione fra le persone… di persona! Poi si sa, difficilmente resisterai al fascino di una partita a tris in remoto! ;)

April 21 2010 | Dalle trincee | 4 Comments »

User experience agile con il pair progr…ehm pair design!

In questo post – scoperto via Alberto – si espongono i vantaggi dello UX design – la progettazione della user experience – condotto in coppia. Noto interessanti analogie con uno dei miei primi post;)

November 23 2009 | Base | 1 Comment »

Più realisti del re: l’Agile UX secondo gli sviluppatori

Nell’ordine Alberto, Gianandrea e Davide mi hanno segnalato questo articolo di Jakob Nielsen, tonicissimo guru della progettazione dell’esperienza utente (User eXperience), dell’usabilità e dello user centred design. Lasciando i commenti più specifici a chi di UX se ne intende assai più di me, ho letto con molto interesse il report di Nielsen, a valle delle molte esperienze e discussioni che ho vissuto al riguardo in questo 2009 che volge al termine e di cui hai potuto scorgere alcuni riflessi tra le pagine di questo blog.

Voglio condividere però il mio punto di vista, senza dubbio centrato sullo sviluppo agile, nel più ristretto ambito di soli due punti esposti da Nielsen.

Primo punto: risulta che il grado di soddisfazione dei partecipanti allo studio fosse leggermente più alto con metodi meramente iterativi piuttosto che anche agili. Trovo questo dato perfettamente in sintonia con quanto ho affermato più volte quest anno sul tema delle metodologie agili usate insieme allo user centred design. Gli interaction designer mancano ancora delle tecniche, degli strumenti – meno – e dei principi culturali – di più – per avere un approccio al proprio lavoro che li sostenga nell’abbandonare i propri semi-lavorati, i deliverable già creati. Quindi, pur percependo forte il valore dei processi agili, trovano ancora più confortevoli i metodi semplicemente iterativi, i quali, ovviamente, sono vissuti già come rivoluzionari da chi abituato a lavorare waterfall.

Secondo punto:

Developers rated the user experience impact on the deliverable’s quality at 4.3, whereas UX people rated it at 4.0 (again on a 1–5 scale, with 5 best). Developers said productivity increased somewhat with UX involvement (3.3), whereas UX rated this only slightly higher at 3.4.

La mia esperienza di progetti con un forte orientamento all’utente, con specialisti UX inseriti nel team, è stata altrettanto positiva. Io vedo l’attività degli interaction designer come un preziosissimo supporto alla scrittura delle user story e mi fa piacere vedere come questo valore sia percepito dagli sviluppatori in modo perfino più forte che dagli interaction designer stessi!

Ho imparato a ritenere la fase della scrittura delle user story una delle più cruciali – se non la più cruciale – per la buona riuscita di ogni progetto. Sei consapevole del valore di requisiti non solo ben espressi, ma anche già confezionati in un formato che supporti il team nella fase di sviluppo? Ti è chiaro come l’attività centrata sull’utente sia un grimaldello precisissimo per violare la serratura troppo spesso chiusa della riduzione razionale dello scope, del controllo del budget e, in ultima analisi, del successo del tuo progetto?

November 12 2009 | Dalle trincee | 3 Comments »

Un blog, un altro blog, un libro e un film.

Con spirito schizofrenico da una parte e prudenza giuridica dall’altra – non abbiamo ancora bene capito cosa potremo ben scrivere – Francesco e io vi presentiamo il blog dedicato al nostro libro Pro PHP Refactoring with Test Driven Design. Poi magari non vi potremo scrivere niente di rilevante; poi magari non vi scriveremo niente che non si possa scrivere sui nostri rispettivi blog; poi magari non ci verrà niente in mente di interessante da scrivere; però oh, noi intanto lo abbiamo tirato su, con buona pace degli spider di Google.

Siamo già a caccia di lettori replicanti, non umani. Alla faccia di Rick Deckard!

September 20 2009 | Recensioni | 2 Comments »

Agile UX, Facebook e il refactoring delle interfacce

In un recentissimo post di Alberto Mucignat, caro amico più volte ospite di questo blog, nonché esperto progettista di interfacce, si possono leggere sintetizzati i punti salienti per capire come lavorano gli interaction designer di Facebook.

Sebbene mi piacerebbe soffermarmi sul punto

3. I designer lavorano principalmente in codice (html/css e un pizzico di php)

tradendo così la mia estrazione da sviluppatore e confermando il codice come valido (!= perfetto) formalismo per questi scopi, preferisco invece farti notare questo:

4. Non si affezionano troppo al lavoro: il software cambia continuamente.

È più di un anno che scrivo e dico che l’unica via per rendere più agile il lavoro degli interaction designers è basata su due punti:

  1. Trovare strumenti che permettano il facile refactoring dei wireframe.
  2. Adottare una filosofia di progettazione più incline al rifacimento e meno al desiderio di essere – disperatamente – up front.

Il primo vincolo potrà anche essere squisitamente tecnico – ed è solo questione di tempo, ma il secondo non è che di natura umana.

E ti pare poco!

September 17 2009 | Dalle trincee | 6 Comments »

Scrum non basta. E nemmeno XP.

In un saliente post del caro Alessandro Astarita leggo

Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.

tratto da un post di Ron Jeffries.

Il refactoring è una pratica essenziale. Essenziale, nel caso la sedimentazione linguistica non lo portasse alla luce immediatamente, significa relativo all’essenza, fondamentale, che è assolutamente necessario.

Assolutamente necessario.

Troppo spesso si parla di agile – buzzword che francamente sto cessando di impiegare – e si pensa di poter garantire evolutività incrementale solo con un po’ di iterazioni buttate in un calendario e delle user story scritte male. Bisogna essere produttivi per un mercato che cambia. Bisogna essere pronti a rispondere agli stimoli.

Il codice deve essere pronto a seguirci. Ovunque.

June 20 2009 | Base | 1 Comment »