Digital Product Design
Cosa significa digital product design
Digital Product Design significa capire cosa deve fare un prodotto digitale, come deve funzionare per chi lo usa e farlo evolvere mentre prende forma.
Partiamo dal problema, dalle persone che lo incontrano e dal risultato che vogliamo ottenere. Mettiamo a fuoco funzionalità, flussi, priorità e interfacce, poi cerchiamo di arrivare il prima possibile a qualcosa che si possa usare davvero.
È la parte del lavoro che decide cosa costruire. Come poi il sistema viene costruito e fatto funzionare è un altro mestiere: lo sviluppo software su misura.
Un prodotto è molto più facile da capire quando smette di essere un'idea e comincia a funzionare.
Progettiamo anche costruendo
Wireframe e mockup servono, e li facciamo. La prototipazione è utile proprio perché costa poco sbagliare. Quello che non facciamo è aspettare di aver disegnato tutto prima di cominciare a costruire.
Iteriamo quasi da subito sul software reale: il cliente lo usa, lo mette alla prova, e l'idea cambia mentre prende forma. Alcune cose che sembravano indispensabili su uno schermo statico si rivelano inutili appena qualcuno prova a usarle, e viceversa. Su progetti circoscritti questo modo di lavorare può diventare l'ossatura di tutto il progetto: è l'approccio BitBoss AI.
Costruire non arriva dopo il design. In parte, è uno degli strumenti con cui progettiamo.
Su cosa lavoriamo
Cinque dimensioni del prodotto, non un elenco di professionalità interne. Dentro ci sono UX design, interaction design e UI design, ma il lavoro si organizza per problemi, non per discipline.
Un prodotto esiste per ottenere un risultato
Un prodotto digitale non si giudica da quanto è bello o da quante funzioni ha, ma da cosa permette di ottenere: vendere un servizio, ridurre lavoro manuale, permettere a un team di lavorare meglio, raccogliere dati più utili, migliorare un processo o creare qualcosa che prima non esisteva.
Sapere quale di questi risultati conta davvero è quello che permette di decidere: senza, ogni funzionalità sembra ugualmente importante.
Più possibilità, meno affezione alle prime idee
Un'ipotesi può diventare qualcosa di visibile e utilizzabile molto prima di quanto succedesse qualche anno fa. Si possono costruire varianti, provarle e scartarle. Cambiare un flusso costa meno.
Il design non diventa meno importante: succede il contrario. Quando esplorare costa poco, la differenza la fa saper guardare i risultati e decidere, invece di difendere la prima idea solo perché è costata fatica.
Semplificare non significa togliere complessità
Molti software gestiscono processi complessi, e il design non deve fingere che quella complessità non esista. Deve decidere quale parte mostrare, a chi, in quale momento e in quale forma.
Dietro un'interfaccia semplice possono esserci regole, stati, eccezioni e permessi articolati. Semplificare significa tenerli sotto controllo, non scaricarli sull'utente sotto forma di venti campi da compilare.
Quando l'interfaccia non è più soltanto fatta di schermate
Non tutto deve passare da menu, form e pulsanti. Chi usa il prodotto può scrivere, parlare, allegare un documento o chiedere direttamente un risultato.
Togliere struttura dall'interfaccia non significa togliere struttura al prodotto. Anzi: bisogna progettare con più attenzione cosa può succedere, cosa va confermato prima di essere eseguito, quali azioni sono permesse a chi, e come rendere comprensibile ciò che il sistema ha appena fatto.
Come tutto questo regga davvero, tra dati, permessi e tracciabilità, è un tema di sviluppo software su misura, non di design.
Dove può arrivare il lavoro
La progettazione di un prodotto digitale può partire da un'idea, da un processo che esiste già, da un software da ripensare o da una prima versione già costruita.
E può arrivare a una direzione di prodotto più chiara, a una nuova esperienza, a un prototipo, a una prima versione funzionante o a un prodotto che continua a evolvere insieme allo sviluppo.
Digital Product Design e sviluppo non hanno un confine netto: quando costruire ci aiuta a prendere una decisione migliore, costruiamo.
Se il problema è un altro
Non tutti i problemi che ci vengono portati sono problemi di prodotto.
Tecnologia e organizzazione
Se la domanda riguarda soprattutto architettura, team, fornitori o governance, è un lavoro di consulenza software.
Il prodotto
Se riguarda cosa deve fare il prodotto, come deve funzionare, cosa deve vedere chi lo usa e con quali priorità, siamo nel posto giusto.
Il sistema
Quando il lavoro entra in backend, dati, integrazioni, infrastruttura, sicurezza e mantenimento, si parla di sviluppo software su misura.