Guadagni:
- Capacità di elaborare e creare token di progettazione, denominazione dei componenti e regole di utilizzo coerenti con l'intelligenza artificiale
- Capacità di produrre rapidamente documentazione sui componenti, esempi di cose da fare/non fare e testi di utilizzo con intelligenza artificiale
- Capacità di verificare i suggerimenti dell'intelligenza artificiale per eventuali conflitti con il sistema di progettazione esistente e preservare la singolarità
Un sistema di progettazione è il linguaggio comune che fa sì che una famiglia di prodotti appaia e si comporti in modo coerente: componenti riutilizzabili (pulsante, scheda, campo modulo), token di progettazione (definizioni denominate di valori come colore, spaziatura, tipografia) e documentazione che spiega come utilizzarli. Un buon sistema di progettazione consente a dieci designer di progettare lo stesso prodotto come se fosse prodotto da un'unica fonte. Installare e mantenere questo sistema è un lavoro faticoso, ripetitivo e ad alta intensità di testo; È proprio qui che brilla l’intelligenza artificiale. Ma l'essenza del sistema è la singolarità e la coerenza; Le raccomandazioni dell'AI non possono essere accettate senza essere verificate per eventuali conflitti con il sistema attuale.
Token e denominazione: la base per la coerenza
Un token di progettazione è un valore denominato e riutilizzabile di una decisione di progettazione: colore-primario, spazio-centro, testo-titolo-maiuscola. Grazie ai token, puoi cambiare un colore in un unico posto e aggiornarlo nell'intero prodotto. Ma il potere dei token dipende dalla coerenza dei nomi; Se blue-1, main-blue, primarioBlue vengono utilizzati insieme, il sistema si bloccherà.
L'intelligenza artificiale è brava in due cose qui: rivedere il set di token esistente rispetto a uno schema di denominazione coerente e suggerire nomi conformi allo schema per i nuovi token. Una richiesta come "Traduci questo elenco di token in una denominazione semantica (basata sul significato)" ti aiuterà a generare nomi che trasmettono significato, come colore-azione-primario invece di blu-500. Ma la decisione finale sul nome riguarda il contratto della squadra; Il modello fornisce solo uno schema.
Suggerimento: quando assegni i token all'IA, fornisci 5-6 esempi del tuo schema attuale e dì "mantieni lo stesso schema". La richiesta senza campione produce nomi estranei al tuo sistema.
Documentazione dei componenti: l'area più produttiva dell'intelligenza artificiale
La documentazione di un componente include: cosa fa, quando usarlo, quando non usarlo, le sue varianti, gli stati (predefinito, passaggio del mouse, passivo, errore), note sull'accessibilità ed esempi di "fare/non fare". Scrivere questi testi a mano richiede ore, motivo per cui molti team trascurano la documentazione.
L'intelligenza artificiale colma questa lacuna: quando descrivi un componente, produce bozza di documentazione, regole di utilizzo ed esempi di cose da fare/non fare in un formato coerente. Pertanto, la documentazione va da "non c'è" a "c'è una bozza, verrà corretta", il che è un grande vantaggio. Tuttavia, il modello non conosce il comportamento effettivo del componente; È tuo compito far corrispondere le regole che produce con la realtà del sistema.
frammento di documento
Contributo dell'intelligenza artificiale
verifica umana
Cosa fa?
Chiara definizione del contorno
Vera idoneità allo scopo
Quando usarlo
Scenari generali
Regole specifiche del prodotto
Esempi di fare/non fare
Coppie di draft veloci
Effettivi abusi
Nota sull'accessibilità
Promemoria standard
Confermato da test reali
Elenco varianti/casi
elenco possibile
Coloro che effettivamente esistono nel sistema
Controllo delle contraddizioni: preservare la singolarità
Il nemico acerrimo del sistema di progettazione è la duplicazione: due pulsanti che svolgono lo stesso lavoro, due scale spaziali diverse, due regole contrastanti. Quando l'intelligenza artificiale suggerisce un nuovo componente o regola, quel suggerimento potrebbe entrare in conflitto con il sistema esistente: non tiene presente l'intero sistema modello. Quindi valuto ogni suggerimento chiedendomi "questo è in conflitto con qualcosa che già esiste?" Filtra con la domanda. Puoi anche utilizzare l'intelligenza artificiale nella scansione dei conflitti: puoi fornire il riepilogo del sistema attuale e la nuova raccomandazione e elencare i conflitti. Ma la decisione finale “singolare corretta” spetta alla squadra.
tre mini custodie
Caso 1: debito relativo alla documentazione saldato. Solo 6 dei 24 componenti di una squadra avevano la documentazione. Per i restanti 18 componenti dotati di intelligenza artificiale sono state prodotte bozze di documenti; Il team ha risolto ciascuno di essi in 10-15 minuti. Il lavoro, rimandato per settimane, è stato completato in due giorni.
Caso 2: la denominazione dei token è diventata coerente. In un sistema i colori erano mescolati come blue1, mainBlue, brand-blue. L'intelligenza artificiale ha tradotto i 40 token esistenti in uno schema semantico; Il team lo ha rivisto ed è passato a un unico standard. Gli errori di colore sono stati notevolmente ridotti nei progetti successivi.
Caso 3: l'elemento in conflitto è stato respinto. L'intelligenza artificiale ha proposto un nuovo componente chiamato "pulsante di azione secondaria". Quando il team ha analizzato le contraddizioni, ha scoperto che svolgeva lo stesso lavoro del "pulsante fantasma" esistente e ha rifiutato il suggerimento. Lezione: non tutti i suggerimenti aggiungono un nuovo componente al sistema; A volte è giusto utilizzare ciò che è disponibile.
Prompt copiabili
Il tuo ruolo: progetta l'amministratore del sistema. Documenta questo componente: <<componente e il suo comportamento>>.Formato: cosa fa | Quando utilizzare | Quando NON utilizzare |Varianti | Situazioni | Note sull'accessibilità | 2 Fare / 2 Non fare esempio. Inventa un comportamento che non conosci; Scrivi "la squadra deve compilare".
Traduci questo elenco di token in uno schema di denominazione semantico (basato sul significato). I miei esempi di schemi attuali: <<5-6 esempi>>. Continuare nello stesso schema. Per ciascun token, fornire il vecchio nome -> nuovo nome -> tabella di giustificazione. Elenco: <<token>>
Cerca contraddizioni: riepilogo del mio attuale sistema di progettazione: <<summary>>. Nuovo componente/regola proposta: <<suggerimento>>. Questo suggerimento è in conflitto con il sistema esistente (componente che svolge lo stesso lavoro, regola in conflitto, token duplicato)? Elenca i conflitti e il tuo suggerimento.
Genera coppie di esempi "fare/non fare" per questo componente: scenari realistici di utilizzo corretto e realistici di utilizzo errato. Per ogni coppia, spiega in una frase perché è vero/falso. Componente: <<nome e scopo>>
Prompt debole / Prompt forte
Debole: "Scrivi la documentazione per questo pulsante".
Risultato: un testo generico e formattato senza collegamento al sistema.
Forte: "Documenta questo pulsante nel seguente formato (cosa fa / quando non usarlo / varianti / casi / accessibilità / non fare-non fare); inventa un comportamento che non conosci, scrivi 'il team deve compilare'."
Risultato: manoscritto coerentemente formattato, correttamente spaziato e modificabile.
Differenza: formato di prompt forte + divieto di fabbricazione + prompt fare/non fare.
Errori comuni
- Richiesta di denominazione del token senza esempio. Il modello genera nomi estranei al tuo sistema; la consistenza è rotta.
- Aggiunta di componenti senza cercare contraddizioni. La duplicazione è l’arcinemico del sistema.
- Supponendo che il comportamento inventato dal modello sia corretto. L'intelligenza artificiale non conosce il comportamento effettivo del componente.
- Accettare la valutazione di accessibilità senza test. Il promemoria standard non sostituisce il test vero e proprio.
- Scrivere la documentazione una volta e non aggiornarla. Il documento dovrebbe essere aggiornato man mano che il sistema cambia.
In sintesi
Il sistema di progettazione è l'infrastruttura di coerenza e scalabilità; ma la sua manutenzione è spesso trascurata perché richiede molto testo ed è ripetitiva. L'intelligenza artificiale affronta questo debito producendo rapidamente documentazione dei componenti, esempi di cose da fare/non fare, script di utilizzo e bozze di denominazione dei token. Ma l'essenza del sistema è la singolarità e la coerenza: ogni nome di token deve essere verificato rispetto allo schema campione, ogni proposta di componente deve essere scansionata in modo contraddittorio, ogni descrizione di comportamento deve essere verificata rispetto alla realtà. Utilizzare il modello come un efficiente disegnatore; La squadra prende la decisione giusta individuale.
Compito dell'applicazione
- Seleziona un componente con documentazione mancante e produci una bozza di documento al primo prompt.
- Completa i campi contrassegnati "La squadra deve compilare" con il comportamento reale.
- Con il secondo prompt, converti i tuoi 8-10 token nello schema semantico e crea una tabella dei nomi vecchia/nuova.
- Per un'idea di un nuovo componente, cerca le contraddizioni con il terzo suggerimento.
- Con il quarto prompt, generare coppie di esempio da/non fare per un componente e aggiungerle al sistema.
lista di controllo
- [] Ho collegato la denominazione del token allo schema di esempio.
- [ ] Ho scansionato i nuovi componenti per individuare eventuali conflitti.
- [ ] Ho verificato i comportamenti modellizzati con la realtà.
- [] Avevo pianificato di confermare le note sull'accessibilità con test effettivi.
- [ ] Ho mantenuto la documentazione in un formato coerente.
- [ ] Ho preservato la singolarità e impedito la duplicazione.