# email-design.md: un brief del brand per l’agente email

URL canonico: https://brew.new/it/blog/email-design-md
Autore: Thomas Park
Pubblicato: 2026-06-15
Aggiornato: 2026-09-28

Un codice esadecimale dice a un agente email quale blu usare. Non gli dice perché un brand mette una piccola etichetta in carattere monospaziato sopra ogni titolo, né perché i suoi separatori sono linee sottili invece che riquadri.

Era questo il problema del nostro primo modello del brand in Brew. Raccoglievamo molti valori, eppure perdevamo i dettagli che rendevano riconoscibile un brand.

## L’oggetto aveva un campo per quasi tutto

All’inizio, un brand ci sembrava un insieme di dati strutturati. Modellavamo colori, tipografia, asset e un’ampia raccolta di proprietà di stile. Un crawler compilava i campi, poi il processo di generazione li assemblava nel contesto per l’agente email.

Il risultato poteva avere il colore e il font giusti e sembrare comunque generico. Ogni nuovo brand portava un dettaglio che lo schema non aveva previsto. Potevamo continuare ad aggiungere campi, ma la domanda più utile era un’altra: come spiegherebbe un designer lo stesso brand a un’altra persona?

Un designer scriverebbe una guida: valori esatti dove contano, esempi dove aiutano e, tra gli uni e gli altri, un testo che spiega le decisioni.

Così abbiamo cambiato ciò che chiedevamo di produrre all’agente di estrazione.

## Il documento è il brief

Lo chiamiamo `email-design.md`. È un documento Markdown modificabile che descrive come deve apparire un determinato brand nelle email.

Ecco un esempio inventato e abbreviato:

```markdown
# Acme email design

## Voice

Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.

## Signature details

- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.

## Assets

Use the approved logo URL from the asset list.
Do not invent product images or customer logos.
```

Il documento può contenere una regola come “usa il colore d’accento per un solo elemento in ogni email” accanto al valore esatto del colore. Così l’agente ha un’istruzione anche per i casi che non avevamo previsto uno per uno.

![Brew che mostra un email-design.md modificabile accanto alla conversazione sul brand.](/blog/email-design-md-editor.png)

*Le istruzioni del brand sono visibili. Una correzione entra a far parte del brief successivo.*

Qui il Markdown è utile perché le persone possono leggerlo e modificarlo senza un modulo apposito. I titoli danno struttura al documento, e aggiungere una nuova regola di design non richiede un nuovo campo nel database. È una scelta di formato pratica. Non sosteniamo che il Markdown usi sempre meno token del JSON, né che ogni modello sia stato addestrato soprattutto sul Markdown.

## Le email hanno bisogno di istruzioni di design proprie

Un sito web e un’email hanno vincoli di rendering diversi. Il supporto per font, layout e modalità scura varia da un client di posta all’altro. Un design che sembra corretto nell’anteprima del browser va comunque testato in inbox.

Per questo il documento del brand include indicazioni specifiche per le email: font di riserva, larghezze dei contenitori, schemi di layout adatti alle tabelle e scelte per sfondi chiari e scuri. Queste istruzioni aiutano l’agente a prendere decisioni appropriate, ma non garantiscono un rendering identico in ogni client.

Le immagini hanno requisiti diversi, quindi Brew usa anche `image-style.md` per le indicazioni sulle immagini. Tenere esplicitamente separati i due ambiti è più semplice che chiedere a un’unica lista di token di descrivere ogni mezzo.

## Parti dal materiale di cui ti fidi già

Il sito pubblicato è una prova utile, ma non sempre è la fonte di riferimento. Potrebbe contenere una vecchia campagna o un esperimento di stile che il team del brand non usa più.

Oltre al dominio, Brew può usare le linee guida del brand, i loghi, le immagini e altro materiale di riferimento che fornisci. Quando sono in disaccordo, le linee guida caricate hanno la priorità su quanto Brew deduce dal sito web. Rivedi il documento che ne risulta, soprattutto dove il materiale di partenza è incompleto o incoerente.

![Il modulo di configurazione del brand, con un campo per il sito web e uno spazio per i file di supporto.](/blog/email-design-md-ingest.png)

*Un dominio e i file approvati forniscono al processo di estrazione prove di tipo diverso.*

Se la forma dei pulsanti è sbagliata, cambia l’istruzione. Se il tono di voce è troppo formale, sostituisci l’aggettivo vago con una frase di esempio. Una correzione così è molto più facile da discutere di un grande oggetto pieno di campi che nessuno vuole modificare.

## Cosa dimostra il cambiamento, e cosa no

Il documento inserisce direttamente nel contesto di generazione la posizione degli asset approvati, i nomi dei prodotti e le decisioni di design. Questo riduce le lacune che altrimenti il modello dovrebbe colmare tirando a indovinare. Non elimina gli output errati.

Durante questo lavoro abbiamo cambiato anche altre parti dell’agente email. Senza un confronto controllato, non attribuirei un miglioramento complessivo della qualità al solo formato del file. L’affermazione che posso fare è più circoscritta: il brief del brand è più facile da esaminare, correggere e riutilizzare.

Un’email generata ha comunque bisogno di una revisione dei fatti e della grafica. Confronta le affermazioni con il brief, testa i link e controlla il risultato in inbox. La [guida al brief per le email](/it/blog/how-to-brief-an-email-agent) spiega questo passaggio di consegne.

## Lo stesso contesto è disponibile per gli agenti collegati

Il [server MCP](/it/mcp) di Brew è ora disponibile. Un assistente compatibile può lavorare con Brew tramite gli strumenti documentati, usando lo stesso contesto del brand dell’app. L’[annuncio di MCP](/it/blog/brew-mcp) e la [documentazione di configurazione](https://docs.brew.new/api-reference/mcp/overview) spiegano come funziona il collegamento.

Mi piace che le istruzioni del brand abbiano un posto ovvio in cui stare. Quando un’email non ci convince, possiamo indicare una frase, cambiarla e riprovare. È una conversazione più utile che chiedere al modello, per l’ennesima volta, di “renderla più in linea con il brand”.
