Основы дизайна для верстальщиков

Содержание

• Состояния
• Обратная связь
• Технические страницы
• Системность макета
• Юзабилити и доступность
• Неполный дизайн

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

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

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

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

Состояния

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

Старт в Figma для верстальщика

Нет базовых состояний

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

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

Без ориентиров придется придумать состояния самостоятельно. Не стоит усложнять себе жизнь: используйте простые приемы, например, смену цвета или добавление прозрачности.

Нет более специфичных состояний

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

Как исправить → если нет фокуса для конкретного элемента, но есть для других — повторите этот фокус.

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

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

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

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

Обратная связь

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

Например, если мы нажали кнопку «загрузить», то на ней появится индикатор загрузки, оповещая о начале загрузки данных. Если бы индикатора не появилось, то это выглядело бы, словно что-то зависло или клик по кнопке не сработал.

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

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

Нет индикаторов загрузки

Индикаторы можно поделить на лоадеры и скелетоны. Лоадеры (от англ. load — загрузка) отображают во время загрузки чего-нибудь и показываются как на элементе, инициировавшим загрузку, так и в области, где ожидаются данные. Кроме того, лоадер может отражать процесс загрузки в процентах или только графически.

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

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

Нет сообщений об ошибке загрузки или отправки

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

Как исправить → добавить текст с сообщением о неудачной загрузке и, может быть, подходящую иконку. Хорошим решением будет добавить к сообщению кнопку, запускающую повторную загрузку данных.

Недостаточно оформления для валидации

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

Если для валидации расписано мало состояний, то не придумывайте дополнительные проверки. Ограничьтесь дополнением состояний для неверного заполнения.

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

Обязательно добавьте пояснительный текст: пользователь должен знать, что именно сработало не так.

Технические страницы

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

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

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

Системность макета

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

Разные отступы идентичных элементов

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

Как исправить → попробуйте вычислить среднее значение. Возможно, лучше будет выглядеть не среднее, а чуть большее или меньшее: тогда смело берите его. Можно пойти и еще дальше, и сделать отступы на сайте более логичными. Это получится сделать, если не требуется pixel perfect верстки.

Конечно, соблюдать вертикальный ритм не нужно, но сделать кратные отступы будет и удобнее в работе, и придаст виду сайта больше порядка. Используйте отступы, кратные определенному числу. Чаще всего это число 4 (для совсем мелких отступов 2, а для крупных, наоборот, 8).

То есть, нужно будет отступы из макета превращать в ближайшее значение, кратное 4-м: 5 => 4, 7 => 8, 10 => 12.

Слишком много размеров похожих элементов

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

Как исправить → сгруппируйте эти элементы. Близкие варианты объедините в один усредненный. Обычно в макетах можно выделить до 3-4 размеров элемента.

Слишком много размеров шрифтов

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

Как исправить → со шрифтами стоит быть как можно осторожнее. Постарайтесь не переусердствовать с сокращениями, действуйте только если размеров действительно много или отдельный текст выбивается из общего стиля. Будьте осторожны и с выбором размеров, которые останутся. Лучше округляйте в большую сторону — так читаемость текста точно не ухудшится.

Юзабилити и доступность

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

Здесь мы остановимся именно на доступности для пользователей интерфейсов, а не скринридеров.

Недостаточная контрастность

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

Что такое инструменты разработчика

Как исправить → подберите более контрастные цвета, пользуясь инструментами разработчика.

Текст неудобен для чтения

Обратите внимание на размеры шрифтов и высоту строки. Чтобы текст хорошо читался, размер шрифта не должен быть меньше 16 пикселей. Высота строки должна стремиться к соотношению 1.5 для текстов и 1.3 для заголовков.

Как исправить → если возможно увеличить размер шрифта, не навредив дизайну — сделайте это.

Высоту строки можно поставить в относительных единицах:
line-height: 1.5;. Так высота строки будет меняться вслед за размером шрифта.

Площадь элементов неудобна для взаимодействия

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

Как исправить → для тач-интерфейсов рекомендуется не делать интерактивных элементов менее, чем 40×40 пикселей. Для десктопа можно поменьше, но не увлекайтесь: если это не ссылка внутри текста, то хорошо бы сохранить минимальный размер хотя бы 32 на 32 пикселя.

А еще это хорошо работает вместе с использованием кратных размеров: они не только наведут порядок, но и приведут вас к привычным по размерам элементам.

Технические проблемы

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

Иконки не оптимизированы

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

Как исправить → придется научиться работать с вектором внутри Фигмы. Имеет смысл подогнать иконки под один размер, создать фреймы для экспорта и слить элементы вектора через flatten. Манипулирая иконками убедитесь, что случайно не исказили их.

Графика в разных слоях

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

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

Неполный дизайн

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

Но иногда других вариантов не остается.

Отсутствие адаптива

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

Как исправить → постарайтесь не усложнять себе жизнь. Выбирайте те решения, которые будет проще реализовать и которые надежнее работают. Используйте в качестве примера другие аналогичные решения, например, если вы уже делали мобильное меню на другом сайте — повторите известный вам приём.

Проблемы с переполнением

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

Как исправить → если никак не обойтись без переполнения, а дизайн его не предусматривает, то придется применить не самое удачное решение. Для элементов списочного типа можно добавить скролл внутри элемента, либо overflow-кнопку, которая покажет остальной контент. Иногда могут выручить всевозможные слайдеры и карусели.

Но, в итоге, в каждом случае нужно подходить индивидуально.

Итог

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

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