Прибуток:
- Здатність створювати та створювати узгоджені маркери дизайну, іменування компонентів і правила використання за допомогою штучного інтелекту
- Можливість швидко створювати документацію компонентів, приклади робити/не робити та використовувати тексти за допомогою штучного інтелекту
- Можливість перевірити пропозиції штучного інтелекту на конфлікт з існуючою системою дизайну та зберегти сингулярність
Система дизайну — це загальна мова, завдяки якій сімейство продуктів виглядає та веде себе узгоджено: багаторазово використовувані компоненти (кнопка, картка, поле форми), маркери дизайну (іменовані визначення значень, таких як колір, інтервал, типографіка) і документація, яка пояснює, як їх використовувати. Хороша система проектування дозволяє десяти дизайнерам розробляти один і той самий продукт, як якщо б він був виготовлений одним джерелом. Встановлення та обслуговування цієї системи є виснажливою, повторюваною та інтенсивною роботою; Саме тут сяє штучний інтелект. Але сутність системи полягає в унікальності та узгодженості; Рекомендації AI не можуть бути прийняті без перевірки на конфлікт із поточною системою.
Лексеми та іменування: основа узгодженості
Маркер дизайну — це назване, багаторазово використовуване значення дизайнерського рішення: колір-основний, пробіл-центр, текст-назва-велика. Завдяки жетонам ви можете змінити колір в одному місці та оновити його для всього продукту. Але сила лексем залежить від узгодженості іменування; Якщо blue-1, main-blue, primaryBlue використовуються змішано, система вийде з ладу.
Тут штучний інтелект хороший у двох речах: аналізі існуючого набору токенів на відповідність узгодженій схемі іменування та пропонуванні сумісних із схемою імен для нових токенів. Запит на кшталт «Перекласти цей список токенів у семантичне (на основі значення) найменування» допоможе вам створити імена, які передають значення, наприклад color-action-primary замість blue-500. Але остаточне рішення щодо назви – це договір команди; Модель містить лише контур.
Порада: призначаючи токени для ШІ, наведіть 5-6 прикладів вашої поточної схеми та скажіть «дотримуйтеся того самого шаблону». Запит без вибірки створює імена, які є чужими для вашої системи.
Документація компонентів: найпродуктивніша область ШІ
Документація компонента містить: що він робить, коли його використовувати, коли не використовувати, його варіанти, стани (за замовчуванням, при наведенні, пасивний, помилка), примітки щодо доступності та приклади «робити/не робити». Написання цих текстів від руки займає години, тому багато команд нехтують документацією.
Штучний інтелект заповнює цю прогалину: коли ви описуєте компонент, він створює чернетку документації, правила використання та приклади дій/заборонень у узгодженому форматі. Таким чином, документація переходить від «немає» до «є проект, буде виправлено», що є великим виграшем. Однак модель не знає фактичної поведінки компонента; Ваше завдання — узгодити створені ним правила з реальністю системи.
фрагмент документа
Внесок штучного інтелекту
перевірка людиною
Що це робить?
Чітке визначення контуру
Справжня придатність для мети
Коли використовувати
Загальні сценарії
Специфічні правила продукту
Приклади робіть/не робіть
Швидка чернетка пар
Фактичні зловживання
Примітка щодо доступності
Стандартні нагадування
Підтверджено реальним тестом
Список варіантів/випадків
можливий список
Тих, хто реально існує в системі
Перевірка на протиріччя: збереження сингулярності
Головним ворогом системи дизайну є дублювання: дві кнопки, які виконують одну й ту саму роботу, два різних масштаби простору, два суперечливі правила. Коли штучний інтелект пропонує новий компонент або правило, ця пропозиція може конфліктувати з існуючою системою — вона не враховує всю систему моделі. Тому я оцінюю кожну пропозицію, запитуючи: «Чи суперечить це чомусь, що вже існує?» Фільтр із запитанням. Ви також можете використовувати штучний інтелект для сканування конфліктів: ви можете надати поточний підсумок системи та нову рекомендацію, а також отримати список конфліктів. Але остаточне «єдино правильне» рішення залишається за командою.
три міні-чохла
Випадок 1 — заборгованість по документації погашена. Лише 6 із 24 компонентів команди мали документацію. Для решти 18 компонентів зі штучним інтелектом були підготовлені проекти документів; Кожну бригада виправляла за 10-15 хвилин. Роботу, яку відкладали тижнями, завершили за два дні.
Випадок 2 — іменування токенів стало послідовним. В одній системі кольори були змішані, як синій1, головний синій, синій. AI перевів існуючі 40 токенів у семантичну схему; Команда переглянула його і перейшла на єдиний стандарт. Помилки кольорів помітно зменшилися в наступних дизайнах.
Випадок 3 — Конфліктний компонент відхилено. AI запропонував новий компонент під назвою «кнопка вторинної дії». Коли команда перевірила на наявність протиріч, вони виявили, що він виконує ту саму роботу, що й існуюча «кнопка-привид», і відхилили пропозицію. Урок: не кожна пропозиція додає новий компонент до системи; Іноді правильно використовувати те, що є.
Копіювані підказки
Ваша роль: адміністратор системи проектування. Задокументуйте цей компонент: <<компонент і його поведінка>>. Формат: Що він робить | Коли використовувати | Коли НЕ використовувати |Варіанти | Ситуації | Примітки щодо доступності | 2 Робіть / 2 Не робіть приклад. Вигадайте поведінку, яку ви не знаєте; Напишіть «команда повинна заповнити».
Перекладіть цей список токенів у семантичну (на основі значення) схему найменування. Мої поточні приклади схем: <<5-6 прикладів>>. Продовжуйте за тією ж схемою. Для кожного токена введіть стару назву -> нову назву -> таблицю обґрунтування. Список: <<токени>>
Сканування на протиріччя: Резюме моєї поточної системи проектування: <<резюме>>. Новий запропонований компонент/правило: <<пропозиція>>. Чи суперечить ця пропозиція існуючій системі (компонент, який виконує ту саму роботу, суперечливе правило, дублікат маркера)? Перелічіть конфлікти та ваші пропозиції.
Згенеруйте приклади пар «робити/не робити» для цього компонента: реалістичні сценарії правильного використання та реалістичні сценарії неправильного використання. Для кожної пари поясніть одним реченням, чому це істина/неправда. Компонент: <<назва та призначення>>
Слабка підказка / Сильна підказка
Слабко: «Напишіть документацію для цієї кнопки».
Результат: загальний відформатований текст без зв’язку з системою.
Сильно: «Задокументуйте цю кнопку в такому форматі (що вона робить / коли не можна використовувати / варіанти / випадки / доступність / робити-не робити); придумайте поведінку, яку ви не знаєте, напишіть «команда повинна заповнити».»
Результат: послідовно відформатований рукопис із правильним інтервалом, який можна редагувати.
Різниця: жорсткий формат підказок + заборона виготовлення + підказки робити/не робити.
Поширені помилки
- Запит на найменування маркера без прикладу. Модель генерує імена, чужі вашій системі; порушується консистенція.
- Додавання компонентів без перевірки протиріч. Дублювання є головним ворогом системи.
- Припускаючи, що поведінка, винайдена моделлю, є правильною. ШІ не знає фактичної поведінки компонента.
- Прийняття рейтингу доступності без тестування. Стандартне нагадування не замінює реальне тестування.
- Написати документацію один раз і не оновлювати її. Документ слід оновлювати в міру зміни системи.
Підсумовуючи
Система проектування - це інфраструктура узгодженості та масштабованості; але його обслуговуванням часто нехтують, тому що воно містить багато тексту та повторюється. AI вирішує цю заборгованість, швидко створюючи документацію компонентів, приклади «що робити/не робити», сценарії використання та чернетки іменування токенів. Але суть системи полягає в унікальності та узгодженості: кожне ім’я токена має перевірятися на зразкову схему, кожна пропозиція компонента має бути перевірена на суперечливість, кожен опис поведінки має бути перевірений на реальність. Використовуйте модель як ефективний проектувальник; Команда приймає індивідуальне правильне рішення.
Аплікаційне завдання
- Виберіть компонент із відсутньою документацією та створіть проект документа за допомогою першої підказки.
- Заповніть поля з позначкою «Команда повинна заповнити» фактичною поведінкою.
- За допомогою другого запиту перетворіть свої 8-10 токенів на семантичну схему та створіть стару/нову таблицю імен.
- Для нової ідеї компонента скануйте протиріччя за допомогою третьої підказки.
- За допомогою четвертого підказки згенеруйте пари прикладів робити/не робити для компонента та додавати їх до системи.
контрольний список
- [ ] Я пов’язав іменування токенів із прикладом схеми.
- [ ] Я перевірив нові компоненти на наявність конфліктів.
- [ ] Я перевірив моделі поведінки з реальністю.
- [ ] Я планував підтвердити примітки щодо доступності фактичним тестуванням.
- [ ] Я зберіг документацію в узгодженому форматі.
- [ ] Я зберіг сингулярність і запобіг дублюванню.