Come possiamo trasformare i bisogni degli utenti in parametri AI concreti? Esploreremo come abbiamo tradotto gli insight di ricerca di un progetto sanitario, affrontando sfide, soluzioni e il ruolo del design nel collegare gli utenti all’innovazione AI.
La crescita dell’intelligenza artificiale nel design è al tempo stesso entusiasmante e travolgente. Da un lato sblocca possibilità un tempo impensabili — automatizzare compiti complessi, analizzare enormi set di dati e persino adattare dinamicamente le interfacce. Dall’altro costringe noi designer a ripensare tutto ciò che sappiamo su come le persone interagiscono con la tecnologia.
I principi tradizionali del design, che spesso si concentrano su estetica, usabilità e funzionalità, vengono ridefiniti per includere le complessità del lavorare con l’AI — sia come strumento sia come componente centrale dell’esperienza utente.
Progettare per l’AI richiede un cambio di mentalità. I designer devono ora muoversi in territori inesplorati, come creare esperienze utente per sistemi guidati da algoritmi e processi decisionali probabilistici. Devono farsi avanti per colmare questo divario, assicurandosi che l’AI funzioni in modo efficace e sia allineata a obiettivi, valori ed aspettative umane.
In questo articolo spiegherò come abbiamo trasformato gli insight della ricerca in parametri AI, evidenzierò le lezioni apprese nel bilanciare tecnologia e design human-centered e spiegherò perché è fondamentale “sporcarsi le mani” con l’AI quando si costruiscono strumenti di questo tipo.
Ti è mai capitato di ricevere una prescrizione medica e faticare a capire il trattamento da seguire? O forse, dopo una visita medica, hai trovato difficile ricordare le raccomandazioni per i passi successivi? Una documentazione medica chiara e precisa garantisce che i pazienti ricevano la giusta cura e le corrette indicazioni.
Perché ciò avvenga, i medici devono seguire linee guida specifiche nella redazione dei referti per offrire un’esperienza e un servizio migliori. Questo assicura che le informazioni mediche siano strutturate, accessibili e facilmente interpretabili da pazienti e professionisti sanitari. Tuttavia, valutare la qualità e l’usabilità dei referti rimane un processo critico ma inefficiente in sanità, che spesso si basa fortemente sul lavoro umano.
Insieme a ReportAId, un’azienda dedicata a trasformare i referti medici tramite soluzioni basate su AI per rendere l’assistenza sanitaria più organizzata, personalizzata e accessibile, abbiamo progettato una nuova funzionalità di compliance per automatizzare gli aspetti più ripetitivi e dispendiosi del flusso di valutazione.
Nel processo attuale, direttori sanitari e responsabili qualità revisionano manualmente i referti, valutando chiarezza, corretto uso degli acronimi e coerenza strutturale. Questo progetto mirava a ridurre il carico cognitivo, aumentare l’obiettività e semplificare le valutazioni, mantenendo alti standard qualitativi e garantendo il rispetto delle stringenti normative mediche.
La fase di discovery è consistita in metodi di ricerca tradizionali per comprendere a fondo il problema e tradurre i risultati in una soluzione basata su AI. Questa fase ha incluso:
Poiché la fase di discovery non è l’obiettivo principale di questo articolo, non approfondiremo ulteriormente il processo. Tuttavia, nell’articolo “Cosa abbiamo imparato dal People + AI Guidebook di Google” esploriamo la metodologia e le linee guida che abbiamo applicato anche per questo progetto.
Una delle parti più affascinanti (e impegnative) di questo progetto è stata capire come trasformare la nostra ricerca in qualcosa che l’AI potesse effettivamente usare. Avevamo tutti questi insight dalla fase di discovery — interviste, analisi di referti, scomposizione dei flussi di lavoro — ma l’AI non pensa come noi. Non “capisce e basta”. Ha bisogno di regole chiare, dati strutturati e istruzioni precise. Quindi, come tradurre qualcosa di sfumato come la valutazione di un referto medico in un formato che l’AI possa interpretare e su cui possa agire?
Ho iniziato osservando come i referti medici venivano valutati. Il processo non era casuale — direttori sanitari e responsabili qualità avevano già criteri che seguivano per valutare i referti. Attraverso le interviste, hanno condiviso le best practice su cui si basavano e gli errori ricorrenti che incontravano.
Il primo passo è stato dare un senso a questi insight. Ho inserito tutto in una tabella dettagliata, definendo:
Questa è stata la base di tutto ciò che è venuto dopo.
Ovviamente, sapere come gli esseri umani valutano i referti non era sufficiente. Dovevo tradurre questa conoscenza in qualcosa che l’AI potesse elaborare. Ciò significava osservare i referti stessi e capire come erano strutturati.
Alcune parti dei referti contenevano campi obbligatori — sezioni che devono essere compilate per soddisfare i requisiti normativi. Questi erano facili da segnalare per la valutazione AI. Se un campo obbligatorio mancava o era incompleto, era chiaramente un problema.
Altre parti erano campi dinamici, cioè comparivano solo in determinate condizioni. Questo rendeva le cose più complicate. Se un paziente era fumatore, ad esempio, il referto doveva contenere una sezione che specificasse cosa fumava, con quale frequenza e per quanto tempo. Se non era fumatore, quella sezione non era richiesta. L’AI doveva capire quando controllare determinati campi e quando ignorarli.
Analizzando i referti passati, potevo individuare delle costanze — quali sezioni erano più soggette a errori, quali campi erano spesso incompleti e dove tendevano a comparire incoerenze. Questo mi ha permesso di creare regole chiare da far seguire all’AI.
Una volta definita la struttura, era il momento di mappare tutto in un insieme di parametri AI. Ogni parametro era collegato a un criterio di valutazione, formando una mappa dei parametri.
Questa mappa dei parametri è diventata la base per testare i prompt AI. Ci ha aiutato a determinare quali aspetti della valutazione dei referti l’AI potesse automatizzare in modo affidabile e quali richiedessero ancora supervisione umana.
Non volevo tuffarmi subito nella progettazione di soluzioni senza capire davvero come l’AI avrebbe interagito con i dati strutturati che avevamo definito. L’ho già visto accadere — designers creano interfacce bellissime per poi rendersi conto che la tecnologia non può supportare ciò che era stato immaginato.
Così, invece di fissarmi troppo presto su una soluzione, ho adottato un approccio pratico. Volevo esplorare i vincoli tecnologici prima di progettare qualsiasi cosa. Questo significava sperimentare direttamente con l’AI, perfezionare l’interpretazione dei dati e individuare limiti e opportunità prima di definire una soluzione finale.
Per testare correttamente come l’AI avrebbe gestito la valutazione dei referti medici, ho creato un custom ChatGPT e le ho dato un compito specifico: agire come analista di referti medici. Doveva valutare i referti in base a quattro criteri chiave:
Per rafforzare il trattamento degli acronimi nei referti medici, ho caricato un PDF contenente un set predefinito di acronimi approvati, a cui l’AI può fare riferimento durante l’analisi dei referti.
Questo processo ha garantito che gli acronimi venissero usati correttamente e in modo coerente. Ha anche aiutato a ridurre gli errori quando l’AI interpretava erroneamente la terminologia medica o segnalava informazioni errate.
Ogni referto necessitava di un punteggio complessivo di conformità determinato aggregando i risultati di ciascun criterio. Il mio obiettivo era vedere quanto accuratamente e in modo strutturato l’AI potesse eseguire queste valutazioni.
Ho usato esempi reali di errori passati come base per perfezionare il modo in cui l’AI identificava problemi nei referti medici. Invece di basarmi su errori teorici, volevo che l’AI imparasse da problemi reali.
Ad esempio, durante il controllo della struttura dei referti, ho scoperto che alcuni medici usavano simboli come trattini (“-”) o punti (“.”) per bypassare i campi obbligatori invece di compilarli correttamente. L’AI doveva riconoscere questi escamotage e segnalarli come non conformi.
Per affrontare questo problema, ho creato prompt dettagliati che spiegavano come ciascuna sezione del referto dovesse essere strutturata. La sfida più grande era garantire che l’AI seguisse una logica coerente. Non potevo semplicemente dirle, “Verifica se il referto include lo storico del fumo”, ad esempio. Era troppo vago. Dovevo specificare esattamente cosa significasse.
Ecco un esempio di segmento di prompt che valuta la struttura, concentrandosi esplicitamente sullo storico di fumo del paziente.
General Anamnesis (Mandatory)
- Subcategory "Smoking" (Optional)
- If present, it must indicate whether the patient is a smoker, non-smoker, or former smoker.
- If the patient is a former smoker, the following details must be specified:
- What they used to smoke (cigarettes, cigars, or pipe)
- The quantity per day
- Until when they smoked
- If the patient is a current smoker, the following details must be specified:
- What they smoke (cigarettes, cigars, or pipe)
- The quantity per day
- How long they have been smoking
Example:
- Former Smoker
- 2-3 cigarettes/day until one year ago.
- Current Smoker
- 5 cigars/day for the past 10 years.Questo livello di dettaglio ha garantito che l’AI comprendesse esattamente quali informazioni doveva estrarre e come formattarle in modo coerente.
Dopo aver finalizzato la struttura dei prompt, ho caricato referti anonimizzati nel custom ChatGPT per i test. L’obiettivo era simulare condizioni reali e vedere quanto bene l’AI si comportasse nell’analizzare referti con strutture diverse e potenziali errori.
Quando ho iniziato a lavorare a questo progetto, non avevo idea di quante rielaborazione sarebbe stato necessario per creare i prompt corretti. Pensavo che l’AI lo avrebbe capito se avessi descritto chiaramente ciò di cui avevo bisogno. Non è stato così.
Invece, mi sono trovata di fronte a risultati incoerenti, formattazioni inattese e output che non erano in linea con ciò che avevo immaginato. L’AI non interpretava correttamente le mie istruzioni.
Quindi, ho dovuto fare un passo indietro e ripensare il mio approccio. Non si trattava solo di scrivere prompt, ma di capire come l’AI elabora le informazioni e adattarmi di conseguenza. Ho continuato a perfezionare i miei prompt attraverso un processo iterativo di test per migliorare accuratezza e coerenza. Questo approccio per tentativi ed errori è stato essenziale per trasformare l’AI in uno strumento in grado di fornire risultati affidabili.
All’inizio non ero abituata a questo livello di testing e di prompt engineering. Non ero abituata a modificare ripetutamente i prompt per vedere cosa funzionasse e cosa no. Per colmare questa lacuna, ho iniziato a confrontarmi con sviluppatori che avevano esperienza nel lavoro con modelli AI. Avevano intuizioni su come questi sistemi elaborano il linguaggio e mi hanno fornito strategie per affinare il mio approccio.
Ho imparato molto lungo il percorso e condivido qui il mio processo, nel caso anche tu stia lottando con le incoerenze generate dall’AI e voglia migliorare i tuoi prompt.
Un’altra grande sfida è stata tenere traccia dei prompt testati. Ho eseguito più volte gli stessi test perché non stavo documentando cosa funzionasse e cosa no.
Per risolvere questo problema, ho mantenuto un registro dettagliato di ogni prompt testato, dell’output esatto dell’AI e del motivo per cui funzionava (o meno). Questo si è rivelato preziosissimo, soprattutto quando si lavorava con gli sviluppatori. Invece di ricominciare da zero, potevano basarsi sui miei test, evitando ripetizioni e migliorando il modello AI in modo più efficiente.
Era un flusso di lavoro nuovo per me, ma ha messo in evidenza come i processi di design debbano evolvere quando si collabora con tecnologie AI. Questo processo di affinamento ha garantito che l’AI non solo rispettasse i requisiti tecnici, ma fornisse anche risultati in linea con le aspettative e le esigenze degli utenti finali.
Quando ho completato i miei test iniziali e ho cominciato ad analizzare i risultati, ho provato un mix di fiducia e incertezza. L’AI mostrava potenzialità, ma non ero del tutto sicura di quanto fossero realistiche alcune ipotesi in merito all’implementazione reale. La fattibilità teorica è una cosa, far funzionare qualcosa in un sistema reale è un’altra.
Ecco perché abbiamo deciso di coinvolgere il team tecnico in un workshop. L’obiettivo era semplice: perfezionare tutto ciò che avevo appreso dai test con il contributo di chi conosceva a fondo i vincoli tecnici. Volevo convalidare quali parametri fossero realizzabili, quali avessero bisogno di ulteriore affinamento e quali fossero solo desideri irrealistici.
Durante la sessione, ho presentato i miei risultati — come l’AI stava interpretando i dati, dove incontrava difficoltà e cosa sembrava funzionare bene. Abbiamo esaminato i parametri uno per uno e li abbiamo classificati. Abbiamo suddiviso i parametri di valutazione in tre gruppi:
È diventato subito evidente che alcune cose erano molto più gestibili per l’AI rispetto ad altre. Discutendo con il team, ho individuato dove l’AI potesse essere più potente e offrire il massimo valore agli utenti, anche in una versione MVP (Minimum Viable Product). Questo era fondamentale, perché non tutto doveva essere perfetto subito — alcune funzionalità potevano essere affinate col tempo, mentre altre dovevano essere impeccabili fin dall’inizio.
Il principale risultato del workshop è stato rilevare differenze evidenti di fattibilità tra i parametri. Ad esempio:
Questo workshop ha aiutato ad allineare le aspettative con la realtà. Abbiamo identificato dove l’AI potesse avere il massimo impatto, dove fosse necessaria la supervisione umana e cosa non valesse la pena perseguire — almeno per il momento. Ha rafforzato una verità importante:
Il design dell’AI non riguarda solo ciò che è teoricamente possibile. Riguarda ciò che è pratico, funzionale e può essere implementato per portare benefici agli utenti.
Ed è una lezione che porterò con me in ogni progetto guidato dall’intelligenza artificiale a cui lavorerò in futuro.
Lavorare a questo progetto mi ha fatto capire che progettare per l’AI non riguarda solo le interfacce — significa modellare il modo in cui l’AI interagisce con le persone. A differenza del design tradizionale, dove tutto è predefinito, i prodotti guidati dall’AI evolvono, imparano e talvolta si comportano in modo imprevedibile. Ciò significa che non potevo semplicemente dare per scontato che le cose avrebbero funzionato. Dovevo testare, affinare e mettere in discussione le ipotesi per assicurarmi che la tecnologia fosse allineata alle reali esigenze degli utenti.
Ho sempre creduto che un ottimo design nasca dalla comprensione diretta del problema. Con l’AI, ciò significa andare oltre la superficie e capire veramente come funziona la tecnologia. Non si tratta di diventare sviluppatori o data scientist, ma di garantire che l’AI sia allineata alle reali esigenze degli utenti e non serva solo a mostrare le sue capacità tecniche. Ecco perché coinvolgere team multidisciplinari è essenziale — riunire designer, sviluppatori e specialisti AI per colmare il divario tra esperienza utente e capacità dell’AI.
Una delle sfide più grandi è mantenere il design centrato sull’utente piuttosto che guidato dalla tecnologia. L’AI è potente, ed è facile lasciarsi tentare dal concentrarsi su ciò che può fare invece di ciò che dovrebbe fare.
Non lo nego — questo processo è stato una curva di apprendimento ripida. Mi ha richiesto di accettare l’incertezza, collaborare con diversi team e ripensare il mio approccio al design. Ma attraverso tutto questo, ho capito una cosa importante:
Quando i designer si impegnano attivamente con l’AI, non si limitano ad adattarsi alla nuova tecnologia — la cambiano.
Questo è ciò che mi entusiasma di più del lavorare con l’AI. Abbiamo il potere di definire come questi sistemi interagiscono con le persone. Se ci facciamo da parte e lasciamo tutto agli ingegneri, rischiamo di creare strumenti tecnicamente impressionanti ma scollegati dai bisogni umani.
Ma se ci inseriamo nel discorso — se sperimentiamo, mettiamo in discussione le ipotesi e perfezioniamo l’AI con intenzionalità — possiamo assicurarci che la tecnologia serva le persone, e non il contrario.
Ed è una sfida che vale la pena affrontare.
Livia is a designer at Buildo, with competence in UI, UX, and design systems. Her Brazilian background adds a valuable layer of cultural diversity and perspective to the team. She is driven by her passion for research and collaborating with others to deliver top-quality projects.
Stai cercando un partner affidabile per sviluppare la tua soluzione software su misura? Ci piacerebbe sapere di più sul tuo progetto.
