Gevinster:
- Evne til å tegne og lage konsistente designtokens, komponentnavn og bruksregler med kunstig intelligens
- Evne til raskt å produsere komponentdokumentasjon, gjør/ikke-eksempler og brukstekster med kunstig intelligens
- Evne til å sjekke kunstig intelligens forslag for konflikt med det eksisterende designsystemet og bevare singularitet
Et designsystem er det vanlige språket som får en produktfamilie til å se ut og oppføre seg konsekvent: gjenbrukbare komponenter (knapp, kort, skjemafelt), designsymboler (navngitte definisjoner av verdier som farge, avstand, typografi) og dokumentasjon som forklarer hvordan de skal brukes. Et godt designsystem lar ti designere designe det samme produktet som om det var produsert av en enkelt kilde. Å installere og vedlikeholde dette systemet er slitsomt, repeterende og tekstkrevende arbeid; Det er akkurat her kunstig intelligens skinner. Men essensen av systemet er singularitet og konsistens; AI sine anbefalinger kan ikke aksepteres uten å bli sjekket for konflikt med dagens system.
Tokens og navngivning: grunnlaget for konsistens
Et designtoken er en navngitt gjenbruksverdi for en designbeslutning: farge-primær, space-center, tekst-tittel-hovedstad. Takket være tokens kan du endre en farge på ett sted og oppdatere den på tvers av hele produktet. Men kraften til tokens avhenger av konsistensen i navngivningen; Hvis blå-1, hoved-blå, primærblå brukes blandet, vil systemet krasje.
AI er god til to ting her: gjennomgå det eksisterende tokensettet ditt mot et konsistent navneskjema, og foreslå skjemakompatible navn for nye tokens. En forespørsel som "Oversett denne tokenlisten til semantisk (betydningsbasert) navngivning" vil hjelpe deg med å generere navn som formidler mening, for eksempel farge-handling-primær i stedet for blå-500. Men den endelige navneavgjørelsen er lagets kontrakt; Modellen gir kun en disposisjon.
Tips: Når du navngir tokens til AI, gi 5-6 eksempler på ditt nåværende opplegg og si "behold i samme mønster". Den prøveløse forespørselen produserer navn som er fremmede for systemet ditt.
Komponentdokumentasjon: det mest produktive området innen AI
En komponents dokumentasjon inkluderer: hva den gjør, når den skal brukes, når den ikke skal brukes, dens varianter, tilstander (standard, hover, passiv, feil), tilgjengelighetsmerknader og "gjør/ikke"-eksempler. Å skrive disse tekstene for hånd tar timer, og derfor forsømmer mange team dokumentasjon.
AI fyller dette gapet: når du beskriver en komponent, produserer den utkast til dokumentasjon, bruksregler og gjør/ikke-eksempler i et konsistent format. Dermed går dokumentasjon fra «det er ingen» til «det er et utkast, det skal ordnes», noe som er en stor gevinst. Modellen kjenner imidlertid ikke den faktiske oppførselen til komponenten; Det er din jobb å matche reglene det produserer med systemets virkelighet.
dokumentfragment
Bidrag av kunstig intelligens
menneskelig verifisering
Hva gjør det?
Klar disposisjonsdefinisjon
Ekte fitness for formålet
Når du skal bruke
Generelle scenarier
Produktspesifikke regler
Gjør/Ikke-eksempler
Rask utkast par
Faktiske misbruk
Tilgjengelighetsmerknad
Standard påminnelser
Bekreftet av ekte test
Variant/saksliste
mulig liste
De som faktisk eksisterer i systemet
Kontradiksjonskontroll: bevaring av singularitet
Erkefienden til designsystemet er duplisering: to knapper som gjør samme jobb, to forskjellige romskalaer, to motstridende regler. Når AI foreslår en ny komponent eller regel, kan det forslaget komme i konflikt med det eksisterende systemet – det har ikke hele modellsystemet i tankene. Så jeg vurderer hvert forslag ved å spørre "konflikter dette med noe som allerede eksisterer?" Filtrer med spørsmålet. Du kan også bruke kunstig intelligens i konfliktskanning: du kan gi gjeldende systemsammendrag og den nye anbefalingen og få konfliktene listet opp. Men den endelige "entallsriktige" avgjørelsen er opp til laget.
tre minisaker
Sak 1 — Dokumentasjonsgjeld slettet. Bare 6 av et teams 24 komponenter hadde dokumentasjon. Det ble laget utkast til dokumenter for de resterende 18 komponentene med kunstig intelligens; Laget fikset hver enkelt på 10-15 minutter. Jobben, som ble utsatt i flere uker, ble utført på to dager.
Tilfelle 2 - Token-navngivning ble konsistent. I ett system ble fargene blandet som blue1, mainBlue, brand-blue. AI oversatte eksisterende 40 tokens til semantisk skjema; Teamet reviderte den og byttet til en enkelt standard. Fargefeil ble merkbart redusert i påfølgende design.
Sak 3 – Motstridende komponent ble avvist. AI foreslo en ny komponent kalt "sekundær handlingsknapp". Da teamet søkte etter motsetninger, fant de ut at det gjorde samme jobben som den eksisterende "spøkelsesknappen" og avviste forslaget. Leksjon: ikke alle forslag legger til en ny komponent til systemet; Noen ganger er det riktig å bruke det som er tilgjengelig.
Kopiérbare spørsmål
Din rolle: design systemadministrator.Dokumenter denne komponenten: <<komponent og dens virkemåte>>.Format: Hva gjør den | Når skal du bruke | Når IKKE skal brukes |Varianter | Situasjoner | Tilgjengelighetsmerknader | 2 Gjør / 2 Ikke eksempel. Lag opp atferd du ikke kjenner; Skriv "laget må fylle ut".
Oversett denne listen over tokens til et semantisk (betydningsbasert) navneskjema. Mine nåværende skjemaeksempler: <<5-6 eksempler>>. Fortsett i samme mønster. For hver token, oppgi gammelt navn -> nytt navn -> begrunnelsestabell. Liste: <<tokens>>
Skann etter motsetninger: Sammendrag av mitt nåværende designsystem: <<sammendrag>>. Ny foreslått komponent/regel: <<forslag>>. Er dette forslaget i konflikt med det eksisterende systemet (komponent som gjør samme jobb, motstridende regel, duplikattoken)? List opp konfliktene og ditt forslag.
Generer "gjør/ikke" eksempelpar for denne komponenten: realistisk korrekt bruk og realistiske feilbruksscenarier. For hvert par, forklar i én setning hvorfor det er sant/usant. Komponent: <<navn og formål>>
Svak forespørsel / Sterk forespørsel
Svak: "Skriv dokumentasjon for denne knappen."
Resultat: En generell, formatert tekst uten tilknytning til systemet.
Sterkt: "Dokumenter denne knappen i følgende format (hva den gjør / når den ikke skal brukes / varianter / tilfeller / tilgjengelighet / ikke gjør det); lag opp atferd du ikke kjenner, skriv 'teamet må fylle ut'."
Resultat: Konsekvent formatert, riktig avstand, redigerbart manuskript.
Forskjell: sterkt ledetekstformat + fabrikasjonsforbud + gjør/ikke-oppfordringer.
Vanlige feil
- Be om tokennavn uten eksempel. Modellen genererer navn som er fremmede for systemet ditt; konsistensen er brutt.
- Legge til komponenter uten å skanne etter motsetninger. Duplisering er systemets erkefiende.
- Forutsatt at atferden funnet opp av modellen er riktig. AI kjenner ikke den faktiske oppførselen til komponenten.
- Godta tilgjengelighetsvurderingen uten å teste. Standard påminnelse er ikke en erstatning for faktisk testing.
- Skrive dokumentasjonen en gang og ikke oppdatere den. Dokumentet bør oppdateres etter hvert som systemet endres.
Oppsummert
Designsystemet er infrastrukturen for konsistens og skalerbarhet; men vedlikeholdet blir ofte neglisjert fordi det er tekstkrevende og repeterende. AI adresserer denne gjelden ved å raskt produsere komponentdokumentasjon, gjør/ikke-eksempler, bruksskript og utkast til tokennavn. Men essensen av systemet er singularitet og konsistens: hvert tokennavn må verifiseres mot prøveskjemaet, hvert komponentforslag må være motstridende skannet, hver beskrivelse av atferd må verifiseres mot virkeligheten. Bruk modellen som en effektiv tegner; Teamet tar den individuelle riktige avgjørelsen.
Søknadsoppgave
- Velg en komponent med manglende dokumentasjon og lag et utkast til dokument med den første ledeteksten.
- Fyll ut feltene merket "Team må fylle ut" med faktisk oppførsel.
- Med den andre ledeteksten, konverter dine 8-10 tokens til det semantiske skjemaet og lag en gammel/ny navnetabell.
- For en ny komponentide, skann etter motsetninger med den tredje ledeteksten.
- Med den fjerde ledeteksten genererer du gjør/ikke-eksempelpar for en komponent og legger dem til i systemet.
sjekkliste
- [ ] Jeg koblet tokennavnet til eksempelskjemaet.
- [ ] Jeg skannet de nye komponentene for konflikter.
- [ ] Jeg bekreftet den modelllagde atferden med virkeligheten.
- [ ] Jeg planla å bekrefte tilgjengelighetsnotatene med faktisk testing.
- [ ] Jeg oppbevarte dokumentasjonen i et konsistent format.
- [ ] Jeg bevarte singulariteten og forhindret duplisering.