Ha ancora senso uno studio di design?

Una riflessione senza filtri su cosa conta meno, cosa conta di più e dove uno studio esterno continuerà a portare valore.

Negli ultimi vent’anni, trasformare un’idea in un prodotto digitale è stato abbastanza difficile da creare un intero mercato attorno a chi sapeva farlo.

Servivano competenze diverse, tempo, coordinamento e una quantità non trascurabile di denaro. Tra un’intuizione e qualcosa che le persone potessero davvero usare c’era una distanza significativa, e una parte importante del valore stava proprio nella capacità di colmarla. Designer, developer, product manager, product marketer, user researcher, strategist. Le aziende costruivano questi team internamente e cercavano fuori le competenze che mancavano. Progettare e realizzare richiedeva persone difficili da trovare, e quindi preziose.

Nel suo articolo "We Built Companies Around the Cost of Building", Geoff Teehan, Chief Design Officer della fintech Lightspark, osserva come i costi di sviluppo abbiano finito per modellare non solo i processi di prodotto, ma la struttura stessa delle aziende. Si studiava e si discuteva, si progettava e si stimavano tempi e costi. Solo dopo una serie di filtri qualcosa arrivava davvero allo sviluppo. Quel sistema aveva parecchi limiti, ma svolgeva anche una funzione utile: impediva a molte idee di diventare software.

Questo equilibrio sta cambiando molto velocemente. L’intelligenza artificiale sta abbassando il costo di trasformare un’idea in qualcosa di concreto. Un founder può arrivare da solo a una prima versione funzionante di un prodotto tecnologico; un product manager può mettere alla prova una proposta senza aspettare un intero ciclo di sviluppo; un designer può andare facilmente oltre il prototipo visuale e un programmatore può affidare allo sviluppo agentico una parte consistente del suo lavoro.

Questo mette in discussione una delle ragioni storiche per cui ci si rivolgeva a un’agenzia o a una società esterna: accedere a competenze che internamente non c’erano. Non hai designer? Li abbiamo noi. Non hai sviluppatori? Costruiamo noi il prodotto. Non sai arrivare da un’idea a un prototipo? È esattamente il nostro mestiere. Costruire prodotti eccellenti resta difficile. Ma le hard skills, da sole, non bastano più a spiegare perché un’azienda dovrebbe scegliere un partner esterno.

Nel frattempo, il contesto economico è diventato più incerto e le aziende selezionano con molta attenzione su cosa investire. Il valore del design e il costo necessario a produrlo, per anni strettamente legati, cominciano così a separarsi.

Saper fare non basta più. Bisogna essere molto più chiari sul valore che si porta. La domanda allora cambia: se fare diventa più facile, cosa continua a essere difficile?

Dove sta il valore

Quando le possibilità aumentano, diventa più difficile capire quali tra queste meritano attenzione. Possiamo esplorare dieci direzioni laddove prima ne esploravamo due, oppure costruire in pochi giorni una feature che dovremo poi mantenere per cinque anni.

L’abbondanza delle possibilità aumenta il bisogno di giudizio. È qui che entrano in gioco judgment e taste.

Il giudizio (judgment) è la capacità di prendere una decisione sensata quando non esiste una risposta evidentemente corretta. Ed è una condizione normale nei progetti: informazioni incomplete, obiettivi di business, esigenze degli utenti, limiti tecnici, opinioni diverse. A un certo punto bisogna prendere posizione. L’esperienza serve anche a questo. Non garantisce di avere ragione, sarebbe troppo comodo, ma permette di riconoscere alcuni pattern più velocemente, capire dove vale la pena scavare e accorgersi quando un problema apparentemente secondario sta in realtà condizionando tutto il resto.

Il taste è qualcosa di diverso. Non riguarda solo l’estetica, ma lo standard con cui giudichiamo una soluzione. È la capacità di riconoscere quando qualcosa funziona ma non è ancora abbastanza buono, quando abbiamo aggiunto complessità invece di risolvere un problema, o quando una soluzione formalmente corretta continua comunque a non convincere. L’AI può moltiplicare le alternative, ma non può eliminare il problema di stabilire quali siano davvero buone e quali soltanto plausibili.

Se arrivare a qualcosa che funziona diventa più facile, il valore si sposta ancora di più verso la capacità di capire cosa sia abbastanza utile, rilevante e ben fatto da meritare di essere scelto.

Prendere posizione

Un cliente non compra solo competenze: si affida anche al giudizio di chi ha scelto. Presentare cinque opzioni e concludere che “dipende” è facile. Più difficile è arrivare a dire: abbiamo studiato il problema, esplorato le alternative e questa è la direzione che consigliamo. Vuol dire esporsi, spiegare le ragioni di una scelta e accettare la possibilità di scoprire di aver sbagliato.

Se posso ottenere da solo cinquanta versioni di una homepage, probabilmente ho meno bisogno di qualcuno che produca la cinquantunesima. Ho molto più bisogno di qualcuno di cui mi fido che mi dica quali quarantotto buttare e quale portare davvero avanti.

Tornare a ciò che conta

Questo cambiamento ci costringe inevitabilmente a chiederci cosa significhi per Moze. Più ci penso, meno sento il bisogno di inventarci una nuova identità per adattarci al momento. Questo cambiamento ci obbliga piuttosto a distinguere meglio ciò che nel nostro lavoro è essenziale da ciò che, negli anni, gli si è semplicemente costruito attorno.

Quando abbiamo fondato Moze, nel 2012 e negli anni successivi, parlavamo di Agile Studio. Era il modo con cui provavamo a descrivere un approccio abbastanza semplice: tenere vicini design e sviluppo, procedere per piccoli passi, costruire presto e mettere continuamente alla prova le nostre idee.

Da allora sono cambiati gli strumenti, la dimensione dei progetti e anche il significato di molte delle parole che usavamo. Il principio, però, è rimasto sorprendentemente stabile: capire bene il problema, cercare la soluzione più semplice possibile e portarla abbastanza rapidamente nel mondo reale da poterla mettere in discussione.

Per questo non penso che Moze abbia bisogno di aggiungere una nuova specializzazione alla lista o rincorrere una definizione più contemporanea di studio. Preferisco tornare con maggiore decisione alle ragioni per cui abbiamo scelto di fare questo mestiere in questo modo.

Il contesto è cambiato molto. Il punto di partenza no.

Pensare facendo

Parlare di giudizio e capacità di scelta potrebbe far pensare a uno studio più consulenziale, che costruisce meno e passa più tempo a dire agli altri cosa dovrebbero fare. È una prospettiva che ci interessa poco.

Pensare e fare, nel nostro lavoro, sono molto più difficili da separare di quanto sembri. Finché una soluzione rimane in una conversazione, in un documento o in un prototipo astratto, può sopravvivere a lungo senza essere davvero messa alla prova. Quando inizi a costruirla emergono vincoli e contraddizioni che prima non vedevi.

È uno dei motivi per cui abbiamo sempre cercato di tenere design e tecnologia molto vicini. Una scelta progettuale cambia quando incontra il codice; una scelta tecnica cambia quando incontra l’esperienza di chi userà il prodotto. Spesso le soluzioni migliori nascono proprio lì.

Per questo non credo che il making perda centralità. Cambia il motivo per cui è importante. Se una parte dell’esecuzione può essere delegata alle macchine, il valore non sta più nel tempo necessario a produrre qualcosa, ma in ciò che impariamo costruendolo e nelle decisioni che riusciamo a prendere grazie a quel processo.

Togliere per semplificare

Ultimamente ci capita sempre più spesso che un cliente ci mandi un prototipo costruito con Claude. La prima reazione è quasi sempre la stessa: impressionante. In poche ore c’è un prodotto funzionante, con schermate, interazioni e dettagli che fino a poco tempo fa avrebbero richiesto giorni di lavoro.

Poi inizi a guardarlo davvero e quasi sempre c’è dentro troppa roba. Funzioni che nessuno aveva chiesto, opzioni per casi improbabili, impostazioni, filtri, dashboard articolate. Presi singolarmente, molti elementi hanno perfettamente senso. È l’insieme a diventare confuso, fino al punto che fai fatica a capire quale sia davvero il prodotto. Non è un difetto di Claude, è una conseguenza abbastanza naturale di strumenti ai quali è facilissimo chiedere di aggiungere e molto più difficile affidare il compito di capire cosa non serve.

Qui torniamo a una delle cose che abbiamo sempre considerato centrali nel nostro modo di progettare: la semplicità. Per noi significa soprattutto togliere. Capire cosa è davvero necessario, ridurre un passaggio, eliminare una scelta inutile, mettere in discussione una richiesta prima di trasformarla automaticamente in una nuova feature.

Dire le cose come stanno

Negli anni abbiamo imparato ad apprezzare sempre di più la possibilità di dire a un cliente che, secondo noi, non dovrebbe fare quello che ci sta chiedendo.

Succede più spesso di quanto sembri. Arriva una richiesta per una nuova feature e, entrando nel problema, scopri che forse non serve. Una richiesta di progettare un’applicazione mobile si trasforma in una semplice newsletter. Altre volte capisci che non c’è bisogno di un redesign o di una nuova piattaforma, anche se sarebbero cose molto comode da vendere.

Sono conversazioni che qualche volta costano qualcosa nel breve periodo. Se il modello economico dipende dalla quantità di giornate che riesci a mettere a preventivo, suggerire al cliente di fare meno non è esattamente la strategia più intelligente per aumentare il fatturato. Eppure è spesso lì che si costruisce la relazione.

Quando lavoriamo bene con un cliente, a un certo punto smette di chiamarci perché gli servono dei designer o degli sviluppatori. Ci chiama perché vuole sapere cosa ne pensiamo. Quella domanda conta solo se sa che gli diremo davvero quello che pensiamo, anche quando significa vendere meno lavoro.

Per noi l’onestà è sempre stata molto più concreta di un valore scritto su una pagina. Significa poter dire che un’idea non ci convince, che il problema forse è un altro, che una strada è inutilmente complicata. Ottenere rapidamente un prototipo, un’interfaccia o del codice sarà sempre più semplice, invece trovare persone di cui ti fidi tanto da metterti in discussione lo sarà molto meno.

Uno studio esterno può portare anche un’altra cosa: il confronto continuo con aziende e prodotti diversi. Non conosceremo mai il business di un cliente quanto chi ci lavora ogni giorno, ma possiamo riconoscere situazioni già viste altrove, trovare analogie e mettere in discussione abitudini che dall’interno sono diventate invisibili.

Quanto vale il tempo

Se cambia il valore, prima o poi deve cambiare anche il modo in cui lo vendiamo.

Per anni abbiamo stimato i progetti contando persone e giornate. Aveva senso quando il tempo necessario era una buona approssimazione del lavoro richiesto: dieci giorni di design e venti di sviluppo raccontavano abbastanza bene la dimensione di un progetto.

Se oggi è possibile risolvere in tre giorni un problema che prima ne richiedeva dieci, il valore prodotto non diventa automaticamente un terzo. Una buona decisione presa in quei tre giorni può evitare mesi di lavoro inutile. Vendere soltanto tempo crea quindi un paradosso: più diventiamo efficienti, meno dovremmo valere.

Le giornate uomo non spariranno. Ma credo che diventerà sempre più evidente la differenza tra chi compra soprattutto esecuzione e la confronta sul prezzo, e chi sceglie uno studio per il modo in cui affronta i problemi e per la qualità delle decisioni che riesce ad aiutare a prendere.

Forse saranno meno clienti. Ma ti sceglieranno perché vogliono lavorare proprio con te, non perché costi meno di qualcun altro.

Cambiare forma, non identità

Probabilmente serviranno team più piccoli per fare lavori che ieri richiedevano molte più persone. Alcune competenze avranno un peso diverso, cambieranno i servizi e forse anche i mercati in cui lavoriamo. Non ha senso difendere la struttura attuale di una azienda come se fosse parte della sua identità.

Per Moze significa essere disponibili a cambiare: ruoli, processi, modello economico, persino il tipo di problemi di cui ci occupiamo. Quello che non vogliamo fare è costruirci addosso un’identità nuova ogni volta che il mercato cambia direzione. Diventare una “AI agency” perché oggi è ciò che tutti cercano, oppure aggiungere servizi soltanto perché sembrano vendibili. Questo momento ci costringe piuttosto a distinguere ciò che apparteneva a un certo mercato da ciò che dice davvero chi siamo.

Allo stesso tempo, sarebbe altrettanto ingenuo comportarsi come se nulla fosse cambiato. L’AI non è semplicemente un nuovo strumento da aggiungere alla cassetta degli attrezzi, da liquidare dicendo che ora facciamo design e sviluppo “AI-assisted” usando Gemini o Claude. Sta cambiando la velocità con cui possiamo esplorare alternative, il confine tra competenze diverse e, inevitabilmente, il modo in cui un cliente valuta il nostro lavoro. È un cambiamento profondo, e far finta che riguardi soltanto gli strumenti sarebbe un modo comodo per non affrontarlo. Per questo ne parliamo.

Il punto non è preservare Moze così com’è oggi. È preservare ciò che la rende riconoscibile mentre tutto il resto cambia.