Как передавать
дизайн в разработку
7 Февраля 2014
Как передавать дизайн в разработку
7 Декабря 2013
На этот счет образовалась целая дискуссия у Артема Горбунова. Действительно, универсального ответа нет, так как в каждой организации свой подход, в зависимости от того, для какой платформы разрабатываются дизайн макеты, и в каких программах работают специалисты.

Проработав год в крупной компании, где цену времени знают лучше, чем где либо еще, я взял на вооружение несколько пуленепробиваемых правил хорошего тона передачи работы дизайнера в разработку.
1
Опишите логику дизайна текстом
в отдельном документе
Неважно, удаленно вы работаете или в команде, разработчик должен четко понимать как интерфейс будет функционировать: Куда форма будет отправлять данные? Что произойдет, если пользователь введет некорректные данные? Что случится, если значение в фильтре А конфликтует со значением фильтра Б?Поэтому, правильно начинать подготовку дизайна в работу с описания логики, это может выглядеть следующим образом:
2
Покажите все возможные
состояния форм и элементов
Основные вопросы разработки в данном случае будут со стороны команды верстки. Как будет выводиться ошибка? Что произойдет, если надпись в кнопке будет слишком длинная? Что случится, если в карточке вместо фамилии Иванов будет фамилия Константинопольский1988? Что, если изображение будет с прозрачным фоном?

Поэтому, чтобы ответить на эти вопросы нам нужна страница с подробными поведениями форм, ограничениями и т.д.:
3
Создайте мастер-страницу
или UI kit для команды разработки
Когда весь дизайн готов, то помимо всех страниц сайта у вас должна быть еще одна дополнительная — master page, или мастер-страница. А если это сервис, то UI kit просто обязателен. На такой странице должны быть собраны все стили, все виды кнопок и их состояний, все виды форм заголовков других элементов, которые присутствуют в дизайне. Это может выглядеть например вот так:
В подобной работе мне помогают примеры гайдлайнов известных компаний, таких как Google material design, по специфике работы это был Atlassian guidline, так же очень рекомендую пример Контур-гайдов, особенно мне понравились требования к UX-дизайнеру, эдакий чек-лист по собственному профессиональному росту.
Для чего это нужно? Во-первых, для разработки проще, когда основные правила лежат в одном месте, и не нужно никого дергать с разными вопросами, например: А как тут сделать? А как ведет себя кнопка или как выглядят ошибки у чекбоксов и т.д. Во-вторых, если это удаленный проект, подобный гайд задает стиль всему сервису, на него будет ориентироваться вся компания, когда будет создаваться новый контент уже без дизайнера.
4
Zeplin
Экспортируем страницы в Zeplin, предварительно кликнув по экспортируемой графике на Make Exportable в программе Sketch. Если это иконки или иллюстрации, они должны быть либо в векторе, либо в 2x формате для ретины:
Организовываем страницы в Zeplin так, чтобы не приходилось искать, если это бесплатная версия, достаточно указать тэги и визуально разбить все на логические группы:
В идеале, на каждый проект должна быть заведена своя папка, UI kit должен лежать в своей папке и иметь возможность редактирования только одному администратору, чтобы избежать искажения или потери данных в жизненно важном документе.
Заключение
1
Сценарии
Все сценарии дизайна должны быть четко описаны так, чтобы разработчик ни разу не подошел с вопросом к дизайнеру;
2
Состояния элементов
Все состояния форм, ошибок и другой динамики должны быть показаны, необходимые edge cases должны быть продуманы, но без фанатизма;
3
Guidline
Все должны знать, где лежит UI kit или гайдлайны, по которым создавать новый контент;
4
Организация и поиск материалов
Список проектов организован понятно, все версии актуальны, никто не может внезапно обновить дизайн в Zeplin без уведомления администратора.
Мне и моим разработчикам данный подход помогает в работе и не вызывает дополнительных вопросов. Если у вас есть пожелания, дополнения или нарекания по вышесказанному, прошу написать в комментариях.

Понравилась статья? Расскажите друзьям:
Назад   /   Вперед