La guida al processo e alla documentazione di progettazione UX

La documentazione è strumentale per l'ideazione, la progettazione, la creazione e la misurazione delle prestazioni dei prodotti. Ma non dovrebbe essere fatto solo per motivi di manutenzione. Dopotutto, non c'è niente in una spessa pila di scartoffie che assomigli all'esperienza del tuo prodotto reale.

Come descrive Jeff Gothelf, sostenitore della Lean UX, in un articolo per Smashing Magazine, gli spessi deliverable creati semplicemente come riferimento futuro per quanto riguarda l'esperienza dell'utente diventano obsoleti quasi non appena vengono creati. Nel mondo snello e agile di oggi, l'esperienza dovrebbe essere al centro, non i risultati finali. Sia che tu scelga processi leggeri o più dettagliati, la chiave è che la tua documentazione dovrebbe aiutare a portare avanti il ​​progetto (piuttosto che essere solo un indicatore di ritardo).

Di seguito viene fornita una panoramica della documentazione di progettazione e sviluppo del prodotto, dei singoli elementi e delle rispettive fasi a cui appartengono. Lo sviluppo del prodotto e la documentazione possono variare a seconda dell'azienda (ad esempio, Spotify, come discusso in Creazione di prodotti minimi realizzabili su Spotify), ma molti dei risultati finali riportati di seguito sono in qualche modo comuni nella maggior parte delle organizzazioni.

Abbiamo scelto i metodi che riteniamo funzionino meglio, ma sentiti libero di scegliere solo ciò che funziona.

Come si relazionano tutti

Quando si tratta di documentazione di progettazione del prodotto, teoria e pratica sono due cose molto diverse. Conosciamo tutti i principi di base del design incentrato sull'utente. Riconosciamo diversi metodi di ricerca, la fase di prototipazione e il processo di documentazione delle tecniche nei nostri ricchi ambienti metodologici. La domanda che probabilmente ti poni spesso, però, è "Come funziona in pratica?"

Fonte immagine: il processo di progettazione .

In poche parole, si tratta di rendere la documentazione complementare piuttosto che supplementare al processo di progettazione. Prima di entrare nei dettagli, potrebbe essere utile dare una rapida panoramica della documentazione durante la progettazione e lo sviluppo del prodotto. Di seguito, abbiamo fornito una spiegazione pratica di come ogni fase della documentazione di progettazione si collega insieme:

1. Durante la fase iniziale della definizione del prodotto , stai facendo un brainstorming sul prodotto e su come eseguire il progetto al massimo livello con tutte le parti interessate necessarie. Ciò potrebbe comportare un piano di avvio del progetto, una tela snella e un sacco di mappe concettuali e modelli molto precoci di ciò che stai cercando di costruire.
2. Passando alla ricerca , il tuo team affina le ipotesi e riempie gli spazi vuoti. Questa fase varia in base alla complessità del prodotto, ai tempi, alle risorse, al livello di conoscenza esistente e a molti altri fattori. In generale, tuttavia, è bene costruire analisi competitive e di mercato e condurre sondaggi sui clienti. Se si dispone di un prodotto esistente, anche la revisione di analisi, euristica, contenuto, contesto del prodotto e test utente è molto utile.
3. Nell'analisi, i dati di marketing del prodotto raccolti finora forniscono la base per persone, mappe dell'esperienza e documenti dei requisiti come fogli di calcolo delle funzionalità con priorità e matrici di attività utente. A questo punto, la definizione del prodotto, le priorità del prodotto e il piano del prodotto sono stati definiti e sono pronti per risultati di progettazione più formali. Come discusso nella Guida al processo e alla documentazione di progettazione UX, è probabile che anche schizzi e diagrammi vengano costantemente generati durante questo periodo.
4. Da questo output possono essere creati scenari, mappe concettuali e prototipi, che portano alla fase di progettazione . La documentazione comune include schizzi, wireframe, prototipi, diagrammi di flusso delle attività e specifiche di progettazione. Ad esempio, l'analisi competitiva e i personaggi creati durante la ricerca e l' analisi alimentano i modelli, le mappe concettuali e gli scenari. A loro volta, questi pezzi influenzano risultati intermedi e avanzati come wireframe, storyboard e mockup dettagliati. Alcune aziende trattano la fase di ricerca, analisi e progettazione come un unico grande processo, come puoi vedere in questo grafico di panoramica.
5. Durante l'implementazione , il codice e le risorse di progettazione vengono assemblati per creare un prodotto che segua le specifiche di progettazione del prodotto.
6. Al momento del lancio del prodotto live , i dati di feedback come ticket di supporto, segnalazioni di bug e altre analisi continuano a guidare il perfezionamento del prodotto attraverso successive iterazioni e aggiornamenti. Con l'offerta in modalità di produzione, i dati dovrebbero essere continuamente generati e monitorati sotto forma di analisi e report per garantire un successo continuo.
7. Il miglioramento continuo del prodotto basato sui dati si ottiene attraverso la misurazione e l'iterazione dell'offerta in produzione, utilizzando dashboard e analisi delle prestazioni.

Principi guida

Ora che hai visto come ogni fase è collegata tra loro, diamo un'occhiata ad alcuni principi utili per spostare il prodotto lungo ogni fase. Spiegheremo come utilizzare gli sprint di progettazione in modo che il processo si evolva nel tempo invece di essere definito solo all'inizio.

Fonte immagine: Fonte: Design incentrato sull'utente .

Simile alla sua controparte software Agile, gli sprint di design sono sprint di 1-3 settimane incentrati sulla risoluzione di problemi specifici di prodotto e design. Secondo Alok Jain, UX Lead presso 3Pillar, i tre elementi chiave per progettare gli sprint sono la collaborazione, la riduzione dell'attrito di consegna e la concentrazione sul team . In poche parole, la tua documentazione è uno sforzo collaborativo che deve sempre concentrarsi sull'utente stesso. Poiché ti muovi rapidamente tra ogni fase, crei slancio e riduci al minimo gli sprechi. Ancora più importante, stai affrontando problemi più piccoli che consentono una maggiore esplorazione e assunzione di rischi.

Una versione estremamente snella del ciclo completo può essere trovata qui, ma descriveremo in dettaglio di seguito come applicare questo pensiero mentre comprendi il prodotto, progetti il ​​prodotto, rilascia e migliora il prodotto.

1. Comprendere il prodotto

Prima di poter costruire un prodotto, è necessario comprenderne il contesto per l'esistenza. Perché le parti interessate, l'azienda e gli utenti dovrebbero preoccuparsi di portare avanti la tua idea?

Fonte immagine: raggiungi una comprensione condivisa .

Secondo Smashing Magazine, è necessario includere attività che rispondano ai requisiti aziendali, ai requisiti degli utenti e alla migliore soluzione di progettazione per soddisfare entrambi. La parola chiave qui è "attività", perché mentre documenti come Business Model Canvas e Lean Canvas sono importanti, è necessario stimolare le parti interessate, altrimenti ci sono solo un gruppo di persone costose che parlano di cose che tutti già conoscono. Queste attività sono efficienti e invitano alla collaborazione:

• Interviste con le parti interessate : utilizzando questo modello, puoi fare in modo che ogni membro del team intervista 3 parti interessate. Come farà il prodotto a far sentire i clienti? Cosa dovrebbero fare? Registrando come le parti interessate pensano che i clienti penseranno, sentiranno e faranno, stai impostando un benchmark da confrontare con i test di usabilità e l'analisi degli utenti.
• Workshop sui requisiti : riunisci le parti interessate, discuti il ​​piano del progetto e inizia a discutere di come i concetti si inseriscono nel prodotto e
  requisiti tecnici. Puoi iniziare con un Business Model Canvas o un Lean Canvas vuoto e completarlo con il team.
• 8 pazzi : prendi alcuni pennarelli e fai in modo che tutti diano uno schizzo di 8 idee per prodotti o funzionalità in 5 minuti. Chiedi a tutti di segnare ogni idea, e
  inizierai a vedere tendenze e preferenze. Questo era in realtà il passaggio 2 nel processo di riprogettazione di Google Ventures. Per ulteriori idee, dai un'occhiata a questo elenco di attività di brainstorming.

Una volta che hai stabilito le basi, parla e testa con tonnellate di utenti in modo da avere dati sul campo reali per la ricerca e l'analisi. Marcin Treder, CEO di UXPin, si è immerso nello sviluppo dei clienti e nei test di usabilità dopo aver identificato il problema e la portata. Ai tempi in cui UXPin era solo uno strumento di prototipazione su carta, Marcin ha documentato (su carta e video) oltre 50 interviste agli utenti e test di usabilità di persona con superstar dell'esperienza utente come Brandon Schauer, Luke Wroblewski, Indi Young e altri. Il team del prodotto ha quindi utilizzato queste informazioni per creare personaggi, scrivere dozzine di storie di utenti e, infine, delineare i requisiti del prodotto.

In Amazon, viene utilizzato un approccio alternativo "lavorando a ritroso" in cui il primo passaggio è la stesura di un comunicato stampa interno per il prodotto finito. Questo approccio aiuta a lavorare a ritroso rispetto al cliente, piuttosto che cercare di vincolare i clienti a un'idea. Iterando il comunicato stampa finché non sembra interessante, il team del prodotto ottiene un controllo immediato della realtà e un rapido documento di riferimento per la progettazione e lo sviluppo successivi.

2. Progettazione del prodotto

Come discusso nella Guida ai prodotti minimi vitali , una volta che hai un'idea del
scopo del prodotto, il tuo obiettivo principale è costruire un prototipo. Se alla tua squadra piace disegnare sui tovaglioli, creare wireframe ad alta o bassa fedeltà, alla fine dovresti ottenere qualcosa di funzionale. La particolarità di questa fase è che per la maggior parte dei risultati finali, la documentazione è il progetto.

Fonte immagine: Pin UX .

Secondo Cennydd Bowles, Design Manager di Twitter, il team di prodotto dovrebbe ricercare due iterazioni in anticipo, progettare un'iterazione in anticipo e rivedere l'iterazione precedente. Se stai cercando di rimanere agile, consiglia di immergerti direttamente nei prototipi a bassa fedeltà come un modo per dare la priorità alle "interazioni rispetto ai processi". Se vuoi essere un po' più dettagliato ma vuoi comunque rimanere un po' leggero, puoi iniziare con mappe concettuali o schizzi, quindi passare a wireframe a bassa fedeltà e infine creare un prototipo ad alta fedeltà. Indipendentemente dal tuo metodo, assicurati di testare con le parti interessate e gli utenti.

Se il budget e le tempistiche lo consentono, puoi anche creare mappe dell'esperienza per evidenziare dove il prodotto soddisfa o meno le esigenze degli utenti e modelli di attività per fornire informazioni dettagliate sulle attività che gli utenti svolgono per raggiungere i loro obiettivi. Sebbene questi non facciano parte del design, sono complementari poiché devi anche vedere dove si inserisce il tuo prodotto nella mente e nel mercato. È interessante notare che Yelp fa un ulteriore passo avanti nella fase di progettazione creando una guida di stile che include righe di codice comuni, consentendo alla documentazione di essere letteralmente incorporata nel prodotto.

In UXPin, il nostro processo consiste nel tenere una sessione di schizzo di gruppo con pennarelli su carta a griglia, quindi ridurlo a pochi wireframe e quindi aggiungere dettagli fino a quando non avremo un mockup ad alta fedeltà. Se è coinvolto il test degli utenti, costruiremo il mockup in un prototipo ad alta fedeltà. Per le versioni di funzionalità di grandi dimensioni, conduciamo test utente approfonditi, quindi il rapporto è di circa 70/30 a favore dei prototipi.

3. Costruzione e lancio del prodotto

Quando inizi a fare il lavoro tecnico pesante, è importante creare documentazione che ti aiuti a vedere la visione generale. I requisiti specifici possono cambiare man mano che perfezioni il prodotto, ma la tua documentazione dovrebbe aiutarti a capire le priorità man mano che il tuo prodotto diventa libero.

Fonte immagine: la campagna MVP .

Kristofer Layon, UX Manager di RedStamp , ritiene che sia possibile visualizzare i requisiti del prodotto e i documenti delle specifiche tecniche come una tabella di marcia. La road map del prodotto mostra le storie degli utenti e aiuta a stabilire la priorità delle funzionalità che creerai per soddisfarle. A volte, nella tabella di marcia possono essere aggiunte date specifiche in modo che funzioni anche come sequenza temporale. L'eleganza della tabella di marcia è che ti aiuta a dare priorità a ciò che stai costruendo, rendendolo complementare al "come" definito dai requisiti del tuo prodotto e dalle specifiche tecniche. Quando decidi le funzionalità, puoi utilizzare il modello Kano per valutarle in 3 categorie:

• Attributi di base : sono assolutamente necessari solo per il funzionamento del prodotto. Ad esempio, l'attributo di base di un laptop è la tastiera o lo schermo.
• Attributi delle prestazioni : possono essere confrontati tra diversi prodotti come un KPI. Ad esempio, un laptop viene giudicato in base alla velocità della CPU e allo spazio su disco rigido poiché le persone tendono a preferire i computer veloci in grado di archiviare molti dati.
• Attributi deliziosi : sono soggettivi a seconda delle preferenze del cliente. Ad esempio, il Macbook Air è estremamente sottile e liscio al tatto. Il cliente giusto lo troverebbe un ottimo punto di forza mentre gli altri non sono impressionati.

Assegnando un punteggio alle caratteristiche su una scala da 1 a 5 basata su questo modello, puoi quindi tracciarle su una matrice di priorità per aiutarti a iniziare a immaginare come sarà la roadmap del tuo prodotto. In Apple, le "Regole della strada" e "Apple New Product Process" fungono da roadmap del prodotto definendo responsabilità, fasi di creazione e tappe significative dall'inizio al lancio. In effetti, il Regolamento della Strada è preso così sul serio che perderlo può comportarne l'immediata risoluzione (è anche affermato nel documento).

4. Migliorare il prodotto

Mentre crei (e infine lanci) il tuo prodotto, la documentazione deve anche concentrarsi sulla definizione e sul monitoraggio delle vendite e di altri KPI. Dopotutto, non puoi migliorare il prodotto se non sai quali metriche vuoi ottimizzare.

Fonte immagine: gestione del prodotto in base ai numeri .

Dave Daniels, fondatore di LaunchClinic, consiglia di annotare gli obiettivi di lancio (ad es. 30.000 download in 30 giorni) e di verificare di disporre degli strumenti giusti per documentare i progressi. Utilizzando gli strumenti di misurazione e il software di segnalazione dei bug, puoi impostare rapporti ricorrenti per tenerti d'occhio durante le prime settimane dal lancio e oltre. Sul lato cliente, puoi anche segmentare gli utenti e inviare loro sondaggi personalizzati per valutare dove potresti voler iterare.

In Spotify, la fase di iterazione è la fase più lunga dello sviluppo del prodotto. Il team del prodotto utilizza le metriche correnti e la matrice di assegnazione delle priorità (probabilmente creata durante la fase di progettazione) per valutare i vantaggi rispetto allo sforzo di migliorare determinati prodotti oltre il loro "massimo locale". Se determinano che lo sforzo vale la pena, torneranno alla fase di definizione per rinnovare il prodotto per il suo "massimo globale".

Processi oggettivi in ​​un ambiente soggettivo

Quando si tratta di documentazione di progettazione del prodotto, non esiste un unico proiettile magico. Quasi tutte le aziende che utilizzano il nostro prodotto utilizzano parti delle tattiche che abbiamo descritto sopra. Sebbene lo sviluppo del prodotto e la progettazione dell'esperienza utente siano spazi altamente soggettivi, non è necessario che lo siano i processi e la documentazione. Dopotutto, l'obiettivo finale di un prodotto sono le entrate e non c'è nulla di soggettivo in questo.

Fonte immagine: note sul processo di progettazione .

Che tu preferisca una documentazione leggera o che preferisca una documentazione più dettagliata, l'obiettivo è lo stesso: toglilo dalla testa e su carta (o sullo schermo) in modo che il tuo team possa interagire e reagire. La documentazione dovrebbe essere una bussola per il prodotto, non regole scolpite nella pietra. Alcune delle fasi di cui abbiamo discusso possono verificarsi in un ordine leggermente diverso o addirittura in parallelo, ma esistono tutte per fornire un metodo alla follia. Usa ciò che funziona, elimina il resto ed evolvi la tua documentazione man mano che il tuo prodotto si evolve.

Per ulteriori modi per incorporare la documentazione nel processo di progettazione, scarica la Guida alla documentazione di progettazione e processo UX. I consigli degli esperti sono forniti da Aarron Walter, Laura Klein, Ian McAllister e dozzine di altri. Vengono mostrati anche esempi visivi da aziende come Vurb, MailChimp, Apple, Google e molte altre.