Vinster:
- Förmåga att rita och skapa konsekventa designtokens, komponentnamn och användningsregler med artificiell intelligens
- Förmåga att snabbt ta fram komponentdokumentation, gör/inte-exempel och användningstexter med artificiell intelligens
- Förmåga att kontrollera artificiell intelligensförslag för konflikt med det befintliga designsystemet och bevara singularitet
Ett designsystem är det vanliga språket som får en produktfamilj att se ut och bete sig konsekvent: återanvändbara komponenter (knapp, kort, formulärfält), designsymboler (namngivna definitioner av värden som färg, mellanrum, typografi) och dokumentation som förklarar hur man använder dem. Ett bra designsystem tillåter tio designers att designa samma produkt som om den hade producerats av en enda källa. Att installera och underhålla detta system är tröttsamt, repetitivt och textintensivt arbete; Det är precis där artificiell intelligens lyser. Men kärnan i systemet är singularitet och konsekvens; AI:s rekommendationer kan inte accepteras utan att kontrolleras för konflikt med det nuvarande systemet.
Polletter och namngivning: grunden för konsekvens
En designtoken är ett namngivet, återanvändbart värde för ett designbeslut: färg-primär, space-center, text-titel-huvudstad. Tack vare tokens kan du ändra en färg på ett ställe och uppdatera den över hela produkten. Men styrkan hos tokens beror på konsistensen i namngivningen; Om blue-1, main-blue, primaryBlue används blandat kommer systemet att krascha.
AI är bra på två saker här: granska din befintliga token-uppsättning mot ett konsekvent namnschema, och föreslå schemakompatibla namn för nya tokens. En begäran som "Översätt den här tokenlistan till semantisk (betydelsesbaserad) namngivning" hjälper dig att generera namn som förmedlar mening, till exempel color-action-primary istället för blue-500. Men det slutgiltiga namnbeslutet är lagets kontrakt; Modellen ger bara en disposition.
Tips: När du namnger tokens till AI, ge 5-6 exempel på ditt nuvarande schema och säg "håll i samma mönster". Den provlösa begäran producerar namn som är främmande för ditt system.
Komponentdokumentation: det mest produktiva området för AI
En komponents dokumentation inkluderar: vad den gör, när den ska användas, när den inte ska användas, dess varianter, tillstånd (standard, hovra, passiv, fel), tillgänglighetsanteckningar och "gör/gör inte"-exempel. Att skriva dessa texter för hand tar timmar, varför många team struntar i dokumentation.
AI fyller denna lucka: när du beskriver en komponent producerar den utkast till dokumentation, användningsregler och gör/gör inte-exempel i ett konsekvent format. Alltså går dokumentation från "det finns inget" till "det finns ett utkast, det kommer att fixas", vilket är en stor vinst. Men modellen känner inte till det faktiska beteendet hos komponenten; Det är ditt jobb att matcha reglerna som det producerar med systemets verklighet.
dokumentfragment
Bidrag av artificiell intelligens
mänsklig verifiering
Vad gör det?
Tydlig dispositionsdefinition
Sann kondition för ändamålet
När ska användas
Allmänna scenarier
Produktspecifika regler
Gör/gör inte exempel
Snabba dragpar
Verkliga missbruk
Tillgänglighetsanmärkning
Standardpåminnelser
Bekräftad av ett riktigt test
Variant-/ärendelista
möjlig lista
De som faktiskt finns i systemet
Kontroll av motsägelser: att bevara singularitet
Designsystemets ärkefiende är dubbelarbete: två knappar som gör samma jobb, två olika rymdskalor, två motstridiga regler. När AI föreslår en ny komponent eller regel kan det förslaget komma i konflikt med det befintliga systemet – det har inte hela ditt modellsystem i åtanke. Så jag utvärderar varje förslag genom att fråga "kommer detta i konflikt med något som redan finns?" Filtrera med frågan. Du kan också använda artificiell intelligens i konfliktskanning: du kan ge den nuvarande systemsammanfattningen och den nya rekommendationen och få konflikterna listade. Men det slutliga "singular korrekta" beslutet är upp till laget.
tre minifodral
Fall 1 — Dokumentationsskuld rensad. Endast 6 av ett teams 24 komponenter hade dokumentation. Utkast till dokument togs fram för de återstående 18 komponenterna med artificiell intelligens; Laget fixade var och en på 10-15 minuter. Jobbet, som sköts upp i veckor, slutfördes på två dagar.
Fall 2 – Tokennamn blev konsekvent. I ett system blandades färgerna som blue1, mainBlue, brand-blue. AI översatte befintliga 40 tokens till semantiskt schema; Teamet reviderade det och bytte till en enda standard. Färgfel minskade märkbart i efterföljande design.
Fall 3 – Motstridig komponent avslogs. AI föreslog en ny komponent som heter "sekundär åtgärdsknapp". När teamet sökte efter motsägelser fann de att det gjorde samma jobb som den befintliga "spökknappen" och avvisade förslaget. Lärdom: inte alla förslag lägger till en ny komponent i systemet; Ibland är det rätt att använda det som finns.
Kopieringsbara uppmaningar
Din roll: designsystemadministratör.Dokumentera denna komponent: <<komponent och dess beteende>>.Format: Vad gör den | När ska du använda | När ska man INTE använda |Varianter | Situationer | Tillgänglighetsanteckningar | 2 Gör / 2 Gör inte exempel. Hitta på beteende du inte känner till; Skriv "laget måste fylla i".
Översätt den här listan med tokens till ett semantiskt (betydelsesbaserat) namnschema. Mina nuvarande schemaexempel: <<5-6 exempel>>. Fortsätt i samma mönster. För varje token, ange gammalt namn -> nytt namn -> motiveringstabell. Lista: <<tokens>>
Sök efter motsägelser: Sammanfattning av mitt nuvarande designsystem: <<sammanfattning>>. Ny föreslagen komponent/regel: <<förslag>>. Kommer det här förslaget i konflikt med det befintliga systemet (komponent som gör samma jobb, motstridig regel, duplicerad token)? Lista konflikterna och ditt förslag.
Generera "gör/gör inte" exempelpar för denna komponent: realistisk korrekt användning och realistiska felaktiga användningsscenarier. För varje par, förklara i en mening varför det är sant/falskt. Komponent: <<namn och syfte>>
Svag prompt / Stark prompt
Svag: "Skriv dokumentation för den här knappen."
Resultat: En allmän, formaterad text utan koppling till systemet.
Stark: "Dokumentera den här knappen i följande format (vad den gör / när den inte ska användas / varianter / fall / tillgänglighet / gör-inte); hitta på beteende du inte känner till, skriv 'teamet måste fylla i'."
Resultat: Konsekvent formaterat, korrekt fördelat, redigerbart manuskript.
Skillnad: starkt uppmaningsformat + tillverkningsförbud + gör/gör inte-uppmaningar.
Vanliga misstag
- Begär tokennamn utan exempel. Modellen genererar namn som är främmande för ditt system; konsistensen är bruten.
- Lägga till komponenter utan att skanna efter motsägelser. Duplicering är systemets ärkefiende.
- Förutsatt att beteendet som modellen uppfunnit är korrekt. AI känner inte till det faktiska beteendet hos komponenten.
- Accepterar tillgänglighetsbetyget utan att testa. Standardpåminnelse är inte en ersättning för faktiska tester.
- Att skriva dokumentationen en gång och inte uppdatera den. Dokumentet bör uppdateras när systemet ändras.
Sammanfattningsvis
Designsystemet är infrastrukturen för konsekvens och skalbarhet; men dess underhåll försummas ofta eftersom det är textintensivt och repetitivt. AI åtgärdar denna skuld genom att snabbt producera komponentdokumentation, gör/gör inte-exempel, användningsskript och utkast till namngivning av token. Men kärnan i systemet är singularitet och konsistens: varje tokennamn måste verifieras mot exempelschemat, varje komponentförslag måste genomsökas motsägelsefullt, varje beskrivning av beteende måste verifieras mot verkligheten. Använd modellen som en effektiv ritare; Teamet fattar det individuella rätta beslutet.
Applikationsuppgift
- Välj en komponent med saknad dokumentation och skapa ett utkast till dokument med den första uppmaningen.
- Fyll i fälten märkta "Team måste fylla i" med verkligt beteende.
- Med den andra prompten, konvertera dina 8-10 tokens till det semantiska schemat och skapa en gammal/ny namntabell.
- För en ny komponentidé, skanna efter motsägelser med den tredje prompten.
- Med den fjärde prompten, generera gör/gör inte-exempelpar för en komponent och lägg till dem i systemet.
checklista
- [ ] Jag länkade tokennamnet till exempelschemat.
- [ ] Jag skannade de nya komponenterna efter konflikter.
- [ ] Jag verifierade de modelltillverkade beteendena med verkligheten.
- [ ] Jag planerade att bekräfta tillgänglighetsanteckningarna med faktiska tester.
- [ ] Jag förvarade dokumentationen i ett konsekvent format.
- [ ] Jag bevarade singulariteten och förhindrade dubbelarbete.