Учи.ру
Marina Stepanova
2373

Чек-лист для дизайнера и команды

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

В закладки

Профессиональный дизайнер – партнёр в проекте, а не исполнитель. Задача продуктового дизайнера – сделать продукт, удовлетворяющий потребности бизнеса и пользователя. Избежать лишних итераций и недопониманий помогает согласованное «на берегу» ТЗ – техническое задание. Синхронизируйтесь между участниками проекта в понимании базовых вопросов: что мы хотим достичь, для кого, зачем оно пользователю, зачем оно нам, как поймём, что достигли.

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

👉 Дизайнер может не принять задачу в дизайн, если информации на входе не достаточно или она противоречивая. То же самое касается правок.

👉 Если итераций правок больше двух – обсудите ТЗ с менеджером. Вероятно вы по-разному поняли какую-то его часть, чего-то не хватает или что-то оказалось лишним. Или задача на самом деле другая, такое тоже бывает.

Чек-лист для команды

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

  1. Какую проблему решаем?
    Основной вопрос для любых изменений и нововведений. Альтернативные формулировки: что сейчас не так? Ради чего мы это делаем?
    Зачем это дизайнеру 👉Решение, которое предлагает заказчик, может не решать проблему. Не понимая сути проблемы, невозможно предложить удачное решение. Так что сначала синхронизируем понимание проблемы.
  2. Для кого решаем проблему?
    Кто наш пользователь? Какие специфики у этого сегмента аудитории?
    Зачем это дизайнеру 👉Аудитории отличается по портретам и задачам, которые они пытаются решить. Одна и та же проблема имеет разные решения для разных аудиторий.
  3. Какую потребность целевой аудитории закрываем?
    Какие у ЦА pains/gains, которые может решить наш продукт? В каком она находится контексте и что чувствует?
    Зачем это дизайнеру 👉Любой дизайн должен удовлетворять потребности двух сторон: бизнеса и пользователя. Чтобы удовлетворить пользователя, необходимо понимать его потребности, задачи и боли в конкретном контексте.
  4. Какие у ЦА барьеры?
    Какие привычки/суждения пользователя могут помешать достижению цели.
    Зачем это дизайнеру 👉Дополняем знание о пользователе ограничениями. На что точно нельзя рассчитывать и как обходить барьеры.
  5. Цель и метрики
    Что должно стать лучше и на сколько? Выгода для бизнеса в цифрах.
    Зачем это дизайнеру 👉Сложно достичь цель, если не понимаешь критерии успеха. Это как писать экзамен, не зная, что именно будет оцениваться: ответы, скорость, почерк, количество символов или всё вместе.
  6. Какое целевое действие ожидаем?
    Что наша ЦА должна сделать увидев/прочитав/прослушав?
    Зачем это дизайнеру 👉Какое действие пользователя приведёт к улучшению метрик из пункта №5?
  7. Ключевое, что пользователь должен понять/запомнить
    Какое знание должно остаться в голове у пользователя?
    Зачем это дизайнеру 👉Какое сообщение он будет транслировать окружающим? Идея, пронизывающая дизайн.
  8. Ограничения по содержанию
    Что обязательно/желательно/нежелательно/нельзя использовать?
    Зачем это дизайнеру 👉Чтобы учесть обязательные элементы брендинга и всевозможные табу.
  9. Сроки
    Когда нужно выкатывать, когда отдавать в разработку?
    Зачем это дизайнеру 👉От сроков зависит возможный объём работы и наоборот. Договаривайтесь заранее.
  10. Технические ограничения
    Привлеките к обсуждению задачи разработчика.
    Зачем это дизайнеру 👉Технические ограничения есть всегда. Учитывайте их, если они известны сразу или подключайте разработчика на этапе идеи.
  11. Где будет применяться?
    Web/печать/рассылка/YouTube/…
    Зачем это дизайнеру 👉Это про контекст. Позволяет «примерить» ваш дизайн: как решение смотрится в ленте Инстаграма или какая информация попадает в первый экран.
  12. Гипотезы
    Предложения решения проблемы. Не обязательно реализуются, если находится более эффективный способ достижения цели.
    Зачем это дизайнеру 👉Возможно, заказчик уже нашёл решение проблемы.
  13. Референсы
    Удачный пример решения аналогичной проблемы, обзор конкурентов.
    Зачем это дизайнеру 👉У каждого своё субъективное «красиво», «правильно», «прикольно» и т.д. Лучше узнать это заранее.
  14. Финальные тексты
    К моменту начала дизайна они должны быть вычитаны редактором.
    Зачем это дизайнеру 👉Можно ли сделать лендинг с «рыбами» текста? – Можно. А потом переделать, т.к. вёрстка не будет поддерживать содержание. Так что утром тексты, вечером – вёрстка.

Оценка решения и обратная связь

  • Дизайн-решение оценивается в соответствии с поставленным ТЗ, дизайн-стандартам компании (гайды/брендбук/библиотеки/...), UX и общим принципам дизайна (композиция/палитра/...).
  • Заказчик тоже хочет сделать проект «хорошо». Если предложенное решение не подходит – выясните, почему. Принимайте только конструктивную критику. Без подробного фидбека переделать невозможно, т.к. причина несоответствия неясна.
  • Соответствие дизайн-стандартам и визуальная составляющая оцениваются дизайнером-наставником или дизайн-директором.

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

{ "author_name": "Marina Stepanova", "author_type": "self", "tags": [], "comments": 0, "likes": 5, "favorites": 25, "is_advertisement": false, "subsite_label": "uchi.ru", "id": 123768, "is_wide": true, "is_ugc": true, "date": "Wed, 29 Apr 2020 10:12:41 +0300", "is_special": false }
Мегаплан
Не успокаивайте(сь): почему не нужно «нянчиться» с сотрудниками на удаленной работе
С введением режима самоизоляции все вокруг принялись успокаивать оказавшихся взаперти сотрудников. Но удаленная работа…
Объявление на vc.ru
0
Комментариев нет
Популярные
По порядку

Прямой эфир