Ti racconto di come una decisione condivisa in corso d'opera con il team di sviluppo ha portato a una soluzione di navigazione più semplice ed efficace per la sezione più critica del prodotto (dichiarazione dei redditi).
Creare prodotti digitali è difficile. Lo sappiamo. Lo è ancora di più quando si tratta di costruire un SaaS.
E diventa ancora più sfidante quando lavori su ambienti complessi come quello del consulente: una vera e propria intranet, fatta di logiche articolate, casistiche e linguaggio burocratico.
A un certo punto il team di sviluppo mi scrive: 👉 “Implementare questo comportamento nella sidebar richiede troppo effort rispetto alla scadenza del primo rilascio.”
E lì succede la cosa più interessante.
Ci fermiamo. Brainstorming. Decisioni condivise. Iterazioni veloci, in tempo reale.
Non cercavamo solo una soluzione tecnica, ma una soluzione sostenibile, che non fosse disruptive e che rispettasse tempi e contesto.
Alla fine, proprio attraverso questi test live, siamo arrivati a un'alternativa più efficace: una soluzione che aiuta davvero il consulente nel momento più critico del suo lavoro → la creazione della dichiarazione dei redditi.
Stiamo parlando di un'area complessa, densa di informazioni e funzionalità.
La soluzione?
Un componente super personalizzato per questa tipologia di navigazione tra le guide. Un piccolo cambiamento, ma con un grande impatto sull'esperienza.
💭 A volte non serve la soluzione perfetta. Serve quella giusta, nel momento giusto.
Questo modo di decidere insieme, in tempo reale e senza aspettare il redesign perfetto, non è un'invenzione mia: è lo stesso principio dietro alcune delle scelte di design più note del settore.
Intercom, per esempio, ha raccontato pubblicamente come i team di prodotto e ingegneria decidano insieme il "livello minimo sostenibile" di una feature prima del rilascio, invece di rincorrere la versione ideale: meglio spedire qualcosa di solido e iterare, che bloccarsi sulla perfezione.
Basecamp ha reso pubblica da anni la sua filosofia "good enough", documentata nel libro Shape Up: dare un budget di tempo fisso a ogni feature e, quando il tempo scade, spedire la versione che si ha, non quella immaginata a tavolino.
Spotify, nel suo modello di "squad autonomy", incoraggia esplicitamente i team a scendere a compromessi pragmatici con l'ingegneria in corso d'opera, invece di bloccare i rilasci in attesa dell'allineamento perfetto tra design e sviluppo.
Il filo comune è sempre lo stesso: la velocità di allineamento tra design e sviluppo conta più della perfezione della soluzione iniziale.
Come affronti i momenti di allineamento con il tuo team che avvengono anche in corso d'opera quando le necessità cambiano?
#ux #ui #design #dev #startup
Fonti:
Intercom Blog · Basecamp — Shape Up · Spotify Engineering
Creare prodotti digitali è difficile, ancora di più su un SaaS complesso. Quando il team di sviluppo dice che una feature costa troppo effort, la soluzione migliore nasce dal brainstorming condiviso, non dalla tecnica perfetta.
Un componente Angular animato per FidoCommercialista, creato con Claude in un solo prompt. Un test concreto su quanto tempo si risparmia davvero nell'hand-off tra design e sviluppo.
