Ontwerpsysteem: kunstmatige intelligentie in componenten, token en documentatie — Kunstmatige intelligentie in UI/UX-ontwerp

Winst:

Mogelijkheid om consistente ontwerptokens, componentnaamgeving en gebruiksregels op te stellen en te maken met kunstmatige intelligentie
Mogelijkheid om snel componentdocumentatie, do/don't-voorbeelden en gebruiksteksten te produceren met kunstmatige intelligentie
Mogelijkheid om suggesties voor kunstmatige intelligentie te controleren op conflicten met het bestaande ontwerpsysteem en de singulariteit te behouden

Een ontwerpsysteem is de gemeenschappelijke taal die ervoor zorgt dat een productfamilie er consistent uitziet en zich consistent gedraagt: herbruikbare componenten (knop, kaart, formulierveld), ontwerptokens (benoemde definities van waarden zoals kleur, spatiëring, typografie) en documentatie die uitlegt hoe ze te gebruiken. Met een goed ontwerpsysteem kunnen tien ontwerpers hetzelfde product ontwerpen alsof het door één enkele bron zou zijn geproduceerd. Het installeren en onderhouden van dit systeem is vermoeiend, repetitief en tekstintensief werk; Dit is precies waar kunstmatige intelligentie uitblinkt. Maar de essentie van het systeem is singulariteit en consistentie; De aanbevelingen van AI kunnen niet worden aanvaard zonder te worden gecontroleerd op conflicten met het huidige systeem.

Tokens en naamgeving: de basis voor consistentie

Een ontwerptoken is een benoemde, herbruikbare waarde van een ontwerpbeslissing: kleur-primair, spatie-centrum, tekst-titel-hoofdletter. Dankzij tokens kun je op één plek een kleur veranderen en deze voor het hele product bijwerken. Maar de kracht van tokens hangt af van de consistentie van de naamgeving; Als blauw-1, hoofd-blauw en primairblauw gemengd worden gebruikt, crasht het systeem.

AI is hier goed in twee dingen: het beoordelen van uw bestaande tokenset aan de hand van een consistent naamgevingsschema, en het voorstellen van schema-compatibele namen voor nieuwe tokens. Een verzoek als 'Vertaal deze tokenlijst naar semantische (op betekenis gebaseerde) naamgeving' helpt u bij het genereren van namen die betekenis overbrengen, zoals kleuractie-primair in plaats van blauw-500. Maar de uiteindelijke naamgevingsbeslissing is het contract van het team; Het model geeft slechts een schets.

Tip: Wanneer u tokens een naam geeft aan AI, geef dan 5-6 voorbeelden van uw huidige schema en zeg "blijf in hetzelfde patroon". Het voorbeeldloze verzoek produceert namen die vreemd zijn aan uw systeem.

Componentdocumentatie: het meest productieve gebied van AI

De documentatie van een component omvat: wat het doet, wanneer het wel en wanneer niet moet worden gebruikt, de varianten, statussen (standaard, hover, passief, fout), toegankelijkheidsopmerkingen en "doe/niet"-voorbeelden. Het met de hand schrijven van deze teksten kost uren, en daarom verwaarlozen veel teams de documentatie.

AI vult deze leemte op: wanneer u een component beschrijft, produceert het conceptdocumentatie, gebruiksregels en voorbeelden van wel/niet doen in een consistent formaat. De documentatie gaat dus van "er is geen" naar "er is een concept, het zal worden opgelost", wat een grote winst is. Het model kent echter niet het daadwerkelijke gedrag van de component; Het is jouw taak om de regels die het produceert af te stemmen op de realiteit van het systeem.

documentfragment

Bijdrage van kunstmatige intelligentie

menselijke verificatie

Wat doet het?

Duidelijke schetsdefinitie

Echte geschiktheid voor een doel

Wanneer te gebruiken

Algemene scenario's

Productspecifieke regels

Voorbeelden van wel/niet doen

Snelle trekparen

Feitelijke misbruiken

Toegankelijkheidsnota

Standaard herinneringen

Bevestigd door echte test

Variant/casuslijst

mogelijke lijst

Degenen die daadwerkelijk in het systeem bestaan

Controle van tegenstrijdigheden: behoud van singulariteit

De aartsvijand van het ontwerpsysteem is duplicatie: twee knoppen die hetzelfde werk doen, twee verschillende ruimteschalen, twee tegenstrijdige regels. Wanneer AI een nieuw onderdeel of nieuwe regel voorstelt, kan die suggestie in strijd zijn met het bestaande systeem; het houdt niet uw hele modelsysteem in gedachten. Dus evalueer ik elke suggestie door te vragen: "Is dit in strijd met iets dat al bestaat?" Filter met de vraag. Ook bij conflictscanning kun je kunstmatige intelligentie inzetten: je kunt het huidige systeemoverzicht en de nieuwe aanbeveling geven en de conflicten laten inventariseren. Maar de uiteindelijke “enkelvoudig correcte” beslissing is aan het team.

drie minikoffers

Geval 1 — Documentatieschuld vereffend. Slechts 6 van de 24 componenten van een team hadden documentatie. Voor de overige 18 onderdelen met kunstmatige intelligentie zijn conceptdocumenten opgesteld; Het team repareerde ze allemaal in 10-15 minuten. De klus, die weken werd uitgesteld, was in twee dagen geklaard.

Geval 2 – De naamgeving van tokens werd consistent. In één systeem werden de kleuren gemengd zoals blauw1, hoofdblauw, merkblauw. AI vertaalde de bestaande 40 tokens naar een semantisch schema; Het team herzag het en schakelde over op één enkele standaard. Kleurfouten werden merkbaar verminderd in volgende ontwerpen.

Geval 3 — Conflicterende component werd afgewezen. AI stelde een nieuwe component voor, genaamd ‘secundaire actieknop’. Toen het team naar tegenstrijdigheden zocht, ontdekten ze dat deze hetzelfde werk deed als de bestaande "spookknop" en verwierpen ze de suggestie. Les: niet elke suggestie voegt een nieuw onderdeel aan het systeem toe; Soms is het goed om te gebruiken wat beschikbaar is.

Kopieerbare aanwijzingen

Vertaal deze lijst met tokens naar een semantisch (op betekenis gebaseerd) naamgevingsschema. Mijn huidige schemavoorbeelden: <<5-6 voorbeelden>>. Ga verder in hetzelfde patroon. Geef voor elk token de oude naam -> nieuwe naam -> rechtvaardigingstabel op. Lijst: <<tokens>>

Scannen op tegenstrijdigheden: Samenvatting van mijn huidige ontwerpsysteem: <<samenvatting>>. Nieuw voorgesteld onderdeel/regel: <<suggestie>>. Is deze suggestie in strijd met het bestaande systeem (component die dezelfde taak vervult, conflicterende regel, duplicaattoken)? Maak een lijst van de conflicten en uw suggestie.

Genereer "doe/niet"-voorbeeldparen voor dit onderdeel: realistisch correct gebruik en realistische scenario's voor onjuist gebruik. Leg voor elk paar in één zin uit waarom het waar/niet waar is. Component: <<naam en doel>>

Zwakke prompt/sterke prompt

Zwak: "Schrijf documentatie voor deze knop."

Resultaat: een algemene, opgemaakte tekst zonder verbinding met het systeem.

Strong: "Documenteer deze knop in het volgende formaat (wat hij doet / wanneer niet gebruiken / varianten / cases / toegankelijkheid / niet doen); verzin gedrag dat je niet kent, schrijf 'team moet invullen'."

Resultaat: consistent opgemaakt, op de juiste afstand geplaatst, bewerkbaar manuscript.

Verschil: sterk promptformaat + fabricageverbod + wel/niet-prompts.

Veel voorkomende fouten

Tokennaamgeving aanvragen zonder voorbeeld. Het model genereert namen die vreemd zijn aan uw systeem; consistentie is verbroken.
Componenten toevoegen zonder te zoeken naar tegenstrijdigheden. Duplicatie is de aartsvijand van het systeem.
Ervan uitgaande dat het door het model bedachte gedrag correct is. AI kent het daadwerkelijke gedrag van de component niet.
De toegankelijkheidsbeoordeling accepteren zonder te testen. Standaardherinneringen zijn geen vervanging voor daadwerkelijke tests.
De documentatie één keer schrijven en niet bijwerken. Het document moet worden bijgewerkt als het systeem verandert.

Samengevat

Het ontwerpsysteem is de infrastructuur van consistentie en schaalbaarheid; maar het onderhoud ervan wordt vaak verwaarloosd omdat het tekstintensief en repetitief is. AI pakt deze achterstand aan door snel componentdocumentatie, wel/niet-voorbeelden, gebruiksscripts en concepten voor de naamgeving van tokens te produceren. Maar de essentie van het systeem is singulariteit en consistentie: elke tokennaam moet worden geverifieerd aan de hand van het voorbeeldschema, elk componentvoorstel moet op tegenstrijdigheden worden gescand, elke beschrijving van gedrag moet worden geverifieerd aan de hand van de werkelijkheid. Gebruik het model als een efficiënte tekenaar; Het team neemt de individueel juiste beslissing.

Applicatie taak

Selecteer een onderdeel met ontbrekende documentatie en maak meteen een conceptdocument.
Vul de velden gemarkeerd met 'Team moet invullen' in met feitelijk gedrag.
Met de tweede prompt converteert u uw 8-10 tokens naar het semantische schema en maakt u een oude/nieuwe naamtabel.
Voor een nieuw componentidee scant u op tegenstrijdigheden met de derde prompt.
Met de vierde prompt genereert u wel/niet-voorbeeldparen voor een component en voegt u deze toe aan het systeem.

controlelijst

[ ] Ik heb de tokennaamgeving aan het voorbeeldschema gekoppeld.
[ ] Ik heb de nieuwe componenten gescand op conflicten.
[ ] Ik verifieerde het door modellen gemaakte gedrag met de werkelijkheid.
[ ] Ik was van plan de toegankelijkheidsnotities te bevestigen met daadwerkelijke tests.
[ ] Ik heb de documentatie in een consistent formaat bewaard.
[ ] Ik bewaarde de singulariteit en voorkwam dubbel werk.