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

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

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

Презентация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хеппи-энд

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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