О чём нужно помнить, когда готовишь прототип к разработке
Дизайнеру важно уметь работать с другими специалистами, которые занимаются тем же продуктом: например, с менеджерами или разработчиками. Один из этапов работы, на котором чаще всего возникают проблемы в коммуникации, — это передача прототипа в разработку.
Ошибки, которые допускают дизайнеры, отдавая макеты разработчикам, могут быть связаны как с жёсткими, так и с гибкими навыками. К первым относится умение работать в графическом редакторе (например, в Figma), а ко вторым — умение выстроить коммуникацию и довести проект до конца. Артём Разиньков, наставник на курсе «Дизайнер интерфейсов» в Яндекс.Практикуме рассмотрел самые распространённые ошибки и подготовил инструкцию о том, как их избежать.
Ошибки, связанные с жёсткими навыками
Непонятные названия слоёв
Начинающие дизайнеры часто называют слои случайным образом и оправдывают это тем, что смотрящий и так всё поймёт. Так в прототипах появляются названия вроде “Frame 185” или “Rectangle 5”. А у разработчиков, которые их видят, возникает резонный вопрос: «Что это за слой, к чему он относится и за что отвечает?» К тому же, если дизайнер не укажет точное название, разработчику придётся самостоятельно придумывать текст для поля alt-text при загрузке на сервер.
Чтобы не тратить своё время на объяснения того, к чему относится “Rectangle 5” и почему он ни в коем случае не должен выходить за пределы “Frame 185”, давайте слоям понятные и информативные названия. Например, если это фотография человека, то назовите слой с ней person-pic, а если это кнопка — button.
Если вы работаете с компонентами и используете Variants, то вам важно соблюдать иерархию в атрибутах компонентов, когда вы придумываете их описания. Сначала может идти версия, к которой относится элемент, затем — название компонента без указания состояния, и только потом его состояние на выбор (активен он или нет).
В этом случае описания должны выглядеть так:
Название: Primary-Button
Вид: Desktop
Размер: 48
Состояние: hover, active или default
Иконка: none, left, right, both
Текст: true или false
Не представлены различные состояния элементов
Если дизайнер забудет отрисовать основные состояния кнопок, ссылок и других элементов (например, как они изменяются после нажатия пользователя), то получившийся макет будет не очень наглядным. В таком случае разработчику придётся уточнять, как каждый объект ведёт себя при нажатии или подведении курсора, — и это сильно затянет работу.
Чтобы так не происходило, продумывайте и отрисовывайте все основные состояния элемента: по умолчанию (default), при наведении (hover) и по нажатию (onclick). Когда вы добавляете ссылку, то обязательно добавьте её состояние после того, как пользователь по ней перейдёт (visited). А если в прототипе есть переключатель или радиокнопка, то нужно придумать, как этот элемент будет выглядеть в неактивном состоянии (disabled).
Нет порядка в иерархии слоёв
Новички считают, что порядок слоёв в макете ни на что не влияет. Но это не так: если в макете кнопки располагаются снизу вверх, а в списке слоёв — как попало, то верстальщику придётся потратить лишнее время, чтобы понять структуру, которую задумывал дизайнер.
В Figma новые слои по умолчанию располагаются над предыдущими. Если вы добавили в прототип заголовок, а затем поставили над ним фотографию, то в списке слоёв заголовок будет стоять под фото. Старайтесь сразу поддерживать правильную иерархию слоёв, чтобы перед передачей прототипа в разработку не тратить время на наведение порядка в макете.
Дробные значения в размерах слоёв
Дизайнеры могут случайно пропускать дробные значения в размерах слоёв. Так часто происходит, когда в макет вставляют векторные иллюстрации или когда в Figma отключена привязка к пиксельной сетке.
Дробные значения ― это не всегда критично. Но если дроби окажутся, например, в размерах карточки товара, то на странице каталога может появиться горизонтальный скролл, и его станет неудобно просматривать.
Если вам нужно поработать без привязки к пикселям, то отключите параметр “Snap to pixel grid” в настройках Figma. При этом объект, в параметрах которого есть дробные значения, лучше обернуть в ещё один фрейм, который в свою очередь будет выровнен по сетке. Такой приём часто используется при рисовании иконок.
Для того, чтобы в вашем проекте не было дробных значений:
— Выравнивайте объекты по пиксельной сетке. Это можно быстро сделать при помощи плагина Pixel perfect.
— Включите привязку к пиксельной сетке и масштабируйте объекты, зажав Shift. Figma сама округлит дроби до целых значений.
— Старайтесь указывать только целые значения в размерах слоёв и отступах между ними.
Для удобства используйте в работе классический четырёхпиксельный модуль. Модульный дизайн последователен и предсказуем. Когда все значения чётные, интерфейс намного проще масштабировать. Некоторые дизайнеры используют пятипиксельный модуль — но это требует большей подготовки и опыта.
Важно помнить, что в коде могут встречаться дробные значения, даже если их не было в итоговом макете. Такое случается, когда макет готовят только для одного устройства (например, десктопа), а адаптацию под устройства с меньшим разрешением оставляют на усмотрение верстальщика — это нормально.
Неправильное оформление текстовых боксов
Некоторые дизайнеры растягивают текстовые боксы вручную вместо того, чтобы настроить высоту строки. Разработчикам неудобно работать с такими текстовыми блоками: потому что в вебе не принято фиксировать высоту контейнеров. Чаще всего их размер зависит от объёма текста, а высота всего текстового блока — от высоты строки в нём (line-height). Поэтому не рекомендуется растягивать текстовые боксы вручную, лучше настраивать высоту строки набора (line-height) и отступы между абзацами (paragraph spacing) в специальном поле в Figma.
У хорошо проработанных (например, Inter, Montserrat и Helvetica) и системных шрифтов (например, Times New Roman и Georgia) лучше вовсе не менять высоту строки, а оставлять значение по умолчанию (auto). А если вам нужно настроить интерлиньяж вручную, то следите, чтобы текстовые блоки не выступали за колонку текста.
Ещё одна распространённая ошибка: когда дизайнер отбивает отступы между абзацами, нажимая на Enter. При переносе такого текста в вёрстку появляются «фантомные» абзацы, и верстальщику приходится удалять их вручную. Чтобы не создавать им лишнюю работу, используйте между абзацами специальный отступ: в Figma он настраивается прямо под полем для настройки межстрочного расстояния.
Доминирующая сетка
Новички боятся выходить за пределы сетки, думая, что это запрещено или нежелательно. Из-за этого они могут отказаться от простых и очевидных решений в пользу более сложных и неэффективных, но попадающих в сетку. Например, из-за слепого повиновения колонкам и отступам не всегда получится красиво оформить фоновую иллюстрацию для страницы или добавить карусель фотографий на всю ширину экрана. Смотрящему будет казаться, что эти элементы заперты внутри основного контейнера.
Чтобы такого не случалось, не бойтесь выходить за границы сетки, когда это необходимо. Хороший пример такого подхода — это главная страница Яндекса.
На ней есть центральная колонка в 960px, внутри которой расположены строка поиска, новости, прогноз погоды и другие элементы. По бокам от неё есть блоки, которые выходят за пределы сетки: локация, дата, почта и мессенджер. Такое решение обусловлено тем, что главная функция этой страницы — поиск, и поэтому он находится в центре. А дополнительные элементы спокойно расположились по краям: они не мешают пользователю, но если вдруг окажутся нужны, то они рядом.
Ошибки дизайнеров, связанные с гибкими навыками
Страх перед использованием готовых решений
Представьте, что перед вами стоит задача запустить продажу новой модели телефона через пять дней. В таком случае не получится две недели рисовать дизайн веб-страницы, а потом ещё неделю его согласовывать. Вместо этого можно, например, собрать сайт на Tilda и быстро сделать его доступным для покупателей.
В крупных компаниях есть библиотеки с готовыми шаблонами, на основе которых они собирают лендинги. Если страница нужна надолго, то только в этом случае они приглашают разработчика и делают кастомный дизайн.
При поиске решения, важно отталкиваться от задачи, а не от технологий, и не стесняться использовать готовые решения, библиотеки и UI-киты. Не все решения должны быть уникальными. Вероятность того, что подобную задачу уже решали до вас, очень высокая. Поэтому прежде чем изобретать что-то с нуля, посмотрите, нет ли более простого, быстрого и дешёвого способа.
Однако есть важный нюанс: прежде чем взять чей-то шрифт, иконки или фотографии, убедитесь, что они доступны по открытой лицензии — Common Creatives (CC). Так вы обезопасите себя и клиента от судебных разбирательств и больших штрафов за нарушение авторских прав. Бесплатные шрифты можно взять на Google Fonts, иконки — на Flaticon, а фотографии — на Unsplash.
Желание с первой попытки подготовить финальный дизайн
Всегда выполняйте работу поэтапно, чтобы она в каждый момент времени «была готова». Сейчас нарисовать модный интерфейс (UI) стало довольно легко: можно подобрать любые цвета в специальном генераторе палитр Adobe Color, удачные шрифтовые пары взять на Google Fonts или Type Wolf, а градиенты — на Webgradients. Намного сложнее продумать бизнес-логику и путь пользователя на сайте – то есть UX. Это требует больших усилий и развитых аналитических и коммуникативных навыков.
Поэтому всегда начинайте проработку дизайна с UX. Это поможет отсеять слишком сложные идеи и не перегрузить проект ненужными функциями. Если вы не склонны к перфекционизму, то попробуйте нарисовать прототипы на бумаге или на доске и сразу покажите их разработчику. Это можно сделать в любое время, например, за обедом или во время перерыва, и тут же получить обратную связь.
Страх или нежелание общаться с разработчиками
Из-за недостатка общения может возникнуть ситуация, когда дизайнер придумал решение, принёс его разработчику, и выяснил, что оно нежизнеспособное: на разработку уйдёт полгода, а потом ещё месяц — на тестирование.
Для того, чтобы вам не пришлось выбрасывать или переделывать готовый прототип, важно:
— Подключать разработчика к проекту заранее. Лучше всего привлекать его на встречу с клиентом после этапа аналитики и сбора первичных требований.
— Не бояться общаться с разработчиком и задавать вопросы. Показывайте им вайрфреймы или отдельные блоки, уточняйте и задавайте открытые вопросы: «Можно ли такое сделать или нет? Если нет, то почему? Если да, то насколько это сложно и сколько времени займёт?» Спрашивайте до тех пор, пока не поймёте, какое решение будет оптимальным в вашей ситуации.
Говорить с разработчиками на одном языке. В ходе проекта важно помнить, что технические специалисты решают ту же задачу, что и вы. Только вы делаете это с помощью графики и визуальных инструментов, а разработчики — с помощью кода. Чтобы говорить с разработчиком на одном языке и понимать его требования, изучите базовые принципы вёрстки в вебе, логику HTML, CSS и то, как работают анимации.
Боязнь презентаций
Неопытные дизайнеры боятся презентовать свою работу заказчику и поэтому часто совершают такую ошибку: отправляют результат по почте или в мессенджере и просят заказчика на него посмотреть. Заказчик смотрит и грозно пишет: «Мне не нравится!». А дизайнер не понимает, как продолжать разговор после такого ответа.
Презентовать проект клиенту — страшно, особенно если вы в дизайне недавно. Но похоронить классный проект плохой презентацией — ещё страшнее. Новичкам важно учиться рассказывать о том, что вы сделали, объяснять ход мысли — это тоже часть работы дизайнера.
Чтобы меньше волноваться перед клиентом, можно потренироваться на своей команде. Соберите всех вместе и выберите человека, который будет играть роль клиента и задавать вопросы.
Если нужно объяснить, как вы пришли к решению, а времени на полноценную презентацию нет, то можно записать скринкаст. Сделать это можно с помощью Loom, OBS или Zoom, запустив конференцию с самим собой и начав запись экрана. Опишите, что и как работает, покажите, как прототип решает проблемы, которые обозначил клиент или которые вы выявили в ходе аналитики.
Расскажите, какие мысли возникали у во время работы над задачей, и почему вы предлагаете именно такое решение. Это избежать вопросов вроде: «А почему вот эта кнопка фиолетовая, а та, что рядом — белая?» Будет хорошо, если после презентации или скринкаста у разработчика или клиента не останется вопросов к вам. Но если они появляются, то всё равно не стоит волноваться: это дополнительный повод поразмышлять над своим решением и сделать его ещё лучше.