Dizaina sistēma: mākslīgais intelekts komponentos, marķieros un dokumentācijā — Mākslīgais intelekts UI/UX dizainā

Ieguvumi:

Spēja ar mākslīgo intelektu izstrādāt un izveidot konsekventus dizaina marķierus, komponentu nosaukumus un lietošanas noteikumus
Spēja ātri izveidot komponentu dokumentāciju, darīt/nedarīt piemērus un lietojuma tekstus ar mākslīgo intelektu
Spēja pārbaudīt mākslīgā intelekta ieteikumus pretrunā ar esošo projektēšanas sistēmu un saglabāt singularitāti

Dizaina sistēma ir izplatīta valoda, kas liek produktu saimei izskatīties un rīkoties konsekventi: atkārtoti lietojami komponenti (poga, kartīte, veidlapas lauks), dizaina marķieri (nosaukti vērtību definīcijas, piemēram, krāsa, atstarpes, tipogrāfija) un dokumentācija, kas izskaidro to lietošanu. Laba dizaina sistēma ļauj desmit dizaineriem izstrādāt vienu un to pašu produktu tā, it kā tas būtu ražots no viena avota. Šīs sistēmas uzstādīšana un uzturēšana ir nogurdinošs, atkārtojošs un teksta ietilpīgs darbs; Tieši šeit mirdz mākslīgais intelekts. Taču sistēmas būtība ir savdabība un konsekvence; AI ieteikumus nevar pieņemt, nepārbaudot, vai tie nav pretrunā ar pašreizējo sistēmu.

Žetoni un nosaukumu piešķiršana: konsekvences pamats

Dizaina marķieris ir nosaukta, atkārtoti lietojama dizaina lēmuma vērtība: primārā krāsa, atstarpes centrs, teksts-virsraksts-lielais burts. Pateicoties žetoniem, jūs varat mainīt krāsu vienuviet un atjaunināt to visā izstrādājumā. Bet žetonu spēks ir atkarīgs no nosaukumu konsekvences; Ja zilais-1, galvenais-zilais, primārais zilais tiek izmantots jaukts, sistēma avarē.

AI ir labas divās lietās: esošās marķieru kopas pārskatīšana, salīdzinot ar konsekventu nosaukšanas shēmu, un shēmu saderīgu nosaukumu ierosināšana jauniem marķieriem. Pieprasījums, piemēram, “Tulkot šo marķieru sarakstu semantiskajā (nozīmē balstītā) nosaukšanā”, palīdzēs ģenerēt nosaukumus, kas izsaka nozīmi, piemēram, krāsa-darbība-primary, nevis zils-500. Bet galīgais lēmums par nosaukuma piešķiršanu ir komandas līgums; Modelis sniedz tikai kontūru.

Padoms. Nosaucot marķierus AI, sniedziet 5–6 pašreizējās shēmas piemērus un sakiet "saglabājiet to pašu modeli". Bezizlases pieprasījums rada nosaukumus, kas jūsu sistēmai ir sveši.

Komponentu dokumentācija: AI visproduktīvākā joma

Komponenta dokumentācijā ir ietverta informācija par to, ko tas dara, kad to izmantot, kad to neizmantot, tā variantus, stāvokļus (noklusējums, kursora novietošana, pasīvais, kļūda), pieejamības piezīmes un "darīt/nelietot" piemērus. Šo tekstu rakstīšana ar roku aizņem stundas, tāpēc daudzas komandas neņem vērā dokumentāciju.

AI aizpilda šo nepilnību: aprakstot komponentu, tas konsekventā formātā sagatavo dokumentācijas uzmetumus, lietošanas noteikumus un piemērus. Tādējādi dokumentācija no "nav" uz "ir melnraksts, tas tiks labots", kas ir liels ieguvums. Tomēr modelis nezina komponenta faktisko uzvedību; Jūsu uzdevums ir saskaņot tās radītos noteikumus ar sistēmas realitāti.

dokumenta fragments

Mākslīgā intelekta ieguldījums

cilvēka pārbaude

Ko tas dara?

Skaidra kontūras definīcija

Patiesa atbilstība mērķim

Kad lietot

Vispārīgi scenāriji

Preces specifiskie noteikumi

Nedarīt/nelietot piemērus

Ātrā drafta pāri

Reāla ļaunprātīga izmantošana

Pieejamības piezīme

Standarta atgādinājumi

Apstiprināts ar reālu testu

Variantu/gadījumu saraksts

iespējamais saraksts

Tie, kas reāli pastāv sistēmā

Pretrunu pārbaude: singularitātes saglabāšana

Dizaina sistēmas galvenais ienaidnieks ir dublēšanās: divas pogas, kas veic vienu un to pašu darbu, divas dažādas telpas skalas, divi pretrunīgi noteikumi. Kad AI ierosina jaunu komponentu vai noteikumu, šis ieteikums var būt pretrunā esošajai sistēmai — tas nepatur prātā visu jūsu modeļa sistēmu. Tāpēc es novērtēju katru ieteikumu, uzdodot jautājumu "vai tas ir pretrunā ar kaut ko, kas jau pastāv?" Filtrējiet ar jautājumu. Konfliktu skenēšanā varat izmantot arī mākslīgo intelektu: varat sniegt pašreizējās sistēmas kopsavilkumu un jauno ieteikumu un uzskaitīt konfliktus. Bet galīgo "vienskaitli pareizo" lēmumu pieņem komanda.

trīs mini futrāļi

1. gadījums — dokumentācijas parāds nodzēsts. Tikai 6 no 24 komandas sastāvdaļām bija dokumentācija. Pārējām 18 komponentēm ar mākslīgo intelektu tika izstrādāti dokumentu projekti; Komanda katru laboja 10-15 minūšu laikā. Darbs, kas tika atlikts nedēļām, tika paveikts divās dienās.

2. gadījums — marķieru nosaukumi kļuva konsekventi. Vienā sistēmā krāsas tika sajauktas kā blue1, mainBlue, brand-blue. AI tulkoja esošos 40 marķierus semantiskā shēmā; Komanda to pārskatīja un pārgāja uz vienotu standartu. Turpmākajos dizainos krāsu kļūdas tika ievērojami samazinātas.

3. gadījums — konfliktējošā sastāvdaļa tika noraidīta. AI ierosināja jaunu komponentu ar nosaukumu “sekundārās darbības poga”. Kad komanda meklēja pretrunas, viņi atklāja, ka tā veic to pašu darbu kā esošā "spoku poga", un noraidīja ieteikumu. Nodarbība: ne katrs ieteikums sistēmai pievieno jaunu komponentu; Dažreiz ir pareizi izmantot to, kas ir pieejams.

Kopējamas uzvednes

Tulkojiet šo marķieru sarakstu semantiskā (uz nozīmi balstītā) nosaukšanas shēmā. Mani pašreizējie shēmas piemēri: <<5-6 piemēri>>. Turpiniet to pašu modeli. Katram marķierim norādiet veco nosaukumu -> jauno nosaukumu -> pamatojumu tabulu. Saraksts: <<tokens>>

Meklēt pretrunas: Manas pašreizējās dizaina sistēmas kopsavilkums: <<kopsavilkums>>. Jauns ierosinātais komponents/noteikums: <<ieteikums>>. Vai šis ieteikums ir pretrunā ar esošo sistēmu (komponents, kas veic to pašu darbu, konfliktējoša kārtula, pilnvaras dublikāts)? Uzskaitiet konfliktus un savus ieteikumus.

Šim komponentam ģenerējiet “darīt/nedarīt” piemēru pārus: reālistisku pareizu lietojumu un reālus nepareizas lietošanas scenārijus. Katram pārim vienā teikumā paskaidrojiet, kāpēc tas ir patiess/nepatiess. Komponents: <<nosaukums un mērķis>>

Vāja uzvedne / spēcīga uzvedne

Vāji: "Rakstiet šīs pogas dokumentāciju."

Rezultāts: vispārīgs, formatēts teksts bez savienojuma ar sistēmu.

Spēcīgs: "Dokumentējiet šo pogu šādā formātā (ko tā dara / kad neizmanto / varianti / gadījumi / pieejamība / nedarīt); izdomājiet uzvedību, kuru nezināt, ierakstiet "komanda ir jāaizpilda"."

Rezultāts: konsekventi formatēts, pareizi izvietots, rediģējams manuskripts.

Atšķirība: spēcīgs uzvednes formāts + izgatavošanas aizliegums + norādījumi darīt/nelietot.

Biežas kļūdas

Tokena nosaukšanas pieprasīšana bez piemēra. Modelis ģenerē jūsu sistēmai svešus nosaukumus; konsistence ir salauzta.
Komponentu pievienošana, nepārbaudot pretrunas. Dublēšanās ir sistēmas galvenais ienaidnieks.
Pieņemot, ka modeļa izdomātā uzvedība ir pareiza. AI nezina komponenta faktisko uzvedību.
Pieejamības vērtējuma pieņemšana bez pārbaudes. Standarta atgādinājums neaizstāj faktisko pārbaudi.
Dokumentācijas rakstīšana vienreiz un neatjaunināšana. Dokuments ir jāatjaunina, mainoties sistēmai.

Rezumējot

Projektēšanas sistēma ir konsekvences un mērogojamības infrastruktūra; bet tā uzturēšana bieži tiek atstāta novārtā, jo tajā ir daudz teksta un tas atkārtojas. AI novērš šo parādu, ātri sagatavojot komponentu dokumentāciju, nedarīt/nelietot piemērus, lietošanas skriptus un marķieru nosaukumu melnrakstus. Bet sistēmas būtība ir savdabība un konsekvence: katrs marķiera nosaukums ir jāpārbauda parauga shēmā, katrs komponenta priekšlikums ir pretrunīgi skenēts, katrs uzvedības apraksts ir jāpārbauda pret realitāti. Izmantojiet modeli kā efektīvu rasētāju; Komanda pieņem individuālu pareizo lēmumu.

Lietojumprogrammas uzdevums

Atlasiet komponentu, kuram trūkst dokumentācijas, un izveidojiet dokumenta melnrakstu ar pirmo uzvedni.
Aizpildiet laukus ar atzīmi "Komandai jāaizpilda", norādot faktisko uzvedību.
Ar otro uzvedni konvertējiet 8–10 marķierus uz semantisko shēmu un izveidojiet veco/jauno nosaukumu tabulu.
Lai iegūtu jaunu komponenta ideju, meklējiet pretrunas ar trešo uzvedni.
Izmantojot ceturto uzvedni, ģenerējiet komponentam do/nepiemēru pārus un pievienojiet tos sistēmai.

kontrolsaraksts

[ ] Es saistīju marķiera nosaukumu ar piemēru shēmu.
[ ] Es pārbaudīju jaunos komponentus, lai atrastu konfliktus.
[ ] Es pārbaudīju modeļa radīto uzvedību ar realitāti.
[ ] Es plānoju apstiprināt pieejamības piezīmes ar faktisku testēšanu.
[ ] Es glabāju dokumentāciju konsekventā formātā.
[ ] Es saglabāju singularitāti un novērsu dublēšanos.