Лекция 2. Подготовка к UI/UX-проекту

Введение

Работа UI/UX-дизайнера начинается не с открытия Figma и не с выбора цветов для интерфейса.

До того как дизайнер создаст первый экран, необходимо понять:

• какой продукт предстоит проектировать;

• для кого создается продукт;

• какую проблему он должен решить;

• какие задачи ставит заказчик;

• какие ограничения существуют;

• кто будет участвовать в проекте;

• как команда будет принимать решения;

• по каким показателям будет оцениваться результат.

Этот этап называется подготовкой к проекту. В профессиональной среде также используются понятия discovery, предпроектное исследование, сбор требований и погружение в продукт.

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

Поэтому задача UI/UX-дизайнера состоит не только в том, чтобы проектировать экраны. Дизайнер должен понимать контекст продукта и уметь взаимодействовать с заказчиком, менеджерами, маркетологами, разработчиками и тестировщиками.

Цели лекции

После изучения лекции вы сможете:

1. Понять, из каких этапов состоит подготовка к UI/UX-проекту.

2. Определить, какие данные необходимо получить от заказчика.

3. Сформулировать цели, задачи и ограничения проекта.

4. Понять роли участников продуктовой команды.

5. Разобраться, как дизайнер взаимодействует с менеджером, маркетологом, разработчиком и тестировщиком.

6. Понять основные принципы Agile.

7. Подготовить первичную документацию проекта.

8. Использовать ChatGPT для анализа брифа, подготовки вопросов и планирования работы.

1. Что такое подготовка к проекту

Подготовка к проекту представляет собой сбор, проверку и структурирование информации, которая необходима команде для начала работы.

На этом этапе команда еще не создает финальный продукт. Она формирует общее понимание того, что именно нужно сделать и зачем.

Подготовка должна ответить на несколько главных вопросов:

Что мы создаем?

Например:

• интернет-магазин;

• мобильное приложение банка;

• образовательную платформу;

• личный кабинет пациента;

• лендинг нового продукта;

• внутреннюю CRM-систему;

• сервис онлайн-записи;

• редизайн существующего сайта.

Зачем мы это создаем?

Проект должен решать определенную проблему.

Например:

• пользователям сложно оформить заказ;

• компания получает слишком много звонков;

• сотрудники выполняют операции вручную;

• клиенты не понимают стоимость услуги;

• пользователи регистрируются, но не начинают пользоваться продуктом;

• существующий интерфейс неудобен на мобильных устройствах.

Для кого мы это создаем?

Необходимо определить будущих пользователей продукта.

Например:

• студенты;

• преподаватели;

• владельцы малого бизнеса;

• медицинские специалисты;

• родители школьников;

• сотрудники компании;

• администраторы;

• покупатели интернет-магазина.

У одного продукта может быть несколько групп пользователей. Например, у образовательной платформы могут быть преподаватели, ученики, родители и администраторы.

Какие ограничения существуют?

Ограничения могут быть:

• финансовыми;

• техническими;

• временными;

• юридическими;

• организационными;

• связанными с брендом;

• связанными с доступностью данных;

• связанными с квалификацией команды.

Как поймем, что проект успешен?

Результат должен быть измеримым.

Например:

• увеличить количество регистраций;

• сократить время оформления заказа;

• уменьшить количество ошибок;

• повысить конверсию;

• увеличить число пользователей, которые выполняют целевое действие;

• снизить нагрузку на операторов;

• повысить удовлетворенность пользователей.

2. Почему нельзя сразу переходить к дизайну

Заказчик может прийти к дизайнеру с готовой формулировкой:

Нам нужно мобильное приложение.

Но это еще не означает, что бизнесу действительно необходимо мобильное приложение.

Возможно, пользователям будет достаточно адаптивной мобильной версии сайта. Или проблема вообще заключается не в отсутствии приложения, а в сложном процессе оформления заказа.

Другой пример:

Сделайте большую красную кнопку, чтобы пользователи чаще нажимали.

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

Необходимо спросить:

• Какую кнопку пользователи не замечают?

• Какое действие они должны выполнить?

• Есть ли данные о поведении пользователей?

• На каком этапе возникает проблема?

• Что происходит после нажатия?

• Что мешает пользователю принять решение?

• Понимает ли пользователь ценность действия?

Правильная подготовка помогает отделить запрос заказчика от реальной проблемы.

Запрос заказчика может звучать так:

Сделайте современный дизайн.

Реальная проблема может заключаться в другом:

Пользователи не понимают, как выбрать тариф, и покидают страницу.

Поэтому дизайнер должен работать не только с формой интерфейса, но и с причиной поведения пользователя.

3. Основные этапы подготовки к проекту

Подготовку можно разделить на несколько последовательных этапов.

Этап 1. Первичное знакомство

Команда получает общее представление о заказчике и проекте.

На этом этапе необходимо выяснить:

• чем занимается компания;

• какой продукт она предлагает;

• существует ли продукт сейчас;

• кто его использует;

• почему появился запрос на дизайн;

• какой результат ожидает заказчик;

• кто принимает решения;

• какие сроки предполагаются.

На первой встрече не обязательно обсуждать каждую деталь. Главная задача состоит в том, чтобы определить масштаб проекта и понять, какие специалисты понадобятся.

Этап 2. Сбор информации

Команда проводит интервью с заказчиком и заинтересованными сторонами.

Заинтересованные стороны, или стейкхолдеры, это люди, которые:

• влияют на проект;

• принимают решения;

• используют продукт;

• финансируют проект;

• отвечают за его развитие;

• будут работать с результатом.

К стейкхолдерам могут относиться:

• владелец бизнеса;

• руководитель продукта;

• менеджер проекта;

• маркетолог;

• руководитель отдела продаж;

• технический директор;

• сотрудники поддержки;

• администраторы;

• конечные пользователи.

Важно не ограничиваться разговором только с руководителем компании. Руководитель видит продукт с позиции бизнеса, а сотрудники поддержки или продаж могут лучше знать реальные проблемы клиентов.

Этап 3. Анализ полученной информации

Собранные данные необходимо проверить и структурировать.

В ходе анализа команда определяет:

• основную проблему;

• цели проекта;

• пользователей;

• ключевые сценарии;

• функциональные требования;

• ограничения;

• риски;

• спорные вопросы;

• недостаток информации;

• предположения, которые необходимо проверить.

Очень важно разделять факты и предположения.

Факт

По данным аналитики, 60% пользователей покидают страницу оформления заказа на этапе выбора способа доставки.

Предположение

Пользователям не нравится расположение блока доставки.

Предположение нельзя считать доказанным фактом. Его необходимо проверить с помощью аналитики, интервью, опроса, тестирования прототипа или других методов исследования.

Этап 4. Формирование документации

Результаты подготовки фиксируются в документах.

В зависимости от проекта команда может создать:

• бриф;

• техническое задание;

• описание продукта;

• список требований;

• карту стейкхолдеров;

• список пользовательских групп;

• список пользовательских сценариев;

• список функций;

• ограничения проекта;

• список рисков;

• план исследований;

• план работ;

• продуктовый бэклог;

• дорожную карту.

Необязательно создавать все документы одновременно. Состав документации зависит от масштаба и сложности проекта.

Этап 5. Формирование команды

После определения масштаба проекта становится понятно, какие специалисты понадобятся.

Например, для небольшого лендинга команда может состоять из:

• заказчика;

• менеджера;

• дизайнера;

• копирайтера;

• frontend-разработчика.

Для сложного цифрового сервиса могут потребоваться:

• продакт-менеджер;

• проджект-менеджер;

• бизнес-аналитик;

• системный аналитик;

• маркетолог;

• UX-исследователь;

• UX/UI-дизайнер;

• frontend-разработчики;

• backend-разработчики;

• мобильные разработчики;

• тестировщики;

• DevOps-инженер;

• специалист поддержки.

Этап 6. Согласование процесса работы

До начала проектирования необходимо договориться:

• где хранятся материалы;

• где ведутся задачи;

• как часто проходят встречи;

• кто принимает финальные решения;

• как согласовывается дизайн;

• кто дает обратную связь;

• как фиксируются изменения;

• как команда сообщает о рисках;

• кто отвечает за связь с заказчиком.

Если правила взаимодействия не определены, команда может получать противоречивые комментарии от разных представителей заказчика.

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

Поэтому важно заранее определить человека, который принимает финальное решение.

4. Какие данные необходимо получить от заказчика

4.1. Информация о компании

Необходимо узнать:

• название компании;

• сфера деятельности;

• основные продукты и услуги;

• география работы;

• размер компании;

• история компании;

• позиционирование;

• основные конкуренты;

• каналы продаж;

• источники дохода;

• ценности бренда.

Эта информация помогает понять бизнес-контекст проекта.

4.2. Информация о продукте

Следует выяснить:

• что представляет собой продукт;

• какую проблему он решает;

• какую пользу получает пользователь;

• чем продукт отличается от конкурентов;

• существует ли продукт сейчас;

• какие функции уже реализованы;

• какие функции необходимо добавить;

• какие функции являются приоритетными;

• на каких устройствах используется продукт;

• как пользователь узнает о продукте;

• каким образом продукт приносит доход.

Полезно попросить заказчика объяснить продукт максимально простыми словами.

Например:

Наш сервис помогает преподавателю создать интерактивный тест, отправить его студентам и посмотреть результаты прохождения.

Такое описание понятнее, чем длинный перечень технологий и функций.

4.3. Цели бизнеса

Дизайнеру необходимо понимать, зачем компания запускает проект.

Целями могут быть:

• увеличение продаж;

• привлечение новых пользователей;

• повышение конверсии;

• снижение затрат;

• автоматизация процессов;

• выход на новый рынок;

• запуск нового продукта;

• повышение удержания пользователей;

• снижение количества обращений в поддержку;

• повышение узнаваемости бренда.

Формулировка «сделать красивый сайт» не является полноценной бизнес-целью.

Более точная цель может звучать так:

Упростить выбор тарифа и увеличить долю пользователей, которые переходят от просмотра страницы к регистрации.

4.4. Проблема проекта

Необходимо определить, что именно сейчас работает неправильно.

Примеры:

• пользователи не завершают регистрацию;

• клиентам сложно найти нужную услугу;

• интерфейс содержит слишком много функций;

• сотрудники вынуждены переносить данные вручную;

• продукт неудобно использовать со смартфона;

• пользователи не понимают различия между тарифами;

• система допускает большое количество ошибок;

• заказчик не получает нужные данные о клиентах.

Хорошая формулировка проблемы не должна заранее содержать решение.

Плохо:

Нам нужна кнопка быстрого заказа.

Лучше:

Пользователи тратят слишком много времени на оформление заказа и часто не завершают процесс.

4.5. Целевая аудитория

У заказчика необходимо спросить:

• кто использует продукт;

• сколько лет пользователям;

• чем они занимаются;

• где и когда используют продукт;

• какими устройствами пользуются;

• насколько хорошо разбираются в теме;

• какие задачи хотят решить;

• чего опасаются;

• какие сложности испытывают;

• какие альтернативные продукты используют;

• кто принимает решение о покупке;

• кто оплачивает продукт;

• кто фактически работает с интерфейсом.

Покупатель и пользователь могут быть разными людьми.

Например, образовательную платформу оплачивает школа, решение принимает директор, работает с редактором преподаватель, а проходит задания ученик.

Все эти роли необходимо учитывать.

4.6. Пользовательские задачи и сценарии

Пользовательский сценарий описывает последовательность действий, с помощью которых человек достигает цели.

Например, сценарий записи к врачу:

1. Пользователь открывает сайт клиники.

2. Выбирает направление.

3. Находит врача.

4. Смотрит свободное время.

5. Выбирает дату.

6. Вводит контактные данные.

7. Подтверждает запись.

8. Получает уведомление.

Необходимо определить:

• с чего начинается сценарий;

• какую цель преследует пользователь;

• какие действия выполняет;

• где может столкнуться с проблемой;

• какую информацию должен получить;

• чем заканчивается сценарий.

На этапе подготовки необязательно детально проектировать каждый экран. Сначала важно понять общую логику действий.

4.7. Функциональные требования

Функциональные требования описывают, что система должна уметь делать.

Например:

• пользователь может зарегистрироваться;

• пользователь может восстановить пароль;

• преподаватель может создать тест;

• администратор может заблокировать пользователя;

• покупатель может добавить товар в корзину;

• клиент может оплатить заказ;

• менеджер может экспортировать данные;

• система может отправить уведомление.

Необходимо определить приоритет функций.

Для этого функции можно разделить на три группы:

Обязательные

Без них продукт не сможет решать основную задачу.

Желательные

Они улучшают продукт, но могут быть реализованы позже.

Дополнительные

Они не являются критически важными для первой версии.

Такой подход помогает не пытаться реализовать все идеи одновременно.

4.8. Контент

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

У заказчика необходимо узнать:

• есть ли готовые тексты;

• кто отвечает за тексты;

• есть ли фотографии;

• есть ли видеоматериалы;

• потребуется ли создавать иллюстрации;

• на каких языках будет продукт;

• кто проверяет юридические формулировки;

• как часто обновляется информация;

• какой объем контента необходимо разместить.

Если контента пока нет, дизайнер должен учитывать это при планировании.

Нельзя проектировать интернет-магазин, не понимая, какие характеристики товаров необходимо показывать.

4.9. Фирменный стиль

Необходимо запросить:

• логотип;

• брендбук;

• фирменные цвета;

• шрифты;

• правила использования изображений;

• примеры рекламных материалов;

• существующие компоненты интерфейса;

• дизайн-систему;

• требования к тону коммуникации.

Если фирменного стиля нет, необходимо отдельно определить, входит ли его разработка в проект.

Создание интерфейса и создание айдентики являются разными задачами. Они могут выполняться параллельно, но требуют разных ресурсов и сроков.

4.10. Технические ограничения

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

Следует уточнить:

• для какой платформы создается продукт;

• будет ли это сайт, приложение или внутренняя система;

• какие технологии используются;

• существует ли готовая база данных;

• есть ли API;

• с какими системами должна работать интеграция;

• какие браузеры и устройства необходимо поддерживать;

• существуют ли ограничения скорости;

• есть ли готовая библиотека компонентов;

• используется ли существующая дизайн-система;

• какие решения невозможно реализовать в текущей архитектуре.

Технические ограничения лучше обсуждать вместе с разработчиками.

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

4.11. Аналитика и исследования

Необходимо узнать, какие данные уже есть у заказчика:

• веб-аналитика;

• статистика регистраций;

• воронка продаж;

• записи пользовательских сессий;

• обращения в поддержку;

• отзывы;

• результаты опросов;

• проведенные интервью;

• результаты юзабилити-тестирований;

• данные CRM;

• причины отказов;

• поисковые запросы;

• статистика использования функций.

Иногда заказчик уже располагает большим количеством данных, но они находятся в разных отделах.

Например:

• маркетолог знает, откуда приходят пользователи;

• отдел продаж знает причины отказов;

• поддержка знает частые проблемы;

• разработчики знают технические ошибки;

• аналитик знает, на каком этапе пользователи покидают продукт.

Задача команды состоит в том, чтобы объединить эти данные.

4.12. Сроки и бюджет

Необходимо уточнить:

• когда проект должен быть запущен;

• почему выбрана именно эта дата;

• какие этапы должны быть завершены раньше;

• есть ли внешнее событие, от которого зависит запуск;

• какой бюджет выделен;

• входит ли разработка в бюджет;

• входит ли исследование;

• входит ли создание контента;

• входят ли дальнейшие доработки.

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

Понимание причины помогает правильно расставить приоритеты.

4.13. Процесс согласования

Следует определить:

• кто является заказчиком;

• кто принимает финальное решение;

• кто может давать комментарии;

• кто согласовывает тексты;

• кто согласовывает технические решения;

• кто утверждает дизайн;

• сколько времени занимает согласование;

• где фиксируется обратная связь;

• сколько итераций правок предусмотрено.

Обратную связь желательно собирать в одном месте.

Если один человек пишет комментарии в мессенджере, другой отправляет письмо, а третий звонит дизайнеру, часть требований неизбежно потеряется.

5. Вопросы для первой встречи с заказчиком

На первой встрече можно использовать следующий список.

О бизнесе

1. Чем занимается компания?

2. Какие продукты или услуги являются основными?

3. Как компания зарабатывает?

4. Кто является основным клиентом?

5. Кто считается главным конкурентом?

6. Чем компания отличается от конкурентов?

О проекте

1. Что необходимо создать или изменить?

2. Почему проект появился именно сейчас?

3. Какую проблему необходимо решить?

4. Что происходит, если ничего не менять?

5. Как выглядит ожидаемый результат?

6. Есть ли примеры решений, которые нравятся заказчику?

7. Есть ли решения, которые точно не подходят?

О пользователях

1. Кто будет пользоваться продуктом?

2. Какие задачи выполняют пользователи?

3. В каком контексте они используют продукт?

4. Какие проблемы возникают сейчас?

5. Есть ли результаты исследований?

6. Можно ли поговорить с реальными пользователями?

О функциональности

1. Какие действия пользователь должен выполнять?

2. Какие функции являются обязательными?

3. Какие функции можно реализовать позже?

4. Какие роли пользователей существуют?

5. Какие данные необходимо собирать?

6. Какие уведомления должна отправлять система?

Об организации работы

1. Кто принимает финальные решения?

2. Кто участвует в согласовании?

3. Кто отвечает за контент?

4. Кто отвечает за разработку?

5. Где будут храниться материалы?

6. Как часто команда может встречаться?

7. Какие сроки и контрольные точки существуют?

6. Что такое бриф

Бриф представляет собой структурированное описание проекта.

Он помогает зафиксировать:

• информацию о заказчике;

• цели;

• проблему;

• аудиторию;

• требования;

• ограничения;

• сроки;

• участников;

• ожидаемый результат.

Бриф не должен восприниматься как формальность. Его задача состоит в том, чтобы создать единое понимание проекта.

Хороший бриф позволяет всем участникам одинаково ответить на вопросы:

• что мы создаем;

• для кого;

• зачем;

• к какому сроку;

• в каких границах;

• по каким критериям принимается результат.

При этом бриф не является неизменяемым документом. В ходе исследования команда может получить новые данные и скорректировать первоначальные предположения.

7. Формирование команды проекта

Состав команды зависит от:

• масштаба продукта;

• количества функций;

• сроков;

• бюджета;

• технической сложности;

• количества платформ;

• требований к исследованиям;

• количества пользователей;

• требований к безопасности.

В небольшом проекте один специалист может выполнять несколько ролей.

Например, дизайнер может проводить интервью, создавать прототип и готовить интерфейс. Проджект-менеджер может одновременно общаться с заказчиком и вести документацию.

В большом проекте роли разделяются между несколькими специалистами.

Рассмотрим основные роли.

8. Проджект-менеджер

Проджект-менеджер, или project manager, отвечает за организацию проекта.

Его главная задача состоит в том, чтобы команда выполнила согласованный объем работ в установленные сроки и с учетом имеющихся ресурсов.

Основные обязанности проджект-менеджера

• планирование этапов проекта;

• постановка и распределение задач;

• контроль сроков;

• организация встреч;

• коммуникация с заказчиком;

• контроль изменений;

• управление рисками;

• разрешение организационных конфликтов;

• контроль загрузки команды;

• ведение проектной документации;

• информирование участников о состоянии проекта.

Проджект-менеджер не обязательно принимает продуктовые или дизайнерские решения. Он организует процесс, в рамках которого специалисты могут выполнять свою работу.

Взаимодействие дизайнера с проджект-менеджером

Дизайнер сообщает менеджеру:

• сколько времени требуется на исследование;

• какие данные отсутствуют;

• какие решения необходимо согласовать;

• какие риски обнаружены;

• какие задачи зависят от других специалистов;

• когда макеты готовы к проверке;

• почему изменился объем работы.

Проджект-менеджер помогает дизайнеру:

• получить информацию от заказчика;

• организовать интервью;

• согласовать сроки;

• собрать обратную связь;

• подключить разработчиков;

• зафиксировать изменения.

9. Маркетолог

Маркетолог отвечает за понимание рынка, продвижение продукта и привлечение аудитории.

Основные обязанности маркетолога

• анализ рынка;

• анализ конкурентов;

• сегментация аудитории;

• определение каналов продвижения;

• формирование позиционирования;

• разработка рекламных предложений;

• анализ рекламных кампаний;

• работа с воронкой привлечения;

• изучение спроса;

• оценка стоимости привлечения клиента;

• подготовка маркетинговых материалов.

Взаимодействие маркетолога и UI/UX-дизайнера

Маркетолог помогает дизайнеру понять:

• откуда приходит пользователь;

• какое рекламное сообщение он увидел;

• что ему обещали;

• к какому сегменту он относится;

• какое действие считается целевым;

• какие возражения возникают перед покупкой;

• какие предложения лучше работают.

Дизайнер, в свою очередь, помогает маркетологу:

• сделать посадочную страницу понятной;

• выстроить пользовательский путь;

• правильно представить ценность продукта;

• уменьшить количество лишних действий;

• создать понятные формы;

• улучшить конверсионные сценарии.

Важно учитывать согласованность рекламы и интерфейса.

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

10. UI/UX-дизайнер

UI/UX-дизайнер проектирует взаимодействие пользователя с цифровым продуктом.

UX означает user experience, то есть пользовательский опыт.

UI означает user interface, то есть пользовательский интерфейс.

UX-задачи дизайнера

• изучение пользователей;

• анализ задач и сценариев;

• построение пользовательских путей;

• разработка информационной архитектуры;

• создание схем и прототипов;

• проведение юзабилити-тестирований;

• проверка гипотез;

• выявление проблем взаимодействия.

UI-задачи дизайнера

• разработка визуального языка интерфейса;

• работа с цветом;

• подбор типографики;

• создание сеток;

• проектирование компонентов;

• подготовка состояний элементов;

• адаптация интерфейса под разные экраны;

• создание дизайн-системы;

• подготовка макетов для разработки.

На практике UX и UI часто связаны. Но важно понимать, что визуальное оформление является только частью работы дизайнера.

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

11. Разработчики

Разработчики превращают проект интерфейса в работающий цифровой продукт.

Frontend-разработчик

Frontend-разработчик отвечает за часть системы, с которой взаимодействует пользователь.

Он реализует:

• страницы;

• кнопки;

• формы;

• меню;

• анимации;

• адаптивность;

• визуальные состояния;

• взаимодействие с сервером;

• обработку действий пользователя.

Frontend-разработчик работает непосредственно с макетами дизайнера.

Backend-разработчик

Backend-разработчик отвечает за серверную логику, данные и внутренние процессы системы.

Он реализует:

• работу с базой данных;

• авторизацию;

• хранение информации;

• обработку запросов;

• бизнес-логику;

• интеграции;

• права доступа;

• отправку уведомлений;

• работу API.

Например, дизайнер создает экран регистрации, frontend-разработчик реализует форму, а backend-разработчик обеспечивает создание пользователя в базе данных.

Взаимодействие дизайнера с разработчиками

Дизайнеру необходимо передать:

• макеты;

• размеры;

• отступы;

• состояния элементов;

• адаптивные версии;

• сценарии взаимодействия;

• поведение при ошибках;

• поведение при загрузке;

• пустые состояния;

• тексты;

• компоненты;

• прототипы;

• правила использования дизайн-системы.

Разработчиков желательно подключать до завершения дизайна.

Они могут заранее указать:

• какие решения слишком сложны;

• какие функции требуют дополнительного времени;

• какие компоненты уже существуют;

• какие технические ограничения необходимо учитывать;

• какие сценарии не были предусмотрены.

12. Тестировщик

Тестировщик, или QA-инженер, проверяет качество работающего продукта.

Основные обязанности тестировщика

• проверка соответствия требованиям;

• поиск ошибок;

• проверка пользовательских сценариев;

• проверка форм;

• проверка разных устройств;

• проверка разных браузеров;

• проверка нестандартных ситуаций;

• проверка сообщений об ошибках;

• проверка прав доступа;

• повторная проверка исправлений.

Тестировщик проверяет не только то, работает ли кнопка. Он анализирует, что произойдет в разных условиях.

Например:

• пользователь оставил поле пустым;

• ввел неправильный адрес электронной почты;

• потерял интернет-соединение;

• дважды нажал кнопку оплаты;

• открыл страницу на небольшом экране;

• попытался получить доступ к закрытому разделу.

Взаимодействие дизайнера с тестировщиком

Дизайнер должен описывать состояния интерфейса:

• обычное состояние;

• состояние наведения;

• состояние нажатия;

• состояние загрузки;

• состояние ошибки;

• успешное состояние;

• заблокированное состояние;

• пустое состояние.

Тестировщик может обнаружить ситуации, которые дизайнер не предусмотрел.

Например:

• слишком длинное имя пользователя;

• отсутствие результатов поиска;

• загрузка изображения неправильного формата;

• ошибка оплаты;

• окончание сессии;

• отсутствие доступа.

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

13. Дополнительные роли

В сложных проектах могут участвовать и другие специалисты.

Продакт-менеджер

Отвечает за развитие продукта:

• определяет продуктовое направление;

• формирует приоритеты;

• анализирует потребности пользователей;

• работает с метриками;

• принимает решения о развитии функций;

• управляет продуктовым бэклогом.

Проджект-менеджер отвечает преимущественно за организацию проекта, а продакт-менеджер за ценность и развитие продукта.

Бизнес-аналитик

Изучает бизнес-процессы и переводит потребности бизнеса в требования к системе.

Системный аналитик

Описывает взаимодействие систем, данные, интеграции, API и техническую логику.

UX-исследователь

Планирует и проводит исследования пользователей:

• интервью;

• опросы;

• наблюдения;

• юзабилити-тестирования;

• анализ поведения.

Копирайтер или UX-редактор

Отвечает за тексты интерфейса:

• названия;

• подсказки;

• сообщения об ошибках;

• инструкции;

• уведомления;

• тексты кнопок.

14. Как распределить ответственность

В начале проекта полезно создать таблицу ответственности.

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

15. Что такое Agile

Agile можно перевести как «гибкий подход».

Это не одна конкретная инструкция по управлению проектом, а система ценностей и принципов, которая помогает командам работать в условиях изменений.

Agile появился как альтернатива процессам, в которых сначала подробно описывался весь продукт, затем команда несколько месяцев занималась разработкой и только в конце показывала результат пользователю.

В Agile продукт создается постепенно. Команда выпускает небольшие части, получает обратную связь и корректирует дальнейшую работу.

Agile-манифест ставит взаимодействие людей выше формальных процессов, работающий продукт выше избыточной документации, сотрудничество с заказчиком выше жесткого следования условиям договора, а готовность к изменениям выше первоначального плана. Это не означает отказ от процессов, документации, договоров и планов. Они сохраняют значение, но не должны мешать созданию ценного результата. citeturn842259search9turn842259search16

16. Основные принципы Agile

16.1. Ценность для пользователя

Команда должна создавать не просто набор экранов или функций, а полезный результат.

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

Вместо вопроса:

Как сделать этот экран красивее?

Следует задавать вопрос:

Как этот экран помогает пользователю выполнить задачу?

16.2. Работа небольшими итерациями

Необязательно сразу создавать весь продукт.

Можно сначала разработать:

• основной пользовательский сценарий;

• минимальную версию продукта;

• одну ключевую функцию;

• прототип для проверки гипотезы.

После проверки команда может улучшать решение.

16.3. Готовность к изменениям

В начале проекта невозможно знать все.

Во время работы может выясниться, что:

• пользователям нужна другая функция;

• первоначальная гипотеза неверна;

• техническое решение слишком сложное;

• требования законодательства изменились;

• заказчик изменил бизнес-модель;

• исследование выявило новый сценарий.

Agile предполагает, что команда должна уметь адаптироваться, а не защищать первоначальный план любой ценой. Готовность принимать изменяющиеся требования, регулярная поставка результата, постоянное сотрудничество бизнеса и команды, внимание к качеству дизайна и регулярное улучшение процесса входят в официальные принципы Agile. citeturn842259search9turn842259search16

16.4. Постоянная коммуникация

Участники команды должны регулярно обмениваться информацией.

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

Лучше показывать результат поэтапно:

• пользовательский путь;

• структуру;

• схему;

• черновой прототип;

• интерактивный прототип;

• визуальную концепцию;

• готовые компоненты.

Так ошибки обнаруживаются раньше.

16.5. Работающий результат важнее объема документации

Документация необходима, но сама по себе она не является целью.

Можно написать техническое задание на сто страниц, но это не гарантирует, что продукт будет удобным.

Поэтому документация должна помогать команде:

• принимать решения;

• понимать требования;

• проверять результат;

• уменьшать количество ошибок.

16.6. Регулярная обратная связь

Команда должна показывать промежуточные результаты заказчику и пользователям.

Дизайнер может получать обратную связь через:

• обсуждение с командой;

• дизайн-ревью;

• демонстрацию заказчику;

• интервью;

• юзабилити-тестирование;

• анализ прототипа;

• анализ работающего продукта.

16.7. Постоянное улучшение процесса

Команда должна регулярно обсуждать:

• что получилось хорошо;

• что мешало работе;

• где возникли задержки;

• каких данных не хватало;

• как улучшить взаимодействие;

• какие действия стоит изменить.

В Agile такие обсуждения часто проводятся в формате ретроспективы.

17. Agile и Scrum

Agile и Scrum не являются полными синонимами.

Agile представляет собой набор ценностей и принципов.

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

В официальном Scrum Guide используются три зоны ответственности: Product Owner, Scrum Master и Developers. Под словом Developers понимаются все участники, которые создают полезный инкремент продукта. В эту группу могут входить программисты, дизайнеры, аналитики и тестировщики. Отдельной формальной роли project manager в Scrum Guide нет, хотя в реальных организациях менеджеры проектов могут продолжать работать, а их обязанности распределяются в зависимости от структуры компании. citeturn842259search4turn842259search44

Основные элементы Scrum

Спринт

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

Бэклог

Упорядоченный список задач, функций, улучшений и проблем продукта.

Планирование спринта

Встреча, на которой команда определяет цель ближайшего периода и выбирает задачи.

Ежедневная встреча

Короткая синхронизация команды по текущей работе.

Обзор результата

Команда показывает, что было создано.

Ретроспектива

Команда обсуждает, как улучшить процесс работы.

Scrum не должен превращаться в набор формальных встреч. Каждая встреча должна помогать команде принимать решения и двигаться вперед.

18. Что Agile означает для UI/UX-дизайнера

Дизайн создается постепенно

Дизайнер не обязан сразу проектировать весь продукт.

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

Дизайнер работает вместе с командой

Дизайнер взаимодействует:

• с продакт-менеджером по вопросам ценности;

• с маркетологом по вопросам аудитории;

• с аналитиком по требованиям;

• с разработчиками по реализации;

• с тестировщиком по состояниям и ошибкам;

• с заказчиком по ограничениям и ожиданиям;

• с пользователями по удобству продукта.

Макеты могут изменяться

Изменение макета не всегда означает, что дизайнер плохо выполнил работу.

Иногда макет меняется потому, что команда получила новые данные.

Важно понимать причину изменения и фиксировать решение.

Необходимо проектировать заранее

Разработчикам нужны подготовленные макеты до начала реализации функции.

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

Однако нельзя проектировать слишком далеко вперед. Чем больше времени проходит между созданием дизайна и разработкой, тем выше вероятность изменения требований.

Дизайнер участвует в планировании

Перед началом работы дизайнер должен сообщить:

• какие исследования необходимы;

• какие экраны нужно создать;

• какие состояния нужно предусмотреть;

• какие зависимости существуют;

• сколько времени требуется;

• что пока невозможно оценить;

• какие решения требуют обсуждения.

19. Подготовка проекта с помощью ChatGPT

ChatGPT может ускорить работу с информацией, но не заменяет заказчика, исследователя, дизайнера или продуктовую команду.

ИИ полезен для:

• структурирования материалов;

• подготовки вопросов;

• поиска противоречий;

• создания черновиков;

• классификации требований;

• генерации вариантов;

• оформления заметок;

• подготовки документации;

• выявления рисков;

• создания первоначального плана.

Но ответы ChatGPT необходимо проверять.

Модель может:

• неправильно понять контекст;

• предложить несуществующие данные;

• сделать слишком общие выводы;

• смешать факты и предположения;

• упустить ограничения;

• предложить решение, которое не подходит бизнесу.

20. Создание рабочего пространства проекта в ChatGPT

Для длительной работы можно создать отдельный проект в ChatGPT.

В проект можно добавить:

• описание продукта;

• бриф;

• исследования;

• заметки со встреч;

• требования;

• информацию о конкурентах;

• тексты;

• инструкции по стилю работы.

Проекты ChatGPT позволяют хранить связанные чаты, справочные файлы и инструкции в одном рабочем пространстве. Это помогает сохранять контекст при длительной работе над исследованием, планированием и документацией. citeturn842259search8

Перед загрузкой материалов необходимо проверить, разрешено ли передавать их внешнему ИИ-сервису.

Не следует без согласования загружать:

• персональные данные клиентов;

• пароли;

• платежные данные;

• медицинскую информацию;

• коммерческие тайны;

• закрытую финансовую отчетность;

• конфиденциальные договоры;

• внутренние ключи доступа.

При необходимости данные следует обезличить.

21. Как составлять запросы для ChatGPT

Хороший запрос должен содержать контекст и четкую задачу.

Полезная структура:

Роль

Кем должен выступать ChatGPT?

Например:

Выступи в роли бизнес-аналитика и UX-исследователя.

Контекст

Что происходит?

Мы готовим редизайн сервиса онлайн-записи в клинику. Основные пользователи — пациенты 25–60 лет.

Цель

Какой результат нужен?

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

Исходные данные

Какая информация уже известна?

Сейчас запись происходит по телефону. Компания хочет перевести часть записей на сайт.

Ограничения

Что необходимо учитывать?

Не предлагай готовые интерфейсные решения. Сосредоточься на бизнесе, пользователях, процессах и ограничениях.

Формат ответа

Как должен выглядеть результат?

Раздели вопросы на категории и объясни, зачем задается каждый вопрос.

Критерии качества

Как проверить результат?

Вопросы не должны повторяться и не должны подталкивать заказчика к определенному ответу.

OpenAI рекомендует формулировать запросы ясно и конкретно, предоставлять достаточный контекст и улучшать запрос итеративно после анализа первого результата. citeturn842259search0turn842259search5

22. Сценарии использования ChatGPT при подготовке проекта

Сценарий 1. Анализ брифа

Пример запроса:

Выступи в роли бизнес-аналитика и senior UX-дизайнера.

Ниже находится бриф проекта. Проанализируй его и раздели информацию на категории:

1. Подтвержденные факты.

2. Предположения заказчика.

3. Цели бизнеса.

4. Проблемы пользователей.

5. Функциональные требования.

6. Ограничения.

7. Противоречия.

8. Информация, которой не хватает.

Не придумывай отсутствующие данные. Для каждого пробела сформулируй уточняющий вопрос.

Текст брифа:
[вставить текст]

Такой запрос помогает быстро увидеть, какие данные отсутствуют.

Сценарий 2. Подготовка вопросов заказчику

Мы готовим проект образовательной платформы для преподавателей.

Известно, что преподаватели смогут создавать занятия, тесты и просматривать результаты учеников.

Подготовь вопросы для интервью с заказчиком. Раздели их на категории:

• бизнес-модель;

• аудитория;

• пользовательские сценарии;

• функциональность;

• аналитика;

• контент;

• технические ограничения;

• сроки;

• критерии успеха.

Не задавай вопросы, ответы на которые уже содержатся в описании. Для каждого вопроса кратко укажи, на какое проектное решение повлияет ответ.

Сценарий 3. Подготовка к первой встрече

Подготовь сценарий 60-минутной установочной встречи по UI/UX-проекту.

Участники: заказчик, проджект-менеджер, маркетолог, дизайнер и технический руководитель.

Цель встречи: согласовать проблему, цели, аудиторию, границы проекта, роли и дальнейшие действия.

Представь результат в виде таблицы:

• время;

• тема;

• ведущий;

• вопросы;

• ожидаемый результат.

Сценарий 4. Формирование команды

Проанализируй описание проекта и предложи минимальный состав команды.

Для каждой роли укажи:

• зачем она нужна;

• за какие задачи отвечает;

• на каком этапе подключается;

• можно ли объединить ее с другой ролью;

• какие риски возникнут, если этой роли не будет.

Не увеличивай команду без необходимости. Отдельно выдели обязательные и дополнительные роли.

Описание проекта:
[вставить описание]

Сценарий 5. Матрица ответственности

На основе описания проекта создай матрицу ответственности.

Участники: заказчик, проджект-менеджер, маркетолог, UI/UX-дизайнер, frontend-разработчик, backend-разработчик и тестировщик.

Задачи: сбор требований, исследование аудитории, прототипирование, согласование дизайна, разработка, тестирование и запуск.

Для каждой задачи укажи:

• кто выполняет работу;

• кто принимает финальное решение;

• кого консультируют;

• кого информируют.

Отметь задачи, для которых ответственность определена неоднозначно.

Сценарий 6. Анализ рисков

Выступи в роли проджект-менеджера и UI/UX-дизайнера.

Проанализируй проект и составь реестр рисков.

Для каждого риска укажи:

• описание;

• причину;

• вероятность;

• влияние;

• способ предотвращения;

• действия при наступлении;

• ответственного.

Отдельно рассмотрите пользовательские, организационные, технические, юридические и контентные риски.

Сценарий 7. Преобразование заметок в документ

После встречи часто остается неструктурированный текст.

Можно использовать запрос:

Ниже находятся заметки со встречи. Преобразуй их в протокол.

Создай разделы:

1. Контекст проекта.

2. Принятые решения.

3. Открытые вопросы.

4. Обнаруженные риски.

5. Задачи.

6. Ответственные.

7. Сроки.

Не добавляй решений, которых нет в заметках. Если ответственный или срок не указан, напиши «не определено».

Заметки:
[вставить заметки]

Сценарий 8. Подготовка пользовательских историй

Пользовательская история описывает функцию с позиции пользователя.

Простая структура:

Как [роль пользователя], я хочу [действие], чтобы [получить результат].

Пример:

Как преподаватель, я хочу видеть результаты учеников, чтобы понимать, какие темы необходимо объяснить повторно.

Запрос для ChatGPT:

На основе описания продукта создай черновик пользовательских историй.

Не придумывай функции, которых нет в требованиях.

Для каждой истории укажи:

• роль;

• потребность;

• ожидаемую пользу;

• условия приемки;

• вопросы, которые необходимо уточнить.

Сгруппируй истории по пользовательским сценариям.

23. Как проверять результаты работы ChatGPT

После получения ответа необходимо провести проверку.

Проверка на факты

Какие утверждения основаны на предоставленных данных?

Какие выводы ChatGPT сделал самостоятельно?

Проверка на предположения

Не выдал ли ИИ предположение за подтвержденный факт?

Проверка на полноту

Учтены ли:

• цели;

• пользователи;

• ограничения;

• технологии;

• контент;

• сроки;

• аналитика;

• согласование;

• риски?

Проверка на противоречия

Не противоречат ли разные части ответа друг другу?

Проверка на применимость

Можно ли использовать результат в реальном проекте или он остается слишком общим?

Проверка командой

Следует показать результат специалисту, который отвечает за соответствующую область.

Например:

• технические выводы проверяет разработчик;

• маркетинговые выводы проверяет маркетолог;

• требования проверяет аналитик;

• план проекта проверяет менеджер;

• пользовательские выводы проверяются исследованием.

Главное правило:

ChatGPT помогает подготовить решение, но не подтверждает его правильность.

24. Пример подготовки проекта

Рассмотрим условный проект.

Исходный запрос

Онлайн-школа хочет создать личный кабинет ученика.

Заказчик говорит:

Нам нужен современный личный кабинет с расписанием, уроками и домашними заданиями.

Такой информации недостаточно для начала дизайна.

Что необходимо выяснить

О пользователях

• Какого возраста ученики?

• Они занимаются самостоятельно или вместе с родителями?

• С каких устройств заходят?

• Насколько хорошо владеют цифровыми продуктами?

• Есть ли ученики с особыми потребностями?

О сценариях

• Как ученик входит в кабинет?

• Как узнает о следующем занятии?

• Как подключается к уроку?

• Где получает материалы?

• Как отправляет домашнее задание?

• Как получает обратную связь?

• Что происходит, если занятие перенесено?

О бизнесе

• Зачем школе нужен личный кабинет?

• Необходимо ли снизить нагрузку на администраторов?

• Планируется ли продажа дополнительных курсов?

• Нужно ли повысить посещаемость занятий?

• Какие показатели будут измеряться?

О технической части

• Где сейчас хранится расписание?

• Есть ли CRM?

• Используется ли видеоплатформа?

• Есть ли база учеников?

• Нужна ли интеграция с оплатой?

• Кто будет разрабатывать backend?

О ролях

• Ученик;

• родитель;

• преподаватель;

• администратор;

• куратор;

• руководитель школы.

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

Например, ученики пропускают занятия, потому что уведомления отправляются вручную и часто приходят слишком поздно.

Тогда ключевой задачей проекта становится не просто создание расписания, а надежная система уведомлений и подтверждения участия.

25. Результаты этапа подготовки

К завершению подготовки у команды должны появиться:

1. Понятное описание продукта.

2. Сформулированная проблема.

3. Бизнес-цели.

4. Описание пользователей.

5. Основные пользовательские сценарии.

6. Список обязательных функций.

7. Ограничения.

8. Критерии успеха.

9. Состав команды.

10. Распределение ответственности.

11. План работ.

12. Список рисков.

13. Список открытых вопросов.

14. Договоренность о процессе согласования.

15. Понимание следующего шага.

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

26. Типичные ошибки начинающего дизайнера

Ошибка 1. Сразу открывать Figma

Дизайнер начинает рисовать экраны, не понимая задачи.

В результате макеты приходится переделывать.

Ошибка 2. Принимать формулировку заказчика за доказанный факт

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

Его мнение необходимо учитывать, но гипотезы следует проверять.

Ошибка 3. Не задавать уточняющие вопросы

Страх показаться неопытным приводит к тому, что дизайнер принимает решения на основе догадок.

Профессионализм заключается не в отсутствии вопросов, а в умении задавать правильные вопросы.

Ошибка 4. Не учитывать разработку

Дизайнер создает сложные решения без обсуждения с технической командой.

Ошибка 5. Проектировать только идеальный сценарий

Дизайнер показывает, что происходит при успешном выполнении действия, но забывает про:

• ошибки;

• загрузку;

• отсутствие данных;

• ограничения доступа;

• длинный контент;

• нестабильное соединение.

Ошибка 6. Не фиксировать решения

После встречи участники по-разному помнят договоренности.

Все значимые решения необходимо записывать.

Ошибка 7. Использовать ChatGPT как источник истины

ИИ создает убедительно звучащий текст, но это не означает, что выводы подтверждены реальными данными.

27. Чек-лист подготовки UI/UX-проекта

Перед началом проектирования проверьте:

Бизнес

• Понятна цель проекта.

• Понятна бизнес-модель.

• Определены критерии успеха.

• Известны основные ограничения.

Пользователи

• Определены группы пользователей.

• Понятны их основные задачи.

• Известен контекст использования продукта.

• Определено, какие данные необходимо проверить исследованием.

Функциональность

• Сформирован список функций.

• Определены приоритеты.

• Выделена минимальная версия продукта.

• Описаны основные сценарии.

Команда

• Определены участники.

• Назначены ответственные.

• Известно, кто принимает решения.

• Согласован формат коммуникации.

Технологии

• Определены платформы.

• Известны технические ограничения.

• Дизайнер взаимодействует с разработчиками.

• Определены необходимые интеграции.

Процесс

• Согласованы этапы.

• Определены сроки.

• Назначены контрольные точки.

• Определен порядок согласования.

• Создано единое место хранения материалов.

ИИ

• Создан отдельный контекст проекта.

• В запросах указаны цели и ограничения.

• Факты отделены от предположений.

• Результаты ChatGPT проверены специалистами.

• Конфиденциальные данные не передаются без разрешения.

Практическое задание

Задача

Представьте, что заказчик хочет создать мобильное приложение для записи клиентов в салон красоты.

Известно только следующее:

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

Выполните следующие действия

1. Сформулируйте возможную проблему проекта.

2. Запишите пять бизнес-вопросов заказчику.

3. Запишите пять вопросов о пользователях.

4. Запишите пять вопросов о функциональности.

5. Определите возможные роли пользователей.

6. Предложите минимальный состав команды.

7. Распределите ответственность между участниками.

8. Назовите пять возможных рисков.

9. Сформулируйте критерии успешности проекта.

10. Подготовьте один запрос для ChatGPT, который поможет проанализировать собранные данные.

Домашнее задание

Выберите один цифровой продукт:

• приложение доставки;

• образовательную платформу;

• интернет-магазин;

• сервис записи к врачу;

• приложение для управления финансами;

• внутреннюю CRM-систему;

• сервис бронирования мероприятий.

Подготовьте документ предпроектного анализа.

Документ должен содержать:

1. Краткое описание продукта.

2. Возможную бизнес-проблему.

3. Цели проекта.

4. Основные группы пользователей.

5. Основные пользовательские сценарии.

6. Список вопросов заказчику.

7. Список обязательных функций.

8. Возможные ограничения.

9. Предлагаемый состав команды.

10. Ответственность каждого участника.

11. Возможные риски.

12. Критерии успеха.

13. Описание того, как ChatGPT использовался при подготовке.

14. Перечень выводов ChatGPT, которые необходимо проверить.

Итоги лекции

UI/UX-дизайн начинается с понимания проблемы, а не с создания интерфейса.

Перед началом работы необходимо собрать данные о бизнесе, продукте, пользователях, функциях, технологиях, сроках и ограничениях.

Дизайнер является частью команды. Он работает вместе с менеджерами, маркетологами, разработчиками, тестировщиками и заказчиком.

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

ChatGPT может ускорить подготовку проекта: проанализировать бриф, структурировать заметки, подготовить вопросы, определить пробелы и сформировать черновую документацию.

При этом ответственность за проверку информации и принятие решений остается у человека.

Главный результат подготовки к проекту состоит не в количестве созданных документов. Результат достигнут тогда, когда команда одинаково понимает:

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