La velocità nasce da ciò che togli,non da ciò che affretti.
filosofia di design_
Il mio modo di lavorare ha un solo obiettivo: il minor numero di passaggi tra un problema e una decisione. Faccio schizzi prima di prototipare, ricerca prima dei wireframe, scrivo prima di rifinire. Ogni passaggio deve guadagnarsi il suo posto, e ciò che non fa avanzare il prodotto viene tagliato.
Gli strumenti, il ritmo e i principi dietro il mio modo di lavorare
Passa sopra a uno strumento per vedere quando e come lo uso.
Figma · FigJam · Make
DESIGN + SYSTEMSVS Code
FRONT-END + CODEClaude + MCPs
CORE WORKFLOWMaze
RESEARCH + TESTINGNotion
DOCUMENTATIONGit / Vercel
DEPLOY + REVIEWIl resto del mio stack
ritmo dello sprint_
Una settimana nel mio workflow
Non ogni progetto segue questo schema alla lettera, ma il ritmo regge.
Allinearsi & pianificare
Rivedere gli obiettivi dello sprint, rileggere le note di ricerca della settimana precedente, sincronizzarsi con il team. Scrivere un brief approssimativo prima di toccare qualsiasi file di design. Evidenziare i rischi in anticipo, prima che costino uno sprint.
Concept & struttura
Schizzi per l'IA e flussi iniziali. A volte generare un'anteprima HTML per allinearsi con l'engineering prima di aprire Figma. Prima di tutto, il modello di interazione.
Design & lavoro di sistema
Sessioni intensive su Figma. Audit dei token, stati dei componenti, coerenza dei pattern. Se qualcosa non si adatta al sistema, correggo il sistema prima di rilasciare l'eccezione.
Prototipo & validazione
Costruire prototipi interattivi, testare con utenti reali o stakeholder interni. Distribuire su Vercel per revisione asincrona. Nessuna riunione necessaria per ricevere feedback.
Handoff & documentazione
Scrivere la specifica di handoff per i developer. Documentare le decisioni, non solo i risultati. Catturare cosa è cambiato e perché, così il prossimo sprint inizia con contesto, non confusione.
principi_
Come penso al lavoro
Ciò a cui mi affido di default, e ciò su cui non transigo mai.
Definire cosa resta fuori, non solo cosa entra
Un brief di sprint che elenca solo cosa si costruisce invita allo scope creep. Scrivo cosa non tocchiamo esplicitamente in questo ciclo, e perché.
Deploy prima della demo
Un feedback su un file Figma è un feedback su un file Figma. Pubblico una preview live prima di mostrare qualcosa a chiunque, così la reazione riguarda la cosa reale.
Una decisione, un solo posto
Se una decisione esiste solo in un thread Slack o nella memoria di qualcuno, non è mai successa. Ogni decisione viene scritta dove la prossima persona che ci costruirà sopra andrà davvero a guardare.
Asincrono di default, riunioni per eccezione
Le review avvengono su un link pubblicato con commenti scritti. Una riunione dal vivo è riservata a ciò che richiede davvero una conversazione, non a un aggiornamento di stato.
Ogni eccezione viene registrata, non solo sistemata
Quando uno schermo deve rompere il sistema, non è un caso isolato e silenzioso. Diventa un ticket, così il sistema lo assorbe nel ciclo successivo oppure l'eccezione resta visibile.
L'IA si occupa di ricerca e documentazione, mai del design in sé
Claude e gli MCP accelerano la sintesi, gli appunti e le specifiche - la parte fatta di parole, non di pixel. Ogni interfaccia, ogni flow, ogni decisione visiva resta mia, dall'inizio alla fine.
La retro c'è anche quando non si è rotto nulla
Uno sprint pulito si merita comunque quindici minuti su cosa farei diversamente. I post-mortem non sono solo per gli incendi.