Как я делала редизайн крупного синего новостного издания

Лавировать между обновлением дизайна и легаси было сложно, но мы с командой справились. Проектировала интерфейсы по принципу Mobile First, создавала и поддерживала большую дизайн-систему и многое другое
UX
UI
User flow
Дизайн-система
NDA
Назад

Погружаю в контекст

Задача: сделать навигацию сайта более понятной и создать новый визуальный код

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

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

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

  • переосмыслить визуальный код продукта;
  • пересобрать навигацию;
  • упростить взаимодействие с большой архитектурой;
  • создать более цельную и масштабируемую систему интерфейсов.

До CRT клиент уже обращался к другой команде, но в итоге выбрал нашу комманду для реализации проекта.

Продолжительность проекта: около 8 месяцев.

Ограничения проекта

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

1. Существующая продуктовая логика

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

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

Как решили:
Мы не пытались механически заменить старый интерфейс новым. При проектировании каждого раздела учитывали существующую структуру продукта и постепенно адаптировали её под новый визуальный и UX-подход.

2. Совместимость нового дизайна с существующей системой

У клиента уже были работающие библиотеки и инструменты, через которые команда управляла контентом и интерфейсом портала. Поэтому новый дизайн должен был работать не только в Figma, но и в реальной системе.

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

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

Моя роль и задачи

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

Я занималась:
  • развитием дизайн-системы;
  • проектированием рубрик и ленты;
  • разводящих страниц;
  • адаптацией страниц под разные разрешения;
  • подготовкой макетов к вертстке.

Проектирование велось по принципу mobile first: сначала команда собирала и согласовывала решения на мобильных разрешениях, после чего адаптировала их под остальные устройства.

Что было на входе

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

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

Среди них были, например:
  • компонента тестов и опросов;
  • date picker и календарь;
  • галерея и открытие контента в lightbox;
  • карточки изданий и авторов;
  • переиспользуемые компоненты items;
  • и другие компоненты, необходимые для новых разделов портала.

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

Работа над страницами

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

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

После согласований с клиентом некоторые решения приходилось пересматривать и искать новые варианты.

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

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

У клиента было собственное представление о том, как должны работать и выглядеть отдельные части продукта. При этом многие сценарии требовали пересмотра или проектирования с нуля.

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

Пример одного флоу: сделать контактную информацию на региональных станицах более заметной

На региональных главных страницах — например, для Санкт-Петербурга и Северо-Западного округа — была размещена контактная информация редакции.

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

Задача

Найти решение, при котором контактная информация:
  • остаётся заметной;
  • не конкурирует с основным контентом страницы;
  • доступна на разных разрешениях;
  • органично вписывается в новую систему интерфейса.

Решение

Я спроектировала разные варианты размещения в зависимости от размера экрана.

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

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

Пример другого флоу: разводящая страница выпусков газет

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

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

Что нужно было учесть

Непредсказуемый контент
У архивных выпусков могли быть очень длинные заголовки. Сокращать их нельзя было: заголовок приходил из backend в готовом виде и должен был отображаться полностью.

Несколько действий внутри одной карточки
Карточка должна была одновременно позволять:
  • открыть все новости конкретного выпуска;
  • скачать выпуск;
  • в дальнейшем — скачать отдельные полосы, а не только весь выпуск целиком.

Причём возможность скачивания отдельными полосами выяснилась уже в процессе разработки сценария.

Что это изменило

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

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

Что это изменило

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

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

Результат

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

Пример из дизайн-системы: календарь и date picker

В процессе разработки новых разделов понадобился календарь с возможностью выбора даты и периода.

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

Что должен был поддерживать компонент

Пользователь должен был иметь возможность:
  • выбрать конкретную дату;
  • выбрать период;
  • быстро выбрать период за сегодня, неделю, месяц или год;
  • отдельно настроить месяц и год.

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

Результат

Вместо адаптации готового компонента я спроектировала календарь и date picker с нуля. При проектировании учитывала не только основной сценарий выбора даты, но и различные состояния компонента и комбинации действий, чтобы он мог использоваться в разных разделах продукта.

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

Итоги

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

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

Что мне удалось сделать

  • разработать новые разделы новостного портала;
  • расширить UI-kit;
  • создать новые компоненты для дизайн-системы;
  • адаптировать решения под mobile, tablet и desktop;
  • проработать сценарии с учётом реальных данных backend;
  • подготовить решения к production.

Что я вынесла из проекта

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

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

Для меня это был переход от проектирования отдельных интерфейсов к работе с системой продукта в целом.
Made on
Tilda