Дизайнер, работающий с разработчиком, и наоборот – это великолепная возможность ускорить процесс создания сайта. К тому же такое сотрудничество часто дает лучший конечный результат проекта. Совместная работа позволяет каждому специалисту сконцентрироваться на том, что он умеет лучше всего, и на том, чем он предпочитает заниматься – это значит, что оба получат гораздо больше удовольствия от проекта.
Однако, отношения дизайнера и разработчика могут быть весьма сложными, если они не будут правильно скоординированы. Разработчики, или кодировщики, не могут ясно представить себе, что именно дизайнер имеет в виду. С другой стороны, дизайнеры могут не соглашаться с разработчиком в том, что легко сделать, а что практически невозможно, что более или менее эффективно, или какие действия не нужны пользователю и не стоят потраченного на кодировку времени. Многие люди, работающие в сети, считают, что проще быть мастером на все руки, даже если получается не идеально.
Тем не менее, отношения дизайнера и разработчика могут сложиться успешно, и в этом случае это будет выгодно для проекта. Кроме выгоды для проекта и личных предпочтений в работе, дизайнеры и разработчики могут сотрудничать, обучать друг друга и помочь друг другу войти в контакт с другими клиентами или специалистами в данной сфере. В этой статье мы рассмотрим несколько основных правил, которым должны следовать дизайнеры и разработчики, если они хотят установить успешные рабочие отношения.
Работайте вместе в процессе дизайна
Когда многие дизайнеры хотят передать проект на стадию разработки, они связываются с разработчиком после того, как закончат дизайн. Они ожидают, что разработчик просто «создаст это». Несмотря на то, что разработчикам чаще всего удается сделать то, чего хотят от них дизайнеры (или хотя бы что-то похожее), нельзя сказать, что это лучшее решение.
Дизайнеры улучшают внешний вид, способны обеспечить удобство для пользователя наглядно, и возможно спланировать несколько применяемых разработчиками визуальных приемов (выпадающие списки, ползунки, и т. д.). Однако разработчики – это не просто машины, выполняющие все, что хотят дизайнеры. Они кое-что знают об эффективности и удобстве для пользователя с технической точки зрения. Они постоянно спрашивают «стоит ли эта дополнительная функция лишнего кода и замедления загрузки?» или «как легче и понятнее всего это сделать?». От того, как изначально спроектирован веб-дизайн будет зависеть его функциональность, то есть очень важно согласовать дизайн сайта с разработчиком перед его созданием.
В процессе работы над дизайном всегда обсуждайте с разработчиком:
• До того, как начать работу. Клиент знает, что он хочет, и дизайнер поработал с ним, чтобы найти подходящее решение. А что думает по этому поводу разработчик? Что будет наилучшим решением для клиента с позиции кодировки? WordPress, традиционный CMS или статичная веб-страница? Какие интерактивные функции помогут ему достичь своей цели?
• В ходе процесса. Действительно обычный макет/схема – это мудрое решение для запланированной разработки? Как можно было бы это упростить? Усложнить? Какие дизайнерские или интерактивные функции необходимы, а какие нет нужды вносить в стоимость разработки? Каковы сроки для отдельных добавленных элементов?
• Совместно проведите последнюю проверку перед презентацией. Вместе проверьте решения, добавления и изменения перед окончательной передачей клиенту. Затем двигайтесь дальше.
Означает ли это, что дизайн нужно делать таким, чтобы разработчику было легче создавать сайт? Нет, разработчики большей частью любят решать сложные задачи. Суть в том, что было бы неплохо вместе работать над интерактивными приемами, интересными схемами макетов, и больше с разработчиками, чтобы видеть, насколько они будут эффективны, или если разработчик знает любопытные техники, с которыми дизайнер может работать. К тому же, было бы хорошо обсуждать, что технически возможно выполнить или что входит в компетенцию разработчика, и что можно сделать в установленные сроки.
Тщательно объясняйте назначение функций
Самый большой мост между дизайном и разработкой – это интерактивные функции, которые можно отнести к веб-опыту. Создать шаблон PSD с визуальной точки зрения относительно легко, но чтобы точно знать, как должны работать выпадающие списки, ползунки, состояния элементов при наведении на них указателем мыши и т.д., нужны детальные разъяснения. Некоторые функции не требуют разъяснения, но не думайте, что это касается всех.
Крайне важно иметь полную документацию до того, как начнется этап разработки, иначе разработчику придется постоянно переделывать и редактировать уже сделанную работу. Это только отнимет время и повлечет срыв планов. Помогите разработчику понять все правильно с первого раза!
Что касается PSD, убедитесь, что выделенные состояния и прочее должным образом помечены в соответствующих слоях, текстурированных основах и других необходимых шаблонах, или что слои не связаны, и т.д. Помогает и организация PSD документа в виде набора групп слоёв и путей. Сделайте шаблон PSD настолько точно, насколько это возможно. Если вы – разработчик, то обязательно задайте все вопросы до того, как предположить и сделать неправильно!
Поддерживайте откровенное общение
Если в проекте из-за чего-то возникает проблема, не нужно молча решать ее. Говорите! Дайте другим партнерам знать, в чем дело и вместе найдите решение или соответствующим образом измените бюджет. Дизайнеры могут не знать, какие функции требуют много дополнительных усилий, а разработчики могут не понимать и не осознавать важности самых мелких деталей дизайна.
Если разработчик забыл что-то в кодировке веб-страницы, сообщите ему. Если он не понимает функционального назначения какого-либо элемента, объясните ему и помогайте до тех пор, пока все не наладите или не переделаете. Если дизайнер разработал слишком сложный для кодирования дизайн, но достаточно простой по конструкции – разработчик должен упомянуть это на этапе дизайна. Если дизайнер предлагает функцию, больше сложную, чем важную – разработчик, говори об этом!
 | Ты кодируешь это неправильно! |  |
1. Поймите, почему разработчик, возможно, не может сделать это правильно. Что упущено? Он не видит в этом элементе необходимости, и, следовательно, идет по самому легкому и быстрому пути? Более того, может, он прав? Это принципиально важно? И необходимо ли это для дизайна?
2. Объясните, почему так важна эта функция или элемент. Обязательно поговорите с разработчиком о том, почему эта маленькая деталь имеет такое большое значение. Это хороший способ научить кого-то, кто, возможно, не имеет большого опыта в области дизайна, и так как он сам сразу не видит замысел, вы не выглядите как высокомерный придурок, исправляя его без объяснений.
3. Компромисс посередине. Если что-то невозможно или гораздо сложнее выполнить, чем вы думали, будьте открыты для компромисса. Можно ли пожертвовать этой функцией или элементом? Можно ли сделать это по-другому? Можно ли заменить эту функцию другой?
| Это не веб-дизайн, это больше подходит для печати! | |
1. Примите вызов. Если это просто новая структура макета, что-то более сложное или непривычное – это не конец света. Эта работа может быть сложнее, чем обычно, но примите это как вызов и возможность научиться кодировать другим способом.
2. Всесторонне обсудите функциональность. Если функциональное назначение определенного компонента неясно, поговорите об этом и уточните его. Если этот компонент действительно не укладывается в сроки и/или бюджет, сообщите об этом дизайнеру. Не молчите, если вы видите, что есть лучший или альтернативный способ, который вы уже знаете. Возможно, дизайнер пойдет на компромисс.
3. Расскажите дизайнерам о веб-стандартах кодировки и о ее передовых методах. Если что-то не принадлежит к хорошему опыту взаимодействия с точки зрения разработки, скажите об этом дизайнеру. Это может изменить результат этого и всех будущих проектов к лучшему.
Признавайте и уважайте профессии друг друга
Разработчик мог бы сказать, что дизайнер только создает красивые картинки, и относится к работе несерьезно. Работа разработчика же – это «настоящий умственный труд». С другой стороны, дизайнер мог бы сказать, что разработчик не имеет представления о том, что удобно пользователю и не может оценить важность визуальной составляющей для правильного функционирования веб-страницы. Дизайнеры могут жаловаться, что кодировщики не принимают их в серьез. Или наоборот, дизайнеры не принимают в серьез разработчиков: «разработчики не обладают креативностью, они просто механически клепают сайты, как машина – шаг за шагом; штампуя их; не применяя творческое мышление».
Так что если разработчик все-таки не имеет хороших дизайнерских навыков? Что если дизайнер не вполне понимает, что такое умный код, и не может охватить, почему он так важен? Именно для таких случаев и нужна ваш профессионализм, на какой бы стороне вы ни были.
Очевидно, в обеих профессиях есть много нюансов, и как дизайнеры, так и разработчики должны уважать это. Они разные, но нельзя сказать, что какая-то профессия сложнее, проще, креативнее или заслуживает меньшего уважения.
Итак, чтобы быть в хороших отношениях со своим дизайнером или разработчиком, постарайтесь признать его профессиональные навыки, которые требуются для выполнения его части работы и работайте с ним, выполняя свою.
Процесс создания дизайна и разработки пойдет легче, если понимать тонкости каждой профессии. Дизайнер будет знать, когда лучше посоветоваться с разработчиком и наоборот. Они будут знать ограничения, и в чем они, вероятно, будут сильны. Вдобавок ко всем этим преимуществам, понимание и признание талантов своего партнера способствует установлению гораздо более дружеских и спокойных рабочих отношений.
Заключение
Сотрудничество не обязательно должно быть сложным. Сотрудничество вообще не должно быть сложным. Учитывая все преимущества, вытекающие из сотрудничества дизайнеров и разработчиков, нет причин не сделать попытку, и даже еще одну, несмотря на негативный опыт в прошлом. Сотрудничество может помочь как дизайнеру, так и разработчику сконцентрироваться на том, что они любят и делают лучше всего. В результате, работа выполнена лучше, клиенты довольны. Бизнес быстрее растет и развивается.
Высказывайте свои впечатления, положительные или отрицательные, о прошлой работе в команде с другим веб-специалистом. Стоила ли игра свеч, или изменилось ли что-то к лучшему?
Оригинал статьи вы можете прочесть здесь.
