Универсальный виджет комментариев: правила создания и кастомизации
В отделе продуктового дизайна сервисов Rambler&Co мы регулярно занимаемся поддержкой и развитием более дюжины медиа-площадок, каждая из которых имеет свой визуальный код.
Как создать визуальный продукт, который можно легко адаптировать под любой проект, не растягивая разработку на месяцы? Делимся опытом в этой статье.
О проблеме в целом
Представьте, что вы просматриваете какой-нибудь сайт, на котором весь визуал гармоничен и прекрасен. Палитра, шрифтовые пары, иконки, кнопки — всё на своих местах в идеальном симбиозе.
Вы дочитываете интересную статью и уже хотите написать комментарий к ней, как вдруг — бам! На прекрасной картине образовалось отталкивающее пятно. Почему форма комментирования выглядит иначе? И шрифт другой, и размер у него неудачный, и цвета явно не с этого сайта пришли. Вот так выглядит неудачная встреча с неадаптированным виджетом.
Далеко не все разработчики используют собственноручно написанный функционал для таких популярных механик, как комментарии, голосования, чат-боты или формы обратной связи.
Для экономии времени и средств часто применяются сторонние решения, которые не всегда могут соответствовать духу интернет-площадки и сохранять плавность пользовательского опыта.
Краткая предыстория задачи
В прошлом году в рамках глобального редизайна продуктов Рамблера мы начали обновление нашего виджета комментариев. К тому моменту он уже использовался на десятке проектов, но существовал лишь в одном варианте: гарнитура, цветовая палитра и форма элементов на всех проектах были одинаковыми, за исключением акцентного цвета.
Раньше нейтральный стиль в целом выполнял свою задачу: виджет более-менее вписывался в визуал каждой площадки, не вызывая сильного диссонанса. Но со временем проекты Рамблера обрели индивидуальность, и в какой-то момент стало понятно, что виджет комментариев не позволяет сохранить на всех ресурсах целостный визуальный опыт.
Пришло время создать механизм персонализации виджета для каждой площадки.
Вероятные проблемы
Задача определена, переходим к оценке возможных проблем для дизайнеров и разработчиков.
- Легко поддаться искушению создать максимально нативный для каждой площадки дизайн.
Если это случится, дизайнер впредь будет работать не над одним, а над десятком похожих, но все-таки разных продуктов, которые со временем начнут жить самостоятельно. - Разработчики будут тратить в разы больше времени на реализацию и поддержку.
Кроме того, у них не сформируется понимания единых принципов продукта, что приведет к большему количеству ошибок при развертывании и последующей доработке виджета. - Менеджеру продукта нужно понимать, что виджет не создается для каждого проекта индивидуально, а следовательно, не может во всём соответствовать стилю площадки.
Чрезмерная уступчивость со стороны дизайнера лишь увеличит давление со стороны заинтересованных проектов и неизбежно уведет ваш продукт от изначальной целостности.
А как надо?
Как избежать этих проблем? Давайте сперва определим базовые принципы работы дизайнера над универсальным виджетом, а потом разберем их на конкретном примере.
- Создайте «мастер-макет».
Это может быть как индивидуальный макет для площадки, где предполагается использовать виджет чаще всего, так и «нейтральный» вариант.
Определите композицию, элементы управления, соотношения элементов и так далее. Важно, чтобы в итоге у вас был полностью завершенный дизайн. - Определите элементы-константы.
Эти параметры будут базой вашего дизайна и не изменятся ни при каких обстоятельствах.
На эту роль лучше всего подойдут элементы, не несущие явной стилистической нагрузки: общая композиция, элементы управления, отступы, кегль и жирность шрифта.
Также сюда входят элементы, которые сложно или нельзя кастомизировать: дизайн иконок, логотипы соцсетей. - Выберите элементы-переменные.
Как правило, это будут стилеобразующие элементы площадки, которые заметны массовому пользователю: шрифтовая гарнитура, фирменный цвет, скругления у кнопок и так далее.
Важно выбрать ограниченное количество переменных элементов — чем их больше, тем выше шанс запутаться и где-нибудь ошибиться. Также изменение этих переменных не должно затрагивать наши константы. - Проанализируйте целевые площадки.
Соберите и организуйте значения выбранных переменных. Для удобства создайте таблицу — это поможет выявить недостающие или лишние переменные. - Примените собранные параметры в своём «мастер-макете».
При необходимости скорректируйте значения элементов-переменных, если в «сыром» виде они смотрятся неудачно. - Сокращайте и оптимизируйте.
Попробуйте найти те параметры переменных, которые можно применить к большему количеству адаптивных элементов без ущерба визуальному единству, то есть старайтесь не плодить сущности. Тем самым вы упростите дальнейшую работу и себе, и разработчикам.
Впоследствии вы можете создать целые компоненты и менять заранее подготовленные значения переменных. Как видите, за несколько шагов мы проделали работу, которая при ином подходе могла бы занять в разы больше времени и привести к полному беспорядку.
На нашем примере
Вы познакомились с теоретической базой. Теперь рассмотрим ее применение на примере нашего нового виджета комментариев.
В первую очередь мы создавали виджет для медийных проектов Рамблера, где он востребован читателями новостей больше всего, так как структура и исходный визуал виджета прорабатывались сразу с учетом дизайна портала Рамблер.
Константы:
- отступы и размеры элементов
- кегль шрифта, вес начертаний, итерлиньяж
- иконки, заглушки
Переменные:
- шрифтовая гарнитура
- акцентный цвет и его оттенки
- скругления
Подводные камни
И всё же в любом правиле есть исключения.
Например: нашей константой был набор размеров шрифта для заголовков, контролов, базового текста и т.д. Следовательно, любая другая гарнитура должна была быть использована именно в этих значениях. Однако на практике некоторым гарнитурам нужно было добавить хотя бы по 1–2 пункту к размеру шрифта, чтобы результат по своему «весу» соответствовал нашему «мастер-макету».
Другой проблемой для нас стал слишком светлый оттенок акцентного цвета некоторых площадок, который нельзя было применить сразу и для текста, и для кнопок. Поэтому для мелких элементов пришлось подбирать альтернативные, более контрастные оттенки. Это добавило лишнюю сущность, но зато здорово улучшило пользовательский опыт.
Помните, что вы не всегда сможете предугадать, в какой именно среде будет использоваться ваш продукт. Что, если у площадки будет не белый, а светло серый фон — как элементы интерфейса будут выглядеть на нём?
В нашем случае для нейтральных светло-серых кнопок мы были вынуждены использовать полупрозрачный цвет вместо непрозрачной заливки, чтобы не вводить дополнительную переменную и избежать визуальное слияние элементов с фоном близкого цвета.
Выводы
Как видите, при создании универсального продукта нужно заранее выбрать те элементы, которые вы готовы и не готовы менять. В этой статье мы разобрали, как определить эти элементы.
На долгой дистанции такой подход обеспечит целостный образ вашего дизайна в разной среде в сочетании с органичной интеграцией в нее. Это поможет сократить нагрузку на всю команду, сохранит ресурсы и позволит поддерживать продукт на ещё большем количестве площадок.