Sette persone, 21 conversazioni: cosa mi ha insegnato un team sul dare forma a un prodotto

Come un team multidisciplinare di sviluppo, art direction, marketing e UX ha dato forma a un prodotto: da dove nascono le idee e cosa aiuta a coordinarsi.

Metti sette persone su un progetto e non ottieni sette linee di comunicazione. Ne ottieni 21.

Il calcolo è semplice: ognuno può parlare con tutti gli altri, quindi un team di n persone ha n × (n − 1) / 2 conversazioni possibili. Fred Brooks l'ha messo per iscritto nel 1975, in The Mythical Man-Month, per spiegare perché aggiungere persone a un progetto software in ritardo tende a ritardarlo ancora di più (legge di Brooks). Tre persone condividono 3 conversazioni. Sette ne condividono 21. Ognuna può portare un'idea, e ognuna può perderne una.

Per i due anni del mio master ho vissuto dentro quelle 21 conversazioni. Il progetto si chiamava Pawka, un'app mobile che scansiona il cibo per animali e trasforma una lista di ingredienti illeggibile in un punteggio su 100. Il team: tre sviluppatori, due art director, una persona del marketing e io sulla ricerca UX e sul design dell'interfaccia.

Ecco la parte che non mi aspettavo. La decisione che ha fatto funzionare Pawka non è venuta da me.

L'idea migliore non era mia

La mia parte del progetto erano gli utenti. La ricerca dietro Pawka comprendeva 12 interviste semi‑strutturate, tre sessioni di osservazione in negozio e un benchmark dei concorrenti. Sapevamo che i nostri utenti passavano in media 4 minuti e 20 secondi nella corsia del pet food, e che il 92% di loro faceva fatica a leggere un'etichetta standard.

Quello che non avevo era il modello di business. Poi la modalità ospite è arrivata da fuori del ruolo UX: lasciare che le persone scansionino cinque prodotti al giorno senza nessun account, e chiedere la registrazione solo quando vogliono salvare un preferito o vedere la cronologia. Prima un'offerta gratuita, poi il Premium.

Sulla carta sembrava una decisione di marketing. In pratica è stata la migliore decisione UX dell'app.

Nella mappa delle frizioni del percorso utente, "registrazione obbligatoria prima della prima scansione" era l'unico problema valutato 5 su 5: chiedere un impegno prima di mostrare qualsiasi valore distrugge la conversione. Nei test, un partecipante l'ha detto meglio di qualsiasi grafico: "Potevo esplorare senza dare niente. È rassicurante per uno come me che diffida delle app."

Ricerca e modello di business indicavano quindi la stessa porta. Io avevo la prova di dove faceva male. Un compagno di squadra aveva la soluzione. Nessuno dei due l'avrebbe realizzata da solo.

Perché i team multidisciplinari hanno idee migliori (quando funzionano)

È la promessa di un team multidisciplinare, e la ricerca la sostiene.

Nel 2010 Anita Woolley e i suoi colleghi hanno dato a gruppi da due a cinque persone una grande varietà di compiti e hanno trovato qualcosa come un fattore di intelligenza collettiva: alcuni gruppi andavano bene in tutto. Non dipendeva da quanto fosse intelligente il membro più brillante. Era legato alla sensibilità sociale dei membri, e al fatto che tutti prendessero la parola, invece di una o due voci che dominano la stanza.

Google ha trovato uno schema simile studiando i propri team nel Progetto Aristotele. Tra le cinque dinamiche che distinguono i team efficaci, la sicurezza psicologica veniva al primo posto: la convinzione condivisa di poter correre un rischio davanti ai compagni senza essere puniti. L'idea risale allo studio di Amy Edmondson sui team di lavoro del 1999, che collegava la sicurezza psicologica a quanto i team imparano davvero.

Tradotto in un progetto universitario: l'idea della modalità ospite arriva sul tavolo solo se chi ce l'ha si sente libero di portare un'idea di business in una discussione UX. E sopravvive solo se chi fa UX non tratta la propria ricerca come un territorio.

Collaborazione da remoto: il vero nemico era il calendario

Ma mentirei se dicessi che la parte difficile erano le idee. La parte difficile era il tempo.

Sette studenti vogliono dire sette orari: corsi diversi, scadenze diverse, su due anni. Riuscire ad avere tutti disponibili nello stesso momento è stata la parte più difficile dell'intero progetto, e buona parte del coordinamento è avvenuta da remoto.

La ricerca sul lavoro da remoto descrive esattamente cosa fa a un team. Quando Microsoft ha mandato a casa tutta la sua forza lavoro nel 2020, uno studio su oltre 61.000 dipendenti ha mostrato che la collaborazione diventava più isolata e più asincrona: meno legami tra i gruppi, meno chiamate dal vivo, più email e messaggi. Le informazioni circolavano ancora, ma più lentamente, e meno spesso da una disciplina all'altra.

È questo il pericolo per un team misto. Gli sviluppatori finiscono per parlare con gli sviluppatori, gli art director con gli art director, e le 21 conversazioni si riducono in silenzio a tre.

A tenere insieme Pawka, quindi, sono state le cose che si potevano leggere senza che nessuno fosse nella stanza.

Un design system come contratto

Abbiamo trattato il design system come un contratto tra design e sviluppo. Seguiva l'Atomic Design: le fondamenta, poi gli atomi come pulsanti, badge e campi con tutti i loro stati documentati, poi le molecole come la card dei criteri, poi gli organismi come la scheda prodotto completa. Uno sviluppatore che lavorava in un orario diverso dal mio non doveva scrivermi per sapere com'era fatto un pulsante disattivato. La risposta era già scritta.

Sotto c'è una vecchia regola. Nel 1968 Melvin Conway osservava che le organizzazioni progettano sistemi che riproducono la propria struttura di comunicazione. Se il tuo team può parlarsi solo in modo asincrono, il tuo prodotto prenderà la forma di ciò che siete riusciti a scrivere. Quindi scrivete le cose giuste.

Feedback prima dei pixel

Ogni wireframe passava per due o tre giri di feedback interno prima di andare in alta fedeltà. In quella fase le schermate erano volutamente brutte, solo struttura. Questo le rendeva facili da criticare. Nessuno esita a dire "questo flusso è confuso" davanti a dei riquadri grigi, e un commento di un art director sulla gerarchia non costa nulla da applicare finché non esiste nemmeno un colore.

Le personas come arbitri

Alla fine avevamo sette profili, tra cui due anti‑personas, e ogni decisione di design doveva dire quale serviva. Sembra processo fine a sé stesso. In un team in cui tre discipline non sono d'accordo, è l'opposto: la discussione passa da "secondo me" a "Claire, in corsia con due minuti per decidere, ha bisogno di questo".

Il risultato: cosa hanno mostrato i test di usabilità

La prova che il team ha funzionato sta nei test. Il 100% dei partecipanti ricordava ancora il punteggio e il suo colore dopo aver guardato una scheda prodotto per cinque secondi. L'app ha ottenuto 80 sulla System Usability Scale, livello "buono". E l'unico compito in difficoltà, capire come viene calcolato il punteggio, si è fermato al 50% di successo diretto. La correzione è finita subito in cima alla roadmap: un pulsante "Come viene calcolato?" su ogni scheda prodotto.

Consigli di lavoro di squadra per un team di prodotto che inizia

• Contate le vostre conversazioni. In sette, decidete quali delle 21 devono davvero avvenire dal vivo, e date a tutti gli altri scambi un posto scritto.
• Lasciate arbitrare la ricerca, non l'anzianità. Una persona o un punteggio di gravità chiudono una discussione più in fretta di un titolo di lavoro.
• Scrivete ogni decisione dove guarderà la persona successiva. Se esiste solo in una chat o nella memoria di qualcuno, per chi arriva lunedì non è mai successa.
• Rendete sicuro portare idee da fuori del proprio ruolo. La nostra migliore decisione UX è arrivata da fuori della UX.
• Proteggete un momento dal vivo a settimana. Fate tutto il resto in modo asincrono, ma tenete un momento in cui tutte le discipline sono nella stessa chiamata nello stesso momento, così i silos non si chiudono.
• Riconoscete le idee con il nome di chi le ha avute. Le persone continuano a portare idee nei team in cui ci si ricorda da chi sono venute.

Cinque scansioni gratuite

Puoi leggere il caso studio di Pawka completo, dalle 12 interviste ai risultati dei test fino al design system.

Ma se qualcuno mi chiede cosa mi ha insegnato lavorare in team, indicherò la schermata più ordinaria dell'app: cinque scansioni gratuite, nessun account. Sembra un piccolo dettaglio di UX. È l'unico punto in cui un'idea di business, un risultato della ricerca e la frase di un utente diffidente sono atterrati esattamente nello stesso posto.

Non l'ho avuta io, quell'idea. Ho aiutato a dimostrare che era giusta. È a questo che serve un team.