О правках или как заказчик убивает дизайн

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

Проектные чаты в Telegram и корпоративная почта заполнены ИМИ. Мой день начинается с ненавязчивого жужжания уведомлений или звонков на телефоне от заказчиков, и мы снова обсуждаем ЭТО. И каждый день я с нетерпением жду ИХ!

А теперь серьезно. Правки – не самая приятная часть работы дизайнером, но она же и неотъемлемая, ведь видение дизайнера всегда будет ограничиваться техническим заданием, мнением заказчика+маркетолога+менеджера и возможностями разработчиков. Иногда правки оправданы и необходимы, а иногда вызывают лишь непонимание и головную боль. Как справляться со вторыми? Давайте рассмотрим несколько вариантов.

Итог: заказчик доволен, продукт с большой вероятностью – кал мамонта.

Пример: Чуть больше года назад студия получила проект от одного из крупнейших таксомоторных предприятий Санкт – Петербурга.

Задача проекта: с нуля переписать приложения под Android и iOS с совершенно новым дизайном. На момент заключения договора дизайн приложений уже был подготовлен фрилансером, нанятым компанией. Соответственно, мои услуги в этом проекте не были нужны.

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

Когда было решено, что доработки и исправления в дизайне интерфейса будет делать штатный дизайнер MAD Studio, меня уже ждал Word-файл с правками от менеджера компании на 20 листов. Тогда я была начинающим мобильным дизайнером, на счету которого было около 5 проектов и довольно низкая самооценка.

Что ж, подумала я, пора закатать рукава.

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

Все мемы про Бориса и “Олег, где макет ?» – Игорь  с Дезигна, с которых я смеялась раньше, вдруг стали моей реальностью и кошмаром наяву.

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

В один день я услышала фразу, которая звучала примерно так:

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

Так, в приложении экран для заказ такси по внешнему виду стал напоминать панель управления космическим кораблем. Желание заказчика отличиться от простоты навигации в “Яндекс. Такси” или Uber – прямых конкурентов компании – привело всех к созданию какого-то неюзабельного г*вна, которое они приняли за конфетку.

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

Проект, кстати, до сих пор находится на паузе, а их текущее приложение для заказа такси все еще доступно в App Store и выглядит как привет из 2010 года.

UPDATE от весны 2019 года: они все же выпустили приложение, с дизайном, очень сильно напоминающим версию 2017 года.

Итог: заказчик потрепан, но доволен, ищет перспективы для дальнейшего сотрудничества; исполнитель потерял пару миллионов нервных окончаний, но доволен; получен адекватный и качественный продукт с дизайнерскими решениями, проверенными на реальных пользователях.

Пример: Один из наших последних проектов – корпоративное приложение для сотрудников молодой питерской компании, занятой в сфере разрешения производственных задач.

Задача проекта: разработать для сотрудников компании приложения на Android и iOS для поддержания корпоративных связей. Звучит довольно туманно, знаю, но большего я раскрыть, увы, не могу. Дизайн должен был разрабатываться с нуля, с опорой на ТЗ и в рамках фирменного стиля компании.

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

После презентации менеджерам прототипа с первичным дизайном последовало разочарование, сбитое меня с толку. “Нам не нравится сочетание цветов, скучно!” Но это же ваши фирменные цвета! “Иконки слишком абстрактные, можно что-то конкретное?” Но это же было пожеланием из ТЗ. “Слишком просто”. Стоп, разве это не было целью?

Спустя пару дней перетаскивания иконок из категорий “конкретные” в “абстрактные” и обратно и подбора нужного оттенка синего я начала раздражаться. Менеджеры начинали играть во вкусовщину между собой, и создавалось впечатление, что никто из них не знает, что им вообще нужно.

После нескольких продолжительных споров я решила предложить обмен идеями. Я прислала примеры дизайна закрытых проектов (речь идет о NDA) и спросила у заказчика, какие сайты/приложения/продукты вдохновляют его, что кажется симпатичным. Иногда это помогает понять, что творится в его голове. В ответ я получила только макеты несуществующих но красочных проектов с Behance и Dribbble с градиентами и другими трендовыми штуками. И еще признание от заказчика, что его техническое задание ограничило мои возможности. Казалось бы, точки соприкосновения найдены, а непонимание исчерпано, но нет.

Второй момент, сбивший меня с толку, возник на возмущении заказчика, что “Мы делаем только то, что он скажет”. Помните, что было в примере варианта 1?  Заказчику не нравилось, что с ним спорили. В этот раз все было наоборот, заказчик будто ждал, что я буду спорить, делать все по-своему и вообще вести себя как Тёма Лебедев.

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

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

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

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

Всем побольше положительного опыта и понимающих клиентов!