Илья Александров написал о своём опыте создания прототипов: аппарат по продаже симкарт, экран в кабине грузовика, процесс настройки «лайтпака» (аналог Philips Ambilight), звуковая индикация в носимом устройстве — всё кроме сайтов и приложений.

Зачем эти прототипы потребовались, как помогли сэкономить время, сдвинуть проект с мёртвой точки и создать более качественный продукт.

#prototype

Олег Удалов рассказал об интерактивных прототипах.

— Интерактивный прототип симулирует взаимодействие пользователя с продуктом;
— У прототипов может быть разная детализация: от вайрфреймов (можно проверить сценарии взаимодействия) до готовых макетов (становятся основной для разработки продукта);
— Состав прототипа и уровень детализации можно адаптировать под текущие задачи, например: составить представление о будущем продукте, увидеть возможные проблемы предлагаемого решения и потерянные сценарии и экраны, оценить и протестировать удобство интерфейса, получить обратную связь и новые идеи от заказчика или целевой аудитории;
— Прототип создаётся до написания кода и позволяет быстро вносить изменения. Как следствие, сокращаются срок и стоимость разработки;
— Инструменты для создания: Figma, Invision, Protopie, Principle, Framer. От себя добавлю: Axure.

#prototype

Маргарита Романова показала, как без больших трудозатрат повысить интерактивность прототипов в Фигме.

— Выделение строки таблицы, отображение раскрывающегося списка действий со строкой, изменение статуса строки — с помощью интерактивных компонентов;
— Для раскрывающегося списка настройка Absolute position позволяет игнорировать Auto layout компонента, в котором он находится;
— Для Auto layout таблицы настройте Canvas stacking: First on top. Так верхние строки расположатся в слоях выше, и нижние строки не будут перекрывать раскрывающиеся списки действий;
— Отображение в таблице большого количества тултипов;
— Component properties позволяет работать с текстом, не переходя на конкретный слой с текстом. Функция Expose properties from Nested instances позволяет редактировать текст тултипа прямо в свойствах инстанса родительского компонента;
— Чтобы редактировать текст тултипов, которые отображаются с помощью интерактивного компонента, для состояния компонента без тултипа надо добавить тултип с нулевой прозрачностью.

#figma #prototype #table

Екатерина Бессчётнова написала о подготовке прототипа для пользовательского тестирования.

— Прототип строится вокруг сценария тестирования — вопросов и заданий, предлагаемых респондентам;
— Задания следуют из гипотез. Гипотеза: при подборе товара людям неудобно использовать фильтр по цене. Задания: подберите товар Х удобным способом; подберите товар Х не дороже 10 рублей;
— Продумайте точки входа в тестируемый сценарий, чтобы он не начинался для пользователя внезапно;
— Отобразите все граничные случаи, с которыми пользователь может столкнуться, например, сообщение об ошибке, если заполнены не все поля. Страницу с 404-й ошибкой добавлять не надо;
— Добавьте максимум путей решения задачи, чтобы увидеть, куда пользователи на самом деле пойдут, и сравнить эффективность главного и второстепенного пути;
— Добавьте ошибочные пути, чтобы не было гарантии, что все респонденты выполнят задания. Так можно узнать, когда они заметят ошибку и как будут её исправлять. Активны должны быть не все развилки, а только вызывающие сомнения;
— Проработайте не только линейный путь вперёд по сценарию, но и способы вернуться назад;
— Чем ближе прототип к финальному продукту и реалистичнее взаимодействие с элементами интерфейса, тем лучше: визуальные акценты, реалистичный текст и релевантный контент, соответствие тону голоса и так далее;
— Если пользователи должны вводить данные, поля должны быть активны и не заполнены. Если это не прототип в Axure, поля можно заполнять по нажатию. Проверьте, что контент адекватен выполняемому заданию;
— Скройте отображение кликабельных областей и, насколько возможно, служебный интерфейс прототипа;
— Некликабельные элементы, с которыми предположительно могут взаимодействовать респонденты, должны реагировать на наведение курсора и, например, приводить к изменению курсора;
— Учитывайте разрешение устройства, на котором будет проходить тестирование;
— Перед тестированием на респондентах, проверьте прототип внутри команды.

#prototype #user_testing

Кирилл Шерстобитов написал о подготовке прототипа к тестированию.

— Определите, что вы хотите проверить с помощью прототипа;
— Чтобы увидеть проблемы и сформулировать гипотезы, часто проводят модерируемые тесты, для которых подходят даже недоработанные прототипы — модератор может смягчить связанные с ними негативные эффекты;
— Для проверки интерфейсных гипотез лучше подходят количественные методы (от 100 человек на тест). Здесь модератор уже не поможет, поэтому важны понятное задание и работоспособность прототипа (в том числе быстрая загрузка);
— Чтобы проверить навигацию на удобство и понятность, не обязательно делать прототип, можно провести First click test;
— Прототипом можно проверить сценарии поведения в интерфейсе, взаимодействие с интерактивными элементами;
— Разбивайте интерфейс на короткие сценарии под конкретные задачи. Так проще будет готовить прототип, и грузиться он будет быстрее;
— Оптимизируйте прототип для более быстрой загрузки: убирайте лишние скрытые элементы, используйте облегчённые изображения вместо хайрезов;
— Часть советов повторяет статью Екатерины Бессчётновой, которая уже была в UX Notes.

#prototype #user_testing

Иван Мрачко написал о пользе прототипов в заказной разработке.

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

#prototype

Я написал, как быстро сделать в Фигме прототип формы, поля которой можно заполнять в любом порядке.

— С этим помогут локальные переменные (Variables) и условия (экшен Conditional);
— Если их не использовать и просто переводить пользователя с одного экрана на другой, для формы из 4 полей потребуется 16 экранов (включая полностью заполненную форму и полностью незаполненную);
— Поля, с которыми будет взаимодействовать пользователь, надо заменить на локальные компоненты с вариантами «Не заполнено» и «Заполнено»;
— Когда пользователь заполняет поле, это надо сохранять в локальную переменную;
— При отображении формы надо проверять переменные и переключать компоненты заполненных полей на нужный вариант: триггер After delay, повешенный на компоненты конкретных полей, плюс экшен Conditional.

#figma #prototype #form

Маргарита Романова написала первую статью из серии об эффективном прототипировании в Фигме.

— Нелинейный прототип позволяет пользователю отойти от идеального сценария, совершить ошибки. Взаимодействие становится реалистичнее, а инсайты — качественнее;
— Можно проверить интерфейсы, в которых к цели ведут несколько путей;
— В Фигме есть экшен Navigate to, но его лучше использовать для переходов между страницами, а не состояниями одной и той же страницы. Иначе получится куча связанных фреймов, и редактировать такой прототип больно;
— Для возвращения назад используйте экшен Back, он сразу добавляет обратную анимацию;
— Экшен Change to переключает инстанс компонента в заданное состояние. Его достаточно, когда взаимодействие ограничено этим инстансом. Например, пользователь навёл курсор на кнопку, и она изменила цвет;
— С помощью переменных, привязанных к слоям и компонентам, можно сделать так, чтобы действие запускало событие (экшен Set variable), которое будет определённым образом модифицировать эти слои и компоненты;
— Но в этом случае без Smart animate, только Instant;
— Один триггер (например, нажатие на элемент) может приводить к комбинации экшенов. Например, Navigate to и Set variable;
— Популярная ошибка: с помощью Change to настроить, чтобы нажатие на чекбокс ставило или снимало флаг. Если в конкретном сценарии нажатие на него должно делать что-то ещё (разблокировать кнопку), будет 2 конкурирующих набора экшенов, срабатывающих на один триггер (нажатие на чекбокс);
— В этом случае сработают экшены инстанса в сценарии, то есть кнопка в форме разблокируется, а флаг в чекбоксе не появится;
— Решение: сделать интерактивный компонент, но логику привязать к переменной, а не триггеру.

#figma #prototype

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

— Понадобится 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

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

— Вероятность получить ТЗ не в виде длинной спецификации, а в виде вайбкод-прототипа с каждым днём становится всё больше;
— Надо учиться их запускать, а также тестировать с пользователями;
— Потребуется редактор кода. К 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

Маргарита Попова написала об итеративном процессе в дизайне.

— Полезен новым продуктам (MVP и R&D-проекты), в условиях неопределённости, без готовой дизайн-системы, для ускорения поставок функциональности пользователям;
— В каскадной модели разработка следует за дизайном. Минусы: этап дизайна кажется бесконечным, разработчики приходят с вопросами, когда дизайнеры уже заняты другим;
— Дизайн блока функциональности (запланированного в USM) можно разделить, чтобы идти от общих вопросов к частным и чаще получать обратную связь;
— 1. Формирование общей картины: работа с PO и PM, создание User flow, схем работы и прототипов от руки, которые легко выбрасывать при переборе идей;
— 2. Детализация прототипов, добавление отдельных интерактивных элементов, чтобы провести простые пользовательские тесты сценариев использования и обсудить с разработчиками функциональность. Последние могут приступать к проектированию архитектуры;
— 3. Подробный интерактивный прототип со всеми состояниями, дающий возможность провести полноценное тестирование с пользователями. После тестов — внесение правок, запись идей на следующие итерации;
— 4. Дальнейший дизайн идёт параллельно разработке: макеты, состояния компонентов, подготовка к вёрстке, UI-кит;
— Плюсы: вся команда вовлечена в проектирование и принятие решений, решения тестируются, технические вопросы решаются раньше;
— Минусы: сложнее тестировать не финальные макеты, разработка стартует после проработки всего блока функциональности, обсуждения переключают контекст разработчиков;
— Если брать не блок, а небольшой кусочек, можно спроектировать его за спринт (хотя бы простой вариант для начала);
— Плюсы: у разработчиков и дизайнеров общий контекст, пользователи получат фичу и дадут обратную связь, видны метрики, может оказаться, что цель достигнута и дальше полировать дизайн смысла нет;
— Минусы: более сырой интерфейс, большие сценарии не умещаются в спринт, сложнее управлять, больше техдолг;
— Чтобы потом вспомнить, какие дизайн-решения были приняты и почему, можно использовать аналог ADR (пример);
— Когда останавливаться в полировке прототипа: покрыты все сценарии, улучшения не приносят заметной пользы, у команды не осталось вопросов, появилось желание выровнять отступы;
— Итеративный подход снижает тревогу по поводу идеальности результата, а также предлагает задуматься, что считать идеальным результатом (приносит пользу клиентам уже сейчас).

#process #prototype