ru:https://highload.today/blogs/maket-dizajna/ ua:https://highload.today/uk/blogs/maket-dizajna/
logo
Визуализация      16/02/2022

Как сделать понятный макет дизайна сайта или приложения: чек-лист

Игорь Артюхов BLOG

Lead Designer в NIX

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

Скажу сразу: здесь описана идеальная картина мира. В реальности не всегда получается идти по такому плану. Но попробовать стоит.

Перед созданием дизайна

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

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

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

Обсудив все это заранее, вы не только сэкономите время обеим сторонам, но и покажете свой профессиональный подход к процессу разработки.

А когда приступите к дизайну, делитесь со второй стороной промежуточными результатами, спрашивайте у клиента и разработчика, что добавить и в каком виде, а что — убрать.

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

Контрольная проверка накануне передачи макета

Пройдемся по чек-листу:

Курс Python.
Python дозволяє тобі не тільки розробляти сайти та займатись аналітикою даних, а ще й будувати алгоритми, тестувати програми та навіть створювати штучні інтелекти. Стань різноплановим фахівцем!
Дійзнайтеся більше
  • Структура макета. Все зависит от того, где находится файл: в драфтах, в Figma в разделе Teams и т.д. Но в любом случае у хорошего дизайнера все страницы структурированы и правильно подписаны. В идеале можно даже использовать дефисы или тире в названиях страниц в качестве разделителей в структуре макета и добавлять иконки для создания визуальных якорей. Это будет удобно и создателю макета, и разработчику, и другому дизайнеру, который позже откроет этот файл.
  • Подписи для фреймов, если их много. Оформлять их можно даже гигантскими буквами, например: «ГОТОВО К РАБОТЕ», «НЕ ТРОГАТЬ, НАХОДИТСЯ В РАЗРАБОТКЕ». Также можно брать большой текст и создавать рамки и полоски для отделения части фреймов от других. Если же проект итерационный и работа идет с постоянным созданием и поэтапной отправкой в разработку чего-то нового, можете подписывать фреймы так: In progress, Ready for development и т.п. Таким образом девелопер не запутается в файлах и быстрее сориентируется в макете.
  • Названия фреймов, групп и элементов. Помимо подписей к фреймам, стоит стараться создавать логические блоки для наименований или названий. Обычно они соответствуют содержимому. Например, фрейм для страницы «О нас» можно подписать просто About Us, а подвал страницы — как footer.
  • Только необходимые размеры у текстовых блоков. Дизайнеру нужно следить, чтобы не было как слишком большой, так и чересчур маленькой текстовой области вокруг текста. Объясняется это тем, что разработчик измеряет расстояния от низа текстового блока до следующего блока, и в таком случае не должно быть ни пустот, ни избытка текста.
  • Текстовый блок одним слоем. Разработчику гораздо проще работать, когда дизайнер использует для одного массива текста один текстовый слой. При изучении макета и знакомстве со стилями текста разработчик может одной кнопкой скопировать в буфер обмена весь текст. Если он будет выполнен одним слоем, это максимально упростит такую задачу без многократного повторения каждого слоя.
  • Отступы. Это особенно важно для карточек с динамическим контентом, где неизвестен точный размер текста. Например, у товаров в онлайн-магазине могут быть разные по длине названия: как из-за именования продукции, так и требований сеошников, которые часто добавляют в заголовки необходимые для поискового продвижения слова. Поэтому дизайнер для таких текстовых блоков может прорисовывать и показывать, что заголовок размещается от края до края, и что есть некая система отступов, повторяющаяся с каждой стороны каждого блока. Тогда будет понятно, что пустота по бокам от заголовков возникла не просто так и все логично связано.
  • Отсутствие дробных значений. На мой взгляд, цельные значения красноречиво говорят об аккуратности дизайнера и соблюдении им порядка в макете. Дробные же цифры показывают, что дизайнер небрежно к нему относится, и это наверняка проявляется во всем остальном. Не даром при оценке проектов в Figma многие лиды обращают внимание именно на эту, казалось бы, мелочь. Поэтому стоит сразу приучить себя делать все хорошо и правильно. Конечно, если не использовать инструмент Scale и не отключать в настройках привязку к пиксельной сетке, то дробных значений по идее и не будет. Но на всякий случай стоит пройтись по проекту и проверить такие детали.
  • Все выполняется через стили и компоненты. Этот подход обезопасит вас от невнимательности. Допустим, он может поставить скругление блоков и изменить его по всему макету, но буквально в одном месте пропустить такой элемент. В итоге потеряется единство оформления. Поэтому всегда старайтесь использовать компоненты.
  • Сетка или система отступов. Как показывает практика, разработчикам не особо важно использование сетки. При этом им важно наличие некой закономерности, о чем вам стоит подумать заранее. Неприемлемой будет ситуация, когда отступы гуляют от блока к блоку: 25, 27, 33, 28. Вывод в таком случае один: дизайнер явно не сильно старался и не следит за деталями.

Передаем макет разработчику — основные шаги на стороне дизайнера

Макет приложения

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

В макете все должно быть четко структурировано, без лишних деталей.

То же самое касается и moodboards с забракованными концепциями. Последние могут демонстрировать проработку дизайна и общий объем работы.

Также в макете стоит учесть и разные размеры экрана. Если дизайн был нарисован под десктоп, например, шириной 1440 пикселей, надо подумать, как макет будет выглядеть уже на дисплее с разрешением 1920.

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

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

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

Спецификации

Спецификации — это те источники данных, которые интересуют разработчика в первую очередь. Им стоит уделить особое внимание.

Выгрузить спецификации для разработчика можно разными способами. Самый простой — отправка ссылки из Figma. При открытии проекта разработчик сможет перейти во вкладку прототипирования и пункт Inspect. Кроме текстовых и цветовых стилей, там можно выбирать отдельные элементы дизайна (например, кнопки) с названиями, размерами и прочими параметрами. При этом можно менять единицы измерения под CSS, iOS и Android. Обычно спецификаций из Figma для работы разработчика более чем достаточно.

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

Zeplin — это, по сути, плагин под Figma, Sketch, Adobe XD и Photoshop. Для его использования надо регистрироваться, а ключевая логика — синхронизация всех фреймов в макете.

Курс Fullstack Web Development.
Стань універсальним розробником, який може створювати веб-рішення з нуля.
Приєднатися

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

У Zeplin в разы больше доступного и важного функционала для разработчика, чем в Figma. В нем можно найти сборник всех стилей, фактически Style Guide. Зачастую, конечно, можно обойтись и базовыми спецификациями в Figma или обратиться к Avocode со схожим функционалом. А правильнее всего будет узнать у самого разработчика, что ему больше подойдет.

Документация

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

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

  • Style Guide — минимальный вариант документации. Включает описание стилей проекта. Сюда входят цвета, шрифты, сетка, отступы, тени, иконки, изображения, описания использования этих изображений. Если есть изображения нестандартных форматов, нужно учитывать, что изменится в случае их замены разработчиком или заказчиком. Например, будет ли кадрироваться что-то важное.
  • UI Kit — расширенный формат документации. В дополнение к тому, что есть в Style Guide, здесь появляются компоненты. К ним относятся кнопки и другие интерактивные дизайн-паттерны, у которых показаны все состояния (наведения, нажатия, заполнения и т.п.). Если проект достаточно большой и у дизайнера есть время, то UI Kit будет предпочтительнее простого Style Guide.
  • Design System — наиболее комплексный подход к созданию документации. В ней описаны как кнопки и их состояния, так и четко оговаривается, что такие-то кнопки нужны для самых важных действий на сайте и их не надо использовать в таких-то случаях. Таким образом мы затрагиваем буквально все: карточки, тени и т.д. Более того, в подобной дизайн-системе могут быть даже ссылки на исследования, которые проводили дизайнер, UX-ресерчеры, если они участвуют в проекте, или сторонние компании.

Именование стилей и компонентов

В идеале лучше называть стили и компоненты как в языке разметки HTML/CSS и использовать английский. Если надо подписать, например, иконки, то я беру для названия то, что на них изображено или где они используются. Единственное из верстки — это navigation, header, footer, input. Также можно работать с сокращениями: как btn для button или btn secondary и btn primary (второстепенная и первичная кнопки).

Читайте также: Прислушиваясь к советам от Google: как оформлять кнопки в интерфейсе

Карта экранов 

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

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

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

Кликабельный прототип

Кликабельный прототип требуется разработчику по тем же соображениям, что и карта экранов. Он помогает понять, как работают разные элементы. Создавать кликабельные прототипы можно в Figma, Adobe XD, Invision, Axure. Последний раньше считался стандартом среди инструментов прототипирования из-за своего богатого функционала.

Например, многим нравилась возможность делать поля ввода именно полями ввода: кликаешь на них и можешь что-то написать. В Figma поле ввода — это обычный прямоугольник с рамкой. В ней максимум, что можно — показать его состояния, но без интерактива. А вот Axure — достаточно сложный. Сегодня его чаще используют бизнес-аналитики для создания вайрфреймовГрубый набросок структуры продукта.

Иконки и графика

В идеале их все нужно выкачать и отдать разработчику одним архивом. В Figma и Adobe XD можно экспортировать каждую иконку, но если их будет очень много, то разработчику придется обходить по очереди все экраны, находить и кликать на каждую иконку. Поэтому лучше упростить ему задачу и позаботиться о соратнике по команде.

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

Отдельно стоит сказать о названиях графических элементов:

  • Для именования используйте только латиницу.
  • Не пишите английскими буквами украинские или русские слова.
  • Также не стоит использовать пробелы. Лучше замените их дефисами или нижним подчеркиванием.
  • А еще пригодятся префиксы для типа объекта: ic — для иконок, ill — для иллюстраций, pic — для фото.

Например, название иконки можно формировать по четкому принципу: ic, затем нижнее подчеркивание, место нахождения, нижнее подчеркивание и, собственно, что это за иконка. Получится вот такое: ic_main_catalog.

Шрифты 

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

Анимации 

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

Про CodePen скажу отдельно. Этот сервис предлагает огромный открытый архив с различными анимациями. Они называются пинами и — что самое важное — могут содержать код: HTML, CSS и JS (иногда все сразу, иногда только часть из них). Чтобы воспользоваться сервисом, достаточно ввести в поиске, например, «button», чтобы получить сотни вариантов анимации перехода от одного состояния кнопки к другому — и все со столь желанной разработчиками «кодовой» реализацией. Остается выбрать подходящий пин, скопировать ссылку на него и передать линк разработчику.


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

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

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

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Курс Fullstack Web Development.
Стань універсальним розробником, який може створювати веб-рішення з нуля.
Приєднатися

Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.

Топ-5 самых популярных блогеров февраля

Всего просмотровВсего просмотров
229
#1
Всего просмотровВсего просмотров
229
Всего просмотровВсего просмотров
209
#2
Всего просмотровВсего просмотров
209
QA в CodeGeeks Solutions
Всего просмотровВсего просмотров
156
#3
Всего просмотровВсего просмотров
156
Senior Project Manager at Nemesis
Всего просмотровВсего просмотров
99
#4
Всего просмотровВсего просмотров
99
Software Architect at Devlify
Всего просмотровВсего просмотров
95
#5
Всего просмотровВсего просмотров
95
Рейтинг блогеров

Ваша жалоба отправлена модератору

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: