Дизайн-долг платежом красен: улучшаем таблицы в большом продукте
Меня зовут Александра, я дизайнер из Ozon в SX — Seller Experience. Сегодня расскажу продуктовую историю о таблицах и дизайн-долге.
Иногда приходится работать с устаревшими системами, при этом ресурсов на улучшение нет, и поэтому новые доработки внедряются с минимальными изменениями. Каждая новая функциональность всё больше и больше усложняет систему, делая её сложной для использования, а новым сотрудникам тяжело вникать в проект (да, легаси бывает не только у разработчиков).
Так было и с нашим продуктом, который накопил много недочётов. Работа без компонентов усложняла внедрение нового как со стороны дизайна, так и со стороны фронтенда. От неконсистентности страдали и пользователи. Особенно плохи были дела с таблицами. Настолько, что пользователи вручную увеличивали страницу, чтобы найти горизонтальный скролл. Нагруженные таблицы — вечная боль, и ресурсов на возврат дизайн-долга и техдолга, как всегда, нет — новые фичи сами себя не спроектируют. Под катом наша история решения большой задачи с низким приоритетом.
Презентация
Команда собрала все критичные моменты в презентации. Акцент при этом сделали на том, что недочёты легко исправить, а также на том, что изменения качественно улучшат удобство сервиса. Кроме того, в презентации были предварительные макеты, которые показывали, каким удобным и современным мог бы стать продукт.
Мы стремимся развивать сильную дизайн-культуру. Это означает, что бизнес понимает важность удобного интерфейса. После презентации с UX-недочётами и прототипами нового варианта руководители одобрили развитие таблиц и формирование системы компонентов.
Команде разработки тоже понравилась эта инициатива. Раз в неделю мы начали созваниваться и передавали макеты в разработку. Мы договорились закладывать часть спринта на развитие компонентов. Но основная задача была переделать таблицы.
Дизайн-долг наслаивался постепенно или классическое «так сложилось исторически»:
Основная проблема у таблиц была с горизонтальным скроллом: нужно листать сначала вниз, а потом в сторону. Это критично, потому что иначе нельзя дотянуться до трёх точек в конце строк.
Громоздкие фильтры отбирали бóльшую часть рабочей области. По статистике, сервисом пользовались и с телефонов.
Если пользователи отфильтровывали таблицу и кликали на экспорт, то экспортировалась вся таблица без учёта фильтров.
Слишком высокие ячейки. В некоторых местах требовалось уменьшить высоту, чтобы пользователь мог работать с большим объёмом строк.
Сервис был не консистентный. Это плохо как для опыта пользователя, так и для разработки. Дизайнеры тратили много времени на макеты, а фронтендеры — на вёрстку.
На самом деле это довольно-таки частые проблемы с таблицами в крупных сервисах. Конечно, существует много теории на этот счёт, но сделать всё хорошо с первого раза очень сложно. В вёрстке всплывает много моментов, которые нельзя учесть в макетах.
Построение таблиц
Чтобы с таблицами было удобно работать и дизайнерам, и разработчикам, решили задать строгую систему. Теперь таблицы состоят из простых блоков — фильтра, ячеек хедера, обычных ячеек и пагинатора. Из этих элементов и собирается таблица.
Тестирование первой таблицы
Через некоторое время сверстали первый раздел с небольшой таблицей.
Дизайнеры и тестировщики прокликивали все состояния на разных разрешениях, а затем заводили баги. Ошибок было очень много, поэтому тестировали все. Что-то заезжало, где-то слетали эффекты при наведении, а что-то просто не учли. Например, поняли, что надо задать размеры ширин для ячеек. Так и появилась «Линейка» — по сути, наглядная спецификация.
Хеппи-энд
После того, как сверстали первую таблицу и исправили все недочёты, решили обновить все основные разделы с таблицами. Таким образом за полгода команда итерационно их улучшила. В них прекрасно всё: гармоничные отступы, удобные скроллы, лоадеры, скелетоны:
Что получилось сделать:
Теперь футер таблицы и колонка с действиями зафиксирована. Пользователям не надо тянуться до нижнего скрола, и искать заветные три точки в широкой таблице.
Продуман адаптив. Если пользователь увеличивает страницу вручную, всё масштабируется пропорционально. Некоторые наши пользователи так делают. Продумана и мобильная версия.
При настроенных фильтрах экспортируется только то, что отфильтровано. Раньше такого не было.
Теперь в таблице помещается 10 строк вместо 5. Это очень важно для тех, кто часто работает с сервисом.
И, конечно, теперь всё на компонентах. Меньше времени уходит на дизайн и вёрстку.
Команды фронтенда и дизайнеров работали в симбиозе. Мы ставили друг на друга задачи в Jira, созванивались раз в неделю и планировали дальнейшие шаги. Никто и не думал работать спустя рукава, и в итоге у нас сформировалась высокая планка качества работы, которой придерживаемся до сих пор.
План и что может пойти не по плану
Таблицы — значимый элемент в сложных B2B-продуктах. Они присутствуют почти на всех страницах, и, конечно, пользователь проводит с ними бóльшую часть времени. Улучшить таблицы — значит существенно улучшить удобство всего сервиса.
Если вы работаете с устаревшим сервисом, то теперь у вас есть пошаговый план действий по безболезненному улучшению продукта:
Проведите презентацию по основным моментам, над которыми собираетесь работать. Подсветите самые несуразные вещи. Хорошо, если в конце презентации представите красивый макет будущего сервиса.
Заручитесь поддержкой руководителей, возьмите небольшой кусочек и сделай его хорошо.
После тестирования нового раздела можно потихоньку переделывать основные разделы сервиса. Главное — маленькими шагами и итерационно.
Но любой план может пойти не по плану:
На первых порах не будет никакого результата и высок риск сдаться, так что ищите поддержки у других дизайнеров.
Руководство может быть против. Выявите главную причину несогласия и пробуйте работать с ней. Например, если они не хотят, чтобы продуктовые задачи задерживались, то оговорите, что будете двигаться маленькими шагами.
Или вы можете услышать мантру «Работает — не трогай», мол, есть риски не учесть в новом дизайне все нюансы и предыдущие решения. В этом случае можно предложить визуальный тюнинг (мы это ещё называем фейслифтинг).
Если видите, что что-то не удобно, но вам не приходит задача на исправление — не молчите. Ответственность за качество сервиса лежит на всей команде. Не бойтесь предлагать улучшения и будьте активным.
В статье я сосредоточилась на продуктовом процессе улучшения таблиц, но рекомендую и более теоретические статьи:
Игорь Штанг выпустил целый курс по работе с таблицами. Первая часть бесплатно.
Дизайн таблиц для чайников. Костя из AGIMA на простых примерах рассказал, как работать с данными в таблицах.
Таблицами занималась команда «Ozon Performance — рекламные технологии».
Больше продуктовых историй — в моём канале «Дело в дизайне» и нашем командном Telegram-канале Ozon Design.