Готовый дизайн на старте проекта — не такая уж редкость: заказчики порой приносят готовые макеты в надежде, что мы их возьмем и тут же начнем по ним верстать и программировать. Но реальность слишком сурова: в 9 случаях из 10 (если не в 99 из 100) такие макеты оказываются почти непригодны для верстки, а их переделка выходит дороже, чем разработка дизайна с нуля.

Так есть ли смысл готовить дизайн на стороне (как бы двусмысленно это ни звучало), в чем его главные опасности и что делать, если делегировать «картинки» всё-таки очень хочется — рассказываем ниже.

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

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

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

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

Ещё одна проблема при таком сценарии — сам дизайн, который не учитывает современных трендов и стандартов отрасли, так как дизайнеру задачи такого типа достаются не часто. А значит, дизайн придется, как минимум, дорабатывать (чаще — переделывать почти полностью). И тут всего два варианта:

1. переделывать заказчику своими силами по комментариям от студии-разработчика;
2. доверять переделку самой студии (о доработках и их возможной стоимости мы еще поговорим).

Бывает, что заказчик обратился в брендинговое агентство (или дизайн-студию) за обновлением фирменного стиля, а там ему допродали еще и дизайн сайта под новую айдентику. Или, например, заказчик во что бы то ни стало хочет дизайн сайта от конкретной студии, но разрабатывать сайт там же или невозможно (ребята только дизайнят), или слишком дорого («Хочу дизайн от Лебедева!»), или стек технологий не подходит. В этом случае в процессе создания нового сайта появляется третья сторона.

Желание сэкономить. Зачем платить студии разработки за дизайн, если можно нарисовать его своим дизайнером, а разработчики — только сверстают и запустят? Увы, чем дешевле дизайн, тем больше шансов, что он некачественный:

• не отражает текущие тренды в веб-дизайне,
• игнорирует современные потребности пользователей,
• проигрывает в UX и UI,
• не учитывает технические нюансы, которые важны при разработке.

А значит, придется потратить деньги на его доработку (или даже полную переработку). Это как купить подержанный Феррари и пытаться выиграть на нем Формулу-1. Да, можно вложиться в тюнинг, поменять движок и почти все запчасти, но это явно выйдет дороже, чем сразу взять современную гоночную машину.

Сила привычки. Бывает, что заказчик работает с какой-то дизайн-студией годами: та отрисовывает ему айдентику, упаковки, баннеры и бог знает что еще. Дизайнеры «секут фишку», точно попадают в ожидания заказчика и в целом комфортны в работе. Поэтому, когда встает вопрос о новом дизайне, вопроса о подрядчике не существует — этот и никакой другой. Ну и что, что дизайн сайтов — не его конек?!

Страхи. Иногда заказчики боятся доверить дизайн кому-то другому: «А вдруг они всё испортят?!». Поэтому рисуют макеты либо самостоятельно, либо сотрудничают с какой-то студией, с которой уже сработались. Так обычно происходит, если заказчик уже обжигался: заказал дизайн у другого подрядчика, но тот не попал в ожидания. Увы, этот подход не гарантирует, что дизайн от «проверенного» партнера будет соответствовать всем требованиям веба.

Проблемы с аналитикой. Скорее всего, ее вообще не было при отрисовке макетов: да, дизайнер знал какие-то базовые принципы UI и UX, был в курсе современных трендов, а вот о том, какие именно элементы ожидает конкретный пользователь этого сайта, ему никто не рассказал. Потому что за эту часть отвечает веб-аналитик, которого в команде с дизайнером нет.

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

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

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

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

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

Неважно, откуда появился свой дизайн: нарисовали его дизайнеры из подразделения заказчика, его жена-фрилансер или какая-то студия. Итоговый сценарий разработки будет зависеть от его качества. И по факту тут всего два варианта:

В этом случае мы:

• Проводим агрегацию требований. При этом — формируем структуру проекта в виде схемы всех разделов, страниц, блоков и функций. Так мы удостоверимся, что макеты соответствуют логике проекта и их хватает под все бизнес-задачи. 
• Сверяем макеты на соответствие 12-ти колоночной сетке, соблюдение отступов и юзабельность.
• Проверяем идентичность и однотипность всех элементов.
• Вносим правки в макеты, если каких-то элементов не хватает или требуются корректировки. Доработки оцениваем по факту в часах (Time&Material).

Плюсы:

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

Минусы:

• не получится «перепрыгнуть» этап дизайна полностью и сразу перейти к разработке (а так хотелось);
• временные затраты на оценку и формирование структуры, доработки и корректировки, которые могут влететь в копеечку

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

• Также проведем аналитику: изучим целевую аудиторию и сформируем подробную структуру сайта в виде схемы разделов/страниц/блоков — всех составляющих пути пользователя, чтобы не потерять ничего важного. 
• Сделаем мудборд, с помощью которого обсудим анимации, 3D- и другие эффекты, а также дизайнерские фишки, которые можно добавить в проект. 
• Отрисуем и согласуем новые макеты.

Плюсы:

• не придется тратить время и ресурсы на доработки неподходящих макетов (слишком часто это дорого и больно);
• гибкий и прозрачный процесс создания дизайна (Scrum и Agile, как никак).

Минусы:

• придется смириться с потерянными временем и деньгами, которые ушли на создание первой версии дизайна.

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

• аналитику, прототипы, дизайн и верстку поручить одной команде,
• разработку — другой.

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

Каким бы ни было ваше решение, помните — скорее всего, в момент его принятия оно было единственно верным. Успехов!