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

Введение

Всем привет! Меня зовут Александр Остапец, дизайнер продуктов в ГК Юзтех. 

В продуктовом дизайне — 4,5 года. За это время разработал дизайн продуктов в сфере B2B, B2C и Enterprise. В статье я поделюсь своим опытом взаимодействия продуктового дизайнера с аналитиком, разработчиком, тестировщиком и продактом, и дам рекомендации по улучшению процессов. Статья будет полезна дизайнерам продуктов, и тем, кто ставит задачи продуктовым дизайнерам.

Что нужно дизайнеру для выполнения задачи

Мне часто ставили задачи с минимумом информации — спроектировать страницу или добавить функцию. Могут дополнить, как видят путь пользователя в юзерфлоу, юзерстори или объяснить на словах. Также могут прийти с готовым решением: «Мы уже все придумали, нарисуй вот так». Можно сделать как просят и все останутся довольны. Но дизайнеру тоже важно понимать, что он делает, для кого и зачем. 

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

• Кто наша аудитория? На какие сегменты пользователя влияем? Тут может понадобиться исследование, если не расписывались сегменты пользователей, или можно обойтись портретами аудитории;
• Какую задачу пользователя решаем? Какая его конечная цель? Как он решает задачу сейчас?
• Какие еще варианты решения рассматривались? Почему отказались от них?
• Какую задачу бизнеса решаем? Почему ее важно решать?
• Как измерим успех? Какими метриками? Какой показатель у метрик сейчас?
• Какие есть требования или пожелания от пользователей? Требования могут быть в виде отзывов, обратной связи или взяты из глубинных исследований лучше преобразовать их в джобстори или юзерстори.
• Какие есть ограничения от разработки, юристов, безопасников или бизнеса?
• Какой срок решения задачи? 

Роли в команде и как дизайнер взаимодействует с каждым из них

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

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

Аналитики 

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

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

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

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

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

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

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

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

Рассмотрим на примере

Нам надо спроектировать страницу авторизации / регистрации. 

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

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

У системного аналитика мы узнаем, как работает авторизация изнутри, какие способы мы можем дать пользователю. Например, заходить по логину‑паролю или по номеру. Можем ли мы прикрутить авторизацию через сторонние сервисы (Яндекс, Гугл, ВК и тд.). 

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

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

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

Коммуникация дизайна и разработки не простая история, тут все довольно индивидуально. Существует много видов разработчиков, но суть коммуникации дизайнера и разработки всегда одна: мы передаем разработчикам свои макеты, и они по ним верстают проект. Чем меньше у них окажется вопросов, тем качественнее мы проработали макеты. Однако как учесть все технические ограничения, о которых мы не знаем и не нашли ответов у аналитиков? Нужно спросить у того кто знает — разработчика. 

Дизайнеру важно понять как работает продукт внутри: какие базы данных участвуют, какие запросы отправляются и куда. Это даст понимание технических ограничений продукта, и избавит от проектирования лишних экранов, которые невозможно реализовать технически или они отнимут много ресурсов, увеличат стоимость и сроки разработки. Также важно понимать, с какой скоростью приходит ответ от баз данных. Это даст понимание на каких этапах показать загрузку элемента или всего экрана. Еще важно учесть какие ответы могут не прийти от базы данных. Это нужно для проработки ошибок, чтобы правильно указать пользователю на причину и как ее решить. Например, страница 404 с решением — кнопкой «Перезагрузить» (надо обсудить с разработчиками, решит ли это проблему) или кнопкой «Вернуться на главную». Я описал базовые примеры, но нюансов, как правило, намного больше. 

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

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

Команде важно добиться общего понимания. Нам не нужно углубляться в код или говорить на языке разработки. Можно добиться понимания разговором на простом языке: использовать примеры и сравнения. Лучше всего для этого использовать блок‑схемы, строить userflow путей пользователя, указывать на них в какие базы данных уходят запросы и куда они возвращаются. Важно визуализировать процесс, чтобы у всех сложилась одна картинка в голове и полное понимание того, что мы делаем для кого и зачем.

Userflow

Userflow бывает трех видов. Можно использовать один из них или все поочередно. 

1. Task flow

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

2. Warframe flow

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

Screenflow

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

Продакт (менеджер продукта, владелец продукта, Product Owner)

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

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

Владелец продукта является основным стейкхолдером для всей команды, поэтому к встречам с ним надо всегда готовиться. Нужно составлять список вопросов и фиксировать ответы, защищать свои решения, приводя в аргументы количественные и качественные данные — результаты тестов или исследования, метрики, результаты опросников. Каждое решение должно быть аргументированно и иметь смысл и ценность. Нельзя сказать: «Я художник, я так вижу». Нужно оперировать цифрами и приводить ясные аргументы. Например: «Исходя из опроса такого‑то количества пользователей, добавление такого‑то функционала повысит лояльность пользователей (NPS) на столько‑то пунктов.»; «Элементы в интерфейсе расположены так, потому что это привычный паттерн поведения нашей аудитории, мы доказали это в юзабилити тесте, у которого такие‑то результаты»; «Пользователи не пользуются этим функционалом, потому что не замечают его. Мы поняли это посмотрев на метрики, вебвизор и проведя опрос. Вот результаты. Разместив функционал вот тут, пользователи его заметят и начнут использовать, мы подтвердили это в юзабилити тестах. Вот результаты.»

Будет проще, если составить план и презентацию по проделанной работе. Так можно предусмотреть и отработать возражения. Если не подготовиться, то придется импровизировать. В импровизации появляется недосказанность в аргументах и это может привести к переработке функционала. 

Тестировщики или QA-инженеры

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

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

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

Резюме

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

Главное помнить, не бывает глупых вопросов — глупо их не задавать. «Если не спросить, никогда не узнаешь. Если знаешь, нужно лишь спросить» — Елена Когтевран. Задавать и обсуждать надо даже те вопросы, в которых уверен на 99,9%. В этом 0,1% могут крыться нюансы разработки, цели бизнеса и многое другое, что в конечном счете может повлиять на продукт. А если уверен на все 100%, то нужно проверить, совпадает ли твое видение с остальными членами команды, и спросить еще раз. 

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