Bene e benvenuti su Geekbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Mi è appena morto il computer, 5 minuti prima della registrazione di oggi il mio Mac ha tirato l'ultimo sospiro/respiro come si suol dire e quindi ha smesso completamente di funzionare.Sto registrando con un computer di fortuna, spero regga tutto, spero non ci siano problemi ma diciamo va bene così.Detto questo vi ricordo rapidamente i nostri contatti info@gitbar.it e @brainrepo su twitter sono i modi canonici per contattarci ma abbiamo anche il nostro bello caldo e confortevole gruppo telegram un bar vero e proprio dove ci incontriamo ogni settimane chiacchieriamo del più e del meno con interessantissime persone.Se non l'avete ancora fatto mi raccomando iscrivetevi! Potete farlo direttamente dal vostro client telegram semplicemente scrivendo "gitbar" e tutto magicamente apparirà.Però io sto già parlando troppo e voglio lasciare spazio spazio ai miei ospiti di oggi.I miei ospiti di oggi sono due, una vecchia amicizia di Geek/ è una new entry che ci fa super piacere conoscerlo, conoscere, sto già iniziando a perdere colpi, vabbè fate finta di niente, e allora direi che possiamo iniziare.Benvenuti su Gitbar, il podcast dedicato al mondo dei full stack developer, i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare nel modo più efficiente possibile quei prodotti digitali che quotidianamente usiamo.[Musica] Oggi abbiamo con noi, come vi dicevo, una vecchia amicizia di Gitbar, è un front-end developer.Per una nota, ditta spedizioniera internazionale, abbiamo con noi Davide Di Pumpo.Ciao Davide! Ciao a tutti, è un piacere essere di nuovo qui per la terza volta.Eh sì, tu ormai hai la residenza nel nostro circolo e questo ci fa super piacere.Hai portato con te un amico, giusto? Sì sì, però che si presenti da soli come nelle migliori associazioni di alcolisti anonimi.Ciao a tutti mi chiamo Puero Romero e sono un designer, io ho provato a fare lo sviluppatore quando ero piccolo poi mi sono accorto che non ero capace e quindi ho detto faccio il designer.Come avete ben intuito abbiamo un designer, abbiamo un front end developer e abbiamo uno che parla vanvera che sarei io, quindi la puntata di oggi già si presenta con le sue nature frizzanti.Oggi proviamo insieme a voi a cercare di rappresentare un'immagine che in qualche modo vuole fermare quello che è il passaggio tra un design alla realizzazione vera e propria.La prima cosa che voglio analizzare con voi ragazzi è la parte di design dell'interfaccia grafica.Vi faccio una domanda perché sono super curioso.Come nasce un'interfaccia grafica? In realtà, quello che vi starò per dire è che casualmente capita anche con il fatto che sto cambiando, non dico mestiere, ma sto cambiando leggermente posizione rispetto a quello che oggi faccio.Io sono partito disegnando interfacce, quindi di fatto muovendo pixel, creando componenti.Oggi il ragionamento da cui partivo dieci anni fa è cambiato totalmente, proprio è un'altra cosa rispetto a quello che succede oggi.Se una volta c'era più l'idea di utilizzare l'interfaccia grafica, con l'idea di comunicare qualcosa, di supportare un brand, di arrivare a creare un prodotto digitale che potesse piacere alle persone e piacere soprattutto alle persone per cui stavi lavorando nel crearla.Oggi questa cosa per me è cambiata, da ormai più di cinque anni le interfacce che faccio sono molto data driven, quindi partono da un'assunzione che viene fatta dal business rispetto a quello che deve rispondere con l'interfaccia e poi si cerca di costruire un percorso che possa rispondere alle esigenze delle persone con cui stiamo rispondendo attraverso l'interfaccia e poi chiaramente rispondendo anche al business a livello di esigenza di quanti soldi dobbiamo fare con quel prodotto che creiamo.Quindi oggi come parte l'interfaccia per me parte da un bisogno, da un problema da risolvere e dal fatto di accontentare quelle che sono le esigenze del business per riuscire a creare quel prodotto nel migliore dei modi, in modo che sia sostenibile economicamente, ma che possa anche crescere nel tempo perché gli utenti effettivamente lo utilizzano, perché ci vedono un'utilità.Ti direi questo.Si parte da lì.Si, concordo abbastanza.Volevo sottolineare, perché mi è molto piaciuto come Paul aveva detto che inizialmente "disegniamo interfacce", il termine "disegnare" che è il peggior false cliente che purtroppo esiste al mondo non vuol dire fare design, ma appunto quello che è quello che purtroppo ancora oggi succede per la maggior parte delle volte.Si disegna un'interfaccia, ovvero a differenza di quasi tutti gli altri lavori ingegneristici, si prende una sedia e le si fa il disegno, questo è quello che succede nel design di interfacce ancora oggi.Infatti, non per niente alcuni dei siti più visitati dai designer sono i bari a Milo, quando ero giovane io.Dribble, i bari Bianz, cose di questo genere qua, perché sono la fonte di ispirazione.Invece concordo con Paul, io ho fatto pivoti carriera parecchie volte, anche se poi alla fine faccio sempre lo stesso mestiere e il mercato torna a mettere che cambia più che quello che cambio io.La quarta ricopertina di questo libro citava il famoso detto "Content is king, presentation is queen".Era uno dei primi libri che avevo ho letto nella mia vita, una decina di anni fa, sul content-driven design.Prima, in uno dei primi libri, avevo letto una decina di anni fa, che parlava di fare le information map del flow della navigazione dell'utente, di user journey, di farle con i posti, eccetera.e poi da lì andare a definire come sarebbe un'interfaccia, che secondo me è il metodo sano.Prima vedi il contenuto, quello che vuoi.Un esempio stupidissimo è come lo fai un menu? Adesso ho detto menu, in testa vostra è sicuramente almeno balenato qualcosa in ma un conto è il menu di Tinder, un conto è quello di Amazon e quindi a seconda del contenuto dove vai, di quante opzioni hai, il design, ma anche l'interfaccia può cambiare.Davide hai tirato fuori un punto, hai evidenziato un punto che mi stimola una domanda.Noi abbiamo parlato di progettazione, no? Progettazione è quindi un'analisi molto più profonda che è giusto prendere la matita o il mouse o la tavoletta grafica e disegnare l'interfaccia.A questo punto mi chiedo, una parte delle interfacce che noi vediamo tutti i giorni seguono una serie di pattern.Quanto il risultato delle interfacce moderne è figlio dell'applicazione di pattern e quanto è figlio di vera ricerca? Quando dico applicazione di pattern parlo di applicazione cieca, mi viene in inglese, no blind.Io dopo do uno spunto, visto che Paul sta facendo pipo, verso il prodotto tutto tondo.Potremmo parlare magari di Ice Core, che è molto importante per me.Ne parliamo dopo.Ma quello che volevo dire è quanto viene da fatta rivisti? Secondo me la maggior parte di quello che vediamo è replica di qualcosa che funziona.È davvero difficile.Una delle cose che per dirti ti dico, basta andare su LinkedIn, cerca UX Designer, che è anche un titolo ormai vecchiotto, quindi non è che sia una roba moderna.Cerca invece UX/UI Designer.vedrai che troverai parecchie più… è più probabile che tu trovi più hit per questo tipo di ricerca.Perché? Perché spesso e volentieri la parte di ricerca è quella che nel momento in cui si fa UX è quella che viene lasciata più da parte.In parte posso anche essere d'accordo, nel senso che nel mondo moderno prima vai su con un prodotto, meglio puoi vedere se c'è un market per te, meglio puoi andare a Facebook, come diceva "move fast, break things".Vai veloce, quindi vedi una roba già che funziona, prendi e replichi.Ci sono interi business basati su questo.Prendi qualcosa che va, lo replichi, anche se sembri la versione QCIP, ci sono altre cose che faranno funzionare bene la tua cosa.Non è un caso che, in mia opinione, interfacce dei siti diventano sempre più brutte man mano che si va avanti.Per queste due ragioni qua.La prima è che spesso e volentieri diamo più peso al contenuto, perché abbiamo due tipi di approcci praticamente assolutisti quasi.Chi pensa solamente al contenuto, alla ricerca eccetera e tira fuori delle UI che funzionano ma che non sono pleasant, per citare ancora Amazon o un di Amazon non è bellissima, eppure funziona.Oppure, delle cose totalmente campate per aria, che cercano semplicemente di farsi vedere.Per esempio, il nuovo sito di Squarespace, che hanno fatto per pubblicizzarsi con, non mi ricordo il nome dell'attore, quello famoso che ha fatto lo Star Wars nuovo, però lui, che tu guardi il sito, l'interfaccia è super extravagante, ma nemmeno capisci cosa vende il sito.Tutta la gente che l'ho vista mi ha chiesto "Cosa vende?" e quasi nessuno mi ha saputo rispondere.Sai, tutti quei bei siti con le interfacce 3D, le facce giganti, pura ricerca.Quindi abbiamo questi due poli opposti.Secondo me, ad oggi, però, buona parte dei siti che guardiamo sono "t-spill" e "competitor", Cosa che non sempre Duo può fare, come si può vedere in alcune metodologie come le metodologie AIS, ma lascio parlare Polla anche su questo argomento.Polla D'Alessandro "Sono d'accordo con quello che dice Davide, forse oggi la difficoltà principale è che bisogna fare tantissima distinzione dove si sta facendo design.Fai design all'interno di una start-up, fai design all'interno di una multinazionale, quindi sei all'interno di un team di consulenza, sei dentro un'agenzia.A seconda di quelle tipologie di luoghi nei quali tu stai facendo design, hai una cultura che ti viene data dal luogo.Se sei in un'agenzia devi chiudere il progetto velocemente, quindi spendere le minore possibili per creare la cosa che rende più contento il cliente e non l'utente finale.Per quale motivo? Perché l'agenzia prende il progetto, lo finisce ad un certo punto e dà tutto in mano al cliente e il cliente poi se lo tiene e si rivolve da solo.E quindi diciamo che c'è proprio una consegna di chiavi in mano di un prodotto e quindi io non vengo pagato per quello che succederà dopo, neanche come agenzia, né come designer e come sviluppatore, men che meno.è proprio una cosa del fatto di dire "io mi fermo dove ti consegno l'output" e l'output nella maggior parte delle volte è basato sull'esperienza interna di chi lo sta creando, perché magari viene contattato proprio perché ha visto un altro lavoro e dice "mi è piaciuto molto il lavoro che hai fatto per Y, quindi rifai il lavoro per Y per me" e quindi tu cerchi comunque di riprendere quel lavoro e di replicarlo e poterlo dare a un altro cliente, però questo è un modo che salvaguarda l'agenzia, quindi il business dell'agenzia, ma non risolve un problema di fondo.Risolve il problema che l'agenzia in questo modo riesce a campare e a dare un qualcosa che possa accontentare il cliente, ma di fatto non ragioni su quello che l'utente finale è e quindi nel reale caso, nel momento in cui l'utente lo sta davvero utilizzando.Invece in quel caso lì, e quello è la maggior parte estetica pura, Dribbble, BNs, vedere quello che torna di più esteticamente al cliente finale, però al cliente finale inteso come cliente con il quale si interfaccia l'agenzia.E poi hai tutta la parte invece legata al prodotto vero e proprio, dove c'è molto più ragionamento, ci sono molti più interessi da parte dell'azienda nello spostare magari un pixel a destra e a sinistra perché sai benissimo che può farti fare x 1000 euro oppure può non farti fare x 1000 euro ed è una cosa che vedi nel momento quindi il designer prende una scelta, fa quella scelta basata su una serie di dati quindi hai una decisione che vai a prendere coscientemente e analizzi cosa succede dopo che hai preso quella decisione attraverso di analytics, attraverso di testing, attraverso una serie di esercizi che puoi fare.Perciò ci sono queste due progettazioni differenti, come diceva appunto Davide, che si devono per forza staccare.Una è una progettazione estetica puramente basata sulle mie ipotesi, che è quello che penso sia corretto per la persona, per il cliente, e quello che invece faccio, iterativamente parlando, seguendo un processo più ingegneristico e che non va a vedere solamente l'estetica di quello che produco, che tiene conto di una serie di metriche, una serie di dati che devo guardare per dire ok il mio design sta funzionando e riesce a convertire oppure no non sta funzionando e se non sta funzionando per quale motivo non sta funzionando.Per cui se ho compreso bene la prima cosa da fare per la realizzazione di un prodotto che segue questo filone è quello di analizzare il mercato, analizzare l'utente, fare delle e partendo da quello iniziare a progettare quelle che sono le interfacce e gli user, tenendo davanti i vari use case e tutti gli user flow, ho compreso bene giusto? In parte sì, secondo me.Cioè è quello che stai raccontando, è come dire, cioè tu nei libri di scuola hai una serie di istruzioni per riuscire a comporre una serie di step che devi fare.È chiaro che nel momento in cui tu arrivi ad un certo punto della tua carriera non ragioni più solamente in quei sistemi, ma ti sposti da una parte all'altra.Quindi magari dopo che per X anni hai fatto C, D eccetera, oggi magari tendi con una certa seniority a cambiare questo modo di ragionare.Però generalmente sì, quello che mi sono dato conto io negli ultimi anni è che ho parlato con molte più persone all'estero, designer che sono anche founder di piccole realtà e in realtà molti non fanno neanche wireframing, molti non fanno user flow, molti non fanno certe cose che dovrebbero essere fatte da manuale, ma che spesso per il caso d'uso, per una serie di motivazioni, non sono necessarie come prima cosa da fare all'interno di un'azienda.Quindi dirti sì, quello è quello che si dovrebbe fare solitamente, è già una best practice fare quello, ovvero seguire una serie di step che ti porti a non andare sulle tue ipotesi, ma andare sulla ricerca e nel fare una serie di output.Però dall'altra parte bisogna anche dire che non è che se fai quello allora la tua interfaccia avrà successo.Cioè dire che un'interfaccia ha successo è come dire che un cittadino commerciale riesce a fare soldi solo perché c'è un buon negozio all'interno, solo perché c'è una buona estetica all'interno.Quindi è molto più grande il discorso, ci sono tutto il termine di accessibilità, di copywriting, contenuto, quindi un'interfaccia perché funzioni serve che tante cose funzionino.Ed è quella assolutamente la cosa che molto spesso si sbaglia con il design, che si dà molto peso magari a volte a quello che può fare un'interfaccia estetica, ma non a tutto il contorno che c'è.Davide vuoi aggiungere qualcosa? Un esempio gigante che si può fare sulla questione seniority o su "faccio cose, non faccio cose".Io mi diretto anche di disegno di fumetti e cose del genere.Se voi vedete un fumettista disegnare un fumetto, un volto, probabilmente lo farà senza le linee guida.Quando vi fanno fare l'uovo, le due linee per dividere in quattro quadranti la faccia per decidere dove posizionare il naso, gli occhi, le orecchie, la bocca, eccetera.Solitamente alcuni disegnatori lo fanno per tutta la vita.C'è chi è diventato ormai un maestro e praticamente quella roba lì la sa a memoria e non lo fa più.Non si mette lì a rifare le guide.Sbaglia? No.Però è qualcuno che ormai ha tanto pelo sullo stomaco.Io spesso e volentieri, solo questione personas, io inizio a detestarle alle personas, così come detesto i bottoni.Perché essendo alcune delle prime cose che si fa quando si pensa ad un'interfaccia, solitamente ci si spende tantissimo tempo, tantissimo e poi non ti rimane tempo per le cose più importanti.Il classico "tu ti fai il tuo bel tempo, poi vedi che per fare qualcosa all'inizio vai lì, la persona per descriverla vuole proprio coprire tutti gli use case, etc., etc., avere inclusività, etc.Hai messo quattro settimane a scrivere le tue persona e rimango con due settimane a non si deve mai farci.Non lo so, quindi sì, concordo con quello che ha detto Paul.È normalissimo, è difficile dirti che ci sia un vero modus operandi, anche perché visto che è un podcast di sviluppatori, è come l'eterna lotta delle volte tra "è meglio fare TDD, BDD", fare tutto, testi tutto, quanta coverage vuoi e cose di questo genere qua.Dipende, dipende.Ovvio che a tempo, risorse e soldi infiniti cerchi di fare tutto il flusso, ma in realtà non succede.Sì, mentre parlavi mi viene in mente, a parte che io sono sempre per code coverage il più possibile, grazie, ma questo perché anche oggi stavo smadonnando per colpa di questa cosa.Ma a parte questo mi avete riportato in mente il discorso che c'era su Reddit qualche giorno fa su Scrum, il famoso "Scrum è una merda perché il poker è un gioco e non uno strumento".Alla fine è facile dire che il tool è una merda se tu lo applichi perisequamente anche quando non ti serve.L'esperienza ti aiuta a dire "ok, devo spingere più su questo che su quest'altro.Mi basta fare cinque test di integrazione, visto che stiamo parlando a sviluppatori, che fare una coverage 100% di unit test.Quindi sì, però in quel caso se prendi questo tipo di decisione lo fai sulla base di una consapevolezza che è maturata nel tempo, di una seniority come diceva Paul, che ti ci permette anche di dire "no, posso rinunciarci perché il trade-off me lo permette".Uno però degli strumenti veri che io ho riconosciuto nell'analisi delle personas, che per chi non lo sapesse, lo so lo dirò con la zappa come sempre, è una rappresentazione più o meno dettagliata di quelli che sono i nostri potenziali utenti, quindi cerchiamo di dare un' volta ai nostri utenti, o dello user flow, dello user journey all'interno della nostra applicazione.Questi strumenti secondo me molte volte ci aiutano nel momento del dialogo col nostro interlocutore, che è colui che commissiona il nostro lavoro.L'interlocutore spesso portato ad apprezzarne la qualità estetica perché è la prima cosa che salta all'occhio, ma come dicevate prima la qualità estetica spesso inganna e spesso rischia di non essere funzionale con quello che è veramente l'uso, l'utilità, il significato profondo del prodotto digitale che stiamo realizzando.A quel punto penso che questo tipo di strumenti possano in qualche modo supportare la spiegazione, supportare la comunicazione col nostro interlocutore per far capire quanta profondità hanno alcune scelte di design.Mi sbaglio? Paul sei muto.Allora ti direi, per me è in parte corretto quello che hai detto, non so quanto può essere, cioè è che dipende sempre come costruisci gli asset di fatto.Tu adesso hai raccontato un asset delle personas, se posso chiederti come l'hai visto costruire, come l'hai visto fare nella tua esperienza? Ricerchi di mercato, non sono un product design, però ricordo delle schede molto dettagliate che spiegavano l'utente, le aspettative, come l'utente si interfacciava al prodotto o quantomeno ai prodotti simili, cosa cercava… Ecco, solitamente quando secondo me gli asset diventano uno strumento per avere più un certo tipo di valore che porti come professionista dentro l'azienda, più che davvero essere utile per l'azienda stessa, è quello che c'è come problema principale spesso.cioè, gli asset che noi produciamo come designer, da presentazioni a quelle che possono essere ricerca, quelle che possono essere anche un benchmark, di qualsiasi tipo, ha sempre un obiettivo, cioè tutto quanto ha con lo scopo di riuscire a creare più comunicazione tra i team di lavoro, a creare più empatia verso chi ti sta progettando, e se tu stesso ricevi un documento che è molto analitico e non ti racconta una storia, allora hai un problema, perché di fatto nel momento in cui a te non rimane niente come sviluppatore, non riesci o comunque non abbiamo fatto il nostro lavoro come designer da riuscire a farti comprendere quello che sei davvero facendo quando vai a realizzare il codice.Cosa che io vedo tantissimo.Quindi gli output che noi andiamo a produrre, le personas che vengono fatte e vengono utilizzate, anche da grandi aziende oggi hanno senso nel momento in cui risolvono quel problema per il quale sono state create, che non è sempre, che non è il bisogno di capire chi sono gli utenti per i quali progettiamo, ma come rendiamo tutte le persone interne all'azienda consapevoli che quello che producono ha un impatto su queste persone.Quindi è proprio il discorso di far capire a tutti quanti in un'azienda come attraverso una serie di comportamenti che facciamo fra gli utenti stiamo risolvendo il problema che ci siamo posti come azienda che possono essere diverse secondo quello che abbiamo dentro da un SaaS a un'app, a un sito web, a un e-commerce.però sì, quello che per rispondere è serve sempre capire qual è l'obiettivo di fondo e non trasformare l'asset che produciamo in qualcosa che è più ego riferito, che sia più utile all'azienda stessa.Avete tirato fuori, senza tenervene conto, una figata di cosa, da partire dallo Scrum a quello che dicevi tu, Paul.Si vede qua che Paul, di mestiere, aiuta la comunicazione tra le persone dell'azienda, alla fine è praticamente una banca del design.Ed è super collegato alla questione dello Scrum che dicevi tu.Il poker è solo uno scherzo, è solo un gioco.E' vero, nel senso che io spesso e volentieri sono un grande sosteritore di Scrum, anche se non lo faccio da un anno, perché dove sono adesso non mi servirebbe nulla, non posso avere un approccio agile, io lavoro su campagne pubblicitarie e come mi piace dire non puoi purtroppo spostare il Natale, quindi agile, se devi fare quella cosa lì per un periodo, quella era, non puoi togliere feature, piuttosto aumenti risorse.Lo Scrum, gli artefatti, come le personas, tutto quello che ha detto Paul prima, sono solo una cosa per far comunicare le persone tra di loro.Io se faccio il poker, all'inizio sparerò numeri a caso, è vero.Quei 5 che dato è un 5 a caso, Xel, quello che vuoi.La cosa che dico è che ci vogliono solitamente almeno 5 o 6 mesi perché il team abbia una conoscenza collettiva per il quale a quale 5 gli si dà un valore.Esattamente come la genesi semiotica delle parole.Un sasso, prima di essere chiamato sasso, è stato chiamato in miliardi di modi, prima con i versi, poi con i gesti, eccetera.A un certo punto abbiamo sviluppato, come diceva Paolo, un linguaggio comune e globale in cui se io dico "sasso" tutti quelli che parlano una lingua italiana più o meno capiscono a cosa mi riferisca.E' uguale per il menu, è uguale per le persone.Come diceva Paolo, se io ti ho fatto un bellissimo documento analitico, ma tu non riesci a farlo tuo, come designer fallito, perché la mia parte di mestiere è far sì che tu quella cosa lì lo capisca.Quindi oltre all'artefatto in sé, ci sta anche che ci sia un workshop o qualcosa che ti spieghi quella cosa lì.Una delle cose che, come sapete che c'è il pallino per i design system, una delle cose che a alcuni piace paragonare spesso un design sistema è un vocabolario.Per me un design system in un'azienda non è l'insieme di componenti, non è un insieme di tonal voice, bellissimi libri sull'argomento, è un vocabolario comune.Una cosa che se io ti dico "mettici più un bottone primario" e siamo tutte due parti della stessa società, dello stesso gruppo, tu capisci immediatamente quello che voglio dire.Idem con patate, se io ti dico questa roba qui è per la persona gessica, tu devi immediatamente capire quello che ti sto dicendo, così come se ti dico "questa tasca ha una complessità di 5".A quel punto lì, una volta che hai delle parole, se non arrivi ad avere le parole in comune, se non hai questa comunicazione che funziona bene tra tutte le parti, non puoi fare design, non puoi fare progettazione.Penso che l'italiano sia una lingua molto più bellina dell'inglese, artefatto invece di asset, non so che apposta, perché è un risultato artistico fattuale, quasi tangibile.Così come se vuoi fare progettazione, pensate a fare con qualcuno che parla giapponese.Avete mai visto i giochi senza frontiere, quei giochi dove devi fare il salto della la corda insieme.Fate un gioco insieme con una persona che parla la vostra stessa lingua e con una che ne parla una diversa e vedete che secondo me, anche se le condizioni fisiche vanno per chi non parla la stessa lingua, è più probabile che gli altri vadano.Un esempio è il design di iPhone.I primi modelli di iPhone li facevano testare a bambini perché ancora non avevano provato la parola, erano scarsi in comunicazione.Visto che volevano lanciare un prodotto worldwide, volevano essere sicuri che quello che stavano progettando può essere utilizzato anche da persone che non erano in grado di verbalizzare concetti.Questa cosa qui, se ci pensi, oltre ad essere sfruttamento minorile, è anche abbastanza complicata.LM: Tra l'altro, come ripeto spesso nell'episodio, le parole sono gli strumenti con cui noi formiamo i pensieri, per cui se già hai un set finito di parole, fondamentalmente vuol dire che tu riesci a comunicare con una persona che ha un set finito di parole, vuol dire che stai abbattendo anche quell'ulteriore muro di difficoltà.Avete parlato di asset, di artefatti come strumento di comunicazione, strumento di comunicazione con il business, strumento di comunicazione con gli sviluppatori.Voglio fare un doppio salto carpiato e arrivare, parlando di strumento di comunicazione, al momento dell'evoluzione.Voi avete più o meno visto la parte dell'evoluzione, io non so quanti anni tu abbia, Paul, Davide a un'età grafica simile alla mia.Ha visto l'evoluzione, il passaggio, il focus spostato verso il design system, tutto il concentrarsi sulla componentizzazione.Si può dire componentizzazione? spero di sì.Io vengo da un mondo direi pre-nuragico, l'era del bronzo, dove in realtà il designer ti mandava il design della pagina e io in quanto webmaster, adesso faccio felice Davide, dovevo trasformare questo design in codice.Oggi il designer mi manda set di componenti, fatto la divisione, ha individuato quelli che sono gli elementi portanti, li ha raccolti in un design system che erano alla fine, se ci penso, parte dei miei compiti.Io cosa facevo quando mi arrivava quel layout? Mi cercavo di individuare i componenti e me li scrivevo in modo che fossero riutilizzabili.Cosa secondo voi è cambiata con questo shift di responsabilità? Vado io? Sì vado io, purtroppo poco e niente dal mio punto di vista, perché spesso e volentieri mi definisco un designer, anche se Paul non gli piace questa cosa qua.Io mi definisco un designer e una delle cose che da designer al designer devo ogni volta spiegare per esempio è la questione degli stati.Noi progettiamo macchine a stati e anche la cosa più stupida come un link, qualsiasi cosa che c'è sul web, ha almeno tre stati.La più scema che ci sta ha tre stati.e gli stati sono sempre Loading, Error e Idol.Quindi per dire, nonostante ci sia questo tipo di cose che viene fatta la divisione, tutto dovuto al bellissimo libro, penso, di Roselia Bledfrost, Atomic Design, tutta quella cosa lì, che poi ci arriviamo, si è cristallizzata in una forma, secondo me, un po' malata.perché spesso e volentieri, cioè Atomic Design funzionava molto bene per quello che era il flow del tempo.Tu avevi queste belle pagine e tu dovevi atomizzarle.Quindi prendere e fare quel pensiero.Quindi praticamente lì c'era quello shift che dicevi tu.Quello che non vedo fare oggi, che è molto difficile, è fare invece il "backward thinking".Io non ho niente contro "tu fai la pagina e vuoi una roba figa".Se fai design, probabilmente tu la vuoi la roba figa.Ci sta, non c'è niente di male.Sembra che la nota azienda per cui lavoro c'è un concetto che noi ci spingono molto che è "backward thinking".Tu vedi quello che prima di lanciare un prodotto ti scrivi già le PR e FAQ.E quindi tu in questa pagina dovresti scrivere, dovresti pensare un attimino all'insieme e poi andare a vedere il particolare.Invece spesso quello che vedo in questo shift è che sei iniziato a progettare i bottoni.o con la gente che fa direttamente le palette di colore.Oh, che bello! Io mi prendo il mio framework di Atomic CSS che mi dà anche il Figma e da lì ci monto la pagina.Il contrario, no? È come se tu iniziassi a progettare una casa dalla forma del mattone.Non succede.Non succede, solitamente un architetto progetta la casa, ti fai un'idea, lo schizzo, eccetera, e poi vai a progettarne le parti.Questa cosa qui è un attimino venuta a mancare, secondo me.Questo shift è stato fatto, ma è stato fatto quasi per un trend, più che per le reali necessità.Io sto vedendo che delle volte viene portato il componente e tu quel componente non sai nemmeno come andrà a finire.A me è successo che venissero da me con una serie di oggetti input di un form, range, radio, eccetera eccetera.alcuni di questi sono stati progettati, ma non sono mai stati utilizzati.Ma mai! Il calendario che era stato progettato non era stato progettato con lo use case o all'interno di un vero e proprio formula.Quindi questa cosa qui, per carità, è difficile.Una delle cose che si fa, anche lì io dico sempre, il nostro è un lavoro giovane.Alla fine da quanto tempo lo facciamo? Da quante anni si fa web design.25 anni, 30 molto giovane rispetto a magari l'advertising.Nell'advertising si facevano cose fighissime come le mood board.Le fanno anche su UI, su visual, anche tutto.Però chiaramente non tutti.Sì, però una cosa "recente", nel senso...No, no, è che sei designer quindi non lo sai.Attenzione! Recentissimi.Recente intendo dieci anni, che per te è tutta la tua vita lavorativa.Ok, scolpo sotto la cintura.passerò a fare una telecronaca di box.Ricordiamoci che ci conosciamo da una vita.Quindi è la cosa.È recente, si viene fatto, vengono fatte le mood board, vengono fatte anche le tilecard, cose di questo genere qua.Però andrebbero fatte e ci dovrebbero entrare in parte del processo.Invece ancora oggi, un pochettino come succedeva nei tempi di bootstrap, c'è la gente che dice "boh non siamo bootstrap".Sì, ma il sito come deve essere.E che pietre abbiamo 10 componenti.E poi trovi delle interfacce con 70.000 bottoni che ricordano le UI di Visual Basic, quelle bellissime fatte in Visual Basic.Esatto.Non so se ricordate, no? Nel classico io all'epoca avevo l'agenzia di viaggi, il classico gestionale dell'agenzia di viaggi aveva i 70.000 bottoni e non sapevi dove andare a cliccare perché erano tutti sparsi in giro a destra e a sinistra.Per cui torno facendo un piccolo riassunto quello che dice Davide, si tutto bello tutto bello Atomic Design che c'entriamo però proviamo a esplorarlo ma dovremmo partire da quella che è una UX prestudiata, una UX/UI prestudiata A quel punto dimmi se ho capito bene, estrarre questi elementi a posteriori, quindi sono elementi che hanno già un ruolo, si trovano già all'interno della pagina, all'interno dell'applicazione e non sono delle cose che io metto dentro a posteriori solo perché ce li ho.Sì, esatto.Prima hai l'architettura delle informazioni, hai il contenuto, sai quello che vuoi fare, fai un'idea schizzata di quello che vuoi avere, poi parti alla progettazione, all'ingegnerizzazione.È un po' il concetto che c'è nello sviluppo di DRAI, "Don't repeat yourself", però prima volta lo devi scrivere per davvero.Cioè, devi avere almeno uno use case, non è un'interfaccia che ha dei pattern.Prima quei pattern li devi identificare, devi inventare i pattern concorrenti, altrimenti magari ti troverai a usare un componente per qualcosa che non esiste.Io ce ne scampi quanti di questi ricordano il Button Group.Barre piena di bottoni, cioè una cosa che ad un certo punto era esplosa semplicemente per qualche motivo assurdo.Per Apple, per Apple, che la faceva Apple il Button Group, in iOS.e infatti che fine hanno fatto! La cosa più orribile erano i FAB button, quei pulsanti che nascondevano dei menu che apparivano a moda scusate piccolo rant verso i FAB button questo è vero, però quanto questo approccio all'indietro, chiamiamolo così anche se potrebbe essere sbagliato limita poi o crea dei problemi alla consistenza.Io mi sono trovato in delle situazioni, non voglio dare giudizio al designer con cui lavoravo, dove sì lui progettava le interfacce, c'era uno UI kit che stava prendendo forma via via nella sua progettazione, però spessissime volte capitava di incappare nell'inconsistenza, figlia, secondo me, in parte di questo andare al ritroso, quindi magari spacing leggermente diversi o piccole cose che comunque poi da sviluppatore che invece tu ti stai facendo, che ne sono le tue variabili che riusi, ti saltano agli occhi e parti con le bestemmie? Io sullo spacing sono abbastanza maniacale, nel senso che ci sono due cose da dire.Piccole incongruenze non dovrebbero essercene, perché quando fai progettazione di qualcosa, soprattutto di un'interfaccia, secondo me le dimensioni, e per dimensioni Nintendo Phone, si tratta di "side spacing".Dovrebbero essere già definite secondo una scala matematica, quindi un logaritmo di una certa quantità.Per evitare che un domani ci sia qualcosa di più.L'interfaccia dovrebbe avere solitamente un numero di colonne, e cose di questo genere.Come si faceva ai bei tempi, quando si faceva progettazioni per quotidiani, non è che te ne andavi troppo fuori dalla tangente.L'altra cosa è che anche se c'è un inconsistenza, può essere che ci sia un inconsistenza, va bene, è meglio o peggio della prematura optimization.Cioè se noti un inconsistenza puoi sempre mettergli e dire "ho due use case simili".Li fattorizzo in maniera che li porto a un uso comune e ho individuato un pattern, oppure forzo della roba in un pattern che magari non è quello giusto.Questa è la differenza.Perché in realtà, se hai un problema, se fai la riprosa, ti può succedere la roba che dici "questa roba è un po' tirata per l'orecchia".Però secondo me è un male minore di cercare di forzare a tutti i costi qualcosa in contenitori che non insumano.Voi state parlando della casistica di un'azienda dove ha già raggiunto delle validazioni prima? Sì.Ok, quindi siamo molto avanti in quello che è un processo aziendale, l'azienda sta facendo soldi a X designer e X sviluppatori dentro da potersi permettere chiaramente.Questi sono i bei problemi, chiamiamoli così.Esatto, quindi personalmente quando arrivi a quella fase lì di un'azienda vuol dire che hai già comunque una maturità interna per poter fare il leggeramento di qualsiasi tipo, cioè dal scegliere un framework, un framework agnostico che può essere un po' come Ant Design o come Foundation o altri bootstrap che possono aiutarti in parte a validare inizialmente una prima idea, ma poi sai che internamente se vuoi fare una serie di ragionamenti strategici e qui poi si apre un capitolo perché voi adesso avete parlato solamente del rapporto tra design e sviluppo ed è quello che andremo a parlare oggi, ma di fatto poi dopo c'è tutta la parte del quale il marketing, i i sales vanno a vendere quello che noi abbiamo prodotto, che è tutta ancora un'altra cosa enorme ed è lì che poi il valore avviene anche economico in quel bridge lì che c'è tra il marketer che prende il nostro prodotto che abbiamo creato, l'interfaccia che abbiamo realizzato e la promuove in una certa maniera.Non so se avete sentito di recente Brian che ha fatto una bellissima talk nella quale Brian Chesky è il fondatore di Airbnb ed è un designer ed è il terzo o secondo designer presente nelle società più potate da tutta America e sono 100 società e sulle 100 società solo tre ci sono come founder, designer, tutto il resto non hanno come founder quella tipologia di professione.Una delle cose che lui ha detto è che è andato a chiedere a chi, se non a Johnny Hive, di come gestire la parte di design.Johnny Hive, ricordiamo, era il designer che ha creato tutta la parte di tutti i Mac colorati, molti Macbook, quelli bianchi, grigi… LM: Le cose belle della Apple! DLL.Esatto, le cose belle della Apple… LM: Quello che ha tolto le porte, quello che ha fatto tutto bianco, piattissimo… Lui che comunque ha portato un'estetica totalmente diversa, è lui che ha portato anche il minimalismo, ha sia portato lo schema erfismo, ma poi ha portato anche il minimalismo all'interno dell'interfaccia Apple.E una delle cose che lui chiaramente ha detto a Brian nel momento in cui Brian si trovava in difficoltà a gestire il prodotto, è che tutto alla fine è una storia, cioè è importante lo sviluppo e poi il design, ma alla fine le persone vedono le storie.Ed è la cosa sulla quale anche io ultimamente mi sto ricredendo moltissimo.Io ho fatto un processo nella quale sono stato molto nazi come designer, penso che per me gli output che noi producevamo avevano un certo tipo di valore.Oggi sto riconsiderando tutto, considero sempre di più il lavoro di designer o sviluppatore come un'attività che ultimamente sta venendo molto ingigantita rispetto a quello che è suo valore reale poi all'entrata di un'azienda che fa x mila euro, x mila dollari.E quindi, pensando a questo, ho provato a cercare altre persone che non la vedono tutta o design o sviluppo, ma un mix di cose, un mix di competenze.E quello che Brian Chesky realizza è che lui, come anche se non sbaglio in alcune aziende molto grandi e provare a immaginarsi quello che sarà l'articolo di giornale finale per quel determinato prodotto che noi andremo a creare quando usciranno le state giornalistiche.Mi vado a immaginare lo stato finale che le persone e i media avranno del prodotto che io ho realizzato, che è marketing e poi a ritroso torno indietro nel realizzare, nel creare e supportare un prodotto che sia realmente scalabile, che possa fare una serie di A/B testi, che possa fare una serie di cose.E per quello poi ci sono i designer e i sviluppatori che lo creano in quella maniera.Però ecco, il fatto che molto spesso il nostro lavoro, il framework, il "panther" migliori alla fine si scontra molto con quello che è la realtà dei fatti.Quindi quando si parla di aziende che hanno già validato attraverso una serie di modi i loro business, a senso tutti i ragionamenti che stiamo dicendo.Mentre nella maggior parte di aziende, quelle per la quale hanno magari un solo designer che fa tutto o pochi sviluppatori, è molto più complessa la cosa, perché di fatto casualmente nei momenti in cui tutti potrebbero fare tutto, cioè lo sviluppatore potrebbe mettersi a a fare una serie di ragionamenti con il designer e anche col business, non hai questi ragionamenti, hai ragionamenti a silos.Il capo sta lì, dice agli altri cosa bisogna fare, il designer prende, crea il designer, lo manda allo sviluppatore, lo sviluppatore prende, lo guarda, lo analizza, quello che ho potuto vedere io è che negli anni questo modo di lavorare ci ha portato a parte delle aziende grandi a riuscire a creare dei prodotti e a scalare dei prodotti, ma sta avendo anche dei problemi questa gestione di avere un team di design, un team di sviluppo, un team di marketing e poi altri x mila team all'interno di un'azienda.Quando invece il modello Spotify, quindi avere più persone con potenze multidisciplinarie che lavorano insieme può portare risultati migliori di fatto.Avevi una domanda, ma Spotify lo usa il modello Spotify? Allora, da quello che so, da quello che ho visto io, due amici che c'erano dentro, sì.Poi se mi raccontano che ha lavorato io non lo so.Allora, la questione dei team cross funzionali la sposo a pieno, o almeno parzialmente.la sposa appieno, ho avuto delle esperienze che mi hanno fatto notare che in alcuni contesti funzionano veramente bene.Il vero è che avendo avuto un'azienda prima, l'azienda avendo avuto dei responsabili marketing e interfacciandomi io in quanto titolare, sia con gli sviluppatori che con i responsabili marketing, oggi ti posso dire che non lo vorrei tanto marketing in mezzo alle balle quando lavora.Ma è tutto colpito da un disruppatore e tutti i designer, però è figlia di un problema nostro secondo me, che non riusciamo a parlare con quel tipo di persona.In realtà è proprio per questo che ci sono product owner e product manager che dovrebbero in qualche modo mediare le richieste degli stakeholder al tavolo.Perché ragazzi va bene fare tutto lo sforzo del mondo, ma dal punto di vista dello sviluppatore dobbiamo capire le esigenze dell'utente, ma nel contempo lo sforzo veramente per far capire alcune cose al marketing con i loro registri linguistici, se non si è sviluppato un ubiquitous language, un linguaggio comune diventa immane e improduttivo.In part questo è quello che dico, non ho postato qua Paul per caso, perché le persone solitamente che mi piacciono hanno competenze non a te ma a Pettine, quindi hai varie aree, una base molto eraica, delle anni, 3, 4, 5, in cui eri ricchi.Cosa che spesso e volentieri nei marketer, soprattutto quelli moderni, non noti.Su questo te l'appoggio.Ma secondo me non è sbagliato tanto la questione del marketer.Come hai detto tu, è il loro schema linguistico.C'è la questione, citando, non so quanti di voi abbiano visto Mad Men, non l'avete fatto, fatelo, perché è più bello di Breaking Bad.Qui lo dico così faccio un po' di dissing, la gente lo va a vedere.Per intanto l'avete visto? Dovete vederlo se volete sbucciar d'armi, mi spiace.Don Bray perché il protagonista è tutto.È veramente un uomo in show, se lo riaffiguri.Perché lui è il tizio che fa il marketing, è una director, però è il tizio che fa il marketing, è il tizio che fa il visual, è il tizio che fisicamente sta a sere volentiere, se non esegue quasi la campagna.Questo è un pochettino quello che purtroppo anche nelle società alla Spotify io noto mancare.A me piace il film cross-funzionale, è molto molto bello, però io sogno un mondo in cui Quando una persona dice "faccio web" ne capisca almeno un po' di tutto.Per esempio, io mi definisco un designer e oggi ho scritto una query.Se scrivo quelle che dice Paul, PR, FAQ, prima di poter fare qualsiasi cosa tu devi già scrivere non tanto l'articolo di giornale, ma il documento che manda i giornali per farti promuovere il prodotto.Ti devi immaginare quello che diranno i giornali della Gela-Cosa, anche se è un componente, un menu a tendina.Devi scrivere questa roba qui per cercare di entrare in quella logica che dicevamo prima.Il problema grosso è che è difficile.Una delle cose che posso anche dire è che spesso e volentieri ormai chi fa tech non è più un appassionato.Io so per certo che tutti quelli che sono adesso in questo meeting hanno la passione, perché altrimenti non staremmo qua alle 7 di sera a parlare di questo argomento, ma probabilmente staremo a pub a berci una birra.Quindi è anche buona parte di quelli che ci ascoltano, se non la quasi totalità, forse non giusto se ci ascolteranno le nostre dolci metà, è gente di questo genere, perché sta ascoltando un topic tecnico.Però spesso e volentieri la maggior parte delle persone non la fa e quindi esegue il compitino.Secondo più vai user facing, più se fai il compitino è peggio.Nel senso, se sei un DevOps e fai il compitino, probabilmente sei anche un eccellente DevOps.Sto parlando di quello che è più lontano dalla persona perché si occupa della macchina.Backend, frontend, designer, market, più ti avvicini verso il cliente.Più il compitino non lo puoi fare perché un marketer è quello che veramente deve essere abbastanza fluido da capire l'utente, da capire il designer che ci sta lì da cercare di far funzionare la baratta.Così come il designer deve essere abbastanza intelligente da capire il bisogno del marketing, da presentarlo anche in maniera al frontender che lo faccia e via e via discorrendo.Quindi sì, il problema grosso per me non è tanto il marketing, perché è quello che secondo me è il 50% del successo di un prodotto è dovuto dal marketing ad oggi.Quindi non è tanto quello, ma quanto quelle persone lì siano le persone che che valga la pena avere nel team.Spero che, intanto lo posso dire, non penso che i miei colleghi che fanno marketing ascolteranno mai questo podcast.Sei molto buono.Posso condividere un mio schermo? Che avrei da farvi vedere una cosa? Gli ascoltatori non lo vedranno però.Proviamo anche a descriverlo.Allora, provo ad escrivervelo, però lo faccio condividendolo così almeno riuscite anche voi ad aiutarmi.Prima stiamo parlando di fatto di come il marketing non abbia un modo di lavorare troppo simile a quello che facciamo noi designer o sviluppatori che fanno interfacce, ovvero che la giovanina più ingegnerizzata su una serie di cose.Vediamo lo schermo sbagliato.Arrivo, arrivo.Ok, dovrebbe essere tutto lo schermo che state vedendo.Yes.Ok, ditemi se vedete.Ok, perfetto.Allora vi racconto brevemente che cosa fa questa azienda.Questa azienda ha delle membership, è un e-commerce, con delle membership che tu puoi comprare e sulla base delle membership che compri tu puoi acquistare per quanto tempo è la membership attiva una serie di capi all'interno di questo sito.Per questo progetto mi sono occupato di lavorare insieme ai founder dall'inizio alla fine nella realizzazione del business model, quindi un modello di business, pensando a una serie di stakeholder chiave per l'azienda, per permettere a loro di costruire il business reale.Posso fermarti un attimo, Paul? Volevo dire a chi ci ascolta da casa che stiamo guardando una mini-robot con sopra un sacco di faccine e penso delle personas e la divisione dell'azienda di cui si sta parlando.Prima di iniziare a progettare una serie di output reali con un nuovo sito, perché avevano già qualcosa, abbiamo analizzato ciò che avveniva nell'advertising attraverso una metodologia molto più growth hacking, quindi una branchia del marketing che tende più che altro ad avere come obiettivo quello di crescere, quindi di analizzare quello che è il target, capire chi è la persona a cui tu vai a parlare e poi creare una serie di messaggi per la persona che tu vai a parlare.sapendo che questo business che stavamo creando era un e-commerce, abbiamo fatto delle ricerche secondarie e inteso come ci siamo andati a leggere una serie di paper, articoli e abbiamo cercato di parlare con alcuni degli acquirenti che avevano nel sito per capire quali tipologie di utenti potevano esserci.E ne abbiamo identificati totalmente in tre.Il discount shopper, quindi la persona che vuole solamente cercare uno sconto, un quality shopper, quello che vuole vedere la qualità nel prodotto, e il consul shopper, cioè qualcuno che invece vuole vedere una mission che porta all'azienda e con la quale si ritrova in linea, perciò acquista da te.Allora partendo da queste due ipotesi di utenti, quindi sempre come protopersonas, quindi prototipi di persone, abbiamo immaginato una serie di persone, ma non semplicemente la nostra immaginazione, ma facendo un'attività che si chiama Social Listening, ovvero andando a cercare su blog di settore o Reddit o post su Instagram di community che potevano essere molto simili a quelle che noi volevamo creare, dei quote, delle frasi che potevano in qualche modo aiutarci a dire "ok, effettivamente quest'utente che noi ci siamo immaginati esiste".Cioè c'è una persona che vuole sempre lo sconto, c'è quella che vuole sempre la qualità, c'è sempre quella che vuole l'emission.Partendo da quello, abbiamo lavorato su quelli che sono gli atomi di quel advertising, ovvero l'immagine.Tutti gli advertising si compongono di quattro componenti.L'immagine, il pay off, il copy del post e una call to action.Come vedete, sto facendo vedere lo schermo, Per ognuna di queste noi non abbiamo messo delle immagini, abbiamo ragionato sul linguaggio.L'immagine abbiamo scritto, si deve vedere la precedura dello sconto, si deve vedere l'elemento del meno, il payoff invece deve essere il risparmio mensile annuale, la parola risparmio all'interno.Quindi non ti sto dicendo ancora quello che sarà il payoff finale, ti sto dicendo l'intento che dovrà avere rispetto al target che noi abbiamo creato prima.Quindi è un processo di idee collettive di persone che hanno idee di che possano essere quello che vuole cercare lo sconto, quello che vuole cercare la qualità.Quindi facendo questo workshop abbiamo ottenuto una serie di idee e poi siamo potuti andare a lavorare sull'estetica vera e propria, facendo prima della ricerca, quindi cercando di vedere noi facciamo fashion, facciamo membership, chi altri che fa fashion o membership all'interno di advertising oggi fuori che parlano a uno che vuole lo sconto, che elementi ci sono che richiamano lo sconto, quindi una volta che tu hai pensato prima quello che vuoi realizzare, quindi pianifichi ciò che sarà l'output che vuoi avere, fai della ricerca rispetto a chi ha già prodotto degli output del genere e poi lavori nel disegnare effettivamente quelle pre-advertising.Noi non ci siamo solamente fermati qua, ma siamo andati anche oltre creando un prototipo poi di fatto dell'advertising stesso.Quindi non solamente l'advertising vero e proprio, ma come vedete qua alla fine abbiamo messo italiano e inglese.abbiamo realizzato un prototipo del advertising stesso per capire come un utente l'avrebbe visualizzato per poi alla fine fare un test da remoto attraverso zoom con una persona che effettivamente stava provando l'advertising abbiamo fatto fare un esercizio di thinking out loud, ovvero raccontarci ad alta voce quello che vedeva nell'advertising e da lì abbiamo capito quale strada dovevamo prendere per ognuna di queste tipologie che vi ho mostrato e che vi ho raccontato di advertising.Quindi questo che vi ho mostrato è di fatto quello che fa un marketer come si deve.Solo che in molti casi non è così.LM: In questo caso tu stai parlando di advertising, questo si applica anche a prodotti digitali, giusto? Percorsi singoli, analoghi? In questo caso sì, ma perché in realtà anche nello sviluppo, ho lavorato anche con persone che hanno fatto algoritmi, in tutto c'è analisi di ciò che vogliamo fare, anzi pensare a ciò che vogliamo realizzare come fase finale, dove vogliamo arrivare, quindi il punto d'arrivo, come arriviamo a quel punto d'arrivo, quali sono gli step che servono per arrivare a quel punto d'arrivo con le capacità interne che abbiamo e poi si decide e si organizza quello che è il lavoro da qui alla fine dell'obiettivo di quando arriverai al goal che ti sei preso posto prima.Però diciamo che è una roba che può andare bene su qualsiasi cosa, sviluppo, marketing, design, è solamente saper lavorare bene, secondo me, più che l'idea dello sviluppo del design.E' sapere che ci sono una serie di fasi, di momenti, di attività che fai anche tu nella tua vita, o magari no, però se le fai solitamente hai più facilità nel poter capire come prevedere alcune cose che ti potrebbero succedere.LM: Figo! È bello esplorare un mondo che per noi sviluppatori è abbastanza lontano, a meno che non si lavori in startup, nel mondo delle startup forse si ha più sensibilità rispetto a lavorare in una corporation, sei molto più vicino a questi elementi.Vedo che il tempo sta volando, però voglio farvi l'ultima domanda.Abbiamo parlato di Scrum, abbiamo parlato di processo iterativo, però da tutti i discorsi che abbiamo fatto sul design sentivo puzza di waterfall.Per cui vi voglio chiedere quali sono le sfide di un processo iterativo tra designer e sviluppatore? Ci sono delle difficoltà grosse? Dove e come ci si può agire in modo da essere veramente produttivi.Secondo me dipende sempre che fase siamo.Per ognuna di quelle fasi ci sono una serie di cose, di complicazioni che hai di mezzo.Ad esempio prima stavamo parlando del lavoro che facevi quando eri webmaster, che ricevevi il design da parte di un designer con una serie di ragionamenti e poi dovevi traslare quello e realizzarlo.Quello di per sé è un waterfall, non lo puoi fare a meno perché io lo sto costruendo precedentemente senza che tu lo veda, lo finisco e te lo mando, te lo do e tu lo ricevi e lo implementi.Oggi come si riesce ad andare contro questa cosa? Lo si può fare in una grande azienda quando hai un design di componenti riutilizzabili, quando hai i componenti rutilizzabili hai un sistema che ti permette di dire ok questa pagina è fatta da questi 15 componenti e quindi so già quello che è la code base di quei componenti e li vado semplicemente a scantare in una pagina secondo me la parte più difficile è quando il designer crea una tutta una serie di ragionamenti che non ha mai il tempo di riuscire a comunicare con lo sviluppatore per una mancanza di tempo e molto spesso una mancanza di ascolto da parte dello sviluppatore, che può essere sia una colpa del designer che non rende il contenuto abbastanza interessante da poter essere digerito come si deve e dall'altra parte c'è il discorso che molti sviluppatori vedono il design come appunto disegno, quindi colori o forme che vengono create ma senza uno scopo a livello di business.Mentre invece se parliate con persone che sono dei progettisti veri, io l'ho sempre detto questa cosa, ci sono molti più progettisti sviluppatori che progettisti designer.Molto spesso voi realizzate più la progettazione vera e propria perché analizzate una serie di cose che noi non tocchiamo, ma perché non riusciamo a toccare perché vedete infine voi.Nel momento in cui uno è designer però si rende conto che prima ci sono tutta una serie di ragionamenti da fare, allora la cosa cambia.Quindi nel momento in cui c'è un designer che ha quella conoscenza del fatto di conoscere anche un po' del mestiere dello sviluppatore e del sapere che c'è anche tutto un business con il quale devi parlare prima, allora diventa più facile la collaborazione, perché non c'è l'eco in mezzo.LM: Mentre parlavi pensavo a una cosa, che Tool come Figma, che hanno preso tanto in prestito dal processo di sviluppo, quindi la creazione dei componenti, la gestione degli stati, come diceva il buon Davide prima, hanno in qualche modo obbligato il designer avvicinarsi a quel mondo e io ringrazio i DIO, ringrazio i fondatori di Figma perché in realtà prima c'era una sensibilità diversa o almeno io percepivo una sensibilità diversa nell'interfaccia, quindi si conferma quello che hai appena detto dal punto di vista dello sviluppatore.LM: Secondo me il front end prima o poi dovrà morire per dare spazio al designer che possa pensare non solamente l'estetica ma come quell'estetica ragionerà.Cioè io non ci metto niente a ragionare a diverse media query, a come ragionare la tipografia, a livello anche scalabile come dicevi tu prima Davide.Il problema è che deve esserci un sistema che me lo rende possibile e me lo rende prototipabile in modo che io lo possa vedere senza perdere troppo tempo perché dovrò fare molte più prove rispetto magari a uno sviluppatore perché nella mia fase sono in una fase di divergenza e quindi sto realizzando diversi design che però tutti in qualche modo dovrebbero rispondere alla responsiveness di un sito internet.Questo la penso esattamente all'opposto.Io penso che è più facile che domani muoia MiFigma, muoia Framer, muoia quella roba lì perché c'è l'intelligenza artificiale, che non la parte di sviluppo.Perché quello che dici tu per dirti… Per farti un esempio stupirissimo, Breakpoint.Io non scrivo Breakpoint da… In un progetto io per lo più faccio l'ending page, ma in un ending page uso al massimo due breakpoint, mentre sono proprio come due media query.Perché adesso ci sono cose come Clamp, come Minmax, eccetera eccetera.E quei tipi di ragionamenti lì sono esattamente quelli che mangiano.Quando io di mestiere faccio l'intermezzo, cioè nel senso io faccio la figura di mezzo tra i designer e gli sviluppatori.Perché purtroppo pare che queste due entità non riescono a parlarsi in quelle che sono aziende molto molto grandi.E quindi aziende molto molto grandi dicono "bene, tu fai questa cosa qui".E quindi io spesso e volentieri, per lo più, sai cosa faccio? Faccio esattamente quello che dici tu.Io sviluppo componenti per uso e utilizzo del designer.Cioè io libero, risolto.Questo è il 30-40% del mio mestiere.Ti faccio un esempio, esempio, una volta che io ho creato un pattern ricorrente, facciamo un esempio, una roba per fare pacchetti regalo, intesi come te ne so.Ti compro la festa del papà, bagno schiuma, rasoio e spazzola, no? E lo puoi utilizzare come pattern per la festa San Valentino dove ti prendo tre cioccolatini e un bracciale.O all'uscita di un nuovo cellulare, che ti prendo il cellulare, questo è il pattern, un bundle.Nulla di eclatante.Faccio il bundle, quindi io vado lì, faccio la progettazione, prendo questa roba qui, faccio capire che se prendi il bundle ha di una determinata cifra, c'è uno sconto.Tutte queste cose.Per me sono ragionamenti che non dovrebbe fare lo sviluppatore.Sono d'accordo con te, ma il problema è che la maggior parte dei designer non fa questo tipo di ragionamento.L'altra differenza che ti dico, invece, è che io ad oggi devo ancora spiegare che un interfaccia, se vieni da me e mi dici "eh ma sul mio schermo qua metto 10 pixel che non mi piaccio", io posso solo finire a mani in faccia.C'è ancora questa concezione qui che la parte di L'esempio che ti faccio è, c'hai un iPhone, scrivi "designer", che emoji ti viene fuori? Sì, quello del pittore.Quello è il problema, e lì c'è la questione.Quindi secondo me un domani è più facile che una persona abituata a prendere un concetto, trasformarlo in codice, è più facile che questa persona che ne capisce di trasformazioni, di campi, di tutte queste cose qua, riesca a parlare con un'intelligenza artificiale per fare quel missing step che non viceversa.Quella è la questione.Perché per l'intifigma è fighissimo, ma la responsiveness fa schifo.Ancora oggi non è possibile fare una cosa così.Non c'è una cosa di quel genere lì.Non ha l'idea che un testo, se va avanti, la sottaffa.Il flow della pagina non esiste ancora.Perché sono concetti difficili, solo da rendere, ma proprio da progettare.Anche perché a quel punto c'è il codice.Sì, sì, a quel punto l'unica cosa che succederà è che diventerà sempre più facile scrivere codice, cioè il linguaggio verrà estratto, astratto, sempre più in alto, in maniera tale che, basti pensare, per fare un esempio semplice, Flexbox, io ti dico "space between" tra due oggetti e uno va a sinistra e l'altro a destra.C'è una cosa che non capisco, se parli inglese, è esattamente il comando che diresti.Però la parte difficile non è quella, la parte difficile è dire "cosa succede quando non c'è abbastanza spazio?".Le domande che faccio solitamente io sono "cosa succede quando qui non c'è abbastanza spazio?".Cosa succede se quel tipo di forma mentis è quella che, nella maggior parte dei casi, manca proprio l'utilizzatore di Figma, perché altrimenti Figma non avrebbe avuto successo.Aveva avuto successo Framer X, perché la responsiveness ce l'ha.Perché Figma? Perché Figma è molto più user-friendly, Figma è molto più veloce, Figma ti permette di prototipare molto più velocemente il tuo dribble shot.A differenza di Framer dove devi stare lì per dire cosa a programmarti le interfacce.E per programmare interfaccia intendo i tipi.Questa roba che stai dicendo è una roba che è vecchia, nel senso che oggi Framer X non esiste più come quello che tu dici, ma sono reinventati creando uno strumento che è Figma per fare più efflo.credo sia quello che ci sono.L: sì sì, lo so, ce l'ho pubblicato io un po' con LudoFrame.L: però...G: infatti, sono componenti, non lo vedo così difficile da creare.Cioè, quello che mi stai dicendo è che avete, così come io magari ho l'idea di uno sviluppatore, cioè, no, nel mio caso no, non è vero, perché conosco anche te Davide, è che io, ecco, il mio punto è che gli sviluppatori che magari ho conosciuto io nella mia vita, l'idea l'idea generale di uno sviluppatore che si ha è che sono persone mediamente intelligenti, perché la laurea da prendere come sviluppatore è molto più complessa da prendere quella come designer e di conseguenza una persona che è di formazione design, che fa alcune tipologie di scuole, è nella media, non mi dite designer, meno colta, con meno capacità a livello intellettivo e quindi di conseguenza molto spesso sia quello che sto dicendo voi, ma perché non c'è cultura da parte della persona che viene assunta come designer.Quindi partendo da quel concetto lì, io i designer che ho conosciuto, che sono molto capaci, molto bravi, la parte di sviluppo la fanno con lo coding e poi la traslano e la danno attraverso uno sviluppatore.E poi lo sviluppatore si riprende la roba.In realtà no, è come avere un framer, è come avere un figma, però pompato.LM: quello che ti dico io è semplicemente questo, che trovo, sono d'accordo con te, se parliamo delle eccezioni, cioè se prendi un designer che è in grado addirittura di farsi la roba in no code, probabilmente l'andrai a fare.Quello che ti dico io è che è più facile che una persona che riesca a fare l'interfaccia di un tipo riesca ad acquisire la formamenti per fare progettazione, che viceversa.Cioè è più facile che un muratore diventi un ingegnere edile, che un pittore naturista diventi un architetto.Questo è il mio concetto.Poi ovvio, in entrambi i casi, ci saranno le eccezioni, ma per come è il set di base è più facile.Perché è esattamente quello che hai detto tu, è più difficile diventare quella figura che quell'altra.Quindi sarà più facile la traslazione verso una cosa.al netto che io domani mi auguro che l'automatizzazione ci levi a tutti il posto di lavoro e che dobbiamo tutti vivere in qualche altro modo e ci rendiamo conto che non possiamo lavorare per vivere nemmeno.Però quello è appunto domani, secondo me non è tanto la questione tipo...appena che lì mi fa morire.La cosa è che quando è uscito il chat gpt al pubblico la maggior parte dei post erano "adesso gli sviluppatori non servono più".Invece la mia preoccupazione è vera.Sai di chi mi sarei preoccupato se fossi stato per l'AI? Per i project manager, per quelli che fanno 10 start up al secondo, perché quelli lì fanno il pitch, lo marketing eccetera.Ogni 20 seco, cioè chiunque può fare quel mestiere una volta che lei è in in grado.Ed è un mercato molto più remunerativo che fare i scopo.Credo che quello che ha appena detto Davide, rispetto al passo dallo sviluppatore al progettista si amplifichi se non parliamo solo di siti, ma parliamo anche di web application, dove gli stati e gli user journey magari si complicano un attimino e quel tipo di progettazione così profonda o quella formamentis che viene da quel tipo di progettazione, se portata nel mondo del design diventerebbe… se quel tipo di formamentis sviluppata nel mondo dello sviluppo lo portassimo nella fase di progettazione probabilmente si riuscirebbe ad avere qualcosa anche di più robusto.Io mi diletto con la predomazione funzionale e penso a concetti come un monoide, un header, cose di questo genere qua, appostate alla progettazione di interfacce dati, quanto bene ti fanno e quanto questo tipo di progettazione può fare bene all'utente.Quando fai un workflow, se puoi tipizzarlo bene da un punto di vista progettuale è una figata e a quello anche il senso della faccenda.LM: Stiamo andando lunghissimi, però da quello che ha appena detto mi è riportato in mente functional domain driven design, dove quel bellissimo libro è un libro di progettazione e non di sviluppo, se lo sappiamo leggere.Dicevi scusate, ti ho parlato sopra.Se lo leggi in quell'ottica lì sì, mi ho parecchi libri di design, anche quelli che ho trovato che in realtà parlano di sviluppo, se lei gira a quel punto devi stare lì, anche se parla di design di sedia in bambù.LM: Ok, io ricordo che tu portasti i munari al nostro primo episodio.DLL: Esatto, spenteremo a quello, quello che avevo portato l'altra volta.LM: Esatto.Rubo un minuto per ringraziare chi ci sostiene.Ahimè, questo episodio non avrà siglette, cercherò di organizzarmi per i successivi perché ormai il mio computer è morto, però devo ringraziare Elis Pellizzari che ci ha invitato tre birre, abbiamo anche il Cavaliere Vesugo che ci ha invitato una birra mandandoci un messaggio, pareggio raggiunto, ho ascoltato tutte le 167 puntate, tutte o quasi fantastiche, Burp che è scorpacciata, ancora grazie e complimenti.Complimenti a te, bel coraggio di aver recuperato tutte le puntate di Gitbar.Dobbiamo ringraziare anche Livio Francisconi che ci ha mandato un messaggio e in realtà nelle puntate precedenti mi sono scordato di ringraziarvi e quindi vi ringrazio tutti oggi.Ciao Mauro, ciao Mutinatti e gruppo.Ogni giorno che ascolto il podcast mi rendo conto del valore delle puntate che state creando.Per la cr e poi il messaggio è troncato.Cavolo, Livio mandacelo in privato così riusciamo a leggerlo.Dobbiamo anche ringraziare Simone Dalla per le tre birre insieme a Giovanni Italiano.Penso di aver ringraziato tutti, siete tantissimi, grazie per prenderci sulle spalle in questa esperienza, questo progetto un po' pazzo.Davide, io potrei rimanere altre 4 ore con voi e sono sicuro che faremo un altro episodio dove continueremo la nostra chiacchierata, ma vedo che siamo già un'ora e mezza, siamo lunghissimi, io avrei voluto parlare con voi di documentazione, di responsive design, di gestione delle modifiche, di accessibilità, di testing… mamma mia, ci sarebbero argomenti per altri sette episodi.Però prima di lasciarci vorrei che Paul in quanto designer e Davide in quanto senior developer front-end developer riusciste a mandare un messaggio nella vostra narrativa controparte.È come un messaggio ai posteri, Paul verso gli sviluppatori e Davide verso i designer.Chi vuole iniziare? Vuole iniziare allora.Sì, bravo.Io come messaggio agli sviluppatori, quello che posso dire è molto spesso un designer quando si trova...cioè molto spesso i designer hanno una sintoma dell'impostore, impostore, non tutti ma molti ce l'hanno, il che significa molto spesso che a volte hanno paura di mostrare anche alcuni dei loro lavori ancora quando non sono finiti perché si vergognano molto spesso di quello che hanno prodotto.Questo per una serie di motivi, che possono essere personali e di altro tipo.Quello che vedo mancare agli sviluppatori è proprio a volte la mancanza di empatia.Quindi il fatto di banalmente sorridere un po' di più, di essere un po' più accessibile a qualcuno per avere un dialogo.Ed è una cosa che purtroppo, credo che poi impatti molto sul modo in cui si dialoga l'uno con l'altro.È chiaro che abbiamo due presuntità diverse.I designer e i sviluppatori nella maggior parte dei casi hanno presuntità differenti da quel punto di vista, perché fanno due stili differenti.Quindi quello che chiedo al designer è di avere un po' più di empatia verso il designer con il quale si parla e ai designer invece di essere un pochino più...di provare modi diversi con la quale comunicare con il corrispettivo designer con il quale stai lavorando.Promesso, sarò più empatico, basta che non fissiate meeting dalle 9 alle 10 e mezza, in quel caso è molto difficile.Davide? Io ho una laurea in design, quindi sì, la laurea a semplici, io da 8 gennale e basta.Si, ma dipende dove anche la laurea.Anche pregio alla NABA come graphic design and art direction.Una delle cose che non mi dimenticherò mai per tutta la vita è un insegnante molto bravo del primo anno, materiale e strumenti, che a un certo punto, con un alunno distratto, mi stava spiegando banalmente cos'è un ottavino, la cosa che si piega in otto per fare le pagine di un libro, per chi non lo sapesse, e faceva spiegare la difficoltà, il tipo di carta, etc.Aveva delle risme con sé."Vabbè, ma cosa ci vuole applicare in otto?" Aveva commentato un foglio questo alunno.E lui arriva, urlando fortemente, non mi dimenticherò mai, e fa "tocca la carta, tocca la carta!" Per far vedere che una carta, tipo satinata, uso mano, molto spessa, effettivamente può avere delle difficoltà.Ecco, questa è la mia cosa e il mio consiglio ai designer.Considerate sempre qual è il mezzo su cui voi state facendo design.Se siete designer della stampa, dovete sapere qual è la differenza dei dpi, perché magari un cartellone 6x3 non è il caso di stamparlo a 300 dpi, ad Se siete persone che fanno progettazioni di designer di sedie, dovete capire che le sedie devono anche leggere il peso delle persone.Se fate web dovete anche saperne due o tre cosine sul web.Quindi se un sviluppatore domani vi guarda male perché non sapete cos'è un gradiente, e se uno si dice male è perché non puoi forzare l'utente a tenere lo schermo a determinata risoluzione, ci sono dei motivi.Dovrebbe venire da voi a dire "tocca lo schermo!" o qualcosa di questo genere.Il mio consiglio è di essere sempre conscienti, di cercare di studiare esattamente come si studia le tecniche di stampa quando si fa i design di stampa, un minimo di tecniche web, se fai un design web dovresti avere.Io credo che campionerò la tua frase "tocca lo schermo" e lo metterò nella sigla, ti prego.Perché è bellissimo, però è sacrossanto quello che entrambi avete detto.Detto questo, noi ci spostiamo nel momento tipico e topico del nostro podcast, momento che accompagna verso la fine, ma momento importante.E' quella parte dell'episodio nel quale sia i nostri guest che i nostri host condividono con noi un libro, un talk, un video, un disco, qualunque cosa abbia catturato la loro attenzione e Reputino importante condividere con noi.Chi vuole iniziare? e conduco nel paese dei balocchi.Ah, il paese dei balocchi! Io ne ho un bordello di cose, ne ho due, ma proprio easy.Vi consiglio sicuramente il talk di Brian Chesky, che lo trovate sul canale di Figma.ed è un talk, secondo me, molto importante se siete interessati nel capire il valore del design inteso anche non solamente come progettazione, ma proprio business.E poi, come ultima cosa, quello di Design System di Alla Kolmatova, che è anche quello, è un ottimo libro che adesso Davide lo sta apprendendo, lo sta per mostrare, perché è un libro grosso, in cui si parla di Design System.Ed è fatto molto bene, ti permette di dare una buona inferenatura anche dal punto di vista della progettazione, parla anche di non solito le solite componenti ma anche quello che sono i path.Quindi questi due risorse vi consiglio.Fortuna che non lo volevo consigliare io perché mi sono spostato su altro che sono invece cose un po' differenti.Uno di cui vorrei parlare a proposito del design ho già mandato il link, Maura così lo puoi spammare, è una paretina per attrezzi dell'Ikea che ho comprato domenica e che mi fa felice quando la vedo, nonostante sia una roba da vecchi, come direbbe Paul.Però ho lì tutti i miei cavi appesi, il pad del Wii U, la pinzetta con la foto di mia figlia e la to-do list della giornata, una sciacquicciocchezzuola che costa onesto, direi, che è veramente anche molto tattile.un foglio di legno pitturato e anche bellino da maneggiare.Un altro consiglio che invece vi do e che vorrei darvi perché mi è spuntato oggi, penso che tutti quanti, se siete dei videogiocatori, dovrebbe esserci questo nuovo gioco che è uscito gratis, "Sea of Skies", non mi ricordo bene il nome, ma io non voglio parlarvi di lui, "Sea of Stars" è il nome gioco, ma di un titolo che fa cinque anni, proprio in questi giorni, che è The Messengers, dello stesso team, che secondo me è un gioco che dovreste giocare, perché è retro style, quindi a 8 bit, perché fa veramente capire com'è importante che tutte le cose, per far funzionare un prodotto, tutto deve funzionare alla stessa maniera.È un gioco dove funziona il visual, la storia e la musica.Se siete come un certo martiere che ogni tanto bazzica da queste parti qua musicalmente, il doppio vinile è una bomba.L'ultima cosa che vi consiglio so che hanno distampato è "Gendhi Hiroshima" di Keiji Nakazawa, che è un fumetto di un reddice che potete ben immaginare in quale momento sta di conosco.Io lo sto leggendo proprio in questi giorni nella sua versione integrale, che ho comprato quasi un anno fa, ma ho avuto tempo di leggere solo quest'estate, ho visto che l'hanno distampato in un formato accessibile a tutti, perché l'hanno fatto in volumi più piccoli e non la Bibbia che sto leggendo io da 6.000 pagine, quindi è un altro consiglio che vi do se volete farvi una lettura diversa dal solito.Perfetto.Ho due balocchi anch'io, non c'entrano niente o parzialmente niente con quello appena detto.Il primo è Power Pizza, il podcast di Sio.Perché questi balocchi? Perché quest'estate ho avuto necessità, ve ne sarete accorti, di disconnettermi un po' dal mondo del web, spegnere i social e ricaricare un po' le batterie.Power Pizza era uno dei pochi momenti che ho passato col device tecnologico, pochi momenti libri che ho passato col telefonino ed era un bel modo per riequilibrarsi.Mi piace il registro comunicativo che utilizzano, mi piace la simpatia senza volgarità, mi piace tutto il mondo di CEO in genere, quindi ve lo condivido.D'altra parte, questa estate mi sono appassionato di profumeria e quindi ho studiato come si compone un profumo e ci ho visto molto di quello che facciamo nello sviluppo software.C'è un back-end, c'è un front-end, c'è un UI design anche nella creazione di profumi.Il mio consiglio è dottate la vostra appostazione di un vaporizzatore e prendete un paio di oli essenziali che fanno il caso vostro e vi assicuro che vi cambieranno le 9 del mattino.Vi cambierà quella faccia che va dalle 9 del mattino alle 10 e mezza se siete un carattere scontroso come il mio, perché creerà un ambiente che addolcirà il vostro contesto e quindi vi aiuterà e soprattutto scoprirete un senso che spesso trascuriamo e che non è toccato dal nostro lavoro e che ha senso soliticare ogni tanto.Spero che questo episodio vi sia piaciuto, anzi ne sono sicuro e per questo ringrazio Davide e Paul per essere venuti a trovarci, tra l'altro con dei bellissimi sottopancia che vorrei leggervi al vivo.Davide ci ha scritto sotto "fondente al cioccolato" e Paul "fondente al cacao" e io ho visto dove abito durante l'inverno ci aggiungerei fonduta, chiudiamo il cerchio.Detto questo Davide e Poli io vi ringrazio tantissimo, vi ringrazio anche a nome dei nostri ascoltatori.DL: Grazie a te.LM: Non ti abbiamo sentito Davide, eri mutato.DL: Grazie a tutti voi, ciao! LM: Ciao ciao, allora alla prossima.Un abbraccio! GitBar, il circolo dei fullstack developer.Una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web, di metodologie ed strumenti immancabili nella cassetta degli attrezzi dei Full Stack Dead.[ sophomore, I'll Show You the Way ]
