Как улучшить UX в устаревших системах

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

Работа с устаревшими системами часто вызывает страх из-за её сложности и неожиданных последствий.

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

Реальные проблемы устаревшего UX

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

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

1. Устаревшие системы должны сосуществовать с продуктами, построенными вокруг них

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

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

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

2. Устаревшие системы определяют UX

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

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

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

UX-роадмап для работы с устаревшими проектами

Не отвергайте устаревшее: опирайтесь на накопленные знания

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

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

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

Составьте карту существующих рабочих процессов и зависимостей

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

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

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

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

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

Выберите стратегию UX-миграции

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

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

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

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

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

Обновление UI устаревшей системы + публичная бета. Выполните низкорисковую тонкую настройку устаревшей системы для выравнивания UX, одновременно постепенно создавая новую систему с публичной бетой. Это даёт быстрые и долгосрочные результаты и идеально подходит для получения быстрых побед.

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

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

Если вы улучшаете интерфейс поэтапно, полезно отдельно посмотреть Как использовать переменные Figma для тестирования масштабирования шрифта, чтобы привязать UX-рефакторинг к проверяемым сценариям доступности.

Типичные ошибки при работе с устаревшими системами

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

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

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

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

Как выстроить доверие стейкхолдеров в процессе миграции

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

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

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

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

Подводя итоги

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

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

Полезные ресурсы

Ответы на эти вопросы могут быть для вас полезными

С чего начать улучшение UX в устаревшей системе, если документации почти нет?

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

Когда оправдан полный редизайн по принципу «большого взрыва», а когда лучше двигаться инкрементально?

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

Как убедить стейкхолдеров поддержать миграцию устаревшей системы?

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

Как не сломать зависимые системы в процессе миграции?

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

Как вовлечь опытных пользователей в процесс редизайна?

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