Меня зовут Александра, я дизайнер из Ozon в SX — Seller Experience. Сегодня расскажу продуктовую историю о таблицах и дизайн-долге.

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

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

Страница Ozon Performance осенью 2021 года. Трудно прокрутить по горизонтали, чтобы увидеть остальные колонки
Страница Ozon Performance осенью 2021 года. Трудно прокрутить по горизонтали, чтобы увидеть остальные колонки

Презентация

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

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

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

Команде разработки тоже понравилась эта инициатива. Раз в неделю мы начали созваниваться и передавали макеты в разработку. Мы договорились закладывать часть спринта на развитие компонентов. Но основная задача была переделать таблицы.

Дизайн-долг наслаивался постепенно или классическое «так сложилось исторически»:

  1. Основная проблема у таблиц была с горизонтальным скроллом: нужно листать сначала вниз, а потом в сторону. Это критично, потому что иначе нельзя дотянуться до трёх точек в конце строк.

  2. Громоздкие фильтры отбирали бóльшую часть рабочей области. По статистике, сервисом пользовались и с телефонов.

  3. Если пользователи отфильтровывали таблицу и кликали на экспорт, то экспортировалась вся таблица без учёта фильтров. 

  4. Слишком высокие ячейки. В некоторых местах требовалось уменьшить высоту, чтобы пользователь мог работать с большим объёмом строк.

Сервис был не консистентный. Это плохо как для опыта пользователя, так и для разработки. Дизайнеры тратили много времени на макеты, а фронтендеры — на вёрстку. 

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

Старые таблицы. Справа спрятаны ещё колонки, а в конце — заветные три точки с действиями
Старые таблицы. Справа спрятаны ещё колонки, а в конце — заветные три точки с действиями

Построение таблиц 

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

Захотелось кликнуть в сторону, чтобы снять выделение? Так ведь? :) Здесь компонент фильтра и компоненты большой и маленькой таблицы. Дизайнер копирует в свой проект, настраивает, а затем открепляет, чтобы вставить нужные ячейки. Практика показала, что это удобно
Захотелось кликнуть в сторону, чтобы снять выделение? Так ведь? :) Здесь компонент фильтра и компоненты большой и маленькой таблицы. Дизайнер копирует в свой проект, настраивает, а затем открепляет, чтобы вставить нужные ячейки. Практика показала, что это удобно
Компоненты ячеек
Компоненты ячеек
Компонент пагинатора и списка действий
Компонент пагинатора и списка действий
Макеты новой таблицы, полностью свёрстанной на AutoLayout по заданным гайдлайнам системы
Макеты новой таблицы, полностью свёрстанной на AutoLayout по заданным гайдлайнам системы
Компонент новой таблицы. Пагинатор меняется на блок с действиями при выделении строк
Компонент новой таблицы. Пагинатор меняется на блок с действиями при выделении строк

Тестирование первой таблицы

Через некоторое время сверстали первый раздел с небольшой таблицей.

Первая таблица, свёрстанная по новым гайдам
Первая таблица, свёрстанная по новым гайдам

Дизайнеры и тестировщики прокликивали все состояния на разных разрешениях, а затем заводили баги. Ошибок было очень много, поэтому тестировали все. Что-то заезжало, где-то слетали эффекты при наведении, а что-то просто не учли. Например, поняли, что надо задать размеры ширин для ячеек. Так и появилась «Линейка» — по сути, наглядная спецификация.

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

Хеппи-энд

После того, как сверстали первую таблицу и исправили все недочёты, решили обновить все основные разделы с таблицами. Таким образом за полгода команда итерационно их улучшила. В них прекрасно всё: гармоничные отступы, удобные скроллы, лоадеры, скелетоны:

Новые таблицы. Здесь прекрасно всё: отступы, удобные скроллы, лоадер, скелетоны
Новые таблицы. Здесь прекрасно всё: отступы, удобные скроллы, лоадер, скелетоны

Что получилось сделать: 

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

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

  3. При настроенных фильтрах экспортируется только то, что отфильтровано. Раньше такого не было. 

  4. Теперь в таблице помещается 10 строк вместо 5. Это очень важно для тех, кто часто работает с сервисом.

  5. И, конечно, теперь всё на компонентах. Меньше времени уходит на дизайн и вёрстку.

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

План и что может пойти не по плану

Таблицы — значимый элемент в сложных B2B-продуктах. Они присутствуют почти на всех страницах, и, конечно, пользователь проводит с ними бóльшую часть времени. Улучшить таблицы — значит существенно улучшить удобство всего сервиса. 

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

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

  • Заручитесь поддержкой руководителей, возьмите небольшой кусочек и сделай его хорошо. 

  • После тестирования нового раздела можно потихоньку переделывать основные разделы сервиса. Главное — маленькими шагами и итерационно. 

Но любой план может пойти не по плану: 

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

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

  • Или вы можете услышать мантру «Работает — не трогай», мол, есть риски не учесть в новом дизайне все нюансы и предыдущие решения. В этом случае можно предложить визуальный тюнинг (мы это ещё называем фейслифтинг). 

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

В статье я сосредоточилась на продуктовом процессе улучшения таблиц, но рекомендую и более теоретические статьи:

  1. Подборка про верстку таблиц от Бюро

  2. Михаил Греков. UX таблиц, с которыми работают

  3. Игорь Штанг выпустил целый курс по работе с таблицами. Первая часть бесплатно.

  4. Дизайн таблиц для чайников. Костя из AGIMA на простых примерах рассказал, как работать с данными в таблицах.


Таблицами занималась команда «Ozon Performance — рекламные технологии».

Больше продуктовых историй — в моём канале «Дело в дизайне» и нашем командном Telegram-канале Ozon Design.

Комментарии (6)


  1. Vorchun
    28.12.2022 15:02
    +2

    В целом, собрали все лучшие практики.

    Но меня лично всегда интересовал такой вопрос. У нас есть 40 записей. Пусть будет по 20 на странице, т.е. 2 страницы. Считаем, что смотрим таблицу с ноутбука и по высоте она вся не помещается в окно браузера.

    Мы находимся на первой странице. Докручиваем таблицу вниз до конца. Увидели разделитель на страницы. Нажали на ссылку для перехода на вторую страницу.

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

    И вот какой вариант лучше не знаю.


    1. alexcicsav Автор
      28.12.2022 16:51

      Вообще вопрос хороший. Я бы тут отталкивалась от ресурсов разработки и дизайн. Но в первую очередь от разработки)

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

      Мы не смогли сделать анимацию, а инфинити скрол никто из других разделов не делал тогда. Так что сделали, как на видео. Вроде с фиксированным хедером и футером пользователи все понимали.


      1. Vorchun
        28.12.2022 17:00

        В таких табличных формах бесконечный скролл беда. Пользователи хотят работать со страницами. Это нормально. Такой скролл не выход.

        Возможно, я бы предложил не анимацию прокрутки, а прелоудер. И после него открытие первого пункта.

        Технически прокрутить в начало на первый элемент второй страницы несложно. Вопрос скорее эстетики.


        1. alexcicsav Автор
          28.12.2022 17:24

          Звучит разумно. Возможно, так и стоило сделать.


        1. FrolVII
          29.12.2022 00:34

          В таких табличных формах бесконечный скролл беда

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


          1. Vorchun
            29.12.2022 09:10
            +2

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

            Если вы работаете со списком клиентов в ЦРМ - тут уже 50/50.

            Если у вас условная 1С и вы работаете со списком заказов - по страничная навигация удобнее.

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

            Также постраничная (точнее ссылка на состояние листинга) нужна, если вы хотите поделится этим списком с кем-то. С бесконечным скроллом это затруднительно.