Il mio workflow di product design con l’IA, senza Figma

La progettazione del prodotto senza Figma funziona quando un prodotto dispone già di un sistema di progettazione maturo. Il mio flusso di lavoro di progettazione del prodotto AI utilizza tre competenze dell'agente: ui-design esplora nove direzioni, ui-implement trasforma la direzione selezionata nel prodotto e ui-walkthrough esamina ogni stato tramite Agent Browser integrato. Prendo ancora le decisioni; l'agente gestisce la produzione e il controllo ripetitivi.

La maggior parte delle funzionalità del prodotto non iniziano da una pagina vuota. Una volta che un prodotto è in circolazione da un po’, le sue decisioni progettuali di base esistono già nel codice. Sono stati definiti pulsanti, input, schede, navigazione, spaziatura, colori, copia, stati al passaggio del mouse e comportamento mobile. Ricostruire quei pezzi in Figma spesso significa trascinare gli stessi componenti su un'altra tela prima di ricostruirli nuovamente nel prodotto.

Il designer prende ancora le decisioni sul prodotto. L'agente rimuove gran parte dell'assemblaggio e del controllo ripetitivi. Funziona perché Zero dispone già di un sistema di progettazione ragionevolmente maturo.

1. Avviare la progettazione del prodotto senza Figma con un sistema di progettazione

Lavorare senza Figma non significa lavorare senza regole di progettazione. Richiede regole più chiare.

Per Zero, l'agente può controllare:

• Componenti esistenti per pulsanti, input, menu a discesa, schede, finestre di dialogo e navigazione
• Spaziatura, tipografia, colori, bordi e raggi degli angoli stabiliti
• Stati esistenti al passaggio del mouse, selezionato, disabilitato, vuoto e mobile
• Convenzioni di copia come maiuscole e minuscole ed etichette brevi rivolte all'utente
• Veri e propri schermi che mostrano come si combinano questi pezzi

Questi riferimenti rispondono alle domande di progettazione ordinarie. Un nuovo input dovrebbe assomigliare agli input già spediti. Una nuova carta dovrebbe utilizzare la stessa superficie e lo stesso raggio della carta esistente più vicina. Un pulsante icona dovrebbe avere lo stesso feedback al passaggio del mouse degli altri pulsanti icona.

Ciò fornisce all'agente un confine. Può esplorare la struttura di una funzionalità senza inventare un nuovo linguaggio visivo per ogni schermo.

Figma è ancora utile quando un team sta creando un nuovo marchio, un nuovo sistema di componenti o un'interazione che non ha uno stretto riferimento al prodotto. Ma una volta che il sistema è maturo, il prodotto in esecuzione può diventare la principale superficie di progettazione. Questa è la versione in scala delle funzionalità di flusso di lavoro design-as-code che abbiamo utilizzato per ricostruire Zero.

2. Utilizzare ui-design per esplorare nove direzioni di progettazione del prodotto

Ogni caratteristica necessita ancora di essere esplorata. Non voglio che un agente prenda la mia prima frase e la trasformi immediatamente in codice.

Inizio con ui-design. Fornisco all'agente la schermata corrente, il problema dell'utente, l'obiettivo e i vincoli principali. L'agente legge i modelli di prodotto esistenti e restituisce una direzione consigliata più nove alternative.

In parole povere, l’abilità cattura la schermata corrente, crea una direzione consigliata, esplora nove alternative distinte, presenta i compromessi e attende una scelta umana.

Il pensiero progettuale contenuto in queste istruzioni

Questa istruzione non è solo un elenco di regole visive. Trasforma il normale processo di un progettista in una sequenza ripetibile:

1. Comprendere prima di proporre. Cattura la schermata corrente e leggi il prodotto circostante prima di fare qualsiasi cosa.
2. Pensa per sistemi. Considera i componenti esistenti, le pagine dei modelli, i modelli di interazione e le regole di copia come materiale di partenza.
3. Prevenire la reinvenzione. L'intelligenza artificiale tende a creare un nuovo modello quando la richiesta è vaga. L'istruzione gli dice di trovare il componente o la pagina spedita più vicina e di riutilizzarla invece di approssimarla dalla memoria.
4. Esplora prima di scegliere. L'ancora Dopo fornisce una direzione plausibile. Le nove varianti aprono diverse decisioni su layout, gerarchia, densità, punto di ingresso e divulgazione.
5. Esplorazione separata dall'impegno. L'agente si ferma dopo aver presentato le opzioni. Un essere umano confronta i compromessi e sceglie prima che inizi il codice.
6. Rivedi l'intera esperienza. Copia, feedback al passaggio del mouse, stati, comportamento mobile e coerenza visiva fanno parte della progettazione, non della pulizia dopo l'implementazione.

Questo è il pensiero sistemico che desidero dalla mia abilità: comprendere il prodotto esistente, esplorarlo e quindi fare una scelta esplicita.

Ecco le istruzioni originali complete, riprodotte alla lettera dal flusso di lavoro live:

Istruzioni originali complete di ui-design

# vm0/Zero Regole di progettazione dell'interfaccia utente

## Flusso di lavoro: prima le immagini, poi il codice

**Non passare al codice.** Quando viene richiamata questa abilità, il primo risultato finale è sempre una serie di modelli renderizzati che Ming può guardare. L'implementazione avviene solo dopo che è stata scelta una direzione.

### Passaggio 1: Cattura il "prima"

- Se una schermata esiste già, esegui il rendering del suo stato corrente come immagine **prima** (esegui uno screenshot dell'app in esecuzione o esegui il rendering del componente esistente come anteprima statica).
- Se la richiesta riguarda uno schermo nuovo di zecca, il "prima" è lo schermo esistente più vicino o uno stato vuoto: rendilo esplicito nella didascalia.

### Passaggio 2: produci un singolo ancoraggio "dopo".

- Un mockup che rappresenti la migliore interpretazione della richiesta, rispettando pienamente tutte le regole seguenti (componenti, maiuscole e minuscole della frase, input/elenco a discesa dei dettagli dell'agente, raggi della scheda del compositore di chat, pulsante di aggiunta pianificazione, passaggi del mouse IconButton, superfici grigio-50).
- Abbinalo al **prima** fianco a fianco. Etichettateli chiaramente: `Before` / `After`.

### Passaggio 3: genera 9 esplorazioni di varianti

Dopo la coppia prima/dopo, produci **9 modelli di varianti distinte** per la stessa schermata. Ogni variante dovrebbe esplorare un asse di progettazione significativamente diverso, non 9 modifiche di colore. Coprire uno spread come:

1. Layout: colonna singola o divisa/barra laterale/griglia
2. Densità: compatto vs spazioso
3. Gerarchia: quale elemento guida visivamente
4. Trattamento superficiale: sezioni piatte, raggruppate su schede e divise
5. Punto di ingresso: azione in linea, CTA dedicata e eroe a stato vuoto
6. Copy framing: istruttivo, minimale e conversazionale
7. Divulgazione: tutto ciò che è visibile rispetto a rivelazione progressiva/fisarmoniche
8. Composizione: guidata dal contenuto o guidata dal controllo
9. Una regia volutamente non convenzionale/"jolly" che vale la pena vedere una volta

Ogni variante deve comunque rispettare gli aspetti non negoziabili (maiuscole/minuscole della frase, componenti di riutilizzo, stile di input/elenco a discesa dei dettagli dell'agente, raggi del compositore di chat, pulsante di aggiunta pianificazione, passaggio del mouse su IconButton, colori neutri grigio-50). Le varianti esplorano *layout ed enfasi*, non "e se ignorassimo il sistema di progettazione?".

### Passaggio 4: presenta, quindi attendi

- Mostra tutte le immagini a Ming in un unico messaggio: prima la coppia `Before / After`, poi le 9 varianti numerate da 1 a 9 con una didascalia di una riga ciascuna che descrive l'asse da esplorare.
- Chiedi quale direzione (o quale mix) perseguire.
- Non iniziare l'implementazione finché Ming non avrà scelto una direzione.

### Rendering delle immagini

- Percorso preferito: crea anteprime HTML/React statiche che utilizzano token Tailwind reali da `turbo/apps/platform`, eseguine lo screenshot e caricali tramite `okou web upload-file`.
- Per una rapida esplorazione: la competenza `v0` può generare modelli di varianti da un prompt, ma il prompt deve enumerare esplicitamente le regole seguenti (caso della frase, input dei dettagli dell'agente, raggio del compositore della chat, ecc.) in modo che v0 non produca un'interfaccia utente SaaS generica.
- Se la generazione di immagini non è disponibile per la sessione, torna a wireframe ASCII/testuali chiaramente etichettati per tutti gli 11 fotogrammi (prima, dopo, 9 varianti) e segnalalo: non saltare mai silenziosamente il passaggio relativo alle immagini.

---

# Regole di progettazione

Queste sono le convenzioni di progettazione non negoziabili per qualsiasi nuova interfaccia utente fornita all'interno della piattaforma vm0 (`turbo/apps/platform`). Applicateli prima di scrivere i componenti e verificate i PR esistenti rispetto ad essi durante la revisione.

## Principi fondamentali

1. **Riutilizza, non reinventare.** Controlla sempre le primitive esistenti in `turbo/apps/platform/src/components/` e i modelli a livello di vista in `src/views/` prima di introdurre un nuovo componente. Se un'interazione simile è già inclusa nei dettagli dell'agente, nella pianificazione o nel compositore della chat, copia quel modello anziché progettarne uno parallelo.
2. **Rispetta il linguaggio del design Zero.** Superfici morbide, grigi neutri, raggi generosi, bordi sottili, senza ombre nette. La linea di base visiva è "calma, supponente, leggermente editoriale" - mai predefinita SaaS.
3. **Parla dal posto dell'utente.** Il testo deve descrivere ciò che *loro* stanno per fare o vedere, non ciò che sta facendo il sistema. Sii breve: di solito una sola frase, massimo due.

## Modelli di riferimento (copiali direttamente)

| Elemento             | Fonte di riferimento                                  | Perché |
|---------------------|---------------------------------------------------|-----|
| Inserimento testo/area testo | Immissione della pagina dei dettagli dell'agente (`src/views/agent-detail/`) | Imbottitura, bordo, stato focus, trattamento segnaposto stabiliti |
| A discesa/seleziona     | Menu a discesa della pagina dei dettagli dell'agente                         | Stile di trigger stabilito, raggio del menu, passaggio del mouse sull'oggetto, posizionamento del segno di spunta |
| Raggio scheda/pannello   | Scheda compositore chat (cerca componenti `composer`) | Imposta il raggio canonico della carta e lo stile della superficie nell'app |
| Pulsante della pagina principale   | Pulsante "Aggiungi pianificazione" nella pagina della pianificazione          | Il primario neutro-scuro utilizzato ovunque *al di fuori* dei modali |
| Pulsante principale modale  | Il colore primario del marchio (solo all'interno di finestre di dialogo/popover) | I modali mantengono il colore primario del marchio; le pagine no |
| Pulsante solo icona      | IconButton esistente con sfondo al passaggio del mouse           | Ogni icona cliccabile deve avere uno stato visibile al passaggio del mouse |

In caso di dubbi, apri il componente di riferimento nella codebase, leggi le sue proprietà e i nomi delle classi e rispecchiali. Non approssimare a memoria.

## Linee guida per i testi

- **Frasatura dal punto di vista dell'utente.** "Connetti la tua casella di posta" batte "Connessione alla casella di posta richiesta". "Ancora nessun agente" è preferibile a "L'elenco degli agenti è vuoto".
- **Brevità anziché completezza.** Una riga breve ha prestazioni migliori di una frase completa. Riempitivo del rivestimento ("semplicemente", "per favore", "per").
- **Maiuscole e minuscole per tutto.** Etichette, intestazioni, pulsanti, voci di menu, colonne di tabelle: tutte le maiuscole ("Fornitori di modelli", "Chiavi API", "Aggiungi pianificazione"). Mai titolo del caso. Mai `uppercase` tramite CSS sulle intestazioni delle sezioni. Se trovi un'etichetta Titolo-Maiuscolo o tutto maiuscolo, correggila.
- **Nessuna etichetta "decorativa" di didascalia** sopra i campi o le sezioni: si leggono come forma-y e datate. Utilizza un'etichetta normale o salta l'etichetta se il campo è evidente.
- **Nessuna punteggiatura finale** su etichette o pulsanti autonomi. I punti si riferiscono al corpo del testo e al testo di supporto.
- Quando si rinomina una stringa, grep la base di codice per la vecchia stringa e la testa: si fa riferimento alle etichette nei test e nelle traduzioni.

## Componenti e struttura

- Costruisci sempre le pagine a partire da componenti esistenti (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitive di dialogo, ecc.). I nuovi componenti sono l'ultima risorsa e richiedono una ragione.
- Cerca un layout/modello esistente (pagina delle impostazioni, pagina dell'elenco, pagina dei dettagli) ed eredita la sua impalcatura. Non derivare nuovamente la struttura della pagina.
- Quando aggiungi elementi a una pagina in stile impostazioni, abbina la spaziatura della sezione, il trattamento del divisore e la larghezza della riga del modulo utilizzati dalle sezioni vicine.

## Pulsanti

- **Pagina primaria** (la CTA principale su una pagina) → corrisponde al pulsante "Aggiungi pianificazione" nella pagina di pianificazione. Questa è la finestra di dialogo esterna neutra scura/solida utilizzata a livello di app.
- **Primario modale** (il pulsante di conferma all'interno delle finestre di dialogo/popover) → utilizza il colore primario del marchio. Le pagine no.
- **Pulsanti secondari/fantasma** → riutilizza le varianti esistenti; non inventarne di nuovi.
- **Pulsanti icona** → devono avere uno sfondo al passaggio del mouse (in genere `hover:bg-gray-50` o il token al passaggio del mouse IconButton stabilito). Non inviare mai un'icona semplice al passaggio del mouse come destinazione del clic.
- Tutti i pulsanti devono rispettare i token di altezza esistenti: non introdurre dimensioni una tantum.

## Campi di input

- Rispecchia l'input dei dettagli dell'agente: stessa imbottitura, stesso bordo, stesso anello di messa a fuoco (o la sua mancanza: controlla il riferimento prima di aggiungere un anello di messa a fuoco), stesso colore segnaposto.
- Multilinea: utilizza il modello textarea dei dettagli dell'agente (righe fisse o con aumento automatico come nel riferimento).
- Non inserire i due punti alla fine delle etichette dei campi.
- Testo di supporto sotto l'input, in grigio tenue, su una riga singola.

## Menu a discesa / selezioni

- Rispecchia il menu a discesa dei dettagli dell'agente: stesso aspetto del trigger, stesso raggio del menu, stesso riempimento degli elementi, stessi stati al passaggio del mouse/selezionati.
- Il menu non dovrebbe essere più ampio del suo trigger a meno che il contenuto non lo richieda.
- Evita i sottomenu nidificati a meno che un menu a discesa esistente non li utilizzi già.

## Carte e superfici

- Il raggio della scheda e lo stile della superficie corrispondono alla scheda del compositore di chat. Non introdurre un raggio più piccolo o più grande senza motivo.
- I bordi sono sottili (singola linea sottile nel token del bordo esistente). Nessuna ombra esterna a meno che il compositore della chat non ne utilizzi una.
- Superfici neutre su riempimenti mobili/grigio chiaro (sfondi di pillole attivi, riempimenti di contenitori di icone, ecc.) → `bg-gray-50`. `gray-100` e `gray-200` sono stati ripetutamente definiti troppo scuri: inizia da `gray-50`.

## Focus e interazione

- Non aggiungere ombre o contorni `:focus-visible` personalizzati agli elementi di navigazione/marketing: riutilizza invece lo spostamento del colore al passaggio del mouse. (Lo stesso vincolo generalmente si applica all'interno della piattaforma a meno che un componente di riferimento non abbia un anello di messa a fuoco esplicito.)
- Ogni elemento interattivo (pulsante, pulsante icona, riga, collegamento) necessita di uno stato al passaggio del mouse visibile. Prova passando il mouse su ciascuno prima di considerare il disegno completato.
- Gli stati disabilitati utilizzano i token disabilitati esistenti; non arrotolare a mano un colore sbiadito.

## Esamina la lista di controllo

Prima di dichiarare pronta un'interfaccia utente, procedi nel seguente modo:

1. Ho riutilizzato i componenti esistenti invece di crearne di nuovi?
2. Ho abbinato un modello/layout di pagina esistente?
3. Gli input sono visivamente identici agli input dei dettagli dell'agente?
4. I menu a discesa sono visivamente identici ai menu a discesa dei dettagli dell'agente?
5. Le carte corrispondono al raggio e alla superficie del compositore della chat?
6. Ogni frase dell'etichetta è maiuscola? Qualche titolo rimanente o tutto maiuscolo?
7. Il testo è breve e scritto dal posto dell'utente?
8. La pagina principale è il pulsante in stile "Aggiungi pianificazione"? Il marchio primario viene utilizzato solo all'interno dei modali?
9. Ogni pulsante icona ha uno sfondo al passaggio del mouse?
10. Ho passato il mouse su ogni elemento interattivo per confermare il feedback?

Se una qualsiasi risposta è "no", correggila prima di aprire il PR.

## In caso di dubbio

- Apri il componente di riferimento, leggi la sua fonte e copia la struttura.
- Se due componenti di riferimento non sono d'accordo, preferisci quello spedito più recentemente (controlla il registro git).
- Se il progetto ha veramente bisogno di una nuova primitiva, parlane con Ming prima di costruirlo: il lavoro di riprogettazione in bundle appartiene a un PR con lui come revisore.

Non è necessario che le nove opzioni siano nove progetti finiti. Il loro compito è darmi abbastanza spazio per vedere il problema in modo diverso e muovermi nella giusta direzione. Se un concetto non rientra nel prodotto attuale, uno prototipo React autonomo può comunque essere d'aiuto. Per questa funzionalità sono rimasto all’interno del sistema prodotto reale.

Un esempio reale: la navigazione di Zero

Zero aveva originariamente una barra laterale da 300 pixel contenente destinazioni di prodotti, agenti aggiunti e thread di chat. Stava facendo tre lavori contemporaneamente. Volevo separare quei lavori senza cambiare l'area di conversazione.

Il brief del prodotto per l'esplorazione era:

/ui-design

Riproduci la fase di progettazione della navigazione in tre regioni di Zero dalla base storica reale. Separa le destinazioni dei prodotti, gli agenti e le conversazioni in aree più chiare senza modificare l'area della conversazione. Utilizza token, icone e componenti Zero reali. Produci un Prima fedele alla fonte, un Dopo forte e nove varianti veramente diverse. Non modificare il codice prodotto né presentare un mockup come prova del browser.

La prima esplorazione è stata troppo cauta. Diverse opzioni hanno modificato la larghezza e gli stili di selezione, ma sembravano ancora la stessa barra laterale. Ho rifiutato quella serie e ho chiesto all'agente di rendere visibili le differenze a livello di architettura dell'informazione.

La seconda corsa ha restituito nove direzioni veramente diverse. Li ho raggruppati in una tabella 3×3 in modo che siano facili da confrontare senza trasformare l'articolo in una lunga striscia di immagini. Ogni miniatura si apre nel visualizzatore di immagini del blog.

1. Navigazione superiore	2. Cassetto pieghevole	3. Discussione prima
Sposta le destinazioni sopra la conversazione	Nascondi le destinazioni finché non sono necessarie	Rendi le conversazioni l'oggetto principale della navigazione
4. Prima l'agente	5. Prima conversazione	6. Lanciatore di comandi
Scegli un agente prima dei suoi thread	Metti gli agenti bloccati sopra la conversazione attiva	Apri le destinazioni da un menu ricercabile
7. Binario espandibile	8. Inserimento nel dashboard	9. Molo inferiore
Espandi una guida stretta solo quando necessario	Inizia dal lavoro recente	Sposta le destinazioni in fondo

Non ho scelto uno di questi fotogrammi esattamente come disegnato. Li ho usati per decidere cosa dovrebbe restare e cosa dovrebbe cambiare. La direzione finale utilizzava una guida di destinazione stretta, una guida di chat separata, cinque agenti visibili bloccati e l'area di conversazione esistente.

L'importante risultato di ui-design non era solo l'immagine. Si trattava di un breve verbale decisionale:

• Mantieni una barra di destinazione da 68 pixel e una barra di chat da 300 pixel
• Mostra cinque slot agente bloccati
• Mantieni la selezione silenziosa ma leggibile
• Mostra la guida al riordino solo durante il trascinamento
• Mantieni invariata la conversazione e il cassetto mobile esistente

Ciò è stato sufficiente per avviare l'implementazione.

3. Utilizzare ui-implement per trasformare il disegno selezionato in codice

Dopo aver scelto una direzione e collegato la base di codice del prodotto, l'agente funziona direttamente nel codice. Non ridisegno prima il fotogramma selezionato in Figma.

In parole povere, ui-implement salta l'esplorazione perché la direzione è già stata scelta. Trova i componenti reali e la struttura della pagina più vicini, li costruisce, controlla il risultato e verifica la funzionalità in un browser.

Cosa protegge questa istruzione

• La direzione scelta non dovrebbe essere riprogettata durante l'implementazione.
• L'agente deve iniziare con il componente esistente e la pagina modello più vicini.
• Il riutilizzo vince su un nuovo componente a meno che il prodotto non presenti una reale lacuna.
• L'autocontrollo e il controllo del browser rilevano copie, stati e interazioni incoerenti.
• Se una decisione sul prodotto è ancora irrisolta, il lavoro ritorna a ui-design.

In questo modo il sistema di progettazione rimane attivo durante l'implementazione. Non è un documento che l'agente legge una volta. Determina quali componenti sceglie e come controlla l'esperienza finale.

Ecco le istruzioni originali complete, riprodotte alla lettera dal flusso di lavoro live:

Istruzioni originali complete di ui-implement

# vm0/Zero Regole di implementazione dell'interfaccia utente

## Flusso di lavoro: implementalo direttamente

Quando viene utilizzata questa abilità, **salta la fase di esplorazione del mockup e delle varianti**. Inizia immediatamente l'implementazione in `turbo/apps/platform`, applicando tutte le regole di progettazione riportate di seguito.

### Passaggio 1: individuare i componenti di riferimento

Prima di scrivere una riga, apri i componenti di riferimento da specchiare:

- Ingresso/area testo → Ingresso `src/views/agent-detail/`
- Menu a discesa/seleziona → menu a discesa `src/views/agent-detail/`
- Raggio scheda/pannello → scheda compositore chat
- Pulsante principale della pagina → pulsante "Aggiungi pianificazione" nella pagina della pianificazione
- Pulsante solo icona → `IconButton` esistente con sfondo al passaggio del mouse

Leggi i loro oggetti di scena e i nomi delle classi. Rispecchiateli: non approssimateli a memoria.

### Passaggio 2: trova il modello di pagina esistente più vicino

Apri la pagina esistente più vicina della stessa forma (impostazioni, elenco, dettagli) ed eredita la sua impalcatura: spaziatura delle sezioni, trattamento dei divisori, larghezza delle righe del modulo. Non derivare nuovamente la struttura della pagina.

### Passaggio 3: creazione, quindi autocontrollo

Implementare la schermata con le primitive esistenti da `turbo/apps/platform/src/components/`. Una volta completata l'operazione, segui la **lista di controllo per la revisione** in fondo a questa abilità prima di riferire. Correggi ogni risposta "no" prima di dichiarare il lavoro completato.

### Passaggio 4: verifica nel browser

Per qualsiasi lavoro sull'interfaccia utente, avviare il server di sviluppo ed esercitare la funzionalità in un browser prima di segnalare l'attività come completata. Passa il mouse su ogni elemento interattivo, testa il percorso dorato e i casi limite e osserva le regressioni nelle schermate vicine. Il controllo del tipo e i test verificano il codice, non la correttezza delle funzionalità: se non riesci ad aprire il browser, dillo esplicitamente.

### Quando ricorrere a ui-design

Se la richiesta è aperta ("progetta una pagina di impostazioni per X") senza una direzione scelta, interrompi ed esegui invece l'abilità `ui-design`: le varianti prima/dopo + 9 esistono esattamente per quel caso. `ui-implement` è per quando la direzione è già decisa.

---

# Regole di progettazione

Queste sono le convenzioni di progettazione non negoziabili per qualsiasi nuova interfaccia utente fornita all'interno della piattaforma vm0 (`turbo/apps/platform`). Applicateli durante la costruzione e verificate la vostra differenza rispetto ad essi prima di aprire il PR.

## Principi fondamentali

1. **Riutilizza, non reinventare.** Controlla sempre le primitive esistenti in `turbo/apps/platform/src/components/` e i modelli a livello di vista in `src/views/` prima di introdurre un nuovo componente. Se un'interazione simile è già inclusa nei dettagli dell'agente, nella pianificazione o nel compositore della chat, copia quel modello anziché progettarne uno parallelo.
2. **Rispetta il linguaggio di design Zero.** Superfici morbide, grigi neutri, raggi generosi, bordi sottili, senza ombre nette. La linea di base visiva è "calma, supponente, leggermente editoriale" - mai predefinita SaaS.
3. **Parla dal posto dell'utente.** Il testo deve descrivere ciò che *loro* stanno per fare o vedere, non ciò che sta facendo il sistema. Sii breve: di solito una sola frase, massimo due.

## Modelli di riferimento (copiali direttamente)

| Elemento             | Fonte di riferimento                                  | Perché |
|---------------------|---------------------------------------------------|-----|
| Inserimento testo/area testo | Immissione della pagina dei dettagli dell'agente (`src/views/agent-detail/`) | Imbottitura, bordo, stato focus, trattamento segnaposto stabiliti |
| A discesa/seleziona     | Menu a discesa della pagina dei dettagli dell'agente                         | Stile di trigger stabilito, raggio del menu, passaggio del mouse sull'oggetto, posizionamento del segno di spunta |
| Raggio scheda/pannello   | Scheda compositore chat (cerca componenti `composer`) | Imposta il raggio canonico della carta e lo stile della superficie nell'app |
| Pulsante della pagina principale   | Pulsante "Aggiungi pianificazione" nella pagina della pianificazione          | Il primario neutro-scuro utilizzato ovunque *al di fuori* dei modali |
| Pulsante principale modale  | Il colore primario del marchio (solo all'interno di finestre di dialogo/popover) | I modali mantengono il colore primario del marchio; le pagine no |
| Pulsante solo icona      | IconButton esistente con sfondo al passaggio del mouse           | Ogni icona cliccabile deve avere uno stato visibile al passaggio del mouse |

In caso di dubbi, apri il componente di riferimento nella codebase, leggi le sue proprietà e i nomi delle classi e rispecchiali. Non approssimare a memoria.

## Linee guida per i testi

- **Frasatura dal punto di vista dell'utente.** "Connetti la tua casella di posta" batte "Connessione alla casella di posta richiesta". "Ancora nessun agente" è preferibile a "L'elenco degli agenti è vuoto".
- **Brevità anziché completezza.** Una riga breve ha prestazioni migliori di una frase completa. Riempitivo del rivestimento ("semplicemente", "per favore", "per").
- **Maiuscole e minuscole per tutto.** Etichette, intestazioni, pulsanti, voci di menu, colonne di tabelle: tutte le maiuscole ("Fornitori di modelli", "Chiavi API", "Aggiungi pianificazione"). Mai titolo del caso. Mai `uppercase` tramite CSS sulle intestazioni delle sezioni. Se trovi un'etichetta Titolo-Maiuscolo o tutto maiuscolo, correggila.
- **Nessuna etichetta "decorativa" di didascalia** sopra i campi o le sezioni: si leggono come forma-y e datate. Utilizza un'etichetta normale o salta l'etichetta se il campo è evidente.
- **Nessuna punteggiatura finale** su etichette o pulsanti autonomi. I punti si riferiscono al corpo del testo e al testo di supporto.
- Quando si rinomina una stringa, grep la base di codice per la vecchia stringa e la testa: si fa riferimento alle etichette nei test e nelle traduzioni.

## Componenti e struttura

- Costruisci sempre le pagine a partire da componenti esistenti (`Button`, `Input`, `Select`, `Card`, `IconButton`, primitive di dialogo, ecc.). I nuovi componenti sono l'ultima risorsa e richiedono una ragione.
- Cerca un layout/modello esistente (pagina delle impostazioni, pagina dell'elenco, pagina dei dettagli) ed eredita la sua impalcatura. Non derivare nuovamente la struttura della pagina.
- Quando aggiungi elementi a una pagina in stile impostazioni, abbina la spaziatura della sezione, il trattamento del divisore e la larghezza della riga del modulo utilizzati dalle sezioni vicine.

## Pulsanti

- **Pagina primaria** (la CTA principale su una pagina) → corrisponde al pulsante "Aggiungi pianificazione" nella pagina di pianificazione. Questa è la finestra di dialogo esterna neutra scura/solida utilizzata a livello di app.
- **Primario modale** (il pulsante di conferma all'interno delle finestre di dialogo/popover) → utilizza il colore primario del marchio. Le pagine no.
- **Pulsanti secondari/fantasma** → riutilizza le varianti esistenti; non inventarne di nuovi.
- **Pulsanti icona** → devono avere uno sfondo al passaggio del mouse (in genere `hover:bg-gray-50` o il token al passaggio del mouse IconButton stabilito). Non inviare mai un'icona semplice al passaggio del mouse come destinazione del clic.
- Tutti i pulsanti devono rispettare i token di altezza esistenti: non introdurre dimensioni una tantum.

## Campi di input

- Rispecchia l'input dei dettagli dell'agente: stessa imbottitura, stesso bordo, stesso anello di messa a fuoco (o la sua mancanza: controlla il riferimento prima di aggiungere un anello di messa a fuoco), stesso colore segnaposto.
- Multilinea: utilizza il modello textarea dei dettagli dell'agente (righe fisse o con aumento automatico come nel riferimento).
- Non inserire i due punti alla fine delle etichette dei campi.
- Testo di supporto sotto l'input, in grigio tenue, su una riga singola.

## Menu a discesa / selezioni

- Rispecchia il menu a discesa dei dettagli dell'agente: stesso aspetto del trigger, stesso raggio del menu, stesso riempimento degli elementi, stessi stati al passaggio del mouse/selezionati.
- Il menu non dovrebbe essere più ampio del suo trigger a meno che il contenuto non lo richieda.
- Evita i sottomenu nidificati a meno che un menu a discesa esistente non li utilizzi già.

## Carte e superfici

- Il raggio della scheda e lo stile della superficie corrispondono alla scheda del compositore di chat. Non introdurre un raggio più piccolo o più grande senza motivo.
- I bordi sono sottili (singola linea sottile nel token del bordo esistente). Nessuna ombra esterna a meno che il compositore della chat non ne utilizzi una.
- Superfici neutre su riempimenti mobili/grigio chiaro (sfondi di pillole attivi, riempimenti di contenitori di icone, ecc.) → `bg-gray-50`. `gray-100` e `gray-200` sono stati ripetutamente definiti troppo scuri: inizia da `gray-50`.

## Focus e interazione

- Non aggiungere ombre o contorni `:focus-visible` personalizzati agli elementi di navigazione/marketing: riutilizza invece lo spostamento del colore al passaggio del mouse. (Lo stesso vincolo generalmente si applica all'interno della piattaforma a meno che un componente di riferimento non abbia un anello di messa a fuoco esplicito.)
- Ogni elemento interattivo (pulsante, pulsante icona, riga, collegamento) necessita di uno stato al passaggio del mouse visibile. Prova passando il mouse su ciascuno prima di considerare il disegno completato.
- Gli stati disabilitati utilizzano i token disabilitati esistenti; non arrotolare a mano un colore sbiadito.

## Esamina la lista di controllo

Prima di dichiarare pronta un'interfaccia utente, procedi nel seguente modo:

1. Ho riutilizzato i componenti esistenti invece di crearne di nuovi?
2. Ho abbinato un modello/layout di pagina esistente?
3. Gli input sono visivamente identici agli input dei dettagli dell'agente?
4. I menu a discesa sono visivamente identici ai menu a discesa dei dettagli dell'agente?
5. Le carte corrispondono al raggio e alla superficie del compositore della chat?
6. Ogni frase dell'etichetta è maiuscola? Qualche titolo rimanente o tutto maiuscolo?
7. Il testo è breve e scritto dal posto dell'utente?
8. La pagina principale è il pulsante in stile "Aggiungi pianificazione"? Il marchio primario viene utilizzato solo all'interno dei modali?
9. Ogni pulsante icona ha uno sfondo al passaggio del mouse?
10. Ho passato il mouse su ogni elemento interattivo del browser per confermare il feedback?

Se una qualsiasi risposta è "no", correggila prima di aprire il PR.

## In caso di dubbio

- Apri il componente di riferimento, leggi la sua fonte e copia la struttura.
- Se due componenti di riferimento non sono d'accordo, preferisci quello spedito più recentemente (controlla il registro git).
- Se il progetto ha veramente bisogno di una nuova primitiva, parlane con Ming prima di costruirlo: il lavoro di riprogettazione in bundle appartiene a un PR con lui come revisore.

Questa era la richiesta di implementazione specifica della funzionalità:

/ui-implement

Inizia dalla revisione 04d642bb. Aggiungi una suddivisione del desktop predefinita con una barra di destinazione di 68 px, una barra di chat di 300 px e la conversazione invariata. Mantieni la vecchia barra laterale da 300 px quando l'interruttore è spento e su dispositivo mobile. Esegui il rendering di cinque slot bloccati, preserva l'ordine definito dall'utente e mostra le possibilità di riordino solo durante un trascinamento attivo. Non ispezionare la funzionalità storica o i perfezionamenti successivi finché la patch indipendente, i test e le prove del browser non vengono congelati.

Per la funzionalità di navigazione, ho chiesto all'agente di mantenere la vecchia barra laterale quando la funzionalità era disattivata, di mostrare il nuovo layout in tre parti quando era attiva, di mantenere il drawer mobile esistente e di consentire alle persone di riordinare gli agenti aggiunti.

Durante l'implementazione, l'agente ha riscontrato un problema importante. Il vecchio prodotto ricordava quali agenti erano bloccati, ma non ricordava il loro ordine. Un'interazione di trascinamento potrebbe sembrare corretta e quindi reimpostata dopo un aggiornamento.

Quindi l'agente ha fatto di più che disegnare lo stato di trascinamento. Ha reso persistente il nuovo ordine, ha aggiornato la pagina e ha verificato che l'ordine rimanesse. Ha inoltre confermato che le maniglie di riordino apparivano solo durante il trascinamento e scomparivano successivamente.

La consegna dell'implementazione ha mostrato i due stati del desktop che dovevo esaminare. Li mostro a tutta larghezza in modo che l'interfaccia rimanga leggibile. Il comportamento mobile verrà visualizzato più avanti nella procedura dettagliata come acquisizione da parte del telefono ad alta densità.

Stato di riposo del desktop

Riordino attivo

A questo punto avevo una funzionalità funzionante, non un altro file di progettazione. Ma l’implementazione non era ancora la fine. Avevo bisogno di vedere cosa era effettivamente in esecuzione nell'anteprima distribuita.

4. Utilizzare ui-walkthrough per rivedere il prodotto reale

Le procedure dettagliate sui prodotti erano noiose. Vorrei aprire un'anteprima distribuita, preparare l'account giusto, attivare e disattivare le funzionalità, fare clic su ogni controllo, ridimensionare il browser, acquisire screenshot e provare a ricordare quale stato rappresentava ciascuna immagine.

L'agente ha un Agent Browser integrato, quindi posso affidargli il lavoro.

Il flusso di lavoro prevede due passaggi principali:

1. Elencare prima gli scenari. L'agente trasforma le dichiarazioni di progettazione e implementazione in un elenco di controllo.
2. Esegui l'elenco di controllo e allega prove. Esegue ogni scenario nell'anteprima distribuita e restituisce PASS, FAIL o BLOCKED con uno screenshot per ogni stato significativo.

Cosa cambia questa istruzione riguardo alla revisione

• L'agente elenca gli scenari prima di iniziare a fare clic.
• Utilizza il componente realmente distribuito tramite il suo Agent Browser integrato.
• Cattura uno screenshot per ogni stato significativo.
• Contrassegna ogni punto di controllo PASS, FAIL o BLOCKED.
• Non nasconde mai uno stato non disponibile dietro prove false.

Ciò trasforma il clic manuale in un pacchetto di revisione organizzato. Posso esaminare insieme il comportamento previsto, il risultato e le prove.

Le istruzioni complete sono riportate di seguito. Ho tradotto il nome della dipendenza interna in "Agent Browser integrato" per chiarezza rivolta al lettore; per il resto la logica del flusso di lavoro rimane invariata.

Istruzioni originali complete di ui-walkthrough

# Procedura dettagliata dell'interfaccia utente

QA visivo end-to-end di una funzionalità front-end vm0/Zero nella sua anteprima reale per PR. Questo flusso di lavoro definisce cosa verificare e come riportare il risultato; non definisce gli strumenti operativi dell'interfaccia utente.

## Dipendenza richiesta: Agent Browser integrato

Utilizza Agent Browser integrato come unica fonte attendibile per ogni interazione dell'interfaccia utente, tra cui:

- Scoperta e apertura dell'anteprima per-PR.
- Gestione della protezione dell'anteprima e configurazione della sessione.
- Registrazione, OTP, onboarding, checkout di prova Stripe e accesso all'app live.
- Abilitazione delle opzioni di funzionalità.
- Navigazione, interazione con i controlli, fornitura di dati di test o simulati, acquisizione di screenshot, caricamento di artefatti, risoluzione dei problemi e pulizia.

Leggere e seguire le attuali istruzioni Agent Browser integrate prima di eseguire qualsiasi azione sull'interfaccia utente. Non duplicare comandi specifici del runtime, configurazione del motore, meccanismi di selezione, script del contesto di pagina, gestione delle sessioni o metodi di pulizia dei processi in questo flusso di lavoro. Se il Agent Browser integrato cambia, le sue istruzioni correnti hanno la precedenza.

## Quando usarlo

- Esplora l'interfaccia utente di una richiesta pull VM0 nella sua anteprima distribuita.
- Verifica una funzionalità in-app che richiede autenticazione, onboarding, fatturazione, cambio di funzionalità o un vero thread di chat.
- Cattura screenshot fedeli o un breve video dettagliato della funzionalità in funzione nell'applicazione live.

## Flusso di lavoro dettagliato

### 1. Stabilire l'obiettivo e l'ambito

- Identificare il PR, il commit principale, il comportamento visibile all'utente modificato e l'anteprima prevista.
- Confermare che l'anteprima distribuita corrisponda alla testa PR prima del test.
- Leggi la differenza PR e la descrizione per ricavare il percorso critico e gli stati che dimostrano il cambiamento.
- Non correggere il codice, risolvere i conflitti o modificare il comportamento del prodotto durante una procedura dettagliata a meno che l'utente non richieda separatamente l'implementazione.

### 2. Raggiungi la funzione

Utilizza Agent Browser integrato per accedere all'anteprima e raggiungere lo stato della funzionalità live. Segui le regole attuali per l'autenticazione, l'onboarding, la fatturazione, i cambi di funzionalità e le esclusioni della sola anteprima.

Se viene utilizzato un bypass, segnalarlo nel rapporto finale. Non utilizzare mai un bypass di onboarding quando l'onboarding stesso è in fase di test.

### 3. Definire la matrice dello stato visivo

Prima di interagire, elenca l'insieme più piccolo di stati che dimostrano il funzionamento della funzionalità. Includere gli elementi applicabili:

- Stato iniziale/predefinito.
- Stato aperto, passaggio del mouse, focus, selezionato, espanso o attivo.
- Stati vuoti e popolati.
- Stati abilitati e disabilitati.
- Stati di successo, convalida, caricamento ed errore.
- Posizionamento, collisione, capovolgimento, ritaglio e comportamento reattivo.
- Invio o azione downstream quando la funzionalità è interattiva.

Preferisci esercitare il comportamento effettivamente modificato rispetto a un test del fumo generico.

### 4. Guidare il componente live

Utilizza Agent Browser integrato per tutte le tecniche di interazione e di test dei dati.

Il contenuto simulato o inserito può essere utilizzato solo per posizionare un componente dell'applicazione reale in uno stato visivo deterministico. Il componente, lo stile e l'interazione da valutare devono rimanere l'implementazione live dell'anteprima PR.

Per ogni stato deriso:

- Registra quale contenuto o prerequisito è stato deriso.
- Distinguere il contenuto deriso dal comportamento reale dell'applicazione.
- Non insinuare mai che il testo o i dati derisi provengano da un modello o da una fonte di produzione.
- Esercita i controlli reali e il cablaggio a valle ovunque l'ambiente lo consenta.

### 5. Acquisisci prove

Utilizza Agent Browser integrato per acquisire e caricare prove per i checkpoint chiave. Ogni immagine dovrebbe dimostrare uno stato significativo piuttosto che ripetere la stessa vista.

Se l'utente richiede un video, assembla una breve procedura dettagliata con sottotitoli dai checkpoint verificati. Le didascalie dovrebbero identificare l'azione dell'utente e il risultato previsto senza oscurare l'interfaccia utente.

### 6. Consegnare e riferire

Rapporto:

- Collegamento PR, URL di anteprima esatto e commit testato quando disponibile.
- Flusso utente esatto esercitato.
- Account di prova quando ne è stato creato uno.
- `PASS`, `FAIL` o `BLOCKED` per ciascun checkpoint.
- Collegamenti a schermate e un collegamento video opzionale con brevi descrizioni.
- Cambiamenti di funzionalità, bypass, dati fittizi e altre configurazioni di solo test utilizzate.
- Controlli non riusciti, blocchi ambientali o lacune nella verifica.

Non dichiarare che la funzionalità è verificata a meno che non sia stato esercitato il flusso di anteprima dal vivo e non siano state acquisite prove. Se l'anteprima non è disponibile, segnala `BLOCKED` con le prove di distribuzione anziché sostituire una replica locale o statica.

Questa era la richiesta dettagliata della funzionalità:

/ui-walkthrough

Utilizza l'anteprima distribuita tramite Agent Browser integrato come unica verità del browser. Dimostra la barra laterale con funzionalità disattivate, la divisione di 68px e 300px, l'ordine di destinazione, gli stati al passaggio del mouse, cinque slot bloccati, maniglie di solo trascinamento, riordino persistente, selezione del thread, scorrimento e il drawer completo di iPhone. Restituisci PASS, FAIL o BLOCKED per ogni checkpoint. Non sostituire uno stato irraggiungibile con una replica.

Per questa funzionalità, l'agente ha organizzato la procedura dettagliata attorno a queste domande:

• La vecchia barra laterale funziona ancora quando la funzionalità è disattivata?
• La nuova struttura del desktop appare quando è acceso?
• Gli stati al passaggio del mouse e quelli selezionati sono visibili ma silenziosi?
• I cinque agenti bloccati sono leggibili?
• I controlli di riordino rimangono nascosti finché non inizia il trascinamento?
• Il nuovo ordine sopravviverà a un aggiornamento?
• Posso selezionare e scorrere i thread reali?
• Il cassetto mobile esistente funziona ancora?
• Tutte le destinazioni di navigazione sono presenti e nell'ordine corretto?

L'agente ha quindi aperto l'anteprima distribuita come nuovo utente, ha completato l'onboarding, ha abilitato la funzionalità e ha elaborato l'elenco. Ha testato lo stato di riposo, lo stato di passaggio del mouse, lo stato di trascinamento, il comportamento di aggiornamento, la selezione del thread, lo scorrimento e il layout del telefono.

Il risultato è stato 11 PASS, 1 FAIL.

Il fallimento è stato utile. Il layout e le interazioni funzionavano, ma l'anteprima distribuita mostrava solo sei destinazioni del prodotto. Activity e Insights mancavano e l'ordine non corrispondeva al design selezionato.

Scenario	Risultato
Vecchia barra laterale con la funzione disattivata	PASS
Nuovo layout del desktop in tre parti	PASS
Passa il mouse e stati selezionati	PASS
Cinque agenti bloccati	PASS
Guida al riordino tramite solo trascinamento	PASS
Ordine salvato dopo l'aggiornamento	PASS
Selezione e scorrimento del thread	PASS
Cassetto mobile esistente	PASS
Contenuto e ordine della destinazione	FAIL

La consegna finale consisteva in un set di screenshot organizzato anziché in una cartella di immagini senza etichetta. Le acquisizioni del desktop sono 1440 × 900 pixel e quelle del telefono sono 1170 × 2532 pixel. Appaiono uno alla volta di seguito in modo che l'interfaccia rimanga leggibile; clicca su qualsiasi immagine per ingrandirla senza uscire dall'articolo.

Funzionalità disattivata

Funzionalità abilitata

Disposizione della scrivania

Passa il mouse sulla destinazione

Passaggio del mouse sull'agente bloccato

Trascinamento attivo

Ordine salvato

Cassetto mobile

Ciò mi consente di rivedere una funzionalità in modo strutturato. Posso vedere insieme gli scenari previsti, il risultato effettivo ottenuto e le prove. Se qualcosa fallisce, so esattamente dove il lavoro dovrebbe tornare.

Come un team adotta questo flusso di lavoro di progettazione del prodotto basato sull'intelligenza artificiale

L'intero processo è breve. I compagni di squadra possono salvare ogni fase come flusso di lavoro Zero condiviso invece di ricostruire il processo dalla memoria.

Palcoscenico	Ingresso	Produzione
ui-design	Schermata corrente, problema, obiettivo e vincoli	Una direzione consigliata, nove alternative e un record di progettazione selezionato
ui-implement	Il record di progettazione selezionato	Una modifica al codice rivedibile e screenshot degli stati principali
ui-walkthrough	La funzionalità distribuita e il relativo comportamento previsto	Un elenco di scenari organizzato con screenshot PASS, FAIL o BLOCKED

Non è necessario che un compagno di squadra riproduca il mio gusto progettuale. Devono fornire un buon contesto, utilizzare il sistema di prodotto condiviso, fare una scelta esplicita dopo l'esplorazione ed esaminare le prove del browser. Gli stessi tre punti di controllo umani – problema, direzione e accettazione – modellano anche il modo in cui gestire gli agenti IA come una squadra.

Questo flusso di lavoro non rimuove la pratica di progettazione o il pensiero progettuale. Li sposta nelle parti in cui contano di più: definire il problema, stabilire vincoli, confrontare direzioni, scegliere compromessi e giudicare il prodotto in esecuzione.

Quando il sistema dei componenti è maturo, non ho più bisogno di ricostruire ogni funzionalità come blocchi trascinabili in Figma. Posso lavorare con l'agente direttamente nel prodotto, mentre il sistema di progettazione mantiene l'output coerente e la procedura dettagliata mantiene il risultato onesto.

Domande frequenti

Come si costruisce un flusso di lavoro di progettazione del prodotto AI?

Inizia con il sistema di prodotto esistente, non con un prompt vuoto. Separare il lavoro in esplorazione, implementazione e revisione. Lascia che sia l'agente a generare opzioni ed eseguire controlli ripetibili, ma mantieni il progettista del prodotto responsabile del problema, della direzione scelta e dell'accettazione finale.

I progettisti di prodotti possono lavorare senza Figma?

Sì, quando il prodotto dispone già di componenti stabili, modelli di pagina e modelli di interazione. Figma rimane utile per un nuovo linguaggio visivo o un'interazione non familiare. Il punto non è vietare Figma; è per evitare di ricostruire decisioni note sui prodotti su una seconda tela.

L’intelligenza artificiale sta sostituendo i progettisti di prodotto?

Non in questo flusso di lavoro. L'agente assembla le opzioni, modifica il codice e controlla gli scenari. Il progettista inquadra ancora il problema, stabilisce i vincoli, confronta i compromessi, sceglie la direzione e decide se il prodotto in esecuzione è abbastanza buono per essere spedito.