Систем дизајна: вештачка интелигенција у компонентама, токенима и документацији — Вештачка интелигенција у УИ/УКС дизајну

Добици:

Способност израде и прављења конзистентних токена дизајна, именовања компоненти и правила коришћења са вештачком интелигенцијом
Способност да се брзо изради документација компоненти, да се раде/не раде примери и да се користе текстови са вештачком интелигенцијом
Способност да се провере сугестије вештачке интелигенције на сукоб са постојећим системом дизајна и очување сингуларности

Систем дизајна је заједнички језик који чини да породица производа изгледа и да се понаша доследно: компоненте за вишекратну употребу (дугме, картица, поље обрасца), токени дизајна (именоване дефиниције вредности као што су боја, размак, типографија) и документација која објашњава како их користити. Добар систем дизајна омогућава десет дизајнера да дизајнирају исти производ као да га производи један извор. Инсталирање и одржавање овог система је заморан посао који се понавља и захтева много текста; Управо ту блиста вештачка интелигенција. Али суштина система је сингуларност и доследност; Препоруке АИ се не могу прихватити без провере да ли су у супротности са тренутним системом.

Токени и именовање: основа за доследност

Дизајнерски токен је именована вредност одлуке о дизајну за вишекратну употребу: боја-примарна, простор-центар, текст-наслов-велика слова. Захваљујући токенима, можете променити боју на једном месту и ажурирати је у целом производу. Али моћ токена зависи од доследности именовања; Ако се плава-1, главна-плава, примарна плава користе мешано, систем ће се срушити.

АИ је овде добар у две ствари: да прегледа ваш постојећи скуп токена у односу на доследну шему именовања и предлаже имена усаглашена са шемом за нове токене. Захтев попут „Преведи ову листу токена у семантичко (засновано на значењу) именовање“ ће вам помоћи да генеришете имена која преносе значење, као што је боја-акција-примарна уместо плава-500. Али коначна одлука о именовању је уговор тима; Модел даје само нацрт.

Савет: Приликом именовања токена у АИ, дајте 5-6 примера ваше тренутне шеме и реците „одржавајте се у истом обрасцу“. Захтев без узорка производи имена која су страна вашем систему.

Документација компоненти: најпродуктивнија област АИ

Документација компоненте укључује: шта ради, када да се користи, када не треба да се користи, њене варијанте, стања (подразумевано, лебдећи, пасивно, грешка), напомене о приступачности и примере „ради/немој“. Ручно писање ових текстова траје сатима, због чега многи тимови занемарују документацију.

АИ попуњава ову празнину: када опишете компоненту, она производи нацрт документације, правила коришћења и примере уради/немој у доследном формату. Тако документација иде од „нема” до „нацрта има, средиће се”, што је велика добит. Међутим, модел не познаје стварно понашање компоненте; Ваш је посао да ускладите правила која она производи са реалношћу система.

фрагмент документа

Допринос вештачке интелигенције

људска верификација

шта то ради?

Јасна дефиниција обриса

Права кондиција за сврху

Када користити

Општи сценарији

Посебна правила за производ

Уради/Немој примере

Парови за брзи нацрт

Стварне злоупотребе

Напомена о приступачности

Стандардни подсетници

Потврђено правим тестом

Листа варијанти/случаја

могући списак

Они који стварно постоје у систему

Провера контрадикције: очување сингуларности

Највећи непријатељ система дизајна је дуплирање: два дугмета раде исти посао, две различите просторне скале, два сукобљена правила. Када АИ предложи нову компоненту или правило, та сугестија може бити у сукобу са постојећим системом — не има на уму цео систем модела. Зато ја процењујем сваки предлог питањем „да ли је ово у сукобу са нечим што већ постоји?“ Филтрирајте са питањем. Такође можете да користите вештачку интелигенцију у скенирању сукоба: можете дати тренутни резиме система и нову препоруку и навести конфликте. Али коначна "јединствена тачна" одлука је на тиму.

три мини кофера

Случај 1 — Измирен дуг за документацију. Само 6 од 24 компоненте тима имало је документацију. Израђени су нацрти докумената за преосталих 18 компоненти са вештачком интелигенцијом; Тим је поправио сваки за 10-15 минута. Посао, који је недељама одлаган, завршен је за два дана.

Случај 2 — Именовање токена је постало доследно. У једном систему боје су се мешале као плава1, главна плава, бренд-плава. АИ је превео постојећих 40 токена у семантичку шему; Тим га је ревидирао и прешао на јединствени стандард. Грешке у боји су приметно смањене у наредним дизајнима.

Случај 3 — Конфликтна компонента је одбијена. АИ је предложио нову компоненту под називом „Дугме секундарне акције“. Када је тим скенирао противречности, открио је да ради исти посао као постојеће „дугме за духове“ и одбио је предлог. Поука: сваки предлог не додаје нову компоненту систему; Понекад је исправно користити оно што је доступно.

Копирајућа упутства

Преведите ову листу токена у семантичку (засновану на значењу) шему именовања. Моји тренутни примери шеме: <<5-6 примера>>. Наставите по истом обрасцу. За сваки токен дајте старо име -> ново име -> табелу оправдања. Листа: <<жетони>>

Скенирај противречности: Резиме мог тренутног система дизајна: <<сажетак>>. Нова предложена компонента/правило: <<предлог>>. Да ли је овај предлог у супротности са постојећим системом (компонента која ради исти посао, конфликтно правило, дупликат токен)? Наведите конфликте и свој предлог.

Генеришите парове примера „уради/немој“ за ову компоненту: реалистична исправна употреба и реалистични сценарији нетачне употребе. За сваки пар објасни у једној реченици зашто је тачно/нетачно. Компонента: <<име и сврха>>

Слаби промпт / Јаки промпт

Слабо: „Напишите документацију за ово дугме.“

Резултат: Општи, форматирани текст без везе са системом.

Снажно: „Документујте ово дугме у следећем формату (шта ради / када се не користи / варијанте / случајеви / приступачност / не радите); измислите понашање које не знате, напишите 'тим мора да попуни'."

Резултат: Доследно форматиран, правилно распоређен рукопис који се може уређивати.

Разлика: јак формат упита + забрана израде + упити уради/немој.

Уобичајене грешке

Захтевање именовања токена без примера. Модел генерише имена која су страна вашем систему; конзистентност је прекинута.
Додавање компоненти без скенирања противречности. Дуплирање је главни непријатељ система.
Под претпоставком да је понашање које је измислио модел исправно. АИ не зна стварно понашање компоненте.
Прихватање оцене приступачности без тестирања. Стандардни подсетник није замена за стварно тестирање.
Једном писати документацију и не ажурирати је. Документ треба ажурирати како се систем мења.

Укратко

Систем дизајна је инфраструктура конзистентности и скалабилности; али се његово одржавање често занемарује јер је текстуално интензивно и репетитивно. АИ решава овај дуг тако што брзо производи документацију компоненти, примере „уради/не ради“, скрипте за коришћење и нацрте именовања токена. Али суштина система је сингуларност и доследност: свако име токена мора бити верификовано у односу на шему узорка, сваки предлог компоненте мора бити контрадикторно скениран, сваки опис понашања мора бити верификован у односу на стварност. Користите модел као ефикасан цртач; Тим доноси индивидуалну исправну одлуку.

Задатак апликације

Изаберите компоненту којој недостаје документација и направите нацрт документа са првим упитом.
Попуните поља означена са „Тим мора попунити“ стварним понашањем.
Са другим упитом, конвертујте својих 8-10 токена у семантичку шему и креирајте стару/нову табелу имена.
За идеју о новој компоненти, потражите контрадикције помоћу трећег одзивника.
Са четвртом промптом, генеришите примере „уради/немој“ парове за компоненту и додајте их систему.

контролна листа

[ ] Повезао сам именовање токена са примером шеме.
[ ] Скенирао сам нове компоненте за конфликте.
[ ] Верификовао сам моделе понашања са стварношћу.
[ ] Планирао сам да потврдим белешке о приступачности стварним тестирањем.
[ ] Чувао сам документацију у доследном формату.
[ ] Сачувао сам сингуларност и спречио дуплирање.