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