Печалби:
- Възможност за изготвяне и създаване на последователни дизайнерски токени, именуване на компоненти и правила за използване с изкуствен интелект
- Възможност за бързо създаване на документация за компоненти, примери за правене/неправяне и текстове за използване с изкуствен интелект
- Възможност за проверка на предложенията за изкуствен интелект за конфликт със съществуващата система за проектиране и запазване на уникалността
Системата за проектиране е общият език, който прави продуктовото семейство да изглежда и да се държи последователно: компоненти за многократна употреба (бутон, карта, поле на формуляр), дизайнерски токени (именувани дефиниции на стойности като цвят, разстояние, типография) и документация, която обяснява как да ги използвате. Добрата система за проектиране позволява на десет дизайнера да проектират един и същ продукт, сякаш е произведен от един източник. Инсталирането и поддръжката на тази система е уморителна, повтаряща се работа с интензивен текст; Точно тук блести изкуственият интелект. Но същността на системата е единичност и последователност; Препоръките на AI не могат да бъдат приети, без да бъдат проверени за конфликт с текущата система.
Токени и именуване: основата за последователност
Токенът за дизайн е именувана, многократно използваема стойност на дизайнерско решение: цвят-основен, пространство-център, текст-заглавие-главен. Благодарение на жетоните можете да промените цвят на едно място и да го актуализирате в целия продукт. Но силата на токените зависи от последователността на именуване; Ако blue-1, main-blue, primaryBlue се използват смесени, системата ще се срине.
AI е добър в две неща тук: преглед на вашия съществуващ набор от токени спрямо последователна схема за именуване и предлагане на съвместими със схемата имена за нови токени. Искане като „Преведете този списък с токени към семантично (базирано на значение) именуване“ ще ви помогне да генерирате имена, които предават значение, като например color-action-primary вместо blue-500. Но окончателното решение за име е договорът на отбора; Моделът предоставя само контур.
Съвет: Когато именувате токени към AI, дайте 5-6 примера за текущата си схема и кажете „запазете същия модел“. Заявката без извадка създава имена, които са чужди за вашата система.
Документация на компонентите: най-продуктивната област на AI
Документацията на даден компонент включва: какво прави, кога да го използвате, кога да не го използвате, неговите варианти, състояния (по подразбиране, при задържане, пасив, грешка), бележки за достъпност и примери за „да/не“. Писането на тези текстове на ръка отнема часове, поради което много екипи пренебрегват документацията.
AI запълва тази празнина: когато описвате компонент, той създава чернова на документация, правила за използване и примери за правене/неправяне в последователен формат. Така документацията преминава от „няма“ до „има чернова, ще се оправи“, което е голяма печалба. Моделът обаче не знае действителното поведение на компонента; Ваша работа е да съпоставите правилата, които създава, с реалността на системата.
фрагмент от документ
Приносът на изкуствения интелект
човешка проверка
Какво прави?
Ясна дефиниция на контура
Истинска годност за целта
Кога да използвате
Общи сценарии
Специфични за продукта правила
Правете/Не правете примери
Бърза чернова на двойки
Действителни злоупотреби
Бележка за достъпност
Стандартни напомняния
Потвърдено с реален тест
Списък на варианти/случаи
възможен списък
Тези, които реално съществуват в системата
Проверка на противоречие: запазване на сингулярността
Основният враг на системата за проектиране е дублирането: два бутона, които вършат една и съща работа, две различни пространствени мащаби, две противоречиви правила. Когато AI предложи нов компонент или правило, това предложение може да е в конфликт със съществуващата система — то не взема предвид цялата ви моделна система. Затова оценявам всяко предложение, като питам „противоречи ли е това на нещо, което вече съществува?“ Филтрирайте с въпроса. Можете също да използвате изкуствен интелект при сканиране на конфликти: можете да дадете резюме на текущата система и новата препоръка и да имате изброени конфликтите. Но окончателното „единично правилно“ решение зависи от екипа.
три мини калъфа
Случай 1 — Изчистен дълг по документация. Само 6 от 24-те компонента на екипа имаха документация. Изготвени са чернови на документи за останалите 18 компонента с изкуствен интелект; Екипът оправи всеки един за 10-15 минути. Работата, която беше отлагана със седмици, беше завършена за два дни.
Случай 2 — Наименуването на токени стана последователно. В една система цветовете бяха смесени като blue1, mainBlue, brand-blue. AI преведе съществуващите 40 токена в семантична схема; Екипът го преработи и премина към един стандарт. Грешките в цвета бяха значително намалени в следващите дизайни.
Случай 3 — Конфликтният компонент беше отхвърлен. AI предложи нов компонент, наречен „вторичен бутон за действие“. Когато екипът сканира за противоречия, те откриха, че върши същата работа като съществуващия „призрачен бутон“ и отхвърлиха предложението. Поука: не всяко предложение добавя нов компонент към системата; Понякога е правилно да се използва това, което е налично.
Копируеми подкани
Вашата роля: системен администратор за проектиране. Документирайте този компонент: <<компонент и неговото поведение>>. Формат: Какво прави | Кога да използвате | Кога НЕ се използва |Варианти | Ситуации | Бележки за достъпност | 2 Правете / 2 Не пример. Измислете поведение, което не познавате; Напишете „екипът трябва да попълни“.
Преведете този списък от токени в семантична (базирана на значение) схема за именуване. Моите текущи примери за схеми: <<5-6 примера>>. Продължете по същия модел. За всеки токен дайте старо име -> ново име -> таблица за обосновка. Списък: <<токени>>
Сканиране за противоречия: Резюме на текущата ми система за проектиране: <<резюме>>. Нов предложен компонент/правило: <<предложение>>. Това предложение противоречи ли на съществуващата система (компонент, който върши същата работа, противоречиво правило, дублиран токен)? Избройте конфликтите и вашето предложение.
Генерирайте примерни двойки „направете/не правете“ за този компонент: реалистични сценарии за правилно използване и реалистични сценарии за неправилно използване. За всяка двойка обяснете с едно изречение защо е вярно/невярно. Компонент: <<име и цел>>
Слаба подкана / Силна подкана
Слаб: „Напишете документация за този бутон.“
Резултат: Общ, форматиран текст без връзка със системата.
Силно: „Документирайте този бутон в следния формат (какво прави / кога не трябва да се използва / варианти / случаи / достъпност / правете-не правете); измислете поведение, което не знаете, напишете „екипът трябва да попълни“.“
Резултат: последователно форматиран, с правилни интервали, редактируем ръкопис.
Разлика: силен формат на подкана + забрана за производство + подкани за правене/не.
Често срещани грешки
- Заявка за именуване на токени без пример. Моделът генерира имена, които са чужди за вашата система; последователността е нарушена.
- Добавяне на компоненти без сканиране за противоречия. Дублирането е главният враг на системата.
- Ако приемем, че поведението, измислено от модела, е правилно. AI не знае действителното поведение на компонента.
- Приемане на рейтинга за достъпност без тестване. Стандартното напомняне не е заместител на действителното тестване.
- Писане на документацията веднъж и без актуализиране. Документът трябва да се актуализира при промени в системата.
В обобщение
Системата за проектиране е инфраструктурата на последователност и мащабируемост; но поддържането му често се пренебрегва, защото е интензивно на текст и се повтаря. AI се справя с този дълг чрез бързо създаване на документация за компоненти, примери за правене/не, скриптове за използване и чернови за именуване на токени. Но същността на системата е уникалност и последователност: всяко име на токен трябва да бъде проверено спрямо примерната схема, всяко предложение за компонент трябва да бъде противоречиво сканирано, всяко описание на поведение трябва да бъде проверено спрямо реалността. Използвайте модела като ефективен чертожник; Екипът взема индивидуалното правилно решение.
Задача за приложение
- Изберете компонент с липсваща документация и създайте проект на документ с първата подкана.
- Попълнете полетата, отбелязани с „Екипът трябва да попълни“ с действително поведение.
- С втората подкана преобразувайте вашите 8-10 токена в семантичната схема и създайте стара/нова таблица с имена.
- За нова идея за компонент сканирайте за противоречия с третата подкана.
- С четвъртата подкана генерирайте примерни двойки „да/не“ за компонент и да ги добавите към системата.
контролен списък
- [] Свързах именуването на токена с примерната схема.
- [ ] Сканирах новите компоненти за конфликти.
- [ ] Проверих моделираното поведение с реалността.
- [ ] Планирах да потвърдя бележките за достъпност с действително тестване.
- [ ] Поддържах документацията в последователен формат.
- [ ] Запазих уникалността и предотвратих дублирането.