Presentazione tenuta da Timothy Carniato e Mauro Servienti all'Italian Agile Day 2012.

1. EVERYBODY, ALL TOGETHER,
FROM THE EARLY ON..
Agile Experience Design & Development

2. CHI SONO LORO 2?
&
MAURO SERVIENTI TIMOTHY CARNIATO

3. CHI SONO LORO 2?
MAURO SERVIENTI
Software Architect
managed/designs
@mauroservienti
mauro@topics.it
milestone.topics.it

4. CHI SONO LORO 2?
TIMOTHY CARNIATO
Experience Desginer
Straypeople
@straytim
timothy@straypeople.it
straypeople.it

5. DA DOVE SIAMO PARTITI
Punti di vista, abitudini, preconcetti

6. La mia vita da Designer qualche annetto fa..

7. La mia vita da Architect qualche annetto fa..
• Una routine lavorativa “accettabile” basata processo
agile basato su Scrum.
• Un set di User Story troppo spesso fatte da gente ai
margini del progetto
• Un set di specifiche (si fa per dire) che descrivevano
gli aspetti tecnici e tecnologici del progetto
• Un po’ di jpeg, disegnini, simil-wireframe, consigli su
come sarebbe dovuta venire la UI

8. IL PROGETTO DELLA SVOLTA
Cosa abbiamo scoperto
attraverso un progetto reale

9. IL CLIENTE: “ACME Cosmetics” - Big Corp.
CHI È
✓ Head Quarter: 1 per nazione
✓ Rete di distribuzione: 20.000 per nazione
OBIETTIVI PRINCIPALI
Informare la rete in modo “semplice” e
✓ “rapido”
✓ Forniere ad ACME strumenti di analisi

10. IL CLIENTE E IL SUO BRIEF
Ecco il brief
COSA ABBIAMO
✓ Intranet/Extranet sviluppata 10 anni fa
PERCHÈ NON FUNZIONA
✓ È lenta, è vecchia, è brutta, non è usabile
SOLUZIONE
✓ Progettiamone una nuova su SharePoint

11. INIZIA IL PROGETTO
Iniziano le attività di verifica e di integrazione
delle informazioni acquisite

12. RICERCA
150
✓ USABILITY TEST
✓ INTERVIEW (user/stakeholder)
✓ CONTEXTUAL INQUIRY

13. GLI UTENTI
CHI SONO
✓ Aziende che vendono con il marchio ACME
Il loro contatto con ACME è il LOCAL
✓ MANGER (?)
ASPETTATIVE E BISOGNI
Non utilizzano l’attuale piattaforma e non
✓ sanno come potrebbe essere uutile
Trovano informazioni e richiedono aiuto solo
✓
ed esclusivamente al LOCAL MANAGER (?!)

14. LOCAL MANAGER: L’UOMO IN PIÙ

15. PENSIERO DEL CLIENTE
=
REALTÀ
=
INSUCCESSO

16. ✓ NUOVA VISIONE
✓ NUOVA STRATEGIA
✓ NUOVI REQUISITI
X VECCHIE SCELTE TECH

17. LA SOLUZIONE: NUOVA VISIONE & STRATEGIA

18. NUOVI REQUISITI, VECCHIA SCELTA (SharePoint)
• Scambiare messaggi tra elementi della piramide;
✓ • Con il vincolo che si può comunicare solo in «verticale»;
• Mandare messaggi a «tutti» (e.g. newsletter);
✓ • Un subset di «tutti» sotto la posizione del mittente;
✓ • Cercare e organizzare i propri messaggi;
• 20.000 utenti, circa 10 msg/gg (10k/msg)
✓ • 10x2x200x20.000 = 80.000.000 msg/anno (sono tanti)

19. DIFFICOLTÀ EMERSE DURANTE IL PROGETTO PER MAURO
✓ • Scrum chiude fuori i non «dev»
✓ • Le USER STORIES danno una visione ristretta
• Le SPECIFICHE da sole hanno poco valore
✓
• L’ultima cosa che serve per fare la UI sono le jpeg…
✓ • «UX is the word»

20. DIFFICOLTÀ EMERSE DURANTE IL PROGETTO PER TIMOTHY
✓ • Progettare senza aver consapevolezza dell’impatto delle
mie scelte sulla parte di sviluppo
• Concentrazione sulle piccole scelte di design e
✓ conseguente perdita di consistenza e “BIG PICTURE”
sempre più sfocata
• Necessità di collaborare sulle attività di ricerca e di
✓ design
• Perdita di grandi e piccole occasioni legate alle
✓ opportunità tecnologiche

21. DOVE SIAMO ARRIVATI
Consapevolezze, ipotesi e nuove abitudini

22. SPRINT 0
STRATEGY
BRIEF RESEARCH IDEA VISION
CONTEXT
• Designer, Dev da • Entrambi a contatto con i
✓ subito insieme ✓ REALI utenti
• •
Entrambi a contatto Reale collaborazione
✓ con il cliente ✓ (stesse attività)

23. http://www.icponline.it/imgDetail.php?id=5663552

24. INTRODURRE GLI SPIKE
SPIKE
SPRINT SPRINT SPRINT SPRINT
SPIKE identifica uno o più momenti intermedi durante un
progetto in cui il normale processo AGILE si interrompe per
un tempo ben definito allo scopo di riverificare, coinvolgere
gli utenti, affrontare temi e problemi più ampi.

25. INTRODURRE GLI SPIKE
Durante i consueti Sprint il team tende a soddisfare i bisogni
dell’utente nell’immediato senza considerare una visione più
ampia.
I designer in questo modo rischiano di focalizzarsi sui singoli
problemi di design perdendo di vista la VISIONE
complessiva del progetto e il reale punto di vista dell’utente.
Allo stesso modo anche i “DEV” hanno bisogno di uscire
dalle singole fasi di sviluppo per riaquisire una visione
d’insieme.

26. Quando si è troppo immersi nel progetto è difficile avere una
visuale chiaradella direzione che stiamo prendendo.
http://www.icponline.it/imgDetail.php?id=6735512

27. Gli spike permettono di innalzarsi al di sopra dei singoli
problemi per riverificare e correggere la rotta.
http://www.icponline.it/imgDetail.php?id=5318269

28. COSA ABBIAMO IMPARATO
A livello personale l’uno dall’altro

29. COSA POSSO OTTENERE DAL DESIGNER?
✓ Creare e definire la visione d’insieme
✓ Le «personas»
✓ L’architettura dell’informazione
✓ Il modello mentale degli utenti
✓ Una «jpeg» o un wireframe sono muti, quello che serve
sono le «interazioni» e le variazioni degli «stati»
✓ Tutto questo guida le scelte tecniche e tecnologiche e
DDD diventa lo «strumento» perfetto

30. COSA POSSO OTTENERE DALL’ARCHITECT?
✓ La comprensione dei rischi e delle opportunità tech
✓ I vincoli e le loro reali motivazioni
✓ Le occasioni da sfruttare a vantaggio del progetto
✓ I punti che hanno impatto sulla UX e che sono stati
ignorati
✓ La qualità dei dati e dei loro modelli
✓ Quando non conviene reinventare la ruota

31. GRAZIE
MAURO SERVIENTI & TIMOTHY CARNIATO
@mauroservienti @straytim
mauro@topics.it timothy@straypeople.it
milestone.topics.it straypeople.it