Единицы
1. Введение в искусственный интеллект в UI/UX-дизайне: роли, границы, аутентификация и пользовательские данные 2. Синтез исследований пользователей: извлечение информации из данных интервью и опросов 3. Создание персоны и карты путешествия пользователя 4. Информационная архитектура и проектирование пользовательских потоков 5. Создание каркасного дизайна и дизайна с низким разрешением 6. Текст интерфейса и написание UX: написание микротекстов с помощью искусственного интеллекта 7. Искусственный интеллект в прототипировании и дизайне высокого разрешения 8. Анализ юзабилити-тестирования и синтез результатов 9. Система проектирования: искусственный интеллект в компонентах, токенах и документации 10. Искусственный интеллект в доступности и инклюзивном дизайне 11. Экосистема инструментов этики, конфиденциальности, авторского права и искусственного интеллекта
Единица 7 / 11

Искусственный интеллект в прототипировании и дизайне высокого разрешения

Прибыль:

  • Способность быстро создавать скелеты прототипов, образцы контента и идеи микровзаимодействия с помощью искусственного интеллекта.
  • Возможность создавать реалистичный текст-заполнитель и данные для прототипа и тестировать дизайн в реальном использовании.
  • Возможность поддерживать согласованность и логику компонентов при перемещении результатов ИИ в инструмент проектирования (Фигма и т. д.).

Прототип — это кликабельная и управляемая имитация дизайна; Это симуляция, которую пользователь может испытать так же, как и в реальном продукте. С другой стороны, высокоточный дизайн — это дизайн, который стал ближе к конечному продукту благодаря цвету, типографике, реальному контенту и микровзаимодействиям. Цель на этом этапе — сделать идею проверяемой, «как если бы она была реальной». ИИ здесь силен в трех отношениях: быстрое создание скелетов и вариаций, предоставление реалистичного контента и данных-заполнителей, а также предложение идей микровзаимодействия. Но поддержание последовательности и логики компонентов при перемещении выходных данных в инструмент проектирования, то есть встраивание системы в систему, не загромождая ее, — это человеческая работа.

Цель прототипа: дешево протестировать правильный вопрос.

У прототипирования есть одна цель: дешево проверить предположение, не написав кода. «Понимает ли пользователь этот поток?», «Ускоряет ли такой макет его задачу?» Вот почему прототип не обязательно должен быть таким же совершенным, как реальный продукт; оно просто должно быть достаточно реальным, чтобы убедительно изобразить вопрос, подлежащий проверке.

Искусственный интеллект повышает это доверие. Но есть опасность: высокое разрешение кажется «готовым». Когда заинтересованные стороны видят отточенный прототип, они могут принять его за окончательное решение; Однако это все еще гипотеза. Всегда четко говорите, что прототип тестируется, а что еще остается открытым.

Внимание: отполированный прототип преувеличивает зрелость. Если вы не сформулируете это как «это инструмент тестирования, а не окончательный проект; мы тестируем этот вопрос», показывая его заинтересованным сторонам, будут созданы неправильные ожидания.

Реалистичный контент: спасаем прототип от лжи

Самая большая ложь прототипа — это идеальные заполнители, такие как «Lorem ipsum» и «Имя Фамилия». В реальном мире имена длинные, списки иногда пусты, числа иногда отрицательны, а даты иногда устарели. Когда прототип наполнен идеальным контентом, он скрывает реальные проблемы.

Именно здесь ИИ ценен: он создает реалистичный контент-заполнитель и данные разной длины и разных состояний. Вы можете приблизить прототип к реальному использованию с помощью таких запросов, как «Дайте мне 20 реалистичных названий продуктов, некоторые из них очень длинные», «Напишите 5 различных сценариев пустого случая», «Представьте пример данных счета, включая отрицательный баланс». Таким образом, тест проверяет реальность, а не идеал.

Тип контента

фейк (вводящий в заблуждение)

Реалистичный (с искусственным интеллектом)

Имя

«Имя Фамилия»

Примеры с короткими, длинными, одиночными именами, специальными символами

Список

всегда полный

Пустой вариант, 1 элемент, варианты из 100 элементов

Номер

всегда позитивный

Ноль, отрицательные, очень большие значения

текст

идеальная длина

Переполняющее название, очень короткое описание

дата

сегодня

Прошлое, будущее, «сейчас», «3 года назад».

Микровзаимодействия: маленькие, но решающие

Микровзаимодействия — это небольшие, единичные моменты взаимодействия, такие как обратная связь при нажатии кнопки, заполнение поля зеленым цветом, анимация загрузки и т. д. Они создают у пользователя ощущение, что «система меня услышала». ИИ — хороший партнер в мозговом штурме для генерации идей микровзаимодействия (когда, какая обратная связь, какое состояние изменится). Но каждое микровзаимодействие необходимо взвешивать с точки зрения производительности, доступности и отвлечения внимания; причудливая, но ненужная анимация замедляет процесс.

три мини-кейса

Случай 1 — Коллапс ордера на реальных данных. Команда заполнила прототип 30 реалистичными (некоторые очень длинными) названиями продуктов, созданными ИИ. Два расклада карт переполнились; Проблема была обнаружена и исправлена ​​перед тестированием. Урок: реалистичный контент рано выявляет скрытые ошибки.

Случай 2. Доработанный прототип породил ложные ожидания. Дизайнер подготовил прототип в высоком разрешении «только для потокового тестирования», но показал его заинтересованным сторонам без фрейма. Заинтересованная сторона сказала: «Отлично, давайте опубликуем это»; тогда как доступности и содержания еще не существовало. Урок: четко скажите, что тестирует прототип.

Случай 3 — согласованность компонентов нарушена. Эскиз экрана от ИИ содержал другой стиль кнопок, чем кнопка в дизайн-системе. При портировании на Figma дизайнер забыл связать это с системным компонентом; На изделии имеются две разные кнопки. Урок: при перемещении вывода в инструмент необходимо соединить его с существующими компонентами.

Копируемые подсказки

Создайте реалистичный контент-заполнитель для этого экрана: - 20 имен <<тип элемента>>: некоторые слишком короткие, некоторые слишком длинные, одно со специальным символом. - 4 пустых сценария. - 3 примера экстремальных данных (нулевые, отрицательные, слишком большие). Цель: протестировать прототип с реальным, а не идеальным использованием. Контекст: <<экран/продукт>>

Предложите скелет прототипа для этого потока (список экранов + основные элементы на каждом экране): Задача: «<<task>>». Вопрос, который я хочу проверить: «<<гипотеза>>». Предложите ровно столько экранов, чтобы проверить этот вопрос; не добавляйте больше.

Предложите 4 идеи микровзаимодействия для этого взаимодействия (нажатие кнопки, проверка поля, загрузка, успех). Для каждого: триггер, обратная связь, предложение продолжительности и примечание о доступности (чувствительность к движению, объявление средства чтения с экрана). Контекст: <<взаимодействие>>

Проверьте этот эскиз экрана на совместимость с моей системой дизайна: соответствуют ли кнопка, типографика, интервалы и цвет моим существующим правилам компонентов («<<summary>>»). Перечислите каждый несовместимый элемент и укажите, к какому системному компоненту его следует подключить. Черновик: <<текст>>

Слабая подсказка / Сильная подсказка

Слабое: «Приведите пример контента для этого прототипа».

Результат: идеальная длина, однородный, фейковый контент, скрывающий реальные проблемы.

Сильный: «Сгенерируйте 20 названий продуктов; некоторые слишком длинные, одно со специальным символом; добавьте 4 пустых регистра и 3 примера краевых данных; постарайтесь протестировать прототип на реальном использовании».

Результат: контент, который действительно улучшает макет, заранее выявляя ошибки.

Разница: сильная подсказка требует разнообразия + крайний случай + цель.

Распространенные ошибки

  • Тестирование с идеальным контентом. Хорошие заполнители скрывают реальные проблемы.
  • Принятие отшлифованного прототипа за окончательное решение. Если кадрирование не сделано, возникают ложные ожидания.
  • Добавление ненужного экрана. Прототипа должно быть достаточно для проверки гипотезы; слишком много – это пустая трата времени.
  • Нарушение логики компонентов. Если вы забудете подключить компоненты системы при их транспортировке к автомобилю, это приведет к несогласованности действий.
  • Необычное, но ненужное микровзаимодействие. Добавление анимации без учета производительности и доступности.

В заключение

Прототипирование — это способ дешево проверить гипотезу без написания кода; Высокое разрешение делает его правдоподобным, но также создает иллюзию «законченности». ИИ обеспечивает этот этап быстрым каркасом, реалистичным заполнителем и идеями микровзаимодействия. Его наиболее ценный вклад — разнообразные и экстремальные данные, которые позволяют протестировать прототип в реальном, а не идеальном контексте. Ответственность человека заключается в том, чтобы четко сформулировать, что тестируется прототипом, обеспечивая согласованность компонентов и стиля при передаче результатов в инструмент проектирования.

Задача приложения

  1. Напишите одно предложение-гипотезу, которую вы хотите проверить на поток.
  2. Используя вторую подсказку, создайте скелет прототипа, достаточный для проверки этой гипотезы.
  3. С помощью первой подсказки создайте реалистичный контент-заполнитель и заполните прототип.
  4. Используя третью подсказку, сгенерируйте 2–3 идеи микровзаимодействия и оцените примечания о доступности.
  5. С помощью четвертой подсказки проверьте и исправьте черновик на предмет согласованности системы проектирования.

контрольный список

  • [ ] Я четко написал гипотезу, которую тестирует прототип.
  • [ ] Я тестировал контент с реалистичным и крайним содержанием.
  • [ ] Я представил прототип как «инструмент тестирования» для заинтересованных сторон.
  • [ ] Я сохранил количество экранов, достаточное для проверки гипотезы.
  • [ ] Я сопоставлял микровзаимодействия с доступностью и производительностью.
  • [ ] Я поддерживал согласованность, привязывая выходные данные к компонентам системы.