Prompt AI per web designer
9 prompt pronti per i lavori che rubano tempo a chi fa web design: brief del cliente, sitemap, microcopy UX, accessibilità, handoff. Con la tecnica dietro ognuno.
A chi serve questa raccolta
Progetto siti dal 2007, e la parte che ruba davvero le serate non è disegnare: è il contorno. Scrivere il brief partendo dagli appunti di una call, riempire i mockup di testo che non sia lorem ipsum, descrivere allo sviluppatore tutti gli stati di un componente, rispondere al cliente che “non è quello che immaginavo”. Su questo l’AI non sostituisce il giudizio progettuale, ma ti dà una prima bozza ordinata in pochi minuti.
Qui trovi 9 prompt per i lavori che a un web designer mangiano più tempo del previsto. Per ciascuno: cosa fa, il prompt da copiare (sostituisci le parti tra parentesi), la tecnica che lo rende efficace e una nota sui limiti. Se non hai ancora un abbonamento, la maggior parte funziona bene anche con le versioni gratuite degli assistenti AI.
Due regole prima di partire. L’AI sbaglia: contrasti, codice, nozioni di accessibilità vanno verificati con strumenti veri, non sulla sua parola. E non incollare mai materiale riservato del cliente nei prompt: credenziali, contenuti sotto NDA, dati personali degli utenti. Si lavora su descrizioni e segnaposto, non su dati reali.
Impostare il progetto
1. Trasformare gli appunti del cliente in un brief
Cosa fa: prende gli appunti sparsi di un primo incontro e li ordina in un brief di progetto.
Sei un web designer senior. Trasforma questi appunti di un primo incontro col cliente
in un brief di progetto strutturato. Sezioni: obiettivo del sito e azione principale
che deve far compiere all'utente, pubblico, pagine necessarie, tono visivo desiderato,
contenuti già disponibili e cosa manca, vincoli (budget, tempi, tecnici), criteri con
cui il cliente dirà "è andato bene". Dove un'informazione manca, scrivi "DA CHIARIRE"
invece di inventarla. Appunti: [incolla]
La tecnica: il marcatore “DA CHIARIRE” invece di inventare ti restituisce anche la lista delle domande aperte da fare al cliente, non un brief finto-completo.
Nota: il brief è la base del preventivo: rileggilo col cliente prima di stimare tempi e costi.
2. Proporre la sitemap e la struttura delle pagine
Cosa fa: disegna l’alberatura del sito e la sequenza di sezioni delle pagine chiave.
Per un sito di [tipo di attività] con obiettivo [es. ricevere richieste di preventivo],
proponi: 1) la sitemap (pagine e sottopagine in struttura ad albero); 2) per le 3 pagine
più importanti, la sequenza di sezioni dall'alto verso il basso, con lo scopo di ognuna.
Ragiona su cosa cerca l'utente, non su cosa l'azienda vuole dire. Niente pagine inutili.
La tecnica: il vincolo “cosa cerca l’utente, non cosa l’azienda vuole dire” sposta l’architettura sull’intento e ti dà una struttura che converte, non un organigramma aziendale.
Nota: adattala ai contenuti reali disponibili. Una pagina senza contenuto vero resta una pagina vuota.
3. Tradurre una richiesta vaga in direzioni visive
Cosa fa: trasforma “lo voglio moderno ed elegante” in tre direzioni concrete da mostrare al cliente.
Il cliente descrive lo stile che vuole così: "[parole del cliente]". Settore: [X].
Trasforma questa richiesta vaga in 3 direzioni visive distinte. Per ognuna: nome,
mood in una frase, palette di 4-5 colori con codici HEX, accoppiata tipografica (un
font per i titoli + uno per il testo) e 2 aggettivi guida. Le tre direzioni devono
essere davvero diverse tra loro, non varianti della stessa.
La tecnica: chiedere tre direzioni “davvero diverse” dà al cliente una scelta reale e accorcia i giri di revisione sul “non è quello che immaginavo”.
Nota: i contrasti delle palette vanno verificati (vedi prompt 6): l’AI a volte propone accostamenti che non passano l’accessibilità.
Progettare l’interfaccia
4. Scrivere i microtesti dell’interfaccia
Cosa fa: i microcopy di una schermata: pulsanti, etichette, messaggi di errore e di conferma, stato vuoto.
Sei un UX writer. Per [schermata o funzione, es. form di contatto] scrivi i microtesti:
testo dei pulsanti (azione concreta, non "Invia" generico), label dei campi, testo di
aiuto breve, un messaggio di errore per ogni campo che dica come rimediare, il messaggio
di conferma e lo stato vuoto se previsto. Tono [es. cordiale e diretto], italiano,
poche parole per elemento. Mai "Clicca qui".
La tecnica: chiedere errore, conferma e stato vuoto nello stesso prompt copre i tre momenti che di solito ci si ricorda di scrivere solo a sviluppo iniziato.
Nota: leggi i microtesti dentro il mockup. Fuori contesto suonano sempre diversi.
5. Riempire i mockup con testo realistico
Cosa fa: contenuti plausibili al posto del lorem ipsum, così il cliente valuta il design su testo vero.
Genera contenuti realistici in italiano per il mockup di [tipo di pagina] di [attività].
Per ogni sezione che ti indico scrivi un titolo credibile e un testo della lunghezza
giusta per quello spazio: [elenca le sezioni con la lunghezza, es. "hero: titolo + 1
frase", "3 servizi: titolo + 20 parole l'uno"]. Contenuto plausibile ma chiaramente
fittizio, senza dati o claim veri da verificare.
La tecnica: indicare la lunghezza per sezione evita il problema classico, il testo che non entra nello spazio o ne avanza, e mostra il layout come sarà davvero.
Nota: è testo segnaposto realistico, non i contenuti finali: quelli li scrive il cliente o un copywriter.
6. Costruire una checklist di accessibilità sulla pagina
Cosa fa: una checklist di accessibilità calata sugli elementi reali della pagina, non generica.
Sei un esperto di accessibilità web (WCAG 2.2, livello AA). Per una pagina [tipo] con
questi elementi [elenca: hero con testo su immagine, form, menu a tendina...], dammi una
checklist di controlli specifici per QUESTI elementi: contrasto, navigazione da tastiera,
alternative testuali, focus visibile, dimensioni delle aree tap, ordine di lettura. Per
ogni punto: cosa controllare e l'errore tipico da evitare.
La tecnica: ancorare la checklist agli elementi reali della pagina la rende usabile in revisione, al posto della solita lista WCAG generica che nessuno applica davvero.
Nota: la checklist orienta, ma l’accessibilità si verifica anche provando la pagina da tastiera e con strumenti dedicati. Il riferimento sono le linee guida WCAG del W3C.
Consegna e cliente
7. Scrivere la spec di un componente per lo sviluppatore
Cosa fa: descrive a parole un componente con tutti i suoi stati, così chi sviluppa non deve indovinare.
Scrivi la specifica di handoff per lo sviluppatore di questo componente: [es. card
prodotto / menu mobile]. Includi: scopo, anatomia (gli elementi), tutti gli stati
(default, hover, focus, attivo, disabilitato, caricamento, errore, vuoto), comportamento
responsive ai breakpoint principali e cosa succede con contenuti lunghi o mancanti.
Elenco conciso, niente codice.
La tecnica: elencare esplicitamente tutti gli stati e “contenuti lunghi o mancanti” è ciò che evita i ticket del tipo “e qui cosa si vede?” a sviluppo già avviato.
Nota: è la spec di design, non l’implementazione: concordala con chi scrive il codice.
8. Scrivere gli alt text delle immagini
Cosa fa: le alternative testuali delle immagini, utili per l’accessibilità e per la SEO.
Per queste immagini di un sito di [attività] scrivi l'alt text di ciascuna: descrittivo
e conciso (intorno ai 125 caratteri), che comunichi la funzione dell'immagine nel
contesto, non un elenco di dettagli. Se un'immagine è puramente decorativa, segnalalo
(alt vuoto). Immagini: [descrivile una per una].
La tecnica: distinguere le immagini informative da quelle decorative (alt vuoto) è la parte che cambia l’esperienza di chi usa uno screen reader, e che quasi nessuno cura.
Nota: l’alt si scrive sull’immagine vera, e l’AI non la vede: descrivile tu cosa mostra, altrimenti se la inventa.
9. Presentare la bozza e gestire le revisioni
Cosa fa: l’email per mostrare una bozza al cliente senza alimentare richieste di modifica infinite.
Scrivi un'email al cliente per presentare la prima bozza del sito. Tono professionale e
collaborativo. Struttura: cosa trova nel link, le 2-3 scelte di design che ho fatto e
perché (così le valuta con un criterio, non a gusto), come lasciare un feedback specifico
e per pagina, e che questo è il giro di revisioni previsto. Massimo 150 parole, oggetto
incluso.
La tecnica: spiegare il “perché” delle scelte e chiedere un feedback “specifico e per pagina” sposta la revisione dal “non mi piace” a osservazioni su cui puoi lavorare.
Nota: il numero di revisioni incluse va messo nel preventivo, non scoperto in questa email.
Cosa NON fare mai
- Niente materiale riservato del cliente nei prompt: credenziali, contenuti sotto NDA, dati personali degli utenti del sito.
- Non delegare le decisioni all’AI: gerarchia visiva, scelte di design e accessibilità reale restano tue.
- Verifica contrasti, codice e accessibilità con strumenti veri e provando da tastiera, non sulla parola dell’AI.
Se ti è utile il metodo, abbiamo raccolte simili per altri mestieri, dai prompt per commercialisti ai prompt per insegnanti.
FAQ
Servono solo a chi fa il web designer di professione?
No. Funzionano anche per chi cura un sito senza essere designer di mestiere: imprenditori, freelance, chi gestisce il sito di un’associazione. La logica di base resta la stessa, descrivere bene il contesto e dare vincoli precisi.
Funzionano con Claude e Gemini o solo con ChatGPT?
Funzionano con tutti. La tecnica (assegnare un ruolo, dare vincoli, chiedere un output strutturato) vale su qualsiasi assistente. Cambia la qualità della risposta a seconda del modello: se vuoi capire le differenze, le abbiamo messe a confronto nella guida tra ChatGPT, Claude e Gemini.
L’AI può generarmi direttamente il design o il codice del sito?
Produce bozze di HTML e CSS e abbozzi di layout, ma il design e la qualità del codice vanno riviste a mano: tende a soluzioni generiche e a problemi di accessibilità. Per un sito reale conviene usarla sui passaggi qui sopra, non per “fammi il sito”.
Mi basta la versione gratuita?
Per questi compiti, all’inizio sì. Il piano a pagamento (intorno ai 20€/mese) ha senso con un uso quotidiano intenso o per caricare molti file e immagini di riferimento.
Posso usare i testi generati come contenuti finali del sito del cliente?
Come segnaposto realistici sì (prompt 5). Come contenuti definitivi no, non senza revisione: vanno verificati nei fatti, calati sul cliente e ripuliti dai passaggi che suonano impersonali.
Hai notato un errore o vuoi suggerirci un aggiornamento? Scrivici a opendeskeditori@gmail.com — controlliamo ogni segnalazione.
Specializzato in SEO, marketing, web design, social media, content creation, videomaking e applicazioni di intelligenza artificiale. Vent'anni di esperienza in progettazione digitale.
