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

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

Вот попытка перечислить, что обычно идет не так между этими двумя дисциплинами, и как мы можем навсегда устранить эти моменты. Если вы устали впустую тратить свое время на работу с разработчиками, эта статья для вас (разработчики, вы тоже можете узнать из нее кое-что новое).

01. Разработчиков и дизайнеров разделяют


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

Почему так важно, чтобы дизайнеры лучше понимали работу разработчиков? Потому что только тогда они поймут, почему код разработчиков непосредственно влияет на то, какое из дизайнерских решений будет воплощено в результате: разработчикам часто приходится говорить дизайнерам, что их запросы невозможно выполнить, из-за чего дизайнеры думают, что причина заключается в плохом коде или лени разработчиков. Хотя на самом деле чаще всего причина в практичности; некоторые дизайнерские решения идеально подходят под установленную разработчиками инфраструктуру, а многие другие действительно не подходят.

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

Решение

К счастью (для дизайнеров), дизайнерам не нужно учиться кодировать, чтобы решить эту проблему. Есть два решения, которые не требуют больших временных затрат: 1) использовать инструмент вроде Webflow (подробнее о нем поговорим дальше) или 2) взять за привычку просить разработчиков объяснить их подход к разработке и компромиссы, к которым им приходится прибегать, чтобы воплотить эти решения. Последний совет, очевидно, зависит от терпеливости и общительности разработчиков (что может оказаться котом в мешке), поэтому пока давайте сконцентрируемся на первом.

Webflow (и его конкуренты — Webydo или Froont) – это инструмент, который превращает дизайнеров в кодеров. Это способ создавать сайты путем перетаскивания элементов, рассчитанный на профессионалов, а не на новичков. Он позволяет дизайнерам создавать сайты визуально таким образом, чтобы использовать лучшие практики, решения и компромиссы веб-дизайна. Например, в Webflow вы не перетаскиваете волшебный элемент «сетка» на страницу. Вместо этого вы перетаскиваете реальный HTML-элемент «div», в который вы потом добавляете ссылки. В общем, это рисование HTML-кода на странице. И это работает: код, который генерирует эта программа, полностью соответствует W3C, и намного чище, чем любой код, написанный разработчиками вручную.

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

02. Дизайнерам и разработчикам дают разные инструкции


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

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

Решение

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

03. Контент продукта отличается от контента модели


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

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

Решение

Откажитесь от концепции макетов. Начните с первого же дня разрабатывать прототипы с ограниченными функциями. Чем раньше вы начнете работать с материалами, с которыми можно взаимодействовать, тем раньше вы сможете предсказать, как эти материалы нужно будет изменить, чтобы они лучше соответствовали изначальной задумке клиента. Если вы используете инструменты вроде Webflow или Webydo, у вас есть двойное преимущество заставить дизайн работать сразу же; эти инструменты позволяют создавать реальные сайты, а не просто прототипы.

Заключение


Когда дизайнеры и разработчики работают изолированно, конечный результат – это сайт без души или сути. Или и того, и другого. Чтобы избежать этого, работайте вместе с самого начала проекта.

Комментарии (1)


  1. vanxant
    02.04.2015 05:17

    Всё же оставлю коммент к очевидно баллшит-бинго статье (чего стоит хотя бы «намного чище, чем любой код, написанный разработчиками вручную»).
    Так вот, из опыта, главная практика — ну, если мы не берём совсем зелёных дизайнеров, не умеющих правильно сглаживать шрифты в фотошопе — так это проводить внутреннюю приёмку свёрстанного макета дизайнером. Т.е. сладкая парочка дизайнер и фронтенд-разработчик садятся вместе за один компьютер и не выходят на волю до тех пор, пока оба не признают, что макет свёрстан правильно.
    С одной стороны, фронтенд начинает объяснять дизайнеру, что художественные требования оторваны от реальности, данной нам в технологиях. С другой, как известно, хорошие дизайнеры заимствуют, а гениальные — воруют, поэтому у каждого дизайнера всегда есть под рукой ссылки на свежачок с темплейтмонстра и подобных. Получается такое взаимное повышение квалификации) Ну и плюс верстальщики отучаются использовать line-height: 1.42 вместо вертикальной сетки, зато изучают всякие непонятные инженеру трюки вроде letter-spacing и численных значений font-weight.