ТОП-6 трений между дизайнерами и разработчиками
Дизайн часто рассматривается в качестве лёгкого искусства, несущего эстетику и имеющего мало общего с жесткими, правилами логики и тем более, кода. Тем не менее, дизайнеры работают годами, совершенствуя навыки в своём ремесле, а не только развивая бурную фантазию. Однако, оказаться в состоянии объяснить и придать форму «идее, стоящей за дизайнерским безумием» получается далеко не всегда легко и быстро. Это зачастую приводит, к срыву сроков сдачи проектов и прочим неприятным казусам. К счастью, можно найти способы разрядить обстановку.
1. У меня были основания, проектировать дизайн именно таким образом
Проблема: Дизайнер неделями создаёт свои тщательно выверенные визуальные композиции и документацию к ним, казалось бы, лишь для того, чтобы их потом проигнорировали разработчики. За игнорированием некоторыми разработчиками дизайнерских спецификаций стоит простое желание дать возможность браузеру отображать содержимое страницы на стандартных настройках, если только в документации не оговорены изменения, которые необходимо внести для показа дизайнерских изысков.
Дизайнер рассчитывает на то, что разработчик станет внимательно рассматривать элементы дизайна и пытаться добиться соответствия их отображения пиксель в пиксель на готовом макете. Тем не менее, такое требование нередко приводит к появлению на свет интерфейсов, которые выглядят скомканными и плохо организованными, несмотря на все усилия дизайнеров.
Решение: Дизайнеры не должны завышать требования, зная, что сопроводительной документации к их творениям никогда не бывает достаточно для удачной реализации идей. Хорошее руководство к разработанному макету дизайна является первым шагом на пути решения проблемы. Дизайнеры должны работать бок-о-бок с разработчиками, регулярно согласовывая рабочие моменты для достижения наиболее полной степени соответствия технической возможности реализации дизайнерских задумок.
2. Что важно? Всё важно!
Проблема: Разработчик имеет ограниченное количество времени для создания конечной версии продукта, поэтому приоритет будет отдан созданию минимально жизнеспособного продукта, который будет отвечать спецификациям. Большинство дизайнеров рассматривают результат в виде единого целого, а не цепочки взаимосвязанных компонентов. Очень часто до начала разработки бывает трудно выделить наиболее значимые моменты. Поэтому разработчики нередко руководствуются не столько потребностями пользователей и спецификациями, сколько наличием свободного времени в расписании и доступными ресурсами.
Решение: Основные направления разработки должны быть определены на начальных стадиях процесса, отражая требования к выполнению плана минимум – создания, в первую очередь, жизнеспособной версии продукта, а не только простой в реализации на различных стадиях разработки. Дизайнеры могут работать над созданием продукта, техническая реализация которого разбита на отдельные фазы вместо цельного требования к конечному результату. Это поможет значительно облегчить разработчикам планирование своих действий.
3. Сколько это будет длиться?!?!?
Проблема: Дизайнер потратил месяцы на планирование, исследование и создание дизайна, для наиболее полного удовлетворения пользовательских потребностей, лишь для понимания простого факта: разработка дизайна займёт гораздо больше времени, чем ожидалось, из-за противоречивых сроков сдачи, несостыковок требований и их расплывчатости.
Решение: разработка любого пользовательского интерфейса обычно следует после полного завершения работ над дизайнерской составляющей. Поэтому она, как правило, очень сжата в сроках. Никогда не встречал, чтобы разработка дизайна завершилась раньше намеченного срока, оставив больше времени на техническую проработку проекта.
Одним из способов обойти данное временное ограничение, является параллельная работа над дизайном и разработкой проекта в целом. Это сэкономит много времени, позволив разработчикам вступить в игру раньше, чем её закончат дизайнеры. Этот подход не без рисков (возможно, потребуется перерабатывать дизайн), но в целом, он приводит к более быстрому получению результата и соответственно, довольным лицам менеджеров проекта. А не этого ли мы все желаем?
04. Что вы подразумеваете под «Я не могу этого сделать!»?
Проблема: Дизайнер создал действительно классный интерфейс, но разработчик, лишь мельком взглянув на него, заявляет: «Это не будет работать!». Одной из причин такой реакции может быть то, что, действительно, реализовать увиденное невозможно. Но чаще всего за этим кроется одно из двух:
- разработка на основе сложного дизайна займёт больше времени, чем имеют разработчики;
- разработчик просто не знает, как это можно реализовать.
Решение: Если дизайн не может быть внедрён, значит, он не может быть внедрён. Дизайнеру придётся пересмотреть свой макет. Если речь идёт просто о необходимости большего количества времени на разработку, то команда должна решить, вернуться к упрощённому варианту или взять больше времени. Но, если разработчики просто не представляют, как заставить макет работать полностью, дизайнер должен показать примеры , где желаемый подход всё-таки может работать. Для этих целей можно воспользоваться CodePen.io.
05. Тестирование юзабилити является обязательным
Проблема: В понимании многих разработчиков «юзабилити» означает то, что проект работает так, как определено в требованиях. Если дизайнер хочет поэкспериментировать над чем-то, то он должен делать этого до того, как разработчик проведёт множество часов за строительством интерфейса в соответствии со спецификациями. Тем не менее, тестирование можно провести на бумаге и с кликабельными прототипами. Чаще всего, наиболее эффективный тест юзабилити проводят во время самой разработки.
Решение: Запланируйте поэтапное тестирование юзабилити, на уже рабочих частях проекта, давая разработчикам обратную связь на каждой итерации тестирования.
06. Они опять мне говорят, как разрабатывать дизайн!
Проблема: Разработчик прочитывает пару статей по юзабилити и вдруг начинает ощущать себя экспертом в этой области. Дизайнеры же проводят годы за развитием способностей, оттачиванием навыков, приобретением знаний в этой области. Проблема в том, что у каждого, оказывается, есть своё мнение по поводу того, каким должен быть спроектированный им дизайн. Независимо от степени компетенции оценщика. Особенно страдают дизайнерские команды, состоящие из одного человека, – их голос часто заглушают.
Решение: Эту проблему решить непросто, она лежит в плоскости межличностных отношений в команде. Одной логикой и практической необходимостью её не решить. Лучшим путём выравнивания ситуации является, выслушивание оппонентов, без попыток защищаться и спорить. Пусть говорят, а вы слушайте и анализируйте их слова на предмет здравости идей/замечаний.
Их ли заслуга в чужих знаниях, которые они получили из модных журналов о дизайне? Зачем пытаться вешать на вас чужой подход к работе? Они что ли дизайн делают? Пусть знают, объясните, почему вы решили пойти по выбранному пути, признавая попутно своё несогласие с «эталонными» практиками «лучших дизайнеров», о которых они начитались. Иногда столь вредное поведение со стороны разработчиков вызвано простым желанием ощущать, что дизайнер прислушивается к ним. Вот и послушайте. А работайте так, как считаете необходимым. Кто из вас дизайнер, в конце концов!?
Что-нибудь ещё?
Мы изложили шесть часто встречающихся сценариев, ведущих к непониманию между дизайнерами и разработчиками. Интересно узнать ваше мнение по этому поводу. Можете дополнить список или предложить иные способы решения вышеописанных ситуаций? Ваш опыт может быть полезен многим.
Перевод: http://www.creativebloq.com/web-design/frustration...
