Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 Вопрос читателя

2 Заказчик не хочет давать письменное ТЗ по дизайну фирменного стиля. Говорит, чтобы я всё делала на свой вкус и профессиональный взгляд. Как понять, что ему нужно? Как избежать множества переделок?

3 Таня

4 На этот вопрос ответил Женя Арутюнов.

5 Фото: личный архив Жени АрутюноваТаня!

6 Я думаю, это прекрасно, что клиент не даёт ТЗ.

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

8 Я предлагаю вместо "технического задания" писать "понимание задачи".

9 Техническое задание - это когда макеты передаются в производство и сопровождаются пояснениями: про материалы, технологии, размеры, функциональные особенности. Это ещё можно назвать "спецификацией" или "пояснительной запиской". А когда дизайнер начинает работу, его задание ещё не может быть техническим. Можно назвать это "творческим заданием" (тоже "ТЗ"), но я всё-таки предпочитаю термин "понимание задачи".

10 Понимание задачи состоит из ответов на вопросы:

11 <ul><li>Что нужно сделать?</li>

12 <li>Зачем?</li>

13 <li>Каким оно должно быть?</li>

14 <li>Как будем делать?</li>

15 </ul>Это нужно спросить у клиента прямо. Если ответ слишком общий, стоит переспросить, что в точности.

16 Например, ответ "фирменный стиль" - слишком общий. Фирменный стиль никогда не нужен сам по себе, а всегда для унификации какого-то важного для компании дизайна. "Новая упаковка и заодно фирменный стиль", "витрина магазина + фирстиль", "оформление соцсетей + фирстиль", "новый сайт + фирстиль", "дизайн презентаций и документов + фирстиль" - это жизненные истории, в которых всё понятно и органично. "Фирменный стиль и брендбук" - это что-то про оболочку, а не про самую мякотку.

17 Важных вещей может быть больше одной - значит, надо узнать всё про все. Довольно часто выясняется, что подразумеваются два проекта:

18 <ul><li>Придумать какой-то важный дизайн.</li>

19 <li>Закрепить его принципы и стандарты, раскатать на другие носители.</li>

20 </ul>И начинать всегда нужно с первого.

21 Причин делать новый дизайн может быть очень много:

22 <ul><li>создаётся новая компания, бренд, продукт, поэтому нужен дизайн;</li>

23 <li>старый дизайн не устраивает функционально, поэтому нужен новый;</li>

24 <li>старый дизайн надоел, с ним скучно, он стыдный, поэтому хочется новый;</li>

25 <li>появился новый директор по маркетингу, ему нужно быстро показать какой-то прогресс, он меняет дизайн - ведь это проще, чем запустить продукт или навести порядок в дистрибуции;</li>

26 <li>да мало ли ещё что!</li>

27 </ul>О причинах стоит спросить прямо. Если чувствуете, что вопрос "Зачем вам новый логотип?" может прозвучать резковато, скажите: "Зачем мы делаем новый логотип?" В этом больше поддержки, вы уже на одной стороне, уже согласны делать, но вам важно знать зачем.

28 Если ответ звучит поверхностно, в духе "потому что старый слишком старый" - стоит аккуратно и настойчиво уточнять. Нормальный способ уточнить: "В каких ситуациях старый слишком старый?", "В какой момент это помешало?" - в общем, расспросить о том,как проявляетсяпроблема.

29 Спрашивайте, пока не поверите.

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

31 Клиент должен слегка приятно удивиться, увидев новый дизайн, - но не слишком. Или: сильно удивиться одним вариантам дизайна, но не слишком удивиться другим. Делать что-то совершенно неожиданное и только его - это рискованно.

32 Чтобы синхронизировать ожидания, можно собрать мудборд - какую-то доску с примерами, референсами. У меня есть два правила для такого мудборда:

33 <ul><li>В нём должно быть только такое, какое мне самому нравится и хочется делать.</li>

34 <li>В нём должны быть и чужие работы, и мои, тщательно перемешанные с чужими.</li>

35 </ul>Я никогда не прошу клиента собрать примеры дизайна - наоборот, я хочу самостоятельно задавать эстетическое направление ещё на этапе обсуждения. И я хочу проверить, действительно ли клиенту заходит мой дизайн. Я прошу посмотреть всё и поставить плюсики-минусики. Если он заминусует весь мой дизайн - может, и не стоит браться за работу, раз ему явно нравится другое. Такая вот проверочка.

36 Конечно, если клиент показывает свои примеры дизайна - я могу добавить их на мудборд. Но могу и аккуратно покритиковать, и это сравнительно безопасный способ поспорить про дизайн ещё на берегу.

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

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

39 Мы посмотрели на ситуацию глазами дизайнера: почему ему выгоднее самостоятельно работать над пониманием задачи.

40 Я написал целую книгу о том, как позаботиться в первую очередь о себе, она называется "<a>Сложный дизайнер</a>". Книга платная, есть промокод "Скиллбокс".

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

42 Не потому, что ему лень написать ТЗ. Просто клиенту важно, чтобы его поняли.

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

44 А вот рассказать своими словами, как понимаешь задачу, - другое дело. Это сложнее, но это работает.