Якоб Нильсен написал о новой (третьей) парадигме пользовательского интерфейса.

— 1. Пакетная обработка. Точкой контакта были перфокарты. С их помощью пользователь задавал набор инструкций для компьютера, с которыми работал центр обработки данных. Результат приходил через некоторое время (например, на следующий день) в виде распечаток;
— 2. Взаимодействие на основе команд. Происходит через командные строки, полноэкранные текстовые терминалы, графические интерфейсы. После выполнения каждой команды пользователь может оценить ситуацию и изменить последующие команды. Он может не знать точного пути к цели и корректировать свои действия после ответов системы;
— 3. Результаты на основе запроса. Пользователь сообщает системе не какие команды надо выполнить, а какой результат хочет получить (генеративный AI);
— Это сложно назвать взаимодействием, так как нет очерёдности и постепенного продвижения вперёд. Постепенная доработка полученного результата — форма взаимодействия, которая работает сейчас неидеально;
— Когда пользователь не знает, как именно выполнена та или иная операция, сложнее выявить и устранить проблемы;
— Скорее всего, AI-системы будут иметь гибридный пользовательский интерфейс;
— Клики и касания — важный аспект взаимодействия с пользователем, от которого не стоит отказываться. Заполнить длинную форму, общаясь с ботом (даже очень умным), всё ещё слишком сложно.

In English. #ai

Саша Терещенко написал об интерфейсе чат-ботов.

— Предлагайте варианты ответа, так как набирать текст сложнее и не всегда понятно, на какие вопросы готов ответить чат-бот;
— Форматируйте текст, насколько это позволяют ограничения интерфейса. Абзац текста можно отправить отдельным сообщением;
— Добавляйте разные способы отображения контента: диаграммы и графики (в том числе интерактивные), код;
— Показывайте, что система работает. Например, можно отображать информацию по мере её формирования. Это лучше, чем прогресс-бар или лоадер;
— Подстраивайтесь под привычные форматы взаимодействия. Например, взаимодействие с MidJourney построено на интерфейсе Discord;
— Помогайте пользователям формулировать более точные вопросы, исходя из контекста диалога (люди не всегда точно формулируют свои запросы);
— Давайте возможность вернуться в диалоге на шаг назад и запустить параллельную ветку диалога;
— Давайте отрегулировать характеристики ответа, например, сделать его более спокойным или юмористическим.

#ai #chat

Опубликовали видео с Alfa Design Meetup #1:

1. Вячеслав Киржаев, Альфа-Банк — AI в руках дизайнера цифровых продуктов: приёмы и техники для повышения эффективности

2. Кирилл Викентьев, Альфа-Банк — Скайнет на страже пользовательских ценностей: как мы используем AI в командах роста

3. Ольга Петроченко, Альфа-Банк — Почему я так придираюсь к вёрстке: на что дизайнеры часто не обращают внимание при вёрстке макетов, и как этого избежать

4. Геннадий Мохов, mos.ru — Чем занят дизайн-директор: фреймворки, подходы и ритуалы при управлении командой любого масштаба

#ai #figma #layout #management

Фёдор Погуляев написал, как генерировать прототипы мобильных приложений на основе макетов в Фигме.

— Понадобится Node.js, Expo, Git и редактор кода Cursor;
— Expo даёт набор инструментов для создания кроссплатформенных приложений (мобайл и веб) на базе React Native;
— Прототип можно запускать через Expo Go на телефоне как обычное приложение (на любой операционной системе) с нативным поведением, виброоткликом, гироскопом и так далее;
— Git нужен для сохранения всей истории изменений файлов проекта. Полезно при вайбкодинге, так как Курсор может откатить изменения только в пределах одного контекстного окна;
— У Курсора есть Rules and Memories, где можно указать место хранения SVG-ассетов и выбранную библиотеку для анимации (например, React Reanimated). Правила могут распространяться на конкретный проект Project Rules и на все проекты User Rules;
— Пропишите в правилах, что приложение будет в связке React Native и Expo. Возьмите в Фигме personal access token и укажите его в настройках MCP. Так Курсор сможет ходить в Фигму за макетами;
— Если не работаете с дизайн-системой, потратьте время на нормальное именование элементов в Фигме. Так можно будет обращаться к конкретным элементам, а ИИ даже сможет предугадывать ваши желания при создании прототипа;
— Создайте шаблонный проект приложения со стандартной структурой, сбросьте шаблон, чтобы получить чистый проект;
— Начать эксперименты лучше с файла index.tsx, который отвечает за главную страницу;
— Скопируйте в чат ссылку на фрейм главной страницы в Фигме и скажите использовать функцию get_code (команда изучить структуру фрейма), чтобы ИИ воссоздал макет в коде;
— Так можно проверять решения без разработчиков, лучше разобраться в терминологии и логике кода.

#ai #prototype #mobile

Виктор Теплов рассказал, как дизайнеру работать с ИИ.

— Тест Патрика: чаще вы соглашаетесь с ИИ или он с вами? Если вы, то готовьтесь потерять работу;
— Опасные сценарии: профи-скептик не разбирается в ИИ, использует его на удачу и сразу видит некачественный результат; энтузиаст-профан лезет в незнакомую область и полностью доверяет ИИ; дофаминовый наркоман радуется быстрому результату и делает 5 проектов (и ещё 7 в уме);
— ИИ — не партнёр, а инструмент. Человек становится автором продукта и берёт ответственность, когда нажимает на «Принять изменения»;
— По умолчанию ИИ выдаёт массово-приятный результат, похожий на музыку в лифте, которая не бесит, но и не цепляет. Это хорошо для интерфейсов, так как привычные паттерны удобны. Но плохо для творчества, бренда и голоса продукта, где нужна узнаваемость;
— Дизайнеры, которые не хотели разбираться в функциях программ, но хотели «сделать красиво», раньше использовали плагины. Не понимаешь, как работает свет, — плагин Cinematic LUT;
— ИИ может сгенерировать артефакты по фреймворкам вроде JTBD, CJM, Personas, но не может взять на себя ответственность за принятое решение;
— Не получится найти ИИ-инструмент, который просто сделает то, что нужно. Придётся разбираться, как добиться в нём нужного результата;
— План: опишите образ результата, критерии качества и ограничения (что делаем, для кого, в каких условиях). Итерации: делите задачу на шаги, фиксируйте изменения и промежуточные артефакты. Проверка: просите ссылки на первоисточники, объяснить сделанный выбор, дать альтернативы и подсветить риски;
— Рутину надо делать быстро, одинаково и без ошибок. Дизайнер дизайн-системы либо автоматизирует, либо тонет. Раньше для автоматизации надо было стать немного разработчиком, сейчас порог входа снизился. Но ИИ не должен быть автором архитектуры;
— Например, плагин для сбора типографских variables в JSON-стили и построения витрины стилей, плагин для создания шрифта из иконок дизайн-системы;
— Работа с цветовыми токенами. Опишите контракт: структура токенов, устройство имён, запреты, эталонные примеры. Попросите выполнить операцию: добавь новый токен в core-палитру и создай семантический токен bg.main.primary на его основе, добавь во все тематические и брендовые палитры;
— Сначала в режиме Plan, когда ИИ ничего не делает с файлами. Затем просите не только изменить файлы, но и показать изменения, объяснить, почему они соответствуют правилам, подсветить риски, поискать дубли, проверить ссылки;
— В Figma Make можно быстро сделать прототип, проверить поведение компонента в корнер-кейсах и принять решения по вопросам, которые часто всплывают уже во время реализации в коде;
— Доступность инструмента лишь подчёркивает искусность мастера. Кто-то может порубить топором дрова, а кто-то построить дом. Важен опыт, вкус и логика. ИИ не заменяет мастерство, а позволяет делать быстро, много и предсказуемо.

Копия в ВК Видео. #ai #design_system

Лев Брук, дизайнер, отвечающий за Сбол, рассказал о том, как сохраняет интерес к работе.

— Мотивация бывает внешняя (заработать денег на жизнь) и внутренняя (у каждого своя);
— Дизайнеры могут делать мир вокруг удобнее или хотя бы поднимать другим людям настроение;
— Просто скажите себе спасибо;
— Есть желание двигать человечество вперёд, расширять домен знаний, но как это делать?
— Чтобы что-то узнать, надо начать делать что-то по-новому;
— Со временем, попробовав разные варианты, в том числе неудачные, мы научаемся приходить к решению задачи самым коротким путём. В итоге исследовать варианты уже не надо, продуктивность зашкаливает, но пропадает интерес;
— Кейс: надо исправить текст сообщений, все сообщения выгружены в JSON-формате, прочитать его можно с помощью плагина для Сафари, но у них всех некрасивые иконки. В процесс добавляется задача по созданию иконки и, возможно, созданию своего плагина для чтения JSONа (плюс придумать название и промо-текст, пройти ревью в App Store и так далее);
— В итоге: решил задачу, узнал новое, помог людям, получил социальное признание благодаря плагину (позитивные отзывы, 2-е место в рейтинге по количеству скачиваний);
— Редактура — скилл дизайнера;
— Кейс: надо переписать текст, все онлайновые словари синонимов неудобны и завалены рекламой. В итоге: свой онлайн-словарь синонимов;
— Зачем терпеть, если можно сделать себе удобно, оптимизировать часть своей работы на будущее?
— Плагин для Фигмы Scripter позволяет делать простые инструменты для решения небольших задач без заморочек с UI и публикацией плагинов;
— Оставайтесь любопытными, меняйте всё, что бесит;
— Больших и сложных инструментов полно, но легко можно собирать свои версии их отдельных фич.

#process #ai

Дмитрий Ваницкий написал об опыте тестирования вайбкод-прототипа с фронтендом и бекендом.

— Вероятность получить ТЗ не в виде длинной спецификации, а в виде вайбкод-прототипа с каждым днём становится всё больше;
— Надо учиться их запускать, а также тестировать с пользователями;
— Потребуется редактор кода. К VS Code можно подключить любой ИИ. Дмитрий остановился на Antigravity благодаря агентному подходу и продвинутому планированию при решении задач;
— Прототип без бекенда (React app, который сам считает и хранит данные в локальном хранилище) можно легко посмотреть на своём компьютере;
— Для пользовательского тестирования такие прототипы можно сделать доступными в интернете через Netlify или Vercel;
— Зачем нужен прототип с бекендом: использовать реальные данные (дамп базы), обрабатывать запросы не на фронте ради безопасности, тестировать более длинные сессии;
— Чаще всего придётся иметь дело с Vite-проектом. Достаточно попросить ИИ проанализировать проект и запустить его;
— Чтобы всё работало не только у вас на компьютере, регистрируйтесь в GitHub и публикуйте проект там;
— Коммитьте чаще, чтобы не сильно откатываться назад, когда всё сломается;
— Проекты, требующие только фронта, можно публиковать в GitHub Pages, а можно в Vercel или Netlify через интеграцию с Гитхабом (указать его как вендора);
— Если нужен бекенд, репозиторий в GitHub можно подключить к Railway. Надо прописать в конфиге Vite нужный URL, чтобы не ссылаться на локалхост;
— При тестировании на реалистичных данных может потребоваться подменить данные из дампа базы выдуманными, сохранив логику и связи. Дмитрий поделился ИИ-скилом для этого;
— Для немодерируемых тестов таких прототипов подойдут Maze, Useberry, бесплатная платформа Display;
— Чтобы система понимала, когда заканчивать тест, открытие целевого экрана должно сопровождаться изменением URL;
— Если у вас React-приложение, которое работает на стейтах, попросите ИИ добавить подмену URL на финальные экраны.

#prototype #user_testing #ai #tool

Тимур Репин написал о разных видах интерфейса, по каким параметрам их можно сравнить и заменит ли их всех умная строка (нет).

— Человеко-компьютерный интерфейс — все элементы, через которые человек взаимодействует с компьютером. Голос может быть таким же элементом;
— Интерфейс — бутылочное горлышко на пути от быстрого человеческого мозга до ещё более быстрого компьютера. Его расширение повышает эффективность решения задач с помощью компьютера;
— Пропускная способность — сколько информации (как на ввод, так и на вывод) передаётся в единицу времени;
— Скорость решения задачи — параметр, который зависит от количества действий, которые человек должен совершить (нажать кнопок, найти элементов на экране, вспомнить команд), и вероятности ошибиться;
— Оперативность доступа — сколько времени и усилий требуется, чтобы начать взаимодействие с системой. Она повысилась с переходом от мейнфреймов к персональным компьютерам и мобильным телефонам (достаточно просто протянуть руку);
— Переход от командной строки (CLI) к графическому интерфейсу (GUI) повысил скорость решения задач (не надо помнить названия команд и писать их, меньше ошибок) и пропускную способность (нажатие на кнопку вместо написания команды, вместо строк текста — полный графики экран);
— Кстати, был ещё TUI (text user interface), когда интерфейс, похожий на графический, создавался текстовыми символами. Пример: Norton Commander (1984);
— У носимых устройств выше оперативность доступа (они уже на голове или руке) и скорость решения отдельных задач. AR-очки видят то же, что и пользователь, и могут помочь в контексте: подсветить гайку, которую надо закрутить;
— CLI и умная строка удобнее для поиска чего-то конкретного (например, приложения в телефоне по названию), ответа на вопрос в виде небольшого структурированного текста, получения конкретного нужного пользователю результата;
— GUI удобнее для поиска и выбора, когда ещё нет точного запроса, когда не знаешь всех возможностей системы, когда нужно что-то подправить (проще указать, чем описывать) или видеть всё сразу (дашборд);
— Там, где человеку нужно сформулировать цель, делегировать сложное действие или быстро получить ответ, умная строка будет удобнее кнопок. Там, где нужно сравнить варианты, увидеть состояние системы, управлять сложным процессом или точно указать на объект, GUI останется сильнее.

#command_line #ai

Александр Ушаков написал о чатоцентричном интерфейсе.

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

#chat #ai

Андрей Шапиро написал о слабых местах подхода SDD (Specification-Driven Development) в агентной разработке.

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

При этом решения, с которыми агент угадал, в документе не фиксируются. С той же спецификацией во второй раз может получиться другой результат. Детерминированный агент сделает выбор решения повторяемым, но выбор изменится вместе с моделью, её версией или контекстом.

Решение: когда оператор принимает результат, все удачные решения агента делать частью спецификации. Но всё равно останутся нежелательные феномены.

1) Дрейф — отклонение агента от спецификации.
2) Эрозия — потеря важных деталей при правках. Изменение А приводит к незаметному изменению Б, потому что часть важного для Б контекста исключается как неважная для А.
3) Наплыв — перенос свойств объектов, которые видит агент, без требования о переносе. Пример становится образцом целиком, вместе со случайными чертами вроде оформления.

Полностью пересобирать систему при обновлении спецификации дорого, поэтому её код становится точкой отсчёта для следующих итераций. Написанные машиной тесты подвержены ошибкам того же рода. А человек работает медленно, может не заметить дрейф и не видит эрозию там, куда не смотрит.

#ai #docs

Роман Горшков рассказал о переходе дизайн-команды с Фигмы на Клод.

Дизайнер может делать больше задач и быстрее разгребать беклог: что занимало 2 дня, делается за 2 часа. И нет торговли с разработчиками, чтобы реализовать какой-то эффект.

ИИ помогает проверять больше версий решения задачи (есть сервисы, где запрос можно отправить сразу в 4 LLM для одновременной генерации) и захватывать смежные области: саунд- и шрифтовой дизайн. Время всё равно тратишь, но получаешь больше.

Если генерить грамотно, не будет видно, что это ИИ. Надо уметь передавать ИИ свой стиль, логику и онтологию, иначе их будет задавать ИИ, и тогда будет чувствоваться инструмент.

Сейчас опасно ковыряться в кривых и пикселях. Клод создаёт на 99% готовый продукт: специалист может увидеть неправильный рефлекс, баг отражения. Но стоит ли тратить ещё столько же времени, сколько уже потрачено, чтобы довести до 100%? Насколько 1% портит впечатление аудитории? Надо организовывать процесс так, чтобы как можно больше проходить на автомате.

Не нужно знать Фигму с её переменными, плагинами для выгрузки токенов. Она нужна на 5%: поставить рядом пару картинок, собрать историю, подправить что-то небольшое.

Надо научиться не просто вайбкодить (на уровне Фигма Мейк), а пользоваться репозиториями, создавать ветки, коммитить и создавать готовый фронт, использовать скилы и петли проверки. Сейчас таких специалистов мало.

Дизайнеру остаются дискавери, творческий поиск, придумывание вариантов, UX, дизайн-мышление, юзабилити, проработка флоу, приоритеты, выбор из получающихся вариантов. Пригодится база: колористика, насмотренность, хороший вкус. Профессия дизайнера ментальная, а не инструментальная: инструменты меняются, профессия остаётся. Не думать пока нельзя. Надо уметь делать то, что кому-то нужно.

Важные софты: 1) Логика, умение рассуждать хотя бы на уровне своего модуля и делать выводы. Раньше Роман предлагал тестовые задания, теперь задаёт вопросы, чтобы понять, как соискатель формулирует мысли и двигается к ответу. 2) Критическое мышление, умение признавать ошибки и обучаться.

Изменение процесса команда приняла с энтузиазмом: по кайфу получать сразу кликабельный результат. Около 10% не захотели отказываться от старого процесса и ушли думать, подходит ли им новая парадигма.

Перестройка заняла полгода. Руководители разобрались, как делать компоненты с Клодом и стабильно собирать экраны с существующим стилем. Обратным инжинирингом выясняли, почему ИИ сделал что-то не так, какие инструкции сработали. Затем подготовили обучающие материалы и провели первопроходцев, чтобы переход был мягким. Теперь дизайн-опс и лиды помогают настраивать репозитории и осваивать новый процесс.

Когда дизайнер пишет, что результат не подходит, настроенный хук отправляет диалог в дизайн-опс, чтобы они выяснили: проблема в промпте или текущих особенностях работы Клода.

В среднем дизайнеру хватает тарифа за 100 долларов, чтобы делать фронт без больших петель проверки и многих параллельных запросов. Загрузка онтологии дизайн-системы съедает все 20-долларовые лимиты.

С сокращением time to market стали маркировать задачи и менее критичные без ревью лида и дизайн-директора раскатывать волнами на всю аудиторию с пост-ревью. Поддержка и интеграторы дают много фидбека. Продукт большой, часто невозможно узнать обо всех кейсах использования.

#ai #process