С какими проблемами сталкивается веб-дизайнер?

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

Первая проблема, с которой сталкивался каждый дизайнер при устройстве на работу — тестовое задание. Возникает сразу несколько вопросов: «когда его стоит делать?», «должно ли оно оплачиваться?», «какой объём и сроки являются адекватными для исполнения?»

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

Что делать начинающему дизайнеру с минимальным количеством работ и без рекомендаций от предыдущих клиентов? Ответ: быть избирательным. Если вы понимаете, что тестовое задание вам присылает топовая компания или задание выглядит вполне адекватно, то конечно стоит выполнить. Другое дело когда тестовое приходит от неизвестной конторы или аналог тестового есть у вас в портфолио. Отказ от тестового в 99% случаев лишает вас возможности на сотрудничество. Если вы укажите на аналог тестового в портфолио — результат спорный. Возможно заказчик ранее не обратил внимание на уже выполненный проект и указание на портфолио пойдёт на пользу. Возможно, что указание на аналогичный проект будет считаться отказом от тестового задания.

Должно ли оплачиваться тестовое?

Оплачиваемое тестовое задание могут позволить себе только топовые компании. Плюс в больших компаниях хорошо работает кадровый отдел и на тестовое задание выходят 3-5 кандидатов. Но чаще всего крупные компании не оплачивают тестовое задание, так как в топовые компании и так готовы прийти хорошие дизайнеры.

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

Какой объём и сроки являются адекватными для исполнения тестового?

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

Единственный случай когда не стоит выполнять тестовое задание — проектная работа. То есть выполнять тестовое задание, чтобы получить оплачиваемое разовое задание. На этот случай нужно договариваться о минимальной предоплате. Или предлагать минимальный объём работы без оплаты, если вы начинающий дизайнер и у вас нет ссылок на аналогичные проекты.

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

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

Есть один случай когда предоплату не получится взять, я отвечал на этот вопрос на Кью ранее.

Но что делать, если ты начинающий дизайнер и без портфолио и резюме тебе никто не даст предоплату.

В этом случае стоит прибегать к хитрости или принимать риск, что тебе не заплатят за работу.

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

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

Техническое задание — это основная защита дизайнера от переработки. ТЗ должно быть составлено письменно — это железное правило. Иначе дизайнер может быть 1000 раз прав, но его слова ничего не значат, если ТЗ составлено устно.

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

Бывает разное, допустим в середине проекта заказчик решит усложнить проект, добавить новых разделов или решит попробовать новую механику взаимодействия с пользователем. С точки зрения дизайн-проектирования — это новая концепция (считайте новый проект), с точки зрения заказчика — это небольшие изменения.

Есть два распространённых варианта, как рассчитывать кол-во включенных в проект правок.

Первый — числовое значение, к примеру не более 10 правок. Но этот вариант не совсем корректен, так как «поменять цвет» — это одна правка и «поменять стиль» — это тоже одна правка. Только в случае с цветом это займет максимум час, а в случае со стилем до нескольких дней.

Поэтому лучше считать кол-во правок в процентном соотношении изменений, к примеру не более 10% от всего проекта. Тогда изменение цвета будет 1%, а изменение стиля возможно 50% и это уже оплачивается отдельно.

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

Связано это с тем, что заказчику (в большинстве случаев) сложно визуально представить описанную текстом дизайн концепцию, а на примере аналогичного сайта гораздо проще «примерить» её на свой проект.

Важно донести до заказчика, что техническое задание это договор, и при изменении задач меняются условия: цена и сроки.

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

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

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

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

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

Основные моменты:

Цель проекта должна быть чёткой и конкретной. Формулировка: «сделать красиво и чтобы работало» не подходит. Эти слова не измерить. Только цифры или требования можно проверить: «увеличить количество заявок с сайта в двое» или «избавиться от обрыва пути покупки товара».

Метрики — история посещаемости ресурса и поведения интернет-пользователей. С сайта можно получить глубину скролинга, количество нажатий, процент конверсии в заявку, процент отказа, длительность посещения, это минимум по которому проводится аналитика.

Что делать если проект новый и метрик нет?

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

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

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

Заказчик может предлагать нововведения для сайта фразой «а что если...» и приводился пример из противоположной истории пользовательского поведения.

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

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

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

Продвижение — это самый распространённый конфликт между дизайнером и SMM-щиком.

Дизайнер делает сайты для людей, но контекстная реклама и поисковики это робот и там работает другое считывание сайта. То что с точки зрения UX размещается на трёх страницах, SMM-щик посоветует поместить на одной для продвижения.

В данном случае нет плюсов и минусов, нужно здраво анализировать. Если объединение материала принесёт новых пользователей, то возможно стоит пожертвовать UX-ом.

Излишняя вовлечённость заказчика приносит больший результат и в итоге лучше, чем «вы дизайнер, вам виднее».

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

Дизайнер должен чувствовать грань вкусовщины и пользовательски нацеленных предложений в правках.

Спорные моменты проверяются на целевой аудитории и анализе метрик.

Не бывает плохих проектов (заказчиков) — бывает неправильный подход.