Il Product Manager è spesso descritto come “ponte tra business, design e tecnologia”. La parte ponte “tra design e tecnologia” è particolarmente critica quando si tratta di spedire un prodotto di qualità: privo di bug, pixel-perfect e che tiene conto di tutti i possibili scenari e casi limite. Per assicurarsi che bridge funzioni bene, ecco diversi modi in cui viene gestito dal team di progettazione:

• Il progettista spedisce un prototipo completo, che mostra tutti i flussi del prodotto. Sfortunatamente, questo spesso richiede molto tempo e mancherà ancora alcuni casi limite.
• Il progettista spedirà solo un prototipo che mostra i flussi principali della funzionalità e rimane disponibile per le domande del team di sviluppo. Sfortunatamente, questi avanti e indietro sono altamente inefficienti (specialmente in una configurazione remota) e sprecano molto tempo sia dal team di progettazione che dallo sviluppo.
• Il progettista, oltre al prototipo completo, scrive un apposito documento di specifiche che elenca tutti i possibili scenari e casi limite. Il problema è che spesso è una perdita di tempo, perché (1) il tempo prezioso dei designer sarà speso meglio progettando altre funzionalità, non scrivendo un documento specifico e (2) non hanno sempre la stessa visione a 360° del prodotto come fanno i product manager, il che li farà trascurare alcuni scenari e casi limite.

Ecco perché i team di prodotto maturi di solito affidano la scrittura delle loro specifiche di prodotto ai product manager.

Ma come si dovrebbe scrivere le specifiche del prodotto? Ho scritto le specifiche del prodotto negli ultimi 5 anni e ho trovato un formato che è ben apprezzato dai team di software con cui lavoro. In questo post, sto condividendo di più sulla mia metodologia e gli strumenti che sto usando per scrivere le specifiche del prodotto. Sto anche descrivendo alcune limitazioni che sto affrontando con gli strumenti che sto usando e alcune idee di miglioramento che ho in mente.

Ecco i 5 argomenti principali che affronto in una specifica di prodotto:

1. Contesto e obiettivi
2. Mappa dell’architettura
3. Epiche e User stories
4. Criteri di accettazione
5. Design, contenuti e traduzioni

Contesto e obiettivi

Anche se le specifiche del prodotto sono rivolte principalmente ai team software, a loro piace ancora sapere perché stanno lavorando su ciò su cui stanno lavorando. Sono arrivato a capire che uno dei principali driver di motivazione per gli ingegneri del software è l’impatto. Molti di loro sognano di lavorare su funzionalità utilizzate da milioni di utenti. Sono entusiasti quando sentono che la nuova UX che hanno implementato ha aumentato la ritenzione del 15%, ad esempio. Quindi è importante dare un contesto sulla funzionalità che implementeranno:

• Di cosa stiamo parlando? Quale parte del prodotto? Sentitevi liberi di aggiungere qualsiasi storia della funzione che è utile per capire la situazione attuale.
• Qual è il problema attuale? Nota: ci possono essere diversi problemi da risolvere.
• C’è qualche feedback / verbatims qualitativo da parte degli utenti da citare?
• Ci sono dati (ad esempio grafici) da mostrare? In questa sezione, sentiti libero di includere qualsiasi grafico o grafico che renderà i dati più comprensibili.
• Qual è la soluzione scelta? (descrivilo semplicemente, in poche frasi)
• È stata presa in considerazione qualche altra soluzione? Se sì, perché è stato messo da parte?
• Qualche altra soluzione è già stata implementata? Come sta andando?
• Quali sono gli obiettivi ? C’è qualche KPI che stiamo cercando di influenzare? Ciò aiuterà in particolare il team del software a capire se è necessario implementare nuovi tracker / tag / eventi per raccogliere correttamente i dati. Ho visto i team sentirsi così guidati dal progetto che hanno preso l’iniziativa di configurare i dashboard per seguire le metriche in tempo reale, senza che io o chiunque altro lo chiedessi.

Architecture map

Prima di entrare troppo nei dettagli della funzione, è importante dare una panoramica di alto livello di ciò che cambia e ciò che rimane lo stesso nel vostro prodotto. E anche se stai lavorando su un prodotto completamente nuovo, una mappa dell’architettura sarà comunque estremamente rilevante per capire come è strutturato il prodotto.

“Architecture map” è il modo in cui chiamo una rappresentazione di diagrammi di alto livello delle caratteristiche del prodotto (flussi, schermi e contenuti) e di come sono correlati insieme. Alcune persone la chiamano ” Architettura delle informazioni”, “Mappa del flusso”, “mappatura UX”, ecc.

non C’è nessuna dichiarazione ufficiale metodologia di come disegnare un’architettura sulla mappa. Su un’applicazione mobile, di solito cerco di differenziare flussi, schermi e “parti di uno schermo” (o “contenuti in-page”), utilizzando una forma diversa per ciascuno di essi, come dettagliato nella legenda sopra.

Può anche essere utile giocare sul codice colore. Nell’esempio sopra, ho usato 3 colori e anche solido rispetto alla linea tratteggiata per spiegare come l’attuale architettura delle informazioni sarebbe stata aggiornata con il rinnovamento UX dell’applicazione su cui stavamo lavorando. (verde: rimarrà così com’è, arancione: verrà aggiornato, rosso: verrà eliminato; solido: rimarrà nello stesso posto, punteggiato: verrà spostato da qualche altra parte). In questo modo, gli ingegneri avevano una chiara visione a volo d’uccello su quale parte dell’applicazione sarebbe soggetta a modifiche.

Un altro consiglio per costruire una mappa di architettura comprensibile è distinguere chiaramente le varie parti della navigazione, come fatto di seguito con aree separate per ciascuna di esse.

un’architettura di mappa sarà molto utile per il vostro prodotto spec; ti consentirà di evidenziare quale parte del prodotto stai parlando in ciascuna delle tue storie utente.

Quale strumento si dovrebbe usare per disegnare una mappa di architettura? Ci sono tonnellate di loro disponibili là fuori, il mio preferito è estroso (perché è visivamente piacevole e molto semplice, non ingombra di così tante caratteristiche), ma ho anche usato Draw.io in passato — che è interessante perché è integrato con Google Drive, quindi se si lavora con Google Slides e Google Docs lo rende piacevole da usare. È anche integrato con JIRA e Confluence.

Se vuoi saperne di più sulle mappe dell’architettura (cosa fare e cosa non fare, quali strumenti usare, alcuni esempi, ecc.), Toptal ha messo a punto una grande lettura: La Guida completa all’architettura dell’informazione.

Epopee e User stories

Abbattere e spiegare tutte le parti del tuo prodotto può diventare molto rapidamente abbastanza caotico. Scrivendo le specifiche del prodotto negli ultimi 5 anni, il modo migliore che ho trovato per mantenere le specifiche organizzate e comprensibili è suddividerle in base alle “storie degli utenti”.

Che cos’è una storia utente? Secondo Agile Modeling, una user story è “una definizione di livello molto alto di un requisito, contenente solo informazioni sufficienti in modo che gli sviluppatori possano produrre una stima ragionevole dello sforzo per implementarlo.”

L’idea delle storie degli utenti è di mettere gli utenti al primo posto ed evitare di usare esclusivamente il vocabolario tecnico oscuro& quando si discutono le funzionalità. Come dice Atlassian: “Dopo aver letto una storia utente, il team sa perché sta costruendo ciò che sta costruendo e quale valore crea.”

Hanno lo scopo di costruire un prodotto migliore in cui l’utente è al centro dei dibattiti, contrariamente al buon vecchio sviluppo del prodotto waterfall.

Ecco come una storia utente deve essere formulata:

nel < tipo di utente > Voglio < qualche obiettivo > tale < qualche ragione >.

Per esempio, ecco come potremmo formulare utente storie per il seguente capitolo di architettura sulla mappa che ho disegnato per uno dei miei clienti:

• User Story #1: Come un dipendente nel profilo di sezione, voglio modificare il mio profilo, così posso aggiornare la mia foto, nome e cognome.
• Storia utente # 2: Come dipendente nella sezione profilo, voglio accedere alle impostazioni in modo da poter aggiornare la mia password e aggiornare le preferenze di notifica.
• User Story # 3: Come dipendente nella sezione profilo, voglio accedere alla chat in modo da poter dare un feedback agli sviluppatori dell’app

Spetta al product manager decidere quale livello di dettagli vogliono coprire nella user story. Se volessimo, potremmo anche andare un livello più in profondità nella User Story #2, ad esempio:

• User Story #2.a: Come dipendente nelle impostazioni, voglio accedere alla sezione “modifica password” in modo da poter aggiornare la mia password
• User Story #2.b: Come dipendente nelle impostazioni, voglio accedere alle preferenze delle notifiche in modo da poter aggiornare a quale frequenza ricevo ogni tipo di notifiche

Ma come vedi, questo è un po ‘ ovvio e ridondante. Ho scelto personalmente di coprire questi scenarii nei “criteri di accettazione” (vedi sezione successiva) delle storie in questione.

Per organizzare le storie degli utenti, usiamo spesso “epopee”. In termini agili ,le “epopee” sono grandi quantità di lavoro che possono essere suddivise in storie di utenti più piccole. Personalmente uso epiche per raggruppare storie che fanno parte dello stesso tema o area nel prodotto. Per esempio, ho scelto di raggruppare le storie di cui sopra come parte del “Profilo” epico. Alcune persone scelgono di formulare epopee allo stesso modo delle storie degli utenti, con una struttura più semplice (ad esempio ”Come utente, voglio accedere al mio profilo”)

Criteri di accettazione

Per essere sicuri che vengano aggiunti dettagli sufficienti a una storia utente, utilizziamo “criteri di accettazione” (a volte chiamati anche “condizioni di soddisfazione”).

Secondo LeadingAgile.com, “criteri di accettazione “sono” le condizioni che un prodotto software deve soddisfare per essere accettato da un utente, cliente o, nel caso di funzionalità a livello di sistema, il sistema che consuma.”

Nei criteri di accettazione, è necessario elencare tutte le specificità funzionali che non sono chiaramente enunciate dalla storia dell’utente. Esempio:

User Story

Come dipendente nella sezione profilo, voglio modificare il mio profilo in modo da poter aggiornare la mia foto, nome e cognome.

i criteri di Accettazione

• Dato che sto su modifica profilo schermo Quando faccio clic su modifica nome icona Poi si dovrebbe passare alla modalità di modifica, messa a fuoco sull’ingresso e aprire la tastiera (lo stesso vale per il cognome)
• Dato che sto su modifica profilo schermo Quando faccio clic su modifica foto icona, Quindi dovrebbe chiedermi di scegliere tra la fotocamera e la libreria
• Dato che sto modificando il mio nome Quando faccio clic su “salva”, Quindi è necessario reindirizzare me la modalità di lettura e dovrei vedere un successo di notifica

ecc…

Pensare i criteri di accettazione come un lista di controllo che dovrà essere completata per il prodotto da spedire. Il formato dato / Quando / Allora usato sopra è un buon modo per aiutarti a formulare i tuoi criteri di accettazione, ma in alcuni casi può essere difficile da usare.

Design, contenuti e traduzioni

Avere disegni aggiornati nelle specifiche del prodotto

Finora, non ho menzionato quale strumento sto usando per scrivere le specifiche. In passato, sono passato da Google Docs, Google Slides e Notion. Mi è piaciuto molto usare Notion per tutte le interessanti integrazioni che offre (specialmente quelle con InVision e Figma). Ma ora sono completamente passato a Google Docs: preferisco avere più libertà nel modo in cui formatto le mie specifiche di prodotto. È anche più conveniente utilizzare i prodotti Google quando lavori con partner o clienti esterni.

Per assicurarsi che l’identità visiva del prodotto sia accuratamente realizzata dal team di sviluppo, è importante dare loro accesso alle schermate più aggiornate fornite dai designer. Ma poiché non esiste una vera integrazione tra Google Docs e strumenti di progettazione come Figma, InVision o Zeplin, ero solito esportare schermate e copiarle/incollarle nelle mie specifiche di prodotto.

Questo diventerebbe molto rapidamente un problema: i progettisti iterano sui loro schermi su base giornaliera, e anche quando tutto è stato concordato su uno schermo, può cambiare alcune settimane dopo a causa di un componente specifico che viene aggiornato nella libreria di progettazione. Ciò causerebbe le mie specifiche per essere obsolete la maggior parte del tempo.

Ecco perché oggi sto usando solo il nome degli schermi. Ad esempio, se una storia utente su profile edition riguarda le schermate 2 che sono state progettate su Figma, scriverò solo “Nome schermo Figma: edit-profile-1 e edit-profile-2”.

Ovviamente questo non è l’ideale e costringe gli sviluppatori o chiunque altro legga le mie specifiche per passare da diversi strumenti.

Ma questo dimostra che oggi c’è qualcosa di inefficiente nel modo in cui scriviamo le specifiche del prodotto. L’utilizzo di diversi prodotti solleva le questioni dell’integrazione e della sincronizzazione. Come garantire che tutte le informazioni necessarie per costruire un prodotto siano visibili in un unico luogo, senza essere obsolete? (In realtà, questo non vale solo per i disegni, ma anche per l’architettura mappe e contenuti).

→ Se anche tu stai riscontrando questo problema e hai trovato una soluzione, sarei interessato a ottenere il tuo feedback!

Dare un facile accesso ai contenuti e traduzioni per evitare errori di battitura

Quando si progetta schermi con una grande quantità di contenuti, è bello dare agli sviluppatori la possibilità di copiare / incollare facilmente invece di dover ri-digitare se stessi. Altrimenti, potresti finire con (1) molti errori di battitura e (2) sviluppatori incazzati. Ci sono diversi modi per dare loro accesso al contenuto:

• Dando loro accesso ai file sorgente del lavoro di progettazione su Sketch, Figma o Zeplin per esempio.
• Copiando / incollando il contenuto direttamente nelle specifiche (può renderlo un po ‘ disordinato).

Se il prodotto esiste in diverse lingue, dare anche l’accesso a ogni traduzione. Ad esempio, è possibile utilizzare un array per mostrare la traduzione del contenuto originale in ogni lingua. Il livello successivo di gestione della traduzione consiste nell’utilizzare uno strumento di localizzazione (come la frase) e aggiungere solo le “chiavi di traduzione” nelle specifiche del prodotto. Ma ancora una volta, questo implica un altro avanti e indietro tra le specifiche del prodotto e un altro strumento.