UX engineering e prototipazione AI-driven: un workflow ibrido.

Contesto e ruolo

Nel corso di un recente progetto realizzato in Tangible ho lavorato su un software utilizzato in ambito ospedaliero, adottato in diverse strutture sanitarie italiane. Il progetto si è sviluppato nell’arco di circa tre mesi ed è stato per me particolarmente significativo per il ruolo centrale di UX engineer a cavallo tra design e supporto allo sviluppo.

Dalla ricerca al processo progettuale

All’interno del progetto ho seguito direttamente tutte le fasi: dal kickoff alle interviste con stakeholder e utenti, passando per la definizione di flussi e interazioni, fino all’impostazione del design system e all’integrazione di approcci AI di generative UI e vibe coding all’interno del processo progettuale. Il lavoro è stato svolto in collaborazione con altri due designer del team con una chiara suddivisione dei ruoli, ma anche con un confronto costante sulle scelte progettuali.

Uno degli obiettivi interni del progetto era anche quello di mettere a frutto il lavoro di esplorazione e ricerca svolto nei mesi precedenti all’interno del team di R&D aziendale. In quel contesto erano stati analizzati e testati nei mesi diversi approcci legati ad AI, design system, prototipazione e vibe coding. Questo progetto ha rappresentato l’occasione ideale per applicare in modo concreto e controllato quelle sperimentazioni all’interno di un flusso di lavoro reale, arrivando a un deliverable solido e coerente con le esigenze del contesto.

Prototipare per contesti critici e ad alta complessità

Il risultato finale è stato un prototipo ad alto livello di dettaglio, realizzato con dati mock, stati e interazioni che riflettevano in modo fedele il dominio applicativo e le reali intenzioni degli utenti finali. Il prototipo ha coperto sia l’esperienza desktop sia una versione mobile pensata per dispositivi palmari, utilizzati quotidianamente da infermieri e operatori sanitari per attività operative e che ha richiesto un’attenzione particolare, trattandosi di un software leggero utilizzato in contesti critici e spesso in mobilità.

Design system e handoff

In parallelo al lavoro di UX e interaction design, lo UI designer del team ha curato la definizione del design system: il lavoro è partito dalla definizione delle primitives (tipografia, colori, spaziature ecc.) formalizzate poi nei design tokens su cui è stata costruita la component library finale. Questo ha facilitato l’handoff sia internamente, supportando la prototipazione con AI, sia verso l’esterno, permettendo in futuro al team IT di sviluppare l’applicativo in modo più allineato e consapevole.

Ridurre il divario tra design e prototipo

Uno dei temi centrali emersi durante il lavoro è stato quello della coerenza tra design e prototipo, ovvero il divario che spesso si crea tra ciò che viene progettato in Figma e ciò che viene effettivamente rappresentato nei prototipi interattivi. In questo caso la sfida era amplificata dal fatto che nella versione attuale di Lovable al momento in cui è stato scritto questo post, è consentita una sola importazione iniziale del design da Figma tramite il plugin Builder.io, rendendo più complessa la gestione delle iterazioni successive.

Un flusso ibrido tra design, codice e AI

Per aggirare questo limite, è stato adottato un approccio ibrido che ha coinvolto Lovable e Cursor. Il punto di svolta è stato l’utilizzo del MCP (Model Context Protocol) di Figma, che ha permesso di passare a Cursor il link diretto di singoli componenti, frame o intere pagine di Figma e di generare di componenti React a partire dal design, includendo proprietà, variabili e stati.

A partire da questi componenti è stato costruito un design system locale direttamente nel codice, che ha poi costituito la base per la generazione delle schermate complete in modo estremamente fedele al design originale.

Il codice è stato versionato su un repository GitHub, collegato a Lovable. Ogni commit effettuato su GitHub veniva automaticamente importato da Lovable all’interno del prototipo, permettendo di mantenere un allineamento costante tra design, codice e risultato finale. Questo flusso ha reso possibile una corrispondenza quasi one-to-one tra il design in Figma e il prototipo visibile, riducendo drasticamente ambiguità e interpretazioni errate.

In questo senso il lavoro di design non si è limitato a immaginare il prodotto futuro, ma ne ha costruito una prima versione, attraverso un approccio ibrido che ha combinato progettazione, generazione UI con AI agentica e vibe coding.

UX e UI nell’era dell’AI: riflessioni sul ruolo

Dal punto di vista UX e UI, questo approccio ha fatto emergere alcune riflessioni importanti. La prima è che l’uso corretto di auto layout, griglie e componenti in Figma non è solo una buona pratica di UI design, ma diventa un prerequisito fondamentale quando si lavora con l’AI. Se il design è strutturato male, l’AI amplifica i problemi e le iterazioni; viceversa, l’AI accelera il processo in modo significativo.

È emerso anche che, in questo contesto, chi si occupa di UX dovrebbe iniziare a progettare in modo sistemico e modulare, ragionando già in termini di componenti, varianti e proprietà.

Questo significa ingegnerizzare i file Figma anche in fase di UX, adottando le stesse logiche strutturali tipicamente associate al lavoro di UI design, e non delegando questa responsabilità esclusivamente allo UI designer. Questo perché, con la generazione di interfacce supportata da AI e vibe coding, il ritmo di produzione può superare rapidamente quello del lavoro UI tradizionale, creando disallineamenti nel processo.

Per evitare che la UI diventasse un collo di bottiglia, è stato necessario quindi utilizzare componenti definiti in fase di UX, progettati in modo sistemico, applicando progressivamente i design tokens e gli stili del design system in costruzione. Questo ha reso evidente l’importanza di un lavoro UX ingegnerizzato in Figma già dalle prime fasi.

Gestire il livello di dettaglio nel processo di design

Il progetto ha fatto emergere una considerazione critica: il rischio di portare un livello di dettaglio molto elevato nelle fasi iniziali del progetto. Un prototipo molto rifinito può essere estremamente utile per spiegare interazioni complesse ai developer e allineare i team, ma può anche portare stakeholder e clienti a concentrarsi su dettagli marginali, perdendo di vista i principi di progettazione, i flussi principali e le decisioni strategiche.

Ne emerge un contrasto interessante: da un lato la prototipazione ad alto dettaglio come strumento potente di comunicazione e allineamento; dall’altro, la necessità di scegliere con attenzione quando e per chi quel livello di dettaglio è realmente utile.

Oltre alla sperimentazione dei singoli tool (che sono importantissimi), questo lavoro è stato soprattutto un approfondimento sul processo. Un tentativo di capire come integrare in modo coerente strumenti come Figma, Lovable, Cursor, GitHub e l’AI all’interno di un flusso di progettazione e prototipazione che rimanesse controllabile, ripetibile e orientato alla qualità dell’esperienza finale.