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

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

Здравствуйте! Меня зовут Олег Тумаков, я возглавляю направление дизайна ИТ-компании SimbirSoft. Скорость и качество выполняемых задач на проекте, а также его дальнейшее развитие зависит от объема работ, задействованных ресурсов и от того, в каком виде передаются готовые материалы. Грамотный подход к созданию дизайн-макетов и встроенному взаимодействию с отделом разработки сокращает время работы и уменьшает риски на ИТ-проектах.

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

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

Этот кейс натолкнул нас на написание статьи. В ней мы поделимся несколькими правилами оформления и передачи макетов, которых придерживается команда UX/UI-дизайнеров SimbirSoft. Материал полезен не только начинающим дизайнерам, разработчикам, но и владельцам продуктов.

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

1. Структура

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

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

Рис. 1. Оформленные слои в панели
Рис. 1. Оформленные слои в панели

2. Сетка

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

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

Рис. 2. Базовая 4-х пиксельная сетка компонентов
Рис. 2. Базовая 4-х пиксельная сетка компонентов

3. Иконки

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

Рис. 3. Иконка
Рис. 3. Иконка

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

Рис. 4. Иконка
Рис. 4. Иконка

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

Рис. 5. Пиксельная сетка
Рис. 5. Пиксельная сетка

4. UI-kit

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

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

Рис. 6. UI-kit
Рис. 6. UI-kit

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

6. Состояния и связи

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

Рис. 7. Состояние элементов
Рис. 7. Состояние элементов

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

2. Частично заполненный

3. Экран ошибки

4. Экран загрузки

5. Идеальное состояние (полностью заполненный)

Рис. 8. Экран состояний
Рис. 8. Экран состояний

Ещё один момент — связь экранов. Чтобы сценарий работал так, как было задумано, нужно показать план перехода между экранами. Это можно сделать разными способами, один из них – с помощью стрелок:

Рис. 9. Связь экранов
Рис. 9. Связь экранов

7. Количество символов

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

8. Адаптивность

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

Рис. 10. Экраны адаптивной версии
Рис. 10. Экраны адаптивной версии

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

Если остались вопросы, напишите нам в ВК или Telegram. Больше кейсов по дизайну – на нашем сайте и в соцсетях.

1414
1 комментарий

Спасибо ,отличные рекомендации

Ответить