Как дизайнеру работать с разработчиками?
Как дизайнеру работать с разработчиками?
02 декабря 2015

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


Как лучше работать с разработчиками, которые внедряют дизайн, который я делаю?

Ответ: Начать думать как разработчик.

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

Классно спроектированный дизайн - как картина, впечатляет только финальный вариант. Вы не можете взглянуть на композицию и определить как принимались решения, какие ограничения существовали при её создании или какие вещи были приоритетными. С веб-дизайном всё примерно так же - разработчик не можете представить себе ход ваших мыслей: каким образом будут работать те или иные формы, будет ли эта штука двигаться при наведении? Будет ли исчезание? По-отдельности это незначительные вещи, но если смотреть на вопрос в комплексе, то именно мелочи и формируют хорошие дизайнерские решения.  И лучше вам ответить разработчику на все вопрос или же он ответит себе на них сам. Вряд ли дизайнеры хотят такой самостоятельности от разработчиков, ведь они скорее всего сделают неправильное предположение или по крайней мере выберут путь наименьшего сопротивления.

Уделяйте первостепенное внимание потребностям дизайна

Любой дизайнер хочет проектировать что-то чертовски красивое и удобное. Сосредоточьтесь на том, чтобы все используемые вами решения были хорошо документированы. Вы не изменяете мир в вашем проекте - вы просто решаете проблему. Как известно, проблемы бывают достаточно разного свойства, но если вы хотите решить стоящие перед вами задачи максимально хорошо - сконцентрируйтесь именно на этом процессе и защищайте свои решения. Пусть даже вы в меньшинстве (особенно если вас всего несколько в девелоперской компании), вы должны стоять горой за то, чтобы нарисованные и проработанные вами решения исполнялись именно так, как вы это задумывали, а не скатывались в плоскость "это сложно сделать, поэтому будет всплывать вот так".

Вовлеките разработчиков в процесс создания дизайна

У каждого в команде должна быть своя роль. Но это не значит, что один не может повлиять на работу другого. Дизайнерам не интересна работа программистов, ровно как и программистам не очень интересно, что там делают дизайнеры. Но каждый из низ заинтересован в том, чтобы его работа была проще. А для того, чтобы она была максимально простой и быстрой нужно построить эффективную коммуникацию. Покажите разработчикам примерные решения того, чем вы вдохновлялись при создании определённых элементов или механики работы - это поможет ему перестать ломать законы web-физики и подсмотреть технические решения, с помощью которых можно реализовать то, что вы хотите.  Более того, он может сам "пощупать" как это должно работать. Сделайте разработчиков частью своего процесса исследования - они часто могут указать на несущественные на первый взгляд детали, способные усложнить работу для них, для вас, да и пользовательский опыт подпортить. Также можно получить фидбек, когда количество времени, нужное на внедрение ваших дизайнерских решений сильно не совпадает с бюджетами или временными рамками проекта - всегда приятно делать классные вещи, но не когда эти решения идут в ущерб общему функциональности. Разработчик всегда отдаст предпочтения функциональности перед более красивым слоем цвета, ведь все эти "дизайнерские ёрзания" могут стоить ему пол дня разработки плюс ещё несколько часов команде тестировщиков на кросс-браузерное тестирование. 

Постоянно учитывайте контент

Почти весь современный web-дизайн выполнен в контексте CMS. Будь то WordPress, Drupal или что-то кастомное, куда кому-то придется вносить весь контент. Этот кто-то – не разработчик,  и уж точно не дизайнер. Практически любой контент, которые клиент может видеть, он захочет иметь возможность изменить (даже если ему не следует этого делать, но это уже другая тема). Ниже приведен краткий список, который необходимо учитывать при создании дизайна для сайта:

 - Сохранить размеры изображений как можно более последовательным (особенно пропорции)
 - Стандартизируйте редактирование своего контента
 - Поделитесь элементами стиля везде, где это возможно
 - Отдавайте предпочтение повторяемым элементам перед уникальными (они не должны быть идентичными, просто не такими уникальными, чтобы под них было нужно написать 8 шаблонных функций, чтобы обработать незначительные отличия)
 - Расположите элементы в относительной близости для всех точек прерывания
 - Используйте различный контент для заполнения элементов

Последний пункт очень важен. Сложно подсчитать сосчитать, сколько раз соблюдались первые пять пунктов: одинаковый размер изображений, одинаковое количество символов, те же знаки пунктуации, и т.д. Как только рыбу меняют на настоящий контент, сетка сливается в унитаз. Неровные столбцы и урезанный контент может с легкостью сделать профессиональный дизайн похожим на web-проект восьмиклассника. Короче говоря, не включайте то, что требует строгого соблюдения каких-то произвольных правил, если только это правило не было согласовано и понятно всем сторонам процесса разработки + заказчику.

Разработчики ничего не знают о вашем дизайне

Легко забыть, что не все обладают теми же знаниями, что и вы. При этом разработчики виноваты в неудачной реализации проекта наравне со всеми остальными участниками процесса. Но, зачастую, команда разработки попросту ничего не знает о новых правках, за исключением ситуации, когда они были вовлечены в процесс с самого начала. Эта информация может быть получена после взаимодействия с клиентом или контекста самого процесса. Главное - информируйте исполнителей о всех изменениях в дизайне, чтобы любые правки не были сюрпризом для отдела разработки и делались вовремя.

Получи доступ к мастер-классам топовых спикеров и базе полезных материалов


Читайте также
Почему я бросил работу своей мечты в веб-дизайне?
Почему я бросил работу своей мечты в веб-дизайне?

Что толкает людей на то, чтобы бросить работу в компании, на которую ушло так много времени и усилий?

26.02 0
Тренды веб-дизайна 2017 года
Тренды веб-дизайна 2017 года

Наша команда обращает пристальное внимание на все изменения в мире дизайна. Это помогает всегда держать вас в курсе новостей и новинок этой сферы.

26.02 0
Специфика работы full-stack designer
Специфика работы full-stack designer

Кто такой full-stack дизайнер и в чём заключается специфика его работы? За что full-stack дизайнер несёт ответственность в проекте.

26.02 0
-->


Комментарии

×
Подписка на новости Skillsup

Заполните поля, чтобы получать новости о дизайне от Skillsup,
обещаем не тревожить чаще 2-х раз в неделю.
Если передумаете — во всех письмах будет ссылка на отписку.