Универсальный виджет комментариев: правила создания и кастомизации

В отделе продуктового дизайна сервисов Rambler&Co мы регулярно занимаемся поддержкой и развитием более дюжины медиа-площадок, каждая из которых имеет свой визуальный код.

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

О проблеме в целом

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

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

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

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

Краткая предыстория задачи

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

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

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

Вероятные проблемы

Задача определена, переходим к оценке возможных проблем для дизайнеров и разработчиков.

1. Легко поддаться искушению создать максимально нативный для каждой площадки дизайн.
   Если это случится, дизайнер впредь будет работать не над одним, а над десятком похожих, но все-таки разных продуктов, которые со временем начнут жить самостоятельно.
2. Разработчики будут тратить в разы больше времени на реализацию и поддержку.
   Кроме того, у них не сформируется понимания единых принципов продукта, что приведет к большему количеству ошибок при развертывании и последующей доработке виджета.
3. Менеджеру продукта нужно понимать, что виджет не создается для каждого проекта индивидуально, а следовательно, не может во всём соответствовать стилю площадки.
   Чрезмерная уступчивость со стороны дизайнера лишь увеличит давление со стороны заинтересованных проектов и неизбежно уведет ваш продукт от изначальной целостности.

А как надо?

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

1. Создайте «мастер-макет».
   Это может быть как индивидуальный макет для площадки, где предполагается использовать виджет чаще всего, так и «нейтральный» вариант.
   Определите композицию, элементы управления, соотношения элементов и так далее. Важно, чтобы в итоге у вас был полностью завершенный дизайн.
2. Определите элементы-константы.
   Эти параметры будут базой вашего дизайна и не изменятся ни при каких обстоятельствах.
   На эту роль лучше всего подойдут элементы, не несущие явной стилистической нагрузки: общая композиция, элементы управления, отступы, кегль и жирность шрифта.
   Также сюда входят элементы, которые сложно или нельзя кастомизировать: дизайн иконок, логотипы соцсетей.
3. Выберите элементы-переменные.
   Как правило, это будут стилеобразующие элементы площадки, которые заметны массовому пользователю: шрифтовая гарнитура, фирменный цвет, скругления у кнопок и так далее.
   Важно выбрать ограниченное количество переменных элементов — чем их больше, тем выше шанс запутаться и где-нибудь ошибиться. Также изменение этих переменных не должно затрагивать наши константы.
4. Проанализируйте целевые площадки.
   Соберите и организуйте значения выбранных переменных. Для удобства создайте таблицу — это поможет выявить недостающие или лишние переменные.
5. Примените собранные параметры в своём «мастер-макете».
   При необходимости скорректируйте значения элементов-переменных, если в «сыром» виде они смотрятся неудачно.
6. Сокращайте и оптимизируйте.
   Попробуйте найти те параметры переменных, которые можно применить к большему количеству адаптивных элементов без ущерба визуальному единству, то есть старайтесь не плодить сущности. Тем самым вы упростите дальнейшую работу и себе, и разработчикам.

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

На нашем примере

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

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

Константы:

• отступы и размеры элементов
• кегль шрифта, вес начертаний, итерлиньяж
• иконки, заглушки

Переменные:

• шрифтовая гарнитура
• акцентный цвет и его оттенки
• скругления

Подводные камни

И всё же в любом правиле есть исключения.
Например: нашей константой был набор размеров шрифта для заголовков, контролов, базового текста и т.д. Следовательно, любая другая гарнитура должна была быть использована именно в этих значениях. Однако на практике некоторым гарнитурам нужно было добавить хотя бы по 1–2 пункту к размеру шрифта, чтобы результат по своему «весу» соответствовал нашему «мастер-макету».

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

Помните, что вы не всегда сможете предугадать, в какой именно среде будет использоваться ваш продукт. Что, если у площадки будет не белый, а светло серый фон — как элементы интерфейса будут выглядеть на нём?

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

Выводы

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

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