Взаимодействие продуктового дизайнера с командой в Т2
На примере команды продуктового web-дизайна t2.digital рассказываем: с кем на ежедневной основе взаимодействует продуктовый дизайнер, и как сделать это сотрудничество максимально эффективным.
Всем привет! Меня зовут Галя, я дизайнер команды продуктового web-дизайна t2.digital. Сегодня хочу поделиться своим опытом взаимодействия с продуктовой командой T2, которая занимается развитием и поддержкой определенного продукта (например, подписка MiXX), и дать практические советы, как сделать его более эффективным и комфортным для всех участников.
Эта статья будет интересна начинающим специалистам в сфере UX/UI и продуктового дизайна и всем, кто планирует или хочет перейти в продуктовую команду. Понимание процессов позволяет быстрее адаптироваться и расти в профессии, видеть полную картину работы над продуктом.
Дисклеймер: в статье рассматриваются роли в продуктовой команде исключительно с позиции продуктового дизайнера. Я не раскрываю все особенности каждой роли, а фокусируюсь на аспектах, важных для продуктового дизайнера.
Кто есть кто?
В начале пути продуктовый дизайн может показаться лабиринтом из разных специалистов и процессов. Но не пугайтесь – каждый из них играет важную роль в создании продукта. Давайте разберемся, с кем и на каких этапах взаимодействует продуктовый дизайнер в Т2. Вместе мы разложим все по полочкам!
Продакт
Что делает: он же менеджер продукта, владелец продукта или Product Owner, определяет видение продукта, управляет его бэклогом (backlog – список задач) и принимает решения по его развитию. Выступает как «связующее звено» между стейкхолдерами (stakeholders – заказчики), клиентами и командой разработки, преобразуя бизнес-требования в детальное техническое задание.
Когда взаимодействуем: с ним работаем бок о бок на всех этапах развития продукта. Например, на начальном этапе после изучения технического задания часто требуется дополнительное обсуждение требований. После всех внутренних согласований совместно презентуем наши макеты заказчикам и защищаем дизайн-решения.
Для эффективной коммуникации я предпочитаю организовывать личные встречи с продактом, чтобы оперативно обсудить все возникающие вопросы, сразу же проработать возможные правки, аргументированно защитить дизайнерские решения и достичь полного взаимопонимания по проекту. Такой формат общения значительно продуктивнее, чем переписка в мессенджерах или обсуждение в чате Figma.
Системный аналитик
Что делает: создает спецификацию требований для разрабатываемого продукта. Его задача – сделать продукт соответствующим техническим возможностям системы и бизнес-целям компании.
Когда взаимодействуем:
- для уточнения по вопросам о работе системы, если добавляем фичу в уже существующий сценарий;
- для уточнения корнер-кейсов (corner-case – редкая или нестандартная ситуация в работе продукта);
- на этапе аналитики (когда этап дизайна уже завершен), если в макетах что-то не учтено или отрисовано не совсем так, как это работает на самом деле.
В зависимости от задачи макеты могут быть очень объемными по количеству сценариев и корнер-кейсов. Поэтому важно своевременно передать системному аналитику актуальные макеты и все детали дизайна, поскольку они становятся частью спецификации. Пропуск какой-либо информации может привести к тому, что соответствующие элементы не будут реализованы в конечном продукте.
UX-редактор
Что делает: UX-редактор превращает технические и сложные термины в лаконичные и понятные пользователю тексты и отвечает за соблюдение tone of voice компании (уникальный стиль общения бренда с аудиторией) в интерфейсах.
Когда взаимодействуем:
- с самых ранних этапов проектирования макетов до момента согласования дизайна и текстов стейкхолдерами;
- при проведении дизайн-ревью;
- при проведении UX-исследований.
В начале при проектировании мы прикидываем свои варианты текстов для общего контекста, но без UX-редактуры не обходится ни одна новая фича или продукт.
Разработчик (фронт-энд)
Что делает: переводит дизайнерские решения в реальный код, именно разработчики отвечают за видимую часть веб-сайтов и приложений, с которой взаимодействует пользователь.
Когда взаимодействуем:
- на этапе активной разработки, когда у разработчиков могут возникнуть вопросы по макетам;
- на этапе дизайн-ревью при обнаружении расхождений с исходными макетами.
Тестировщик или QA-инженер
Что делает: Простым языком ищет баги/ошибки во всех возможных и невозможных сценариях продуктах, чтобы продукт соответствовал техническим и бизнес-требованиям.
Когда взаимодействуем:
- при запуске новых продуктов (например, во время ребрендинга T2);
- на этапе дизайн-ревью.
Аналитик данных или веб-аналитик
Что делает: Проверяет продуктовые гипотезы, проводит A/B-тестирования, собирает и анализирует данные, которые помогают изучить поведение пользователей на сайте.
Когда взаимодействуем: если нам нужно изучить метрики, которые не отражены в существующих дашбордах, мы можем поставить задачу на сбор этих данных.
Полученные данные от веб-аналитиков помогают нам улучшать наши продукты и интерфейсы, а также защищать наши дизайн-решения на реальных цифрах при показе и обсуждении макетов с продактом и стеикхолдером.
UX-исследователь
Что делает: Изучает взаимодействие пользователей с продуктом, а также определяет потребности, драйверы и стопперы для улучшения пользовательского опыта.
Когда взаимодействуем:
- при сомнениях относительно конкретного дизайн-решения;
- в случае наличия двух вариантов дизайн-решения;
- при наличии гипотез, которые хотели бы проверить.
Для этого мы совместно с продактами заполняем соответствующий бриф, где прописываем, что, как и зачем мы хотим происследовать. Потом на основе полученных результатов принимаем решение. При этом никто не запрещает дизайнеру самому провести исследование или непосредственно поучаствовать в нем.
От теории к практике!
Теперь, когда определили роли в продуктовой команде, пора обсудить, что мы внедрили в процессы, чтобы улучшить взаимодействие с макетами.
- Проектируем Screen-flow – это высокодетализированные макеты, которые показывают последовательность шагов пользовательского пути, а также всевозможные действия, переходы и корнер-кейсы. Это наиболее эффективный подход для наглядного представления и согласования того, как будет работать проектируемый продукт/сервис для всей команды разработки, заказчиков и других заинтересованных лиц.
- Следуем итерационному подходу и ведем чейнджлог (changelog – документ, где подробно описаны внесенные изменения в новой итерации относительно предыдущей). В Figma-файле задачи создаем отдельную страницу для каждой итерации, где храним доработанные макеты с учетом полученных комментариев от аналитиков, заказчиков или инсайтов после проведения UX-исследования. Сохранение прошлых итераций позволяет нам при необходимости быстро вернуться к обсуждению предыдущих вариантов реализации той или иной фичи. Если есть итерации, значит, нужен чейнджлог, его мы внедрили также для улучшения процесса разработки. Были также случаи, когда внесенные изменения в макеты не были выпущены в прод из-за плохо выстроенной коммуникации внутри команды. Поэтому сейчас мы прописываем не только внесенные изменения в чейнджлоге, но и дату внесения этих правок, а также ссылки на соответствующие обновленные макеты, и уведомляем об этом группу разработки в чате стрима.
- Дополнительно оставляем комментарии на стикерах рядом с соответствующим макетом. Комментарии могут быть как для аналитиков, разработчиков, UX-редактора или смежных команд.
- Используем информационно-навигационные блоки, где отображаем название кейса, статусы по копирайту, графике и готовности макетов к аналитике.
- У каждой задачи свой Figma-файл с обложкой, где мы прописываем, кто ответственный дизайнер по данной задаче, чтобы любой из команды знал, к кому обратиться с вопросами по макету. Не поверите, но это тоже ускоряет процесс коммуникации по задаче! Примеры прикольных обложек можно посмотреть в нашем канале T2.Digital – подписывайтесь, там еще много всего интересного и полезного!
- Для дизайн-ревью используем стандартизированные таблицы (шаблоны), где фиксируем замечания, их критичность и статус «исправлено/не исправлено». Для наглядности несоответствий добавляем рядом макеты и скрины с прода.
Но это еще не все!
Успех любого проекта зависит от того, насколько хорошо команда умеет общаться друг с другом. Поэтому крайне важно развивать свои soft skills – личные качества и универсальные навыки, которые помогают эффективно взаимодействовать с окружающими людьми.
Могу выделить несколько навыков, на которые стоит обратить внимание в начале карьеры:
- грамотная коммуникация, а именно навык четко и структурировано излагать свои мысли;
- умение получать и давать конструктивную и экологичную обратную связь;
- конфликт-менеджмент – навык урегулирования разногласий в команде.
Заключительные мысли
Описанный процесс в T2 – это лишь один из возможных вариантов организации работы. В зависимости от продукта или компании роли и зоны ответственности могут различаться. Однако главное остается неизменным: успешная разработка продукта возможна только при эффективном взаимодействии всех участников.
А как вы выстраиваете рабочие процессы? Поделитесь интересными кейсами, нестандартными решениями или полезными инструментами – будем рады узнать о вашем опыте!