Правила хорошего тона веб-дизайнера
или как удовлетворить фронтенд-разработчика

+55

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




Начала писать, потом перечитала и поняла, что куда-то меня понесло... Человеческим языком:

Зачастую, масса проблем при выполнении проекта возникает из-за вечного «бодания» дизайнеров и фронтенд-разработчиков.
Дизайнер сделал макет, передал его на верстку - а сверстанный сайт заметно отличается от исходника.
И понеслась...

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

Сроки сдачи на грани срыва — страдает вся команда.


Между тем, только ли у верстальщиков руки растут не из того места? Всегда ли вина верстальщика в расхождении макета и верстки? Оказывается — нет. Бывает в этом и вина криворукого дизайнера. Когда последний признает это, воцарит любовь и гармония между дизайнерами и верстальщиками.

Утопия? Вовсе нет.

Всего-то навсего, надо следовать заповедям идеального дизайнера.

 

Заповеди идеального дизайнера
или 6 этапов удовлетворения верстальщика

Фронтенд-разработчикам передаем:

1. Макет, подготовленный для верстки

2. Комментарии к макетам - в отдельном текстовом файле

3. Элементы и иконки - в векторе

4. Frontend Style Guide

5. Спецификацию

6. Фавиконку и шрифты

Рассмотрим каждый из перечисленных пунктов подробнее.

Этап 1. Макет, подготовленный для верстки

Дизайнеры, начинайте плеваться и скептически морщиться — вы все это знаете! Казалось бы, зачем в очередной раз говорить об очевидных вещах?
Вроде бы да, но в личной практике мне не единожды приходилось получать макеты от дизайнеров, на которые невозможно смотреть без содрогания.


Макет для верстки должен быть:

1. Разработан по модульной сетке

Хотя о модульных сетках говорят все, почему-то практика показывает, что действительно ее используют через одного.

При передаче макетов в другие отделы
не удаляйте модульную сетку

Этому есть несколько объяснений:

1. Отсутствие сетки выдает дизайнера — дилетанта
   Вы же не хотите давать шанс усомниться в вашем таланте?
2. Макет, разработанный не по сетке, увеличивает сроки завершения верстки
   Верстальщики злы и недовольны. А мы добиваемся всеобщего счастья.
   
   

2. С логически проименнованными группами, элементами и слоями:

Шапка, меню, сайдбар, контент, футер и тд.

3. Не содержит ненужных скрытых слоев/групп/папок

Все скрытые слои, не влияющие на дизайн удаляются - мусор в макете никому не нужен.

4. С встроенным профилем sRGB

Его отсутствие может привести к расхождению цветов макета и верстки.

5. Стили наложения слоев не растрированы

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

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

6. Шрифты

Не деформированы, размеры заданы целочисленной величиной:

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

7. Текст заглавными буквами

Используем не Caps, а инструмент, предусмотренный программой.



Параметры блоков, кнопок и прочих элементов — целое число, желательно, кратное 8.

8. Одинаковые отступы между элементами одного типа

Отступы между элементами одного типа должны быть одинаковы. К примеру, если перед заголовком H2 64 px, то перед следующим H2 необходимо, чтобы было тоже 64 px.

---

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

 

Этап 2.  Комментарии к макетам в отдельном текстовом файле

Комментарии к макетам прикладывайте отдельным файлом. В нем же описываются анимация и прочие спецэффекты. В идеале — с указанными параметрами.

Это позволит свести к минимуму вероятность того, что верстальщик не «заметит» комментарии в силу различных обстоятельств (к примеру, если дизайнер работает в Photoshop, а верстальщик для нарезки использует Avocode, последний просто не видит комментариев, написанных в фотошопе).

Пока он изучает комментарии, можно заняться любимым делом.

Этап 3. Элементы и иконки в векторе

Передавайте иконки в векторе, сохраненные в SVG-формате. А если вы импортируете их в макет, у верстальщика непременно мелькнет мысль, что  жизнь хороша.
Это еще шаг на пути к цели.

Примечание: для маленьких иконок можно использовать иконочные шрифты. В этом случае рисовать векторную иконку не надо, для фронтендщиков в комментариях укажите ее название.

Этап 4. Frontend Style Guide

Подкрепите эффект предыдущих этапов Frontend Style Guide.

Скачать пример (архив, 348 Кб)

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



Пусть верстальщик порадуется.

Этап 5. Спецификация для макета

Добейте верстальщика - сделайте спецификацию для проекта.

Верстальщик рыдает в экстазе.

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

Вишенка на торте:

В заключение — с макетом передаем фавиконку (в необходимом формате) и шрифты.


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

 

---

А если серьезно:

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

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

Посему, дорогие мои коллеги-дизайнеры!

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

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

Написать комментарий