Alberto Mucignat

Alberto Mucignat


Random thoughts around web stuffs (è tutto un equilibrio sopra la follia)

luglio: 2019
L M M G V S D
« Ott    
1234567
891011121314
15161718192021
22232425262728
293031  

Categorie


Augmented design e Agile UX

AlbertoAlberto

Apro un ciclo di pensieri su quello che provo a definire augmented design: trattasi della capacità di rappresentare un prodotto digitale usando una combinazione tra il formato visuale e quello testuale.

Il tarlo mi è venuto da quando con Jacopo abbiamo lavorato a un progetto impostando il lavoro di scrittura delle user story partendo dagli scenari utente. Da poco ho scoperto che questo metodo è stato chiamato User story mapping (da leggere sull’argomento: “Usage-centered user stories & story mapping”, parte 1 e parte 2)

L’idea di “agganciare” le user story agli scenari è piuttosto importante poiché sono convinto che sia il trait d’union tra design e sviluppo, soprattutto nella fase iniziale (ne ho parlato anche al RomeCamp2008).

Un punto importante è che secondo me gli scenari dovrebbero essere individuati prima della stesura delle user story, attraverso la ricerca con gli utenti e la produzione dei personaggi.

Insomma, fin qui tutto ok, nel senso che ormai ne parlo da un po’ di tempo e sono quindi argomenti noti.

Negli ultimi mesi però ha iniziato ad aleggiare questa idea di Jacopo sulle #AugmentedUserStory: l’idea di associare un wireframe alle user story, o viceversa.

In effetti, quando facciamo up-front design è possibile derivare le user stories direttamente dai prototipi digitali o dai wireframe. In questo modo, oltre ad avere una descrizione testuale delle funzionalità da implementare, c’è anche una rappresentazione visuale a supporto.

Ma il punto è proprio questo: perché parlare di rappresentazione visuale “a supporto” delle user story?

Perché non parlare invece di “augmented design” inteso come tutto quello che può servire a specificare meglio il design di un prodotto digitale?

In fondo è già quello che facciamo quando cerchiamo di comunicare il design e che Dan Brown ha ben descritto nel suo libro chiamato appunto “Communicating design“.

Per fare un esempio Doralab ormai impostiamo i progetti seguendo un processo di questo tipo:

Gli scenari guidano il processo di design e quindi tutti i deliverable (user journey, concept maps, page flow, wireframe, prototipi, …), oltre ai test con gli utenti, seguono l’impostazione a scenari.

Viene dunque automatico pensare di basare la scrittura delle user story e il lavoro di sviluppo sugli scenari, anche per dare coerenza al planning delle varie release (possiamo cioè basarci sugli scenari anche nel decidere quali storie dobbiamo implementare per il prossimo rilascio).

A questo punto, la descrizione del design è completa: per ogni scenario ci sono una serie di wireframe/pagine che vengono descritte nel dettaglio attraverso le user story.

Ecco, tutto questo lo chiamo “augmented design”, perché stiamo sostanzialmente lavorando per arricchire il lavoro di progettazione, dettagliarlo, descriverlo meglio. Per favorire il lavoro di sviluppo, ma anche “viceversa” 😉

Comments 7
  • Simone Pomilio
    Posted on

    Simone Pomilio Simone Pomilio

    Author

    Alberto, mi chiamo Simone e lavoro in un’azienda ICT finora un po’ sorda all’introduzione di metodologie UCD nel processo di produzione… governato principalmente da software developers.
    Sto lavorando ai fianchi la direzione 🙂 da anni nel tentativo di sbloccare la situazione e orientare le fasi di analisi e progettazione partendo dall’utente e non dalle “funzionalità” (come vedi siamo indietro di alcuni anni).
    Sono riuscito a forzare la mano prima sui mockup, percepiti immediatamente e tangibilmente utili a tutti i livelli, anche se la maggior parte dei colleghi immagina ancora che piovano dal cielo, generati in un momento di illuminazione creativa… 😉
    Ora l’introduzione molto lenta, da parte mia, di personaggi e scenari dei quali i mockup diventano non solo complemento, ma fonte appunto di progettualità aumentata, sta avendo i suoi frutti. Forse.
    Uno degli ostacoli principali affrontati è stata la difficoltà di traghettare i risultati dell’analisi verso lo sviluppo attraverso deliverables subito fruibili da software engineers e progettisti tecnici.
    In genere infatti i nostri progetti sono molto articolati e mediamente più complessi di un sito web di comunicazione, non tanto in relazione all’architettura dell’informazione, quanto all’interazione e ai flussi utente: solitamente si tratta di Desktop Applications o RIA (o intere piattaforme custom) molto focalizzate sul dominio operativo della committenza.
    E’ qui che ho trovato efficace frammentare gli Scenari in User Stories (con alcuni accorgimenti per collegare task e soluzioni proposte ai commitments) pronte per essere recepite in funzione della stesura di Use Cases tecnici, Sequence Diagrams, ecc…

    Mi sono dilungato un po’, ma ho voluto comunicarti la mia esperienza anche per ringraziarti di questo ottimo post e di altri che mi hanno aiutato a focalizzare strumenti e metodi adatti al mio contesto aziendale con l’obiettivo di rendere sempre più efficace il nostro meraviglioso lavoro.

    Ciao!


  • Alberto
    Posted on

    Alberto Alberto

    Author

    Simone, grazie per aver condiviso! ci sono molti come te in italia che combattono una battaglia culturale per cambiare il modo in cui vengono progettati i software. mi interessa molto la tua esperienza e spero che magari ai prossimi eventi tu voglia condividerla con me e con gli altri!

    solo un appunto: le desktop application, RIA, etc seguono secondo me le stesse pratiche. in ogni caso, l’architettura dell’informazione è essenziale (analizzare il db, le metainformazioni, le relazioni, ecc). nella mia esperienza per le applicazioni più “task oriented” sono molto utili le concept maps -oltre agli altri strumenti che citi- per un paio di motivi principali. il primo è che aiutano a focalizzare lo “scope” del sistema nella sua interezza, cosa che spesso è trascurata e quindi si creano esperienze/task “disgiunti”. il secondo è che aiutano a prendere conoscenza del dominio, specie se sviluppati/verificati assieme al cliente.

    ciao, Alberto.


  • Simone Pomilio
    Posted on

    Simone Pomilio Simone Pomilio

    Author

    Grazie per la risposta!
    Spero anch’io di poterci confrontare in futuro: gli eventi di settore possono essere un grande momento di crescita…

    Assolutamente d’accordo sulle mappe concettuali (o mentali, non so se ci sia differenza), soprattutto per un lavoro molto preliminare di indagine: le sto usando proficuamente da poco e mi trovo bene con XMind.


  • Alberto
    Posted on

    Alberto Alberto

    Author

    le concept map (concept model) sono lievemente diverse dalle mind map. mentre queste ultime “esplodono verso l’esterno”, le concept map rappresentano relazioni tra oggetti e si usano molto per definire logiche del sistema e documentare parti che non si riesce a rappresentare con le mappe del sito o con i flow chart. ne ho parlato anche qui: http://www.mucignat.com/blog/archives/789-sitemaps-o-concept-models.html


  • Simone Pomilio
    Posted on

    Simone Pomilio Simone Pomilio

    Author

    Interessante. Ecco un altro input da approfondire…