Migliore documentazione e comunicazione del team con i documenti di progettazione del prodotto

Il processo tipico per lavorare come designer di prodotti in un'azienda o in una startup potrebbe esserti familiare: è in fase di sviluppo un nuovo prodotto per il quale fornire una soluzione di design. Quindi lavori su alcune proposte di design e le presenti davanti a 1-3 persone per raccogliere feedback.

A volte questo processo funziona bene, ma altre volte no. Ad esempio, alcune persone sono impegnate a prestare attenzione per completare i propri compiti e non dedicano abbastanza tempo a fornire un feedback chiaro e conciso per la tua proposta di design.

Può anche succedere che, anche se il tuo processo è buono, tu voglia comunque formalizzare il processo annotando le decisioni, tenendo traccia delle iterazioni e del processo di progettazione in generale, soprattutto in questi tempi in cui ci troviamo a lavorare da remoto a causa del COVID19.

Documentare il processo ha molti vantaggi. Ad esempio, rende il tuo lavoro più visibile, crea opportunità per ottenere feedback da molte più persone, migliora la comunicazione generale e fornisce un quadro chiaro di come è stata progettata una funzionalità con tutto il contesto e le considerazioni in merito.

La caduta dell'eroe Designer

Intorno al 2018, lavoravo come Product Designer a distanza da Madrid in un'azienda che opera in America Latina, coinvolgendo in questo processo altri team dal Messico e da San Paolo, Brasile.

Prima di iniziare a lavorare in questa azienda, ho avuto molte esperienze diverse nella mia carriera lavorando in ambienti di piccole e grandi dimensioni di molti settori diversi come media, studi di design, un social network, un sistema operativo mobile, ho fondato una startup di e-grocery , e ha anche fatto alcuni concerti freelance con altre piccole startup.

Durante quegli anni ho seguito lo stesso approccio, hai alcune persone sedute nella stessa stanza, hai presentato la tua soluzione, fornisci alcuni schermi, flussi, ricevi un feedback e la presenti di nuovo. Dopo alcune iterazioni, il tuo lavoro sarà pronto per raggiungere la fase di sviluppo.

Tuttavia, questo stesso approccio ha smesso di funzionare. Poco dopo essere entrato a far parte del team, mi sono reso conto che presentare i miei progetti in videochiamata non era abbastanza. Stavo creando molte proposte, ma non sono riuscito a raggiungere l'approvazione finale dei miei stakeholder e dei miei compagni di squadra. Ero confuso e continuavo a chiedermi: cosa stava succedendo? Non stavo progettando la migliore soluzione possibile? Non stavo fornendo un lavoro di buona qualità? Ognuna di quelle domande mi stava facendo perdere fiducia in me stesso. Il problema era che dovevo adattare il mio processo a questo ambiente.

Non appena ho capito che il mio processo non funzionava, ho iniziato a leggere molti articoli su come lavorare come designer da remoto, l'effetto gabbiano (quando qualcuno entra nel tuo lavoro, lo critica duramente e poi vola via), come altre aziende si stavano avvicinando alla collaborazione remota e come hanno formalizzato il loro processo scrivendolo. Dopo aver letto tutto questo materiale, mi sono chiesto in che modo gli sviluppatori stessero affrontando lo stesso problema. Come fanno a collaborare su ambienti remoti in modo quasi asincrono? Come arrivano agli accordi definitivi? Ho scoperto che in effetti la comunità degli sviluppatori ha già un processo che funziona abbastanza bene per loro: si chiama pull request.

Le richieste pull ti consentono di introdurre modifiche in una base di codice più ampia documentandole e convalidando le tue decisioni con il feedback di altre persone. In questo modo, le modifiche che introduci si integrano perfettamente con tutti gli standard e le connessioni che il codice ha già in atto. Questo è esattamente ciò che dovevo ottenere, ma ovviamente in un approccio di design-moda. Lascia che ti presenti il ​​Product Design Doc.

Il documento di progettazione del prodotto

Un Product Design Doc (PDD) è un documento che converte i problemi che si desidera risolvere, il contesto e la soluzione finale in un'iterazione o un approccio basato su fasi.

Ciò significa che puoi documentare l'intero processo di progettazione in un unico documento che può essere condiviso con chiunque nella tua azienda e che vivrà come base di conoscenza per le decisioni sul prodotto che prendi. Suona bene, eh? Scendiamo nei dettagli.

Concetti generali

Un PDD può essere descritto in 4 concetti principali: metadati, contesto, fasi e feedback .

• I metadati sono solo informazioni utili sul documento come titolo, data, stato e così via.

  

• Il contesto è ciò che le altre persone hanno bisogno di leggere, per comprendere le proposte di design che fai, pensarci come la descrizione, il problema, l'abstract o gli obiettivi di ciò che devi raggiungere.

• Le fasi sono le diverse iterazioni del progetto, che in genere iniziano a concentrarsi sulla soluzione più ampia e in ogni fase si concentrano su dettagli più specifici. Ogni fase si basa sulla precedente e affronta il feedback ricevuto. Questo è un modo strutturato per raggiungere un punto finale in cui i problemi risolti non possono più ripresentarsi.

• Il feedback si riferisce a tutte le opinioni, commenti, richieste e consigli che raccogli da altre persone. Puoi raccogliere feedback dalle parti interessate o dai membri del team.

Con questi quattro concetti, puoi creare diverse varianti di PDD per soddisfare le tue esigenze, ogni azienda/progetto è diverso e ciò che ha funzionato per me, non deve funzionare allo stesso modo per te. Ma se tratti questi 4 concetti principali nel tuo PDD, è probabile che funzioni in quasi tutte le situazioni.

Esempio di struttura

Dopo aver compreso i concetti principali, condividerò con voi la struttura che ho utilizzato durante il mio periodo in quell'azienda. Ha le seguenti sezioni:

• Il titolo dovrebbe essere conciso, chiaro e facilmente distinguibile da altri titoli PDD che hai già.
• Lo stato indica in quale fase si trova il tuo documento in questo momento:
• Bozza
  Sto ancora lavorando alla definizione del Contesto. Non pronto per il feedback.
• S30, S60, S90
  Le diverse fasi (30%, 60%, 90%) della tua soluzione (maggiori dettagli sulle fasi successive).
• Completare
  Tutti i feedback sono stati affrontati e non ci sono punti mancanti. Il PDD è terminato.
• L' abstract è la descrizione del problema per il quale è necessario progettare, collegandosi comunemente ad altre utili letture correlate che potresti avere.
• Gli obiettivi sono i punti chiave su cui la tua soluzione deve concentrarsi, questa è una lista di controllo che rivedrai costantemente per essere sicuro di essere sulla strada giusta.
• S30 (o Stage 30% ) è la prima proposta che fai in base all'astratto e agli obiettivi, concentrandoti sulla soluzione più ampia anziché sui dettagli, magari fornendo un wireframe a bassa fedeltà o una tecnica simile. Questa è la fase in cui la soluzione proposta potrebbe adottare un approccio completamente diverso e si prevede che si verificheranno importanti feedback.
• S60 (o Stage 60% ) è la tua soluzione al 60% di completezza e applica il feedback di S30. Ha meno dettagli di S90, ma indica chiaramente l'intenzione della tua soluzione. Fornisci un wireframe ad alta fedeltà con più casi coinvolti e alcune definizioni di flusso. Potresti ricevere una sorta di feedback incentrato principalmente su casi persi e piccoli scenari imprevisti.
• S90 (o Stage 90% ) è lo stadio che ha la soluzione al 90% di completezza e applica il feedback di S60. Questa fase si concentra sui dettagli più fini del tuo progetto, inclusi tutti i diversi scenari, casi d'angolo, design visivo e persino prototipi. Dovrebbe avere una sorta di feedback minore.

Ti starai chiedendo, devo seguire lo stesso ordine e la stessa convenzione di denominazione delle fasi? Beh, no, non lo fai. Puoi rinominare lo stage da S30, S60 e S90 in solo: Esplorazione, Proposta, Soluzione.

Puoi anche modificare l'ordinamento in modo che il lavoro più raffinato (S90, Soluzione) arrivi in ​​cima al documento e il flusso di lettura vada dalla fase finale a quella iniziale (S30, Esplorazione).

Modelli

Inizia rapidamente con uno dei modelli forniti per le piattaforme di scrittura più comuni. Ricorda: le convenzioni di denominazione delle sezioni sono totalmente personalizzabili. Se non ti piace Abstract , usa semplicemente Brief , About o qualsiasi cosa adatta alle tue esigenze. Il concetto principale che dovrai mantenere riguarda la creazione di diverse iterazioni per concentrarti su ogni fase, puoi semplicemente rinominare S30 per esplorazione, S60 per proposta e S90 per soluzione.

• Carta
• Nozione
• documenti Google
• Esempio di vita reale

Principali vantaggi dell'utilizzo di PDD

1. Ogni decisione è documentata.
   Ciò significa che anche quando lasci la tua azienda/progetto (e questo prima o poi accadrà), tutta la conoscenza generata rimarrà in azienda per sempre, così altre persone possono guardarla e ripetere da dove hai lasciato.

2. Migliora la comunicazione.
   Ottenere persone diverse dal tuo team sul PDD per fornire feedback aiuta tutti a rimanere sulla stessa pagina ed essere consapevoli delle decisioni prese.

3. Limita i cambiamenti infiniti da parte degli stakeholder.
   Ogni fase si concentra su una diversa angolazione del problema, passando da soluzioni più ampie a soluzioni ristrette. Ciò consente alle persone di concentrarsi su un singolo problema alla volta, aiutandole nelle fasi finali.

4. Il prodotto è costruito in modo collaborativo.
   Invece delle parti interessate che definiscono soluzioni specifiche, lasciamo che i team di progettazione, progettazione e altri si impegnino con la soluzione rendendoli partecipi di essa.

Note finali

Chiudendo la storia di questa azienda remota, ho avuto modo di lavorare lì ancora per qualche mese e sono stato in grado di implementare i Product Design Docs almeno su 5 diversi progetti. La mia frustrazione si è ridotta molto e sono riuscito a raggiungere un consenso sulle mie proposte di design in modo che il prodotto continuasse ad evolversi. Da allora, l'azienda è cresciuta molto e parte del lavoro che ho svolto durante il mio tempo è ancora in uso.

PS: Ho iniziato a scrivere questo articolo nel 2019, poi nel 2021 ho visto che Abstract stava creando un prodotto per documentare il processo di progettazione, quindi ho deciso di rimettermi in carreggiata e finirlo. Sembra che sia ancora un argomento abbastanza rilevante.

Bibliografia

• Come eseguire esercizi di progettazione su un team remoto di Hannah Hearth
• Evita l'effetto gabbiano: il quadro del 30/60/90 per il feedback di Lauren Moon
• Come si progetta un documento di design? di Giovanni Saito
• Il potere del design doc di Brendan Fagan
• Presentazione dei taccuini di Matt Colyer