Design collaborativo: una guida alla progettazione di prodotti aziendali di successo

Probabilmente hai sentito parlare di sviluppo software Agile, gestione dei processi Kanban e Lean UX. Il design collaborativo è un approccio filosofico e tattico diverso alla progettazione di prodotti aziendali .

Il design collaborativo è il processo di progettazione in un ambiente partecipativo, coinvolgente e realistico a tutte le mani o in un ambiente di fiducia del cervello. NON sta progettando nel vuoto; invece, come suggerisce il nome, la progettazione collaborativa mette il designer al centro dei vari team e dipartimenti per lavorare con tutti al fine di costruire un prodotto coeso. In questo modo nessuno viene escluso e il prodotto può essere costruito con tutti gli stakeholder coinvolti.

Ogni organizzazione aziendale è diversa e riunire le parti interessate attorno a qualsiasi idea o attività può sembrare come un gregge. In questa guida esamineremo suggerimenti e trucchi per lavorare con i principali attori, non solo per ottenere il loro contributo, ma anche per coinvolgerli in questo nuovo approccio incentrato sul design.

Incontra i giocatori

I designer sono bravi in ​​molte cose, ma il loro ruolo inizia con la risoluzione dei problemi. Ciò richiede sapere chi sono gli esperti e lavorare con loro. Ogni membro del team di sviluppo prodotto ha le proprie esigenze e responsabilità, quindi conoscerli è fondamentale quanto completare effettivamente l'incarico assegnato.

Quindi, senza ulteriori indugi, incontriamo il team:

• I product manager definiscono l'ambito, i requisiti e i cicli di iterazione di sviluppo per prodotti e funzionalità; sono spesso i guardiani delle funzionalità prima di un sì/no finale e sono esperti nel comunicare con l'intera organizzazione, compresi i dirigenti.
• Gli ingegneri costruiscono il prodotto in modo da comprendere le capacità e i limiti tecnici. Ciò li rende una risorsa fondamentale per determinare le principali preoccupazioni, tra cui le tempistiche di sviluppo, le tecnologie da utilizzare, l'ambito e spesso la fattibilità del design (se i nostri concetti sono possibili date la tecnologia e i limiti di tempo).
• Gli architetti di database e di sistema sanno come i dati vengono integrati e hanno una profonda comprensione di ciò che è necessario per mantenere le prestazioni, continuando a costruire sul prodotto/piattaforma esistente.
• Gli esperti interni in materia (PMI) hanno una profonda familiarità con i processi aziendali, i casi d'uso, la storia e la politica, nonché le aspettative generali del management, dei clienti e degli utenti.
• Le vendite si concentrano sulla presentazione del prodotto ai potenziali clienti. Questo rende le vendite il primo punto di contatto, quindi la loro comprensione del prodotto è fondamentale per chiudere (e spesso creare) lead.
• I formatori (o in SaaS, gli agenti di successo dei clienti ) hanno un'esposizione diretta al team di vendita e agli utenti nuovi o di prova e possono fornire volumi di informazioni utili sulle prestazioni del prodotto in vitro e oltre.

Quando tutte le parti che lavorano sul prodotto sono coinvolte nel processo di progettazione (uno dei principi fondamentali della metodologia Agile), il prodotto risultante ha una possibilità significativamente maggiore di raggiungere il successo, non perché i designer stiano lavorando con le parti interessate, ma perché le parti interessate, più spesso che no, capire le esigenze specifiche di utenti e aziende in un modo che potremmo non fare. Lavorare in modo collaborativo sembra sempre l'opzione migliore, ma come lo facciamo?

Come collaborare con gli stakeholder

Product Manager, Portale del Prodotto e Cronometristi

I product manager hanno spesso un attaccamento personale al prodotto e sono tenuti ad aspettative molto elevate all'interno dell'azienda. Devono anche rispondere agli utenti o ai clienti dei loro prodotti in caso di problemi, promesse non mantenute o richieste di una nuova funzionalità.

Apprezzano molto la comunicazione semplice e devono essere tenuti aggiornati su progressi, problemi ed eventuali modifiche. A loro piace vedere le bozze prima e frequentemente e, poiché possono funzionare su varie scale (a diversi livelli, dallo sviluppo diretto del prodotto all'esperienza pratica con modifiche anche minori), le tue interazioni con loro possono variare notevolmente.

Poiché i PM trascorrono così tanto tempo a comunicare con i vari stakeholder (interni ed esterni), è importante tenerli informati senza aspettarsi che controllino con te. Imposta check-in regolari con i tuoi PM per presentare bozze iterative, ascoltare il loro feedback e terminare sempre con un elenco di azioni per la riunione successiva.

Non ci vorrà molto per imparare quali sono i loro obiettivi per la funzionalità del prodotto. I PM sanno che i progettisti sono risolutori di problemi, quindi i progettisti devono fornire dati e analisi per dimostrare il loro ragionamento. Che tu abbia ragione o no non importa. Dimostra che costruire il miglior prodotto è l'obiettivo e guadagnerai la fiducia di un PM!

Ingegneria: responsabile della realizzazione dei progetti

Gli ingegneri (detti anche sviluppatori) sono le persone più vicine al prodotto; lo costruiscono! Questo dà loro un vantaggio perché possono sperimentare e testare direttamente i singoli componenti del prodotto in azione . Questo è fantastico perché, senza dubbio, troveranno i punti deboli in qualsiasi progetto, a volte prima di creare qualsiasi cosa, il che è doppiamente eccezionale perché è un enorme vantaggio su così tanti livelli trovare i difetti prima che il software sia codificato.

Il modo migliore per guadagnarsi la fiducia di un gruppo di ingegneri è produrre specifiche di prodotto complete e complete o coinvolgerli all'inizio... o entrambi.

Quando gli sviluppatori sono considerati veri stakeholder , sono più che disposti a discutere di casi d'uso, scenari, sfide tecniche e le opzioni per superarli.

È facile dimenticare che gli ingegneri sono veri architetti del prodotto; hanno un interesse acquisito nel risolvere i problemi con il progettista, soprattutto quando la sfida è difficile o potrebbe essere gestita in altro modo.

Database e System Architect, Guardiani delle Strutture Dati

Gli architetti di database e di sistema sanno come funziona il prodotto dietro le quinte. Sanno tutto su come i dati vengono archiviati e strutturati, cosa può essere integrato e come tutti i sistemi parlano tra loro. Tendono a essere meno interessati al modo in cui il prodotto funziona per gli utenti rispetto a come interagisce con i vari sistemi (che è ciò di cui sono in definitiva responsabili).

Possono essere particolarmente difficili da gestire per i progettisti incentrati sull'utente. È importante ricordare che anche se un architetto di database/sistema non interagisce mai con gli utenti finali, il suo obiettivo è sempre quello di avvantaggiarli, sia attraverso l'affidabilità, la velocità o la semplicità del prodotto.

La loro conoscenza del funzionamento delle strutture dati e delle ramificazioni di eventuali modifiche alla funzionalità del prodotto sono troppo facili da perdere senza il loro contributo di esperti. È importante invitare e coinvolgere architetti di sistema in riunioni e discussioni sulle modifiche ai prodotti, anche se la loro posizione non sembra direttamente correlata.

Un modo per collaborare con un architetto di sistema è creare un elenco di controllo con le seguenti domande:

• La caratteristica X influisce sulla struttura dei dati corrente?
• Ci sono ulteriori lavori di progettazione/sviluppo considerando l'architettura attuale?
• Il design Y è in conflitto con qualsiasi input/output utente esistente?
• Ci sono servizi esterni interessati dalla funzione X?

Questo semplice elenco ti indicherà la giusta direzione, anche senza una chiara comprensione di come funzionano le strutture dati monolitiche preesistenti (e possibilmente). Qualsiasi cosa spuntata è un'area che dovrebbe essere indagata con una semplice discussione.

Esperti in materia e analisti aziendali, i maghi dell'informazione

Gli esperti in materia sono nominati in modo appropriato; sono esperti in materia e possono essere una miniera d'oro di informazioni uniche e preziose. Spesso hanno conseguito lauree specialistiche nel settore o hanno trascorso la maggior parte della loro vita lavorando nel loro settore. Hanno un'esperienza pratica su come dovrebbe funzionare l'azienda e ricordano la lunga e dolorosa storia e la politica che hanno portato tutti dove sono oggi.

Un analista aziendale conosce i dettagli di come opera l'organizzazione e spesso svolge la stessa funzione di una PMI se i dati sono disponibili ma non c'è un esperto interno.

Impegnarsi con le PMI per apprendere come il progetto viene percepito dal management per assicurarsi che le aspettative interne siano soddisfatte e che non si stia percorrendo un territorio pericoloso. Invita gli analisti alle sessioni di progettazione, dicendo loro in anticipo che sono gli esperti e chiedendo loro di condividere la loro conoscenza di fallimenti storici, conflitti politici e altre questioni che possono essere fondamentali per il successo del rilascio del prodotto.

Customer Success Manager, il punto di contatto di un nuovo cliente

Quando i nuovi clienti vengono finalmente integrati dalle vendite, i formatori (o, per le aziende SaaS, i Customer Success Manager (CSM)) subentrano per insegnare ai nuovi utenti come utilizzare effettivamente il prodotto. Quindi è ovvio che i formatori trascorrono molto tempo a parlare con utenti inesperti. Un CSM ha una prospettiva unica perché interagisce con i clienti che spesso non sono stati coinvolti nella decisione di acquisto per la propria azienda.

Con questa prospettiva unica, i formatori/CSM possono fornire informazioni preziose per le decisioni di progettazione, sia per l'onboarding dei clienti che per il comportamento dei nuovi utenti. Molte organizzazioni aziendali tengono traccia e monitorano il modo in cui i loro nuovi clienti utilizzano vari prodotti e registrano qualsiasi cosa, dalle chiamate ai reclami, ma i formatori hanno un'idea di ciò con cui i clienti lottano davvero.

Includere un formatore senior in tutte le principali riunioni di progettazione e informarsi su eventuali decisioni con lui. Poni domande come "Quali sono i primi tre reclami più gravi dei clienti?" e "I nuovi clienti sono in media soddisfatti del prodotto?" e "Quali cambiamenti ritieni forniranno il maggiore impatto positivo per te e il tuo team?" In questo modo, impariamo tutti qual è il sentiero felice; le scarpe da ginnastica sono i nostri occhi e le nostre orecchie per tutti i modi in cui i clienti utilizzano effettivamente il prodotto.

Sales, il primo contatto del prodotto con i clienti

Le vendite e il design sono spesso in contrasto. Alcune organizzazioni sono orientate alle vendite mentre altre no, ma in ogni caso, c'è una chiara differenza negli obiettivi: il team di vendita vuole aumentare le vendite mentre il design vuole migliorare l'esperienza dell'utente. Non sempre si allineano.

Non deve essere così. La maggior parte dei venditori ha lamentele molto ragionevoli con cui confrontarsi: hanno poco o nessun controllo sulle decisioni sui prodotti, gli viene chiesto di assumere impegni che non possono davvero promettere e sono spinti a raggiungere obiettivi di fatturato specifici nonostante tutto. Non sorprende che i team di vendita e di prodotto abbiano regolarmente accese discussioni!

Tuttavia, come i formatori, l'organizzazione di vendita ha una prospettiva unica sulle esigenze dei clienti e, spesso, quella prospettiva è la differenza tra fare una piccola vendita e portare una balena! Comprendi le diverse aree con cui il team di vendita deve lottare. Prova a partecipare a ogni tipo di chiamata e scopri come comunicano quei potenziali clienti.

Questo aprirà la conversazione con le vendite. Non si tratta solo di far sentire i loro bisogni; si tratta di migliorare l'esperienza per i potenziali utenti in ogni fase, dalla prima comunicazione a dopo l'onboarding. Scopri cosa sentono di più i venditori dai potenziali clienti, quali sfide incontrano quando finalizzano l'affare e quali sono le preoccupazioni maggiori dopo che è stato concluso.

Il design in azienda non deve essere un incubo

Come designer, tutte queste parti mobili possono essere molto difficili da gestire, soprattutto quando non sei considerato un "manager" nel senso ufficiale del termine. In qualità di stakeholder chiave nella comunicazione tra team, nella raccolta dei requisiti e nel feedback sulla progettazione, dovresti avere accesso a tutti questi professionisti a un certo livello.

Il modo più critico, ma anche più semplice, per farlo è ascoltare tutte le parti e prendere sul serio il loro feedback. Nella maggior parte delle organizzazioni, il passo successivo è raccogliere quel feedback e collaborare con il product manager per organizzare i requisiti in un lavoro attuabile.

Da lì, dipende dalle priorità e dal colmare le lacune. In definitiva, l'obiettivo è progettare il miglior prodotto e abbiamo bisogno dell'aiuto di tutto lo staff di sviluppo prodotto. Riconoscere che ogni ruolo è importante e rendere il personale consapevole del proprio valore nel ciclo di sviluppo del prodotto li apre alla possibilità di fornire le informazioni di cui un designer ha bisogno per prendere migliori decisioni di progettazione del prodotto.

• • •

Ulteriori letture sul blog di Toptal Design:

• Procedure consigliate per la progettazione dell'interfaccia utente ed errori comuni
• Stati vuoti: l'aspetto più trascurato dell'esperienza utente
• La semplicità è la chiave: esplorare il design Web minimale
• Principi euristici per interfacce mobili
• Progettare per la leggibilità - Una guida alla tipografia Web