Perimetro e stato della consegna

Ogni schermata è progettata nei tre formati: desktop 1440, tablet 768, mobile 375. Le voci della tabella rimandano direttamente alla sezione corrispondente nel file Figma.

Deliverables concordati ed evidenze

Per ogni attività prevista dal contratto: cosa è stato prodotto e dove verificarlo.

Elementi inclusi oltre alla base

Aggiunti nel corso del lavoro senza costi ulteriori, perché alzano la qualità del risultato e riducono il lavoro in fase di sviluppo.

Perimetro operativo esteso

Il contratto prevedeva l'area proprietari. Sono state progettate anche le aree fornitori e collaboratori, con viste dedicate ai rispettivi ruoli e permessi, così che l'intera operatività passi dallo stesso sistema di interfaccia.

Coerenza totale di stili e token

Ogni testo e ogni colore del materiale consegnato è ricondotto a uno stile o a un token condiviso: nessun valore scritto a mano. In pratica significa due cose in sviluppo: nessuna ambiguità su quale sia il valore giusto, e la possibilità di propagare una modifica globale intervenendo in un punto solo.

Tipografia normalizzata

Le dimensioni fuori scala sono state ricondotte al sistema tipografico, così che la scala usata nel design corrisponda esattamente a quella da implementare.

Nuovi componenti riutilizzabili

Gli elementi che ricorrono sono stati trasformati in componenti con varianti responsive (ad esempio la scheda proprietà nelle tre versioni desktop, tablet e mobile), pronti al riuso invece che ridisegnati caso per caso.

Giornale arrivi/partenze allineato ai requisiti di dettaglio

La sezione è stata rivista sui requisiti funzionali dell'area riservata: tabella sintetica con più stati di arrivo gestiti nella stessa vista (check-in, atteso, no-show), colonne coerenti con il ruolo del proprietario, e scheda di dettaglio a comparsa per i dati estesi della prenotazione.

Reverse engineering approfondito delle email

Oltre ai flussi richiesti, è stata prodotta una mappatura email per email dei 38 flussi transazionali, con oggetto, destinatario, mittente, allegati e contenuto, e con i PDF di esempio reali affiancati. È materiale direttamente utilizzabile da chi implementa le comunicazioni.

Verifica responsive schermata per schermata

Il comportamento ai tre formati è stato verificato singolarmente, non solo impostato: cosa collassa, cosa si riordina e cosa passa a drawer è leggibile confrontando le tre versioni della stessa schermata.

Strumenti AI a corredo

Un plugin con due funzioni (verifica di conformità e consulenza di implementazione) per mantenere la qualità anche dopo il passaggio in sviluppo. Dettagli in fondo a questo documento.

Mappa completa dei materiali

Ogni voce apre direttamente la sezione corrispondente nel file Figma.

Area pubblica e ricerca

Area cliente (post-login)

Pagine di servizio e contenuto

Area proprietari

Area fornitori e collaboratori

Email transazionali

Design system e regole di handoff

Analisi e requisiti

Accesso consigliato: visualizzazione sul file Figma per tutto il team, così commenti e specifiche restano un'unica fonte condivisa.

Prototipo navigabile

Il prototipo ha punti di ingresso dedicati: ognuno apre direttamente il flusso corrispondente, senza doverlo cercare.

Come è organizzato il file Figma

Struttura per pagine

Il file è diviso in una pagina per area: Area cliente (che comprende sito pubblico, ricerca, checkout e tutta la parte post-login), Proprietari, Fornitori, Collaboratori. Le fondamenta del sistema (Fundamentals, Basic components, Complex components, asset statici e regole di handoff) vivono nella pagina Area cliente, come libreria condivisa da tutte le altre.

Sezioni e numerazione

Dentro ogni pagina il lavoro è diviso in sezioni numerate per riga logica: la prima riga copre il percorso pubblico (01 Homepage fino a 10 Checkout), la seconda l'area riservata del cliente (dal 21 Accesso al 28 Dati), la terza le pagine di servizio e i modelli (dal 41 Pagina contenuto al 50 Offerta via email). Le aree operative usano il prefisso del ruolo (PROP, FORN, COLL).

Naming delle schermate

Ogni schermata segue il pattern Codice_versione Nome / Formato, per esempio PROP.09_v1 Giornale A/P / Desktop. Il codice identifica la schermata in modo stabile, il formato dice a quale breakpoint si riferisce. Questo permette di citare una schermata precisa in una conversazione, in un ticket o in un commento senza ambiguità.

I tre formati

Desktop 1440, tablet 768, mobile 375. Le tre versioni della stessa schermata sono affiancate: il confronto diretto mostra cosa collassa, cosa si riordina e cosa cambia comportamento (per esempio un pannello che su desktop è affiancato e su mobile diventa un drawer a comparsa).

Stati e varianti

Dove il comportamento lo richiede, la stessa schermata esiste in più stati di contenuto: vuoto, popolato, in caricamento, in errore. Sono progettati, non lasciati all'interpretazione: la versione vuota di un elenco è una schermata a sé, con il proprio messaggio e la propria azione.

Commenti e annotazioni

I comportamenti non deducibili dal disegno (animazioni, regole condizionali, casi limite) sono annotati con i commenti Figma sulla schermata di riferimento. Sono il canale consigliato anche per le domande in fase di implementazione: restano attaccati al punto esatto a cui si riferiscono.

Design system

La regola di fondo: nel materiale consegnato non esistono valori scritti a mano. Ogni colore e ogni testo proviene da uno stile condiviso, e ogni elemento ricorrente è un componente. Questo va mantenuto in codice, perché è ciò che rende il sistema modificabile in un punto solo.

Tipografia

Un unico carattere per tutto il prodotto: Google Sans Flex. La scala è organizzata in famiglie d'uso, non in dimensioni arbitrarie:

• Display, tre misure per i titoli di maggiore impatto, ciascuna in versione estesa e compatta
• Title, sei livelli (da Primary a Tiny) per la gerarchia dei titoli di sezione e di blocco
• Body, quattro misure (Large, Medium, Default, Small) per il testo corrente
• Label, tre misure per etichette, metadati e testi di supporto
• Button, tre misure per i testi dei controlli

Le varianti "Relaxed" e "Compact" della stessa misura differiscono per interlinea: la prima per la lettura estesa, la seconda per i contesti densi.

Colore

Palette semantica organizzata per famiglie, ciascuna declinata su una scala di intensità da 50 a 950. Il nome della famiglia indica la funzione, non la tinta, così il significato resta stabile anche se il valore cambia.

Unica eccezione voluta: i pulsanti di accesso social mantengono i colori ufficiali di Google, Apple e Facebook, quindi stanno fuori dalla palette per ragioni di riconoscibilità e di linee guida dei rispettivi brand.

Componenti

La libreria copre gli elementi di base (pulsanti, campi, menu a tendina, checkbox, radio, badge, tooltip, tab) e quelli complessi (menu di navigazione, footer, banner, schede struttura e relative sotto-schede, scheda proprietà, stati vuoti). Ogni componente porta con sé le sue varianti e i suoi stati.

Regola pratica per lo sviluppo: usare il componente esistente invece di ricostruirlo. Se una schermata mostra un pulsante, è quel pulsante, con quelle varianti. Le ricostruzioni ad-hoc sono il modo più rapido per far divergere il prodotto dal design nel giro di poche settimane.

Tabelle

Le tabelle di dati (prenotazioni, listino, giornale, documenti) non sono un componente unico: le colonne cambiano per schermata e per ruolo. Sono però costruite con gli stessi token di bordo, spaziatura e testo, quindi restano coerenti pur non condividendo una struttura comune.

Spazi, ombre e focus

Spaziature su scala definita, cinque livelli di ombra e due stili di focus (su fondo chiaro e su fondo scuro) sono definiti nei Fundamentals. Lo stile di focus in particolare non è decorativo: è il requisito di accessibilità che rende il prodotto navigabile da tastiera.

Accessibilità

Il progetto è stato impostato come "accessible by design", con target WCAG 2.2 livello AA. Le scelte sono già incorporate nel design; quello che segue è ciò che va preservato in fase di implementazione.

Cosa è già garantito dal design

• Contrasti verificati sulla palette: le combinazioni testo/sfondo previste rispettano le soglie richieste
• Stili di focus definiti come parte del sistema, non lasciati al default del browser
• Gerarchia dei titoli coerente in ogni schermata, senza salti di livello
• Stati di errore comunicati anche in testo, non affidati al solo colore
• Aree di tocco dimensionate per l'uso su mobile

Cosa dipende dall'implementazione

• Semantica HTML: landmark corretti, un solo H1 per pagina, liste vere, tabelle dati con intestazioni associate
• Ordine del DOM coerente con l'ordine visivo di lettura
• Navigazione da tastiera completa, focus sempre visibile e mai intrappolato, gestione corretta dell'apertura e chiusura dei pannelli modali
• Testi alternativi descrittivi per le immagini informative e vuoti per quelle decorative
• Etichette associate ai campi, non affidate al solo placeholder
• Attributo di lingua corretto sulla pagina e sui blocchi in lingua diversa

Il documento di linee guida allegato traduce ogni criterio in indicazione operativa, criterio per criterio.

Linee guida operative

Documenti scritti in forma azionabile, regola per regola. Oltre a essere una guida per le persone, sono strutturati per poter essere dati direttamente in pasto a un assistente AI, così da automatizzare verifiche e stesura dei testi.

Accessibilità WCAG 2.2 AA — linee guida per lo sviluppo

Ogni criterio tradotto in indicazione pratica, organizzata per area: struttura e semantica HTML, immagini e contenuti non testuali, navigazione da tastiera e gestione del focus, contrasti e colore, form ed errori, dimensioni delle aree interattive. Utilizzabile come checklist di implementazione o come riferimento per far verificare il codice a un agente AI.

Accessibilità — checklist di design

La controparte lato design dello stesso standard, per validare una schermata prima e durante lo sviluppo. Utile anche in futuro, quando verranno progettate schermate nuove non comprese in questa consegna.

Copy delle email transazionali — regole di scrittura

Principi di scrittura, tono di voce e anatomia dell'email (mittente, oggetto, preheader, apertura, messaggio chiave, riepilogo, azione, chiusura), con esempi prima/dopo presi dalle email realmente in uso. Include le convenzioni di mittente e le regole di coerenza tra comunicazioni diverse. Pronta per generare o riscrivere i testi mantenendo un'unica voce.

I documenti sono allegati alla email di consegna.

Agenti AI per il supporto allo sviluppo

A corredo della consegna forniamo un plugin per assistente AI (tipo Claude Code) pensato per mantenere alta la qualità del prodotto dopo il passaggio in sviluppo. Un solo plugin da installare, due funzioni distinte.

Verifica di conformità — /design-check

Si passano due indirizzi: la pagina realizzata (staging o produzione) e il frame Figma corrispondente. L'agente legge il design come riferimento, ispeziona la pagina reale (struttura, stili calcolati, comportamento ai vari formati) e restituisce una tabella a semaforo degli scostamenti, ciascuno con il livello di urgenza e la correzione proposta.

Cosa confronta: spaziature e dimensioni, uso corretto dei token di colore e tipografia, impiego dei componenti del design system al posto di ricostruzioni ad-hoc, struttura e semantica del DOM, accessibilità, elementi SEO di base, e resa dei colori.

Il confine è preciso: l'agente assume il design come corretto e verifica soltanto che il codice vi corrisponda e rispetti gli standard oggettivi. Non commenta né mette in discussione le scelte di design.

Consulenza di implementazione — /design-advice

Risponde alle domande operative del team: "abbiamo questa pagina e dobbiamo aggiungere questa funzione, come la realizziamo restando coerenti?". L'agente parte da ciò che esiste già e indica quale componente usare, in quale variante, quale pattern seguire e dove nel file c'è un caso analogo da cui copiare l'approccio. Copre anche il comportamento atteso ai tre formati e gli impatti sull'accessibilità.

È utile soprattutto per le schermate non comprese in questa consegna: invece di inventare una soluzione nuova, il team ottiene quella coerente con il sistema esistente.

Personalizzazione tecnica (a cura del team di sviluppo)

Il plugin conosce a fondo il design, ma alla consegna non conosce i dettagli tecnici del vostro ambiente: sono informazioni che il design non poteva possedere. Il comando /onboarding, da eseguire una sola volta, serve esattamente a colmare questo divario: raccoglie e salva nel repository lo stack frontend, gli ambienti e il processo di deploy, ciò che il PMS espone o non espone al frontend, le aree legacy e i vincoli che non possono cambiare.

Quelle informazioni diventano poi il perimetro di entrambe le funzioni. Più sono precise, più le risposte sono aderenti a ciò che si può davvero fare: un suggerimento che ignora un limite dell'infrastruttura è un suggerimento inutile. I punti da compilare sono già predisposti nel template, con le domande esplicite.

Requisiti e installazione

Serve un assistente AI (tipo Claude Code) con il collegamento al Figma in modalità sviluppo configurato; per la sola verifica di conformità serve anche il collegamento a un browser, perché l'agente deve poter leggere la pagina reale.

L'installazione avviene aggiungendo il plugin e installandolo dal marketplace locale, poi eseguendo la configurazione iniziale. Le istruzioni puntuali sono nel file di documentazione incluso nel pacchetto.