Siamo onesti: MCP, CLI e i grandi modelli linguistici sono spettacolari per macinare codice, token o riordinare dati. Ma quando si tratta di capire il contesto di un wireframe o rispettare il design system e usare i componenti in nuove creazioni di un prodotto complesso, l'autonomia dell'AI crolla.
Inoltre far funzionare davvero questi strumenti richiede una mentalità da "smanettoni". È un paradosso non da poco per un designer, che si ritrova a bruciare intere giornate o si sente frustrato (i feel you, me lo avete detto in tanti) cercando di capire come interagire con questi meccanismi invece di fare quello per cui è pagato… progettare.
Per questo, nell'utilissimo bot Discord sviluppato da Filippo Primieri, Founder di FidoCommercialista, ho codificato un processo che trasforma l'AI da "generatore di sogni infranti" a un assistente progettuale rigoroso.
Lo scopo è stato creare qualcosa che avesse un rapporto tra rapidità di esecuzione e di beneficio molto alto! Con un'avvertenza. Ovviamente più il perimetro è ridotto, con più precisione riesce ad agire (fare una proposta e analisi di un componente è diversa rispetto a farla di 5 pagine). Ora riparmio circa il 70% di lettura dei requisiti e valutazione delle discrepanze.
Un piccolo esempio di qualche proposta su componenti specifici:
Se incolli da qui in poi tutto questo articolo dentro il tuo Cursor, scegli “Plan” in basso a sinistra e potrai ricrearlo senza problemi.
È importante chiedere di fare il più possibile tutto in autonomia e di guidarti in max piccoli 5 step alla volta per inserire i pochi dati richiesti.
💡 Nota sulla sostenibilità (ovvero: come non farsi prosciugare dai token)
Costruire un sistema così non deve essere un lusso. Potete usare:
Per i testi, io consiglio di passare dalle API di:
Per le immagini basta un modello base "light" per mantenere i costi bassissimi.
Unica regola d'oro: bisogna saper risparmiare. Progettate il bot in modo che sia asciutto; cadere nella trappola del "risucchio di token" con prompt infiniti o inutili è un attimo, e la sostenibilità del processo deve essere sempre la priorità.
Lo scopo è creare un bot che possa analizzare con funzioni read i vari file (magari sfruttando la tecnologia NanoClaw) e rispondere tramite testo e generazione immagini. Niente di super complesso.
Di seguito sono definite le linee guida che andranno salvate in una memoria persistente, che sarà articolata su più livelli, inclusi lo storico della chat e i dati dell'ultima settimana.
All'interno del sistema verranno archiviate le preferenze specifiche sia dei singoli utenti che dei team; pertanto, ogni componente dovrà presentarsi e delineare le proprie necessità per l'addestramento personalizzato del proprio bot.
L'AI non deve mai iniziare a lavorare nel vuoto. All'apertura di ogni task, il mio assistente mi pone 4 domande bloccanti:
Io scrivo “nuovo progetto” e si parte!
L'errore più comune? Il Lorem Ipsum.
Il mio bot ha l'ordine tassativo di usare solo dati veri da Notion (che in questo caso è l’oracolo) in modo anche da valutare realisticamente come viene visualizzata un’interfaccia durante l’uso.
Cosa più importante...se un requisito manca, mi segnala la lacuna per il CTO.
Non accetto mai un'unica soluzione.
L'AI genera sempre almeno 3 proposte (Cosa + Perché + Pro/Contro).
Il vero valore aggiunto? Il Labeling.
Ogni componente nel mockup ha una label che indica esattamente a quale componente dello Storybook corrisponde (es. Atoms/Tooltip).
Il risultato: Un confronto immediato tra layout "Prima" e "Proposte", con una tabella comparativa che evidenzia la scelta consigliata.
Mando al team in tempo reale, spiego ed emergono subito eventuali punti critici, limiti tecnici, di tempo o lacune.
Questo prima che io abbia toccato Figma (lo faccio da telefono magari mentre cammino e ragiono, mi aiuta a pensare).
Per rendere la collaborazione fluida con i team, da sempre ho integrato un codice colore per i post-it su Figma.
Ora il bot analizza in tempo reale:
Per mantenere il controllo totale, il protocollo prevede regole ferree di comunicazione:
L'AI non sostituirà il designer che sa pensare, ma sta già sostituendo il designer che esegue senza un metodo.
Questo processo non è solo una lista di comandi: è un modo per garantire che ogni decisione di design sia ancorata ai dati, documentata e scalabile, eliminando i rischi di discrepanze tra la documentazione tecnica e l’output.
Attualmente come stai addestrando la tua AI a rispettare i design system? Sono genuinamente curiosa perché ogni volta parlando con la community scopro cose interessantissime e che mi arrichiscono.
#ai #design #startup
L’accessibilità digitale non è una checklist. È una scelta progettuale.Un articolo che va oltre il livello più superficiale del tema. Non solo WCAG o compliance, ma progettazione reale: test con utenti, uso consapevole delle tecnologie assistive, tipografia, design system.
