Share
Il "deliverable". Un concetto semplice da capire (qualcosa che "offri"), ma difficile da spiegare correttamente.
Un modo per descrivere un deliverable sarebbe come un pezzo di lavoro o un artefatto che è un collettivo di un gruppo più ampio di lavoro. Ad esempio: una mappa del sito, un modello di navigazione e una definizione di ricerca rientrerebbero tutti nell'ambito di "architettura delle informazioni". Per formalizzare questo deliverable ci potrebbe essere un documento che contiene tutti questi artefatti e una copertina con alcune informazioni sulla versione.
Inoltre, artefatti e risultati possono essere autonomi e intercambiabili. Un wireframe, ad esempio, può essere utilizzato come deliverable su un progetto per mostrare a un manager che stai facendo progressi, fornire informazioni sullo sviluppatore sulla struttura necessaria o raccogliere un pagamento milestone da un client.
La cosa importante da togliere è che un deliverable non è qualcosa che dovrebbe essere fatto per ottenere un output, ma per fornire maggiore lucidità o avvicinare il progetto / prodotto allo stato finale desiderato. Pertanto, è importante pensare in modo critico sul motivo per cui si sta creando un deliverable e su quale livello di fedeltà / formalità in quanto esiste il potenziale per perdere un sacco di tempo!
I deliverable hanno un pubblico e, a volte, alcuni si sovrappongono come mostrato nel diagramma di Venn in basso. Capire che il pubblico è un primo passo importante nella comprensione della necessità del deliverable e del livello di fedeltà o formalità che potrebbe essere richiesto.
Generalmente, il product manager o qualsiasi manager interno sarà in gran parte interessato alla fase di scoperta e definizione. Questo è quando il business ha bisogno e i processi vengono sottoposti ad hash e il prodotto viene definito. Pertanto, se richiedono una rappresentazione di ciò che il prodotto può sembrare lungo la linea, potrebbe essere meglio consegnare uno schizzo disegnato a mano di alcuni layout, piuttosto che perdere tempo nella codifica di un prototipo, ad esempio.
Gli sviluppatori hanno il compito di programmare ciò che è stato scoperto, definito e progettato in rappresentazioni finali tramite codice. C'è molto spazio per l'interpretazione errata con i wireframe. Qualunque layout sia consegnato a un team di sviluppo deve essere pixel perfetto e le specifiche dovrebbero essere create, in quanto il tuo sviluppatore medio creerà esattamente ciò che richiedi, specialmente se si tratta di un team in outsourcing!
Nel caso dei clienti, i deliverable potrebbero dover essere più raffinati e servire come strumenti di marketing (per mostrare quanto è buona l'agenzia). A volte utilizzerai i deliverable per influenzare lo stakeholder esterno o per soddisfare parte di un accordo contrattuale quando lavori con una "struttura di pagamento milestone".
Pubblico e tipi consegnabiliIl pubblico non solo ha un ruolo importante nel modo in cui creare il deliverable, ma anche la struttura dell'organizzazione. Nulla rimane costante, anche all'interno della stessa struttura (come una società di consulenza); i risultati finali possono variare da progetto a progetto. Le descrizioni sottostanti sono generalizzazioni, ma un buon punto di partenza se hai difficoltà a cercare di capire quale tipo di output potrebbe essere necessario.
I deliverable sono spesso di maggiore fedeltà in questo ambiente, dal momento che l'obiettivo non è solo quello di far progredire il progetto, ma anche di educare il cliente e assicurarsi che siano "impressionati" dal deliverable. In effetti, è rassicurante per il cliente che ha fatto la scelta giusta con te su un concorrente.
Ciò è fondamentale nella fase di gara in cui un certo numero di società di consulenza competono per lo stesso lavoro. Tuttavia, tieni presente che ci sono molte altre cose che i clienti hanno in mente quando fanno la loro selezione; come competenza tecnologica, risorse ecc.
I deliverable in un "hackathon" sono concepiti con lo scopo di presentare ad una giuria. Potrebbe esserci un mazzo di diapositive e potresti presentare alcuni storyboard, roadmap di prodotti ... Qualsiasi cosa che possa suscitare emozione, comunicare un problema e risolvere il problema e dimostrare una chiara visione dei passi avanti! Questa non è probabilmente l'occasione per un prototipo completamente sviluppato, a meno che tu non abbia membri del tuo team con quella capacità.
Nella mia esperienza, i concerti freelance (specialmente quelli eseguiti online) sono spesso di portata molto ridotta. Spesso è necessario "Wireframe per l'app X" o "Rapporto sull'usabilità per il sito Web X". Questi risultati sono utilizzati principalmente per indicare il completamento piuttosto che il progresso e sono spesso legati a pagamenti milestone.
L'avvio dei deliverable si concentra principalmente sulla scoperta, la convalida e la definizione, poiché l'imprenditore sta cercando di rompere il mercato. Anche il design è importante e i deliverable all'interno della fase di perfezionamento del progetto ruotano attorno all'idea di rotazione e all'apporto di modifiche da parte degli utenti e dei primi stakeholder..
Per "team di prodotto" mi riferisco a un'azienda che ha uno o più prodotti digitali e personale interno. Questi team generalmente utilizzano i deliverable in un processo end-to-end. Possono avere una fedeltà inferiore, tranne quando il product manager deve comunicare e impacchettare le informazioni per i dirigenti. Ogni deliverable tende ad allinearsi più a diverse fasi del processo UX.
I deliverable possono anche cadere in un numero di fasi all'interno del processo di UX Design:
Tipi di deliverable durante il processo di progettazione UXCome puoi vedere, in una fase iniziale del processo ci sono più risultati finali dal momento che il progetto inizia ampiamente e c'è più lavoro speso a pianificare e cercare di identificare la cosa giusta su cui lavorare. Questo modello è probabilmente più applicabile ai team di prodotto e c'è un sacco di crossover nel ruolo durante le prime due fasi. Ad esempio, i progettisti di UX, i responsabili di prodotto e gli analisti aziendali possono collaborare alle mappe di viaggio dei clienti.
Perché creiamo risultati, come elencato sopra, è contestuale. I motivi si basano su ruolo, tipo di organizzazione, pubblico e molti altri fattori. Ecco cinque dei motivi più comuni per la creazione di risultati finali:
Il mio approccio personale è quello di mantenere i deliverable comuni al centro del mio processo; come personaggi, prototipi e interviste agli utenti. Tengo i risultati meno comuni sulla periferia; come focus group e modelli di dominio.
Mi piace anche esplorare i risultati che potrei non aver sentito prima. Ci sono così tanti metodi diversi là fuori. Può davvero darti una prospettiva più ampia e renderti un designer migliore per aggiungere alcuni nuovi risultati al tuo flusso di lavoro.
Bene, questo copre i risultati finali! Ecco alcuni dettagli da portare via:
Accentsconagua