Molti team software hanno difficoltà a integrare efficacemente la progettazione nel loro processo Agile. I designer che non lavorano a stretto contatto con il resto del team tendono a generare lavoro extra per tutti (inclusi se stessi) e possono creare silos di conoscenza dannosi all'interno del team di prodotto.
In Atlassian lavoriamo in modo collaborativo per incorporare l'intero team Agile nel processo di progettazione. Assicurandoci che tutti siano coinvolti nel processo di progettazione, otteniamo più prospettive su un problema e non ci affidiamo alla documentazione per condividere le idee. Questa presentazione spiega come:
- Coinvolgere l'intero team nel processo di progettazione
- Integrare la progettazione nel processo Agile
- Acquisire informazioni sui clienti per attività di test e ideazione più rapide
Domande e risposte
Queste domande e risposte comprendono vari argomenti, dagli strumenti di progettazione utilizzati da Atlassian al modo in cui Atlassian gestisce i feedback dei clienti.
D1: I designer e gli sviluppatori sono sempre persone diverse? Con HTML5 e le moderne tecniche di interfaccia utente, è difficile per i designer non avere competenze di programmazione di base?
R1: Il confine tra designer e sviluppatori sta diventando sfocato. In Atlassian abbiamo designer che provengono da un background ingegneristico e altri che non sono in grado di scrivere una riga di codice. Abbiamo validi visual designer, information architect e facilitatori. Ognuno ha punti di forza diversi ed è importante riconoscerli e utilizzarli all'interno del team.
D2: Le persone esterne al team di prodotto, ad esempio gli addetti al marketing, partecipano ai workshop di progettazione?
R2: Ai nostri workshop partecipano persone di diverse discipline, ma sono tutti lì per un motivo. Di solito, ci sono rappresentanti dei reparti di gestione dei prodotti, ingegneria e progettazione, ma anche qualcuno che si occupa dell'assistenza o del marketing, in modo da avere prospettive diverse.
I workshop possono durare diversi giorni, il che prevede un impegno non indifferente. Trovo utile condividere il programma in anticipo in modo che le persone sappiano dove possono aggiungere valore e quando invece possono assentarsi per qualche ora. Tuttavia, è consigliabile che ci sia un gruppo principale presente per tutto il tempo.
D3: Come avete fatto a convincere i dipendenti a lavorare alla creazione della bozza, a partecipare alla progettazione e a presentare le idee? Ho la sensazione che gli owner di prodotto e gli sviluppatori siano riluttanti a dedicarsi a queste attività, per paura o per altri motivi.
R3: Incute già timore dover condividere idee con un gruppo, ma disegnare in pubblico può essere ancora più spaventoso! Ecco perché preferisco dividere il gruppo in coppie per questa fase del workshop. In questo modo, è possibile alleggerire la pressione causata da un foglio di carta bianco che ti fissa. Inoltre, le persone possono discutere sulle idee e mantenere lo slancio.
Ho scoperto che dopo aver partecipato a una di queste sessioni, tutti si sentono a proprio agio con il processo e si divertono davvero a dare il proprio contributo. C'è sempre un brusio nella stanza con molte conversazioni interessanti in corso.
È anche importante far sapere a tutti che non stai cercando capolavori. Tutto ciò che desideri è una rappresentazione visiva della loro idea, ad esempio lo schizzo di un'interfaccia, un diagramma o solo un elenco puntato, qualsiasi cosa che aiuti il resto del gruppo a raggiungere una comprensione condivisa. Se tutto ciò viene messo su carta, puoi anche conservarlo come riferimento dopo che il workshop è finito.
D4: Come si aggiornano i nuovi membri del team di progettazione?
R4: Abbiamo un processo di onboarding per tutti i nuovi membri del team di progettazione. Si inizia con una presentazione delle attività di progettazione in Atlassian, del nostro processo e del modo in cui lavoriamo con il resto del team di prodotto. Approfondiamo i principi di progettazione che abbiamo sviluppato e mostriamo esempi di come questi vengono messi in pratica. Ci sono corsi di formazione per approfondire le nostre risorse di progettazione: tramite gli utenti tipo, le linee guida per la progettazione di Atlassian e il playbook.
Durante le prime settimane i nuovi designer vengono inoltre affiancati a un designer esperto che mostrerà loro come fare e li aiuterà ad acquisire maggiore responsabilità.
Un altro modo per aggiornare i nuovi designer è farli partecipare a un workshop durante la prima settimana. È un ottimo modo per incontrare il team di prodotto e sperimentare in prima persona come lavoriamo insieme. C'è molto da imparare durante i primi mesi, ma un workshop è il luogo ideale per una full-immersion e affrontare un problema di dimensioni ridotte.
D5: Quali sono i metodi di ricerca sui clienti che ritieni più utili? Ricerca sul campo, osservazione, usabilità, altro?
R5: Penso che tutti i tipi di ricerca sui clienti siano utili, ma che entrano in gioco diversi tipi di ricerca nelle diverse fasi di un progetto.
Ad esempio, all'inizio di un progetto si vuole avere una piena comprensione del problema e del contesto in cui le persone stanno lavorando. Le domande contestuali sono davvero utili a questo scopo: si visita un team sul posto di lavoro per parlare del suo processo, dell'impatto del problema e di cosa il team necessita per essere più efficace. È bello vedere in prima persona come i membri del team cercano di portare a termine i task e le frustrazioni che incontrano.
I test sugli utenti e le interviste con i clienti sono ottimi per quando hai sviluppato meglio le tue idee. Puoi ottenere informazioni preziose osservando le persone mentre completano un flusso utilizzando un semplice prototipo o semplicemente parlando di una soluzione proposta.
I test A/B, d'altra parte, sono un modo fantastico per valutare l'efficacia della tua soluzione.
D6: Quali strumenti utilizzano i designer di Atlassian?
R6: I designer di Atlassian utilizzano lo strumento giusto per il lavoro da svolgere. A volte sono carta e penna alla vecchia maniera, altre volte HTML e CSS.
Per creare progetti ad alta fedeltà, la maggior parte del team utilizza Sketch, ma utilizziamo anche la suite Adobe. Tutti gli elementi dell'interfaccia utente della libreria di modelli Atlassian sono stati creati come oggetti vettoriali, quindi è piuttosto semplice formare un layout di base da cui partire. Per una creazione di prototipi semplici, utilizziamo InVision o Marvel. Per interazioni più complesse usiamo Framer Studio, Origami, Axure o codice scritto a mano.
Consumiamo anche un sacco di post-it e pennarelli per lavagna. :)
D7: Quali sono alcune delle sfide da affrontare quando si lavora all'interno di un framework Agile?
R7: Imparare a rinunciare alla perfezione e produrre invece un lavoro veloce e iterativo è la sfida più grande. Come designer, si vuole sempre creare lavori di alta qualità, ma bisogna accettare di dover rilasciare un lavoro perfetto al 90% per poi migliorarlo in un secondo momento.
D8: Hai citato diversi modi per ridurre la documentazione. Che tipo di documentazione conservate? Avete eliminato tutta la documentazione?
R8: Utilizziamo Confluence per condividere il lavoro in corso e raccogliere feedback dall'intero team. Una pagina tipica include contesto sul problema che stiamo cercando di risolvere e il valore offerto dalla soluzione proposta. Ci saranno poi foto di schizzi, mockup ad alta fedeltà o link a prototipi incorporati nella pagina per illustrare una soluzione. Le persone aggiungono commenti e domande e il designer pubblica le progettazioni aggiornate man mano che il progetto avanza. Tuttavia, non si tratta realmente di "conservare la documentazione", perché questa è una pagina in evoluzione che raccoglie risorse di progettazione e feedback.
D9: Come affrontate la progettazione distribuita quando un team non è co-ubicato?
R9: Atlassian è un'azienda globale, quindi lavorare con team distribuiti è una cosa che facciamo tutti i giorni. Su Jira abbiamo team a Sydney, Danzica e Saigon e siamo sempre alla ricerca di modi per accorciare le distanze. La tecnologia aiuta molto: utilizziamo Hipchat per le videochiamate e i messaggi, Confluence per pubblicare, condividere e commentare il lavoro e Jira per organizzare tutto il lavoro. Tuttavia, non è un sistema perfetto e nulla può sostituire la comunicazione faccia a faccia. Quando possibile, cerchiamo di riunire le persone nella stessa stanza per affrontare le parti cruciali di un progetto. Altrimenti, una buona regola è comunicare persino i più piccoli dettagli ai membri del team remoti e fare del proprio meglio per tenerli aggiornati.
D10: Come si fa a controllare e filtrare le informazioni inutili mascherate da "feedback dei clienti"?
R10: Riceviamo molti feedback dai clienti, il che è un'ottima cosa! Abbiamo uno strumento di feedback che raccoglie i commenti degli utenti e li salva come ticket in un progetto Jira. Trascorro la prima parte della mia giornata a leggere i ticket più recenti mentre sorseggio un caffè. Mentre esamino i commenti, prendo nota di eventuali temi o schemi comuni che emergono e aggiungo etichette per raggrupparli. Posso filtrare tutti i feedback utilizzando queste etichette per scoprire quante persone hanno sollevato un problema simile. Quindi, una volta stabilito uno schema, posso presentare questo problema al team di prodotto con casi d'uso specifici che possiamo affrontare.
