Соавторы статьи:

@Alexandr_Lopatkin @mihail-lisin @Vlad_Design

Мы команда проектировщиков интерфейсов Экзона, а Экзон — это продукт для цифровизации строительства.

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

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

Оглавление

• Как мы поняли, что пора начинать редизайн

• Подготовили схематичный прототип

• Проработали разные концепции

• Протестировали и доработали финальный вариант

• Как редизайн повлиял на фронтенд

• Факапы

• Результат

Как мы поняли, что пора начинать редизайн

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

Экзон имеет свою архитектурную специфику, которую нужно учитывать:

• Продукт объединяет в себе функциональность нескольких продуктов, которые разбиты по модулям.

• Над каждым модулем работает отдельная команда аналитиков и фронтов.

• В каждом модуле свои пользователи, но есть и те, кто работает в нескольких модулях. 

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

Экзон обрастал сделанными на скорую руку решениями. Появлялись новые модули — их количество выросло с четырёх до восьми за три года. 

Функциональность постепенно разрасталась, и системой становилось всё сложнее пользоваться. Интерфейс начал напоминать франкенштейна из разрозненных решений.

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

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

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

Изначально интерфейс проектировали на компонентах MaterialUI, потому что разработчики работали с React и им это было удобно. От MUI решили не отказываться, но кастомизировать.

Редизайн разбили на этапы:

Этап 1

• Определиться с общей концепцией будущих изменений.

• Оптимизировать компоновку основных блоков лейаута и внедрить токены в Figma.

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

• Улучшить цветовую палитру.

Этап 2

• Переосмыслить шапку.
  

Этап 3 и последующие

• Пересобрать все формы на новых компонентах.

• Переделать сайдбары, тулбары и таблицы.

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

В статье разберём только второй этап и поговорим про шапку.

Подготовили схематичный прототип

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

Собрали все уникальные варианты шапки

Провели большое внутреннее исследование:

• Общались с аналитиками и разбирали модули, сценарии и состояния шапки.

• Изучили проблемы пользователей и коллег.

• Собирали предложения по улучшению интерфейса.

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

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

На этот этап ушёл примерно месяц и 30 часов созвонов.

Создали универсальный схематичный прототип

Цель этапа — выявить все уникальные состояния интерфейса и свести их в единый схематичный прототип.

1. Отсмотрели все видеозаписи с пользовательскими сценариями

2. Сделали скриншоты каждого уникального состояния шапки

3. Поместили скриншоты в один Figma-файл и структурировали

4. Создали схематичные прототипы каждого варианта

5. Наложили их друг на друга и сделали уникальную схему

6. Собрали единый схематичный прототип
   

Сначала нужно было найти разницу в логике всех навигаций.

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

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

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

Работали с референсами

В поисках вдохновения мы изучили сложные и нагруженные системы, такие как:

• Windows

• YandexCloud

• Notion

• GanntPro

• AirTable

• VK WorkDisc

Три системы лучше всего соответствовали нашему видению и задачам:

• Проводник Windows 11 — привычные десктопные паттерны подходили нам, так как большинство наших пользователей работают на Windows.

• YandexCloud — пример высоконагруженного веб-интерфейса с продуманной навигацией и архитектурой. Отличный образец компактного и удобного интерфейса.

VK WorkDisc — примечательная механика, где скрытые вкладки схлопываются в кебаб.

Референсы — это только отправная точка. Мы адаптируем их и дополняем собственными идеями, учитывая сложность и нишевость нашего продукта.

Проработали разные концепции

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

Аппбар

Сразу решили сделать аппбар вертикальным, чтобы освободить рабочее пространство. Решение простое и логичное, но с остальными организмами всё оказалось куда сложнее.

Хлебные крошки

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

Вариант со слешем, синим цветом и дропдаунами

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

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

Окрасили крошки в цвет ссылок, но синий отвлекал внимание от основного контента.

Зато в этом варианте родилась идея сиблингов. Сиблинги — это разделы одного уровня, которые открываются по клику на иконку рядом с названием. Термин быстро прижился в команде. Теперь мы используем этот компонент и в других интерфейсах.

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

Вариант, в котором добавили иконки

Сделали это для наглядности, чтобы разделить между собой разные сущности:

• Домик — это меню списка проектов

• Многоэтажка — паспорт проекта

• Кубики — модули

Вариант с кнопой «Назад»

В старой шапке была кнопка «Назад». И мы поначалу боялись её убирать, поскольку предполагали, что это уже привычный для пользователей паттерн. Ещё в этом варианте появилась кнопка с кубиками и дропдауном, она вызывает список модулей.

Ещё один странный вариант с кнопкой «Назад»

В этом варианте паттерн с кнопкой «Назад» сломали. При нажатии на неё выпадал список всех предыдущих страниц. От этого варианта отказались — он слишком неочевидный.

Финальный черновик

• Иконки превратили в кнопки — по нажатию на них выпадает список одноуровневых вкладок-сиблингов.

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

• Когда у раздела нет сиблингов, иконку не показываем.

• Убрали кнопку «Назад», чтобы не дублировать встроенный функционал браузера и разгрузить хлебные крошки.

Шапка страницы модуля

Сложности в проектировании шапки были на каждом шагу:

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

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

Пришлось проделать серьёзную работу. Процесс шёл одновременно с редизайном хлебных крошек, поэтому здесь тоже рассматривали их разные варианты. 

Вариант 1

Это первый черновой вариант с новым UI. Он показывает видение редизайна, но не учитывает всех технических особенностей. Мы показали его в рамках общей концепции на презентации для команды.

Вариант 2

Хлебные крошки спрятали в попап для компактности, но в таком варианте пользователи делают лишние клики.

Вариант 3

Здесь стремились к компактности и простой компоновке, но скрыли популярные пункты меню. Стало сложнее ориентироваться и снова приходилось делать лишние клики.

Вариант 4

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

Вариант 5

Эта последний концепт на уровне чернового драфтинга. Он компактный, в нём есть иконки и ничего не сбивает с толку. Он стал основным после Варианта 4, когда тот не прошёл тестирование.

Шапка страницы документа

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

При проектировании интерфейса опирались на базовую иерархию: слева направо, сверху вниз. Например, «Изменение» главнее «Версии», поэтому располагается левее. 

Вариант 1

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

Вариант 2

Здесь экспериментировали со вкладками справа. Сделали их не в виде отдельных кнопок, а наподобие вкладок браузера. Таким образом акцентировали активную вкладку. Этот вариант стал основным, его мы будем тестировать.

Вариант 3

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

Вариант 4

Вернули вкладки вправо. Часть данных скрыли под иконку «инфо», добавили кнопку копирования ссылки на страницу. Всё ещё получалось слишком нагружено и детально.

Вариант 5

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

Протестировали и доработали финальный вариант

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

• Пройти все сценарии в своих модулях

• Проверить логику и совместимость с бизнес-процессами

• Дать нам обратную связь

(Не) финальный концепт

Обратная связь от аналитиков обнадёжила — всё работает, важных кейсов не потеряли.

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

Стало понятно, что этот вариант никуда не годится, только когда фронты показали его на тестовом стенде. Из-за разного размера пункты меню прыгали при переключении вкладок. В итоге отказались от этого решения, хоть и с запозданием.

Доработанный концепт

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

Структурно этот вариант нас полностью устраивал. Однако визуальная связь между меню первого и второго уровня казалась слабой — элементы выглядели как сваленные в кучу. Начали дорабатывать UI, чтобы сделать структуру более наглядной.

Рабочая версия

Докрутили UI и связали меню первого и второго уровня. Но шапка стала слишком акцентной и перетягивала внимание. А ещё серый текст плохо считывался на бледно-синем фоне.

Чистовой вариант

Убрали синий акцент с шапки и аппбара, при этом выдержали контрастность текста на сером фоне. Этот вариант успешно прошёл все тесты, мы его дошлифовали и наконец-то отдали в разработку.

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

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

Новый дизайн шапки затронул не только визуальную часть, но и логику фронтенда.

Универсальный роутинг

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

Адаптив

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

Почему не стали делать мобильную адаптацию

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

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

Факапы

Отдали в разработку кривую шапку

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

На тестовом стенде всё встало на свои места: решение оказалось провальным. Интерфейс получился дёрганным из-за разных размеров активной вкладки и остальных. Пришлось всё откатывать и переделывать.

Проблемы с процессом

Мало обратной связи

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

Пролетели по срокам

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

Сломанный телефон

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

Результат

Аппбар

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

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

Также избавились от висящей справа внизу кнопки «помощи». Её переместили в отдельный пункт внутри аппбара. 

Было

Стало

Хлебные крошки

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

Позже мы создали специальный шрифт и заменили иконки в хлебных крошках на спецсимволы. Это помогло избежать проблем с масштабированием интерфейса. 

Было

Стало

Шапка страницы модуля

Решили главную задачу — освободили пространство под контент. Сократили его с 235 до 88 пикселей, то есть в 2,5 раза.

Важные элементы выделили, а лишние — удалили. Внутренние элементы шапки переработали и сделали более компактными.

Было

Стало

Шапка страницы документа

• Исправили ошибки в архитектуре интерфейса продукта.

• Выстроили логичную и понятную последовательность элементов.

• Заменили текстовые обозначения разделов на иконки

• Упростили вёрстку.

Было

Стало

Заключение

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

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

Благодарим участников:

Влад Назаров — отвечал за шапку и навигацию. Проделал огромную работу по систематизации и проектированию.  

Михаил Лисин — курировал аппбар и дизайн-систему. Следил за тем, чтобы все решения были согласованными и целостными.  

Владимир Калинин — руководитель отдела. Помогал команде и направлял её.  

Александр Лопаткин — проектировщик интерфейсов и автор этой статьи. Обобщил опыт команды и изложил его в этом материале.

Доводилось ли вам решать подобные задачи?

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

Соавторы статьи:

@Alexandr_Lopatkin @mihail-lisin @Vlad_Design