Nelle parole della skill
Una disciplina orientata all'artigianato per costruire UI di prodotto — dashboard, pannelli di amministrazione, app SaaS, strumenti, pagine di impostazioni, interfacce dati — con le decisioni che prenderebbe un top team di design. Impone un brief operativo prima del codice: chi è l'utente, l'unico verbo per cui è venuto e come dovrebbe sentirsi l'interfaccia, espresso in parole che abbiano davvero un significato.
Da lì prescrive l'esplorazione del dominio (dominio, mondo colore, elemento distintivo, default rifiutati), una scala tipografica costruita su un rapporto in cui peso e colore svolgono il lavoro di gerarchia, un'unica strategia di profondità scelta con decisione, token semantici invece di valori letterali hardcoded, e gli essenziali di rifinitura e movimento — numeri tabulari, raggio concentrico, durate sotto i 300ms, nessuna animazione sulle azioni ad alta frequenza. Esplicitamente non per landing page, siti marketing, campagne o lavoro puramente di brand.
Che cosa produce
- Una proposta Suggest + Ask che indica Dominio, Mondo colore, Elemento distintivo, Rifiuto e Direzione.
- Campioni renderizzati inline — swatch della palette, la scala tipografica nel carattere reale, card di elevazione impilate, l'elemento distintivo come componente reale — quando è presente uno strumento di rendering; l'implementazione stessa finisce comunque nel codebase.
- Un file .interface-design/system.md salvato contenente direzione, strategia di profondità, decisioni di gerarchia e pattern di componenti ripetuti, scritto solo dopo che l'utente dice di sì.
Come funziona
- 01Scrivere il Brief di Lavoro
Prima di qualsiasi codice, rispondere a chi è la persona umana, quale verbo deve compiere e come dovrebbe percepirsi l'interfaccia — mantenendo il tutto compatto a meno che la direzione richieda conferma.
- 02Esplorare il Dominio del Prodotto
Produrre quattro output prima di proporre una direzione: almeno 5 concetti di dominio, 5 o più colori dal mondo fisico del prodotto, un elemento distintivo, e 3 default ovvi da rifiutare.
- 03Proporre e Confermare la Direzione
Guidare con un blocco Suggest + Ask che indica Dominio, Mondo colore, Elemento distintivo, Rifiuto e Direzione, poi verificare che la direzione sia corretta prima di costruire.
- 04Renderizzare Campioni Dove Possibile
Se la sessione dispone di uno strumento di rendering visivo inline, mostrare la palette, la scala tipografica, i livelli di elevazione e l'elemento distintivo come componenti reali invece di descriverli; altrimenti ricorrere al codice.
- 05Costruire su Ciò che Esiste, Poi Verificare
Ispezionare l'app, i token, i pattern dei componenti e system.md, applicare la patch all'implementazione, eseguire build, typecheck o test dove disponibili, poi verificare visivamente a larghezze desktop e mobile.
- 06Offrire di Salvare i Pattern
Dopo un task, offrire di registrare direzione, strategia di profondità, decisioni di gerarchia e pattern di componenti ripetuti affinché le sessioni successive rimangano coerenti.