Studio Dentistico Evergreen
Prodotto digitale end-to-end per uno studio odontoiatrico, dalla prenotazione paziente al gestionale interno.
Ruolo
Product Designer (ricerca, UX/UI, architettura dati, prototipazione)
Anno
2026
Settore
Sanità · Servizi
Strumenti
Figma (con Figma Make per varianti UI rapide), Claude per sintesi ricerca e ideazione, Lovable e Cursor per prototipo funzionante e handoff a codice, GitHub per il versionamento del codice del gestionale, Supabase per lo schema dati, Linear per il tracking delle iterazioni, Maze per i test di usabilità.
Il contesto
Molti studi dentistici, soprattutto quelli di medie dimensioni, gestiscono ancora le prenotazioni via telefono e i dati dei pazienti su fogli sparsi o gestionali datati. Il risultato è un doppio problema: i pazienti, spesso già in ansia, faticano a prenotare, e lo staff perde tempo a coordinare agende e disponibilità. Ho affrontato lo scenario come progetto di prodotto completo, non come sito vetrina, progettando un'esperienza unica per due utenti diversi, il paziente che prenota e lo staff che gestisce lo studio, a partire dagli stessi dati.
Il problema
- Come rendere la prenotazione online abbastanza semplice e rassicurante da convincere anche chi teme il dentista a completarla senza chiamare?
- Come dare allo staff uno strumento che sostituisca agenda cartacea e telefonate, senza richiedere formazione complessa?
- Come strutturare i dati (pazienti, medici, trattamenti, disponibilità) in modo che le due parti del prodotto, sito pubblico e gestionale, restino sempre sincronizzate?
Processo
01
Positioning e tono
Ho costruito il brand "Evergreen" attorno a un'idea precisa, uno studio pensato anche per chi teme il dentista. Da qui il copywriting ("tempi distesi, ogni passaggio spiegato prima di farlo"), la palette chiara e naturale, e dettagli come la sezione dedicata alla sedazione cosciente e i preventivi scritti in anticipo, pensati per ridurre l'ansia da incertezza.
02
Mappatura dei flussi
Ho distinto due percorsi con bisogni opposti: il paziente, che cerca velocità e rassicurazione (prenotare in meno di due minuti, capire subito costi e tempi), e lo staff, che cerca controllo e visione d'insieme (agenda per medico, stato dei pazienti, disponibilità). Ne è nato un flusso di prenotazione a 3 step (trattamento, medico, data/orario) sul lato pubblico, e una dashboard separata dietro autenticazione per lo staff.
03
Architettura dati
Prima di disegnare le schermate ho definito la struttura dati che sostiene entrambi i lati del prodotto. Questa struttura permette agli slot mostrati nella pagina di prenotazione di riflettere la disponibilità reale di ogni medico, ed è la stessa base dati che alimenta la dashboard dello staff, un solo sistema con due interfacce.
- pazienti, anagrafica e note
- medici, profilo, specializzazione, foto
- trattamenti, nome, durata, prezzo di partenza, categoria
- appuntamenti, collega paziente, medico, trattamento, data/ora e stato
- disponibilita_medici, fasce orarie ricorrenti per medico
- indisponibilita, eccezioni puntuali (ferie, permessi)
04
UI e prototipazione
Ho progettato l'interfaccia pubblica con un impianto editoriale (foto reali dello studio e del team, testimonianze, sezione prima/dopo) per costruire fiducia prima della prenotazione. Ho tenuto il flusso di booking essenziale, con riepilogo sempre visibile e possibilità di annullare o spostare gratuitamente fino a 24 ore prima, un dettaglio pensato per abbassare la soglia d'ansia di chi prenota.
05
Gestionale, notifiche e PWA
Ho progettato il prodotto come piattaforma SaaS completa, non solo come sito: un gestionale per lo staff (agenda per medico, stato dei pazienti, disponibilità), conferme e promemoria automatici via SMS ed email, e un'app installabile (PWA) sia lato paziente, per gestire prenotazioni da smartphone, sia lato staff, per consultare l'agenda da tablet in studio.
Decisioni chiave
Prenotazione in 3 step invece di un unico form lungo
Riduce il carico cognitivo e dà un senso di progresso, importante per utenti ansiosi.
Dashboard staff separata invece di un pannello admin generico
I bisogni di chi gestisce l'agenda sono diversi da quelli del paziente: serve vista calendario, non un form.
Disponibilità dei medici come dato strutturato, non testo libero
Permette di calcolare automaticamente gli slot liberi, evitando doppie prenotazioni.
Copy orientato alla rassicurazione ("nessuna sorpresa in fattura", "puoi fermarti quando vuoi")
Coerente col positioning: il prodotto doveva sembrare meno ansiogeno, non solo esserlo tecnicamente.
Stato del progetto
Il concept pubblico (home, servizi, prenotazione, contatti) è live. Dashboard gestionale, collegamento degli slot al database reale e notifiche automatiche sono le estensioni naturali, già mappate nell'architettura dati.
Cosa dimostra questo progetto
Il progetto dimostra un ragionamento di prodotto end-to-end: due utenti con bisogni diversi, una struttura dati che li sostiene entrambi, e scelte UX motivate da un insight specifico (l'ansia da dentista) invece che da convenzioni di settore.