Составила небольшую памятку по взаимоотношениям менеджер-дизайнер. Не имеет значения, работаешь в продукте с PM или в агентстве в внешним заказчиком. Не утонуть в итерациях, не разругаться и сделать рабочий продукт – реально. Коллеги-дизайнеры, нежно и упорно доносите эту информацию до менеджеров. Применимо для любых направлений дизайна.
Профессиональный дизайнер – партнёр в проекте, а не исполнитель. Задача продуктового дизайнера – сделать продукт, удовлетворяющий потребности бизнеса и пользователя. Избежать лишних итераций и недопониманий помогает согласованное «на берегу» ТЗ – техническое задание. Синхронизируйтесь между участниками проекта в понимании базовых вопросов: что мы хотим достичь, для кого, зачем оно пользователю, зачем оно нам, как поймём, что достигли.
👉Принимайте задачу в письменном виде. Во-первых, при письме получаются точные формулировки. Во-вторых у команды будет один источник правды. Проговорите ТЗ устно. Вы с менеджером должны одинаково интерпретировать все пункты. Если по ходу проекта возникают новые вводные, менеджер должен доносить их до команды в тот же момент и вносить правки в ТЗ.
👉 Дизайнер может не принять задачу в дизайн, если информации на входе не достаточно или она противоречивая. То же самое касается правок.
👉 Если итераций правок больше двух – обсудите ТЗ с менеджером. Вероятно вы по-разному поняли какую-то его часть, чего-то не хватает или что-то оказалось лишним. Или задача на самом деле другая, такое тоже бывает.
Чек-лист для команды
Ответы появляются в процессе работы и прорабатываются разными членами команды. К началу работы над макетами они должны быть согласованы между участниками процесса.
- Какую проблему решаем?
Основной вопрос для любых изменений и нововведений. Альтернативные формулировки: что сейчас не так? Ради чего мы это делаем?
Зачем это дизайнеру 👉Решение, которое предлагает заказчик, может не решать проблему. Не понимая сути проблемы, невозможно предложить удачное решение. Так что сначала синхронизируем понимание проблемы. - Для кого решаем проблему?
Кто наш пользователь? Какие специфики у этого сегмента аудитории?
Зачем это дизайнеру 👉Аудитории отличается по портретам и задачам, которые они пытаются решить. Одна и та же проблема имеет разные решения для разных аудиторий. - Какую потребность целевой аудитории закрываем?
Какие у ЦА pains/gains, которые может решить наш продукт? В каком она находится контексте и что чувствует?
Зачем это дизайнеру 👉Любой дизайн должен удовлетворять потребности двух сторон: бизнеса и пользователя. Чтобы удовлетворить пользователя, необходимо понимать его потребности, задачи и боли в конкретном контексте. - Какие у ЦА барьеры?
Какие привычки/суждения пользователя могут помешать достижению цели.
Зачем это дизайнеру 👉Дополняем знание о пользователе ограничениями. На что точно нельзя рассчитывать и как обходить барьеры. - Цель и метрики
Что должно стать лучше и на сколько? Выгода для бизнеса в цифрах.
Зачем это дизайнеру 👉Сложно достичь цель, если не понимаешь критерии успеха. Это как писать экзамен, не зная, что именно будет оцениваться: ответы, скорость, почерк, количество символов или всё вместе. - Какое целевое действие ожидаем?
Что наша ЦА должна сделать увидев/прочитав/прослушав?
Зачем это дизайнеру 👉Какое действие пользователя приведёт к улучшению метрик из пункта №5? - Ключевое, что пользователь должен понять/запомнить
Какое знание должно остаться в голове у пользователя?
Зачем это дизайнеру 👉Какое сообщение он будет транслировать окружающим? Идея, пронизывающая дизайн. - Ограничения по содержанию
Что обязательно/желательно/нежелательно/нельзя использовать?
Зачем это дизайнеру 👉Чтобы учесть обязательные элементы брендинга и всевозможные табу. - Сроки
Когда нужно выкатывать, когда отдавать в разработку?
Зачем это дизайнеру 👉От сроков зависит возможный объём работы и наоборот. Договаривайтесь заранее. - Технические ограничения
Привлеките к обсуждению задачи разработчика.
Зачем это дизайнеру 👉Технические ограничения есть всегда. Учитывайте их, если они известны сразу или подключайте разработчика на этапе идеи. - Где будет применяться?
Web/печать/рассылка/YouTube/…
Зачем это дизайнеру 👉Это про контекст. Позволяет «примерить» ваш дизайн: как решение смотрится в ленте Инстаграма или какая информация попадает в первый экран. - Гипотезы
Предложения решения проблемы. Не обязательно реализуются, если находится более эффективный способ достижения цели.
Зачем это дизайнеру 👉Возможно, заказчик уже нашёл решение проблемы. - Референсы
Удачный пример решения аналогичной проблемы, обзор конкурентов.
Зачем это дизайнеру 👉У каждого своё субъективное «красиво», «правильно», «прикольно» и т.д. Лучше узнать это заранее. - Финальные тексты
К моменту начала дизайна они должны быть вычитаны редактором.
Зачем это дизайнеру 👉Можно ли сделать лендинг с «рыбами» текста? – Можно. А потом переделать, т.к. вёрстка не будет поддерживать содержание. Так что утром тексты, вечером – вёрстка.
Оценка решения и обратная связь
- Дизайн-решение оценивается в соответствии с поставленным ТЗ, дизайн-стандартам компании (гайды/брендбук/библиотеки/...), UX и общим принципам дизайна (композиция/палитра/...).
- Заказчик тоже хочет сделать проект «хорошо». Если предложенное решение не подходит – выясните, почему. Принимайте только конструктивную критику. Без подробного фидбека переделать невозможно, т.к. причина несоответствия неясна.
- Соответствие дизайн-стандартам и визуальная составляющая оцениваются дизайнером-наставником или дизайн-директором.
Обе стороны заинтересованы сделать проект хорошо. Обычно споров и «переобувания на ходу» можно избежать, если синхронизироваться по вопросам чек-листа перед работой над макетами. Иногда в итерациях рождается истина, но лучше оставить это в качестве исключения из правила.