Документирование дизайна: +100 к точности

Раунд первый

Извечной проблемой при создании приложений или веб-проектов является стадия вёрстки дизайна или даже интеграции готовой вёрстки в проект.

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

Типичный взгляд дизайнера и разработчика.

Для начала стоит понять, что дизайн в контексте интерфейса — это не просто элемент эстетики. На самом деле, разработка дизайна интерфейса такая же инженерная задача, как и программирование с вёрсткой. В каждом макете должна быть своя чёткая система и логика. Это значит, что месторасположение элементов, размеры кнопок, механика работы вспомогательных элементов подчиняются неким рациональным принципам. Что произойдёт при нажатии на ту или иную кнопку? Возникает вспомогательный элемент слева или справа? А может быть, в модальном окне? Вызывается он с помощью щелчка мышки или при простом наведении на какой-то из элементов? Как быстро этот элемент реагирует? Все эти аспекты имеют огромное значение для восприятия. Больше, чем можно себе представить.

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

Как себя должна вести стрелка, если ширина окна меньше? А если больше? По этому макету однозначно не скажешь.

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

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

Не спешите бросать камни в огород коллег. Лучше задумайтесь, что можно предоставить своим разработчикам в помощь, чтобы дизайн был воплощён именно так, как задумывалось?

Страница со всеми типовыми элементами

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

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

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

Спецификация дизайна

В процессе работы над проектом каждый дизайнер определяет для своих макетов некую систему — размеры модулей, отступы у всех элементов, пропорции заголовков и текста, а также механику взаимодействия элементов. К сожалению, часто вся эта система так и остаётся в голове дизайнера. Увы, статические картинки, которыми по сути и являются дизайн-макеты, не до конца дают представление о том, как это должно работать в жизни. Ну а кроме того, тому же верстальщику, чтобы сверстать макет, придётся, по-хорошему, провести целое исследование. Будем откровенны, многие просто забьют. Либо в силу собственной лености, либо в силу объективного ограничения по срокам.

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

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

Как это может выглядеть?

Какие элементы стоит описывать и каким образом? Идея такой спецификации в том, чтобы отвязаться от ПО, которое использует дизайнер, и создать один документ в универсальном формате.

Естественно, что в таком случае у нас отпадают всякие лайфхаки в духе PSD-файлов с комментариями или AI-документы с десятками artboard.

Оптимальным выбором является многостраничный PDF-документ, который структурирован по типу описываемых элементов:

1. Сетка — какая сетка используется, ширина колонок и типовых отступов. Как изменяется ширина колонок в зависимости от размера экрана.
2. Типографика — какие шрифты используются для основного текста, заголовков и вспомогательных стилей (например, выделение или цитата)
   
3. Кнопки и элементы форм — как себя ведёт кнопка в разных состояниях, как она меняет свою ширину в зависимости от контекста, цвета, шрифт, в конце концов — радиус скругления уголков.
4. Подробное описание каждого логического блока — шапки, подвала или навигационного меню. Или уникальных блоков в духе фильтра в более сложных проектах. Параметры для описания всё те же — шрифты, цвета, размеры и отступы.
   
5. Интерактивные элементы, например, слайдеры или модальные окна — с каким эффектом они появляются, с каким эффектом изменяют своё состояние.

Чтобы было понятно, скажу просто: если вы действительно болеете за то, как ваша дизайнерская задумка будет воплощена в жизнь, потратить время на её детальное описание безусловно стоит.

Инструменты в помощь

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

PNG Express — плагин для Photoshop для создания спецификаций дизайна по таким параметрам, как расстояние, высота/ширина, эффекты слоёв, цвета градиента, шрифт, его размер и цвет. Работает с версией Photoshop CS5 и выше. До патча Photoshop CC 14.1 был примечателен ещё тем, что сам нарезал изображения по параметрам в названиях слоёв и групп.

Второй инструмент — улучшенная и доработанная концепция PNG Express — Specctr. В первую очередь Specctr хорош тем, что работает сразу для трёх продуктов Abode — Illustrator, Photoshop и Fireworks. В остальном — всё тот же PNG Express, так что тут больше дело привычки.

Больше?

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

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

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