Как сетка ухудшила UX

Как сетка ухудшила UX

Автор: Саша Окунев Уровень: для профи

image

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

Я делаю систему управления товарами Озона, и в этом мне помогает замечательный дизайнер Андрей Ковалёв. Без его вклада этой системы бы не получилось.

В самом начале проекта мы задались вопросом, какое разрешение используют наши контент-менеджеры, чтобы на основе него понять стандарт ширины для наших макетов. Выяснил, что у нас в офисах Москва Сити и ещё одном городе с компьютерами всё хорошо: мониторы имеют разрешение минимум 1920 по ширине, а у некоторых вообще 4K. Поэтому, я стремился сделать систему, которая выгодно смотрится в первую очередь на больших экранах.

Проблемы больших экранов

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

За эту небрежность к типографике я недолюбливаю дизайн Confluence и Slack, дизайнеры которых не обращают на длину строки никакого внимания и отводят контенту столько места, сколько есть на экране:

Slack: когда ширина экрана становится злом.
Slack: когда ширина экрана становится злом.

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

Полосу текстового набора нужно контролировать по ширине и не допускать ситуации, когда в одной строке больше 10-12 слов.

Подход бесконечно тянущейся вёрстки хорошо работает только в интерфейсах, где на первый план выходит работа с медиа: редакторах вроде Figma, Cinema 4D, Premiere Pro и подобных. В парадигме интерфейса-редактора он является единственно возможным вариантом. Рабочая область в нём получает максимум пространства, а различные панели жмутся по краям, стремясь быть как можно меньше. В таких продуктах не может быть мест, где встречаются широкие полосы.

1560/12

Наша сетка имела максимальную ширину модульной системы в 1560 px, после которой 12-колонник переставал растягиваться по ширине и красиво держал форму по центру экрана, образуя пустоты по бокам. Вёрстка при этом смотрелась плотно и подтянуто. 12-колонник — мощное оружие. Он сразу вносит порядок в поведение блоков при изменении ширины окна.

Подход 1560/12 работал в банке, где никогда не было большого количества контента. Всего в вёрстке было два основных блока: слева сайдбар для вертикального меню банковских продуктов, справа основная страница текущего продукта и ленты его операций.

Вёрстка одной из версий интернет-банка на 1920px: просторная, и при этом собранная. Отступы между модулями здесь и далее — 24px.
Вёрстка одной из версий интернет-банка на 1920px: просторная, и при этом собранная. Отступы между модулями здесь и далее — 24px.

Поскольку 12-колонник хорошо себя проявил в банке, я взял его за основу и в CMS.

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

Я посчитал, что занимать всю ширину экрана избыточно. Однако, не взял в расчёт, что интерфейс CMS трёхколонный, а товары, которые в нём фигурируют, имеют больше свойств, чем есть у банковских операций в аналогичном списке. При этом нужно демонстрировать контент с максимальной плотностью. Свойства товаров одновременно должны быть видны в списке, чтобы контент-менеджер мог отличать друг от друга похожие товары, не кликая на карточку. Кроме того, у них есть потребность много работать с большими текстовыми описаниями товаров в карточках. Максимальной ширины в 500 px, которую давала вёрстка в 4 колонки сетки 1560/12, для работы не хватало.

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

Как исправлял ситуацию

1. Ручная настройка ширины блоков

Контент-менеджеры просили её в первую очередь и она выйдет в ближайших версиях системы. Отступы между белыми блоками можно будет перетаскивать.

Некоторые технические подробности

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

2. Тогл для категорий и фильтров

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

Скрываемый блок слева освободил пространство.
Скрываемый блок слева освободил пространство.

3. Сетка на максимум ширины

Для больших экранов на 1920 px мы расширили сетку до 1840 px, что дало почти 600 px на карточку товара на трёхколоннике. На широких местах, где есть тексты, ширину полосы ограничиваем не белым блоком, а через max-width.

Избавились от пустот по бокам, отдали максимум пространства контенту.
Избавились от пустот по бокам, отдали максимум пространства контенту.

icon
Подпишись на /designer — канал, паблик и образовательный сайт о дизайне интерфейсов. О Фигме, других инструментах, дизайн-менеджменте и работе продуктового дизайнера в корпорациях.

Выводы

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

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

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

Старый добрый Mobile First никто не отменял. Всегда стоит начинать проектировать от меньшей ширины к большей, даже если не предполагается мобильной версии. Считаю, что оптимальной шириной макетов для админок остаётся 1280 px, как бы ни хотелось её увеличить. Для лендингов она может быть побольше.

Наверх: