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

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

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

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

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

В этом посте я расскажу, как мы в RuStore выстроили процесс, который помогает не просто «признавать боль», а системно с ней работать: выявлять, приоритизировать и закрывать. И почему UX-долг — это про деньги и эффективность, а не просто «чтобы было красиво».

Что такое UX-долг и почему это не про красоту

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

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

UX-долг не кричит об ошибке и не выскакивает баннером, он протекает, и его можно измерить:

• в конверсии (пользователь не туда нажал, ушёл, долго искал, запутался, не понял);

• в вовлечённости (интерфейс отпугнул, хотя фича полезная);

• в удержании (первый опыт — скомканный);

• в репутации (пользователь ушёл и больше не вернулся, но саппорт о нём даже не узнал или узнал от PR).

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

• накапливаются в тех зонах, до которых вечно не доходят руки;

• проявляются тогда, когда вы уже на проде и времени нет;

• мешают пользователю пройти путь, хотя технически всё работает (и это уже не только про UX, но и про бизнес).

Чтобы этого не происходило, мы фиксируем все найденные UX-проблемы — будь то тестирование на проде или прототипах — в таск-трекере RuStore Inbox (RSI). Так проблемы становятся видимыми, осмысленными и управляемыми. Именно эту копилку задач мы и называем UX-долгом. 

UX-долг может быть разным:

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

_{*Однако, это лишь один из возможных подходов. Если взглянуть шире, UX-долг можно трактовать как совокупность всех потенциальных пользовательских затруднений — даже тех, что пока не выявлены. В этой модели отправной точкой становится факт проведения исследования до начала реализации — по аналогии с подходами к техническому или дизайнерскому долгу. В таком случае и сама матрица принимает иную форму:}

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

Не субботник, а системная работа, встроенная в жизнь продукта

Год первый

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

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

• Продуктовые команды туда почти не заглядывали.

• Обновлять таблицу забывали.

• Переносить задачи в бэклог — невозможно.

В результате исследовательская работа уходила «в стол». Что-то исправили? Что-то проигнорировали? Как именно реализовали? Ответов не было, как и какой-либо прозрачности. И, честно говоря, не было и ощущения, что тебя услышали.

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

• Раз в месяц — слишком редко. Для одних задач —  уже поздно, для других — ещё рано.

• Собрать всех — сложно. Кто-то не пришёл, кого-то не было — обсуждение есть, решений нет. 

• Свериться с тем, какие проблемы вообще были — ручной квест.

Это всё больше походило на патч, чем на систему. UX-долг продолжал расти.

_{*Чтобы что-то заработало, нужно сначала понять, почему текущая система не работает. Я писала об этом подробно в статье на Хабре: «Прежде чем выстраивать процесс, проведите ретро с продуктом. Поймите, в каких инструментах и приоритетах он живёт. И делайте шаг навстречу — туда, где происходит реальная работа».}

Год второй

Мы поняли, что нужен инструмент, который будет жить рядом с продуктом. Так в нашу работу вошёл таск-трекинговый проект Rustore Inbox, и вместе с ним — задачи RSI, которые стали частью общего продуктового процесса. Через этот проект любой член команды может предложить идею или инициативу для развития RuStore: 

• Feature Request — запросы на новые функции и улучшения. 

• Suggestion — любые предложения, которые могут повлиять на рост продукта или компании (не обязательно продуктовые).

• Problem — отчёты о проблемах: баги, неожидаемое поведение, невозможность совершить нужное действие. 

Теперь каждая проблема из исследования вносится в проект Rustore Inbox и превращается в отдельную задачу RSI. К примеру, Problem с меткой ux_debt, в которой обязательно указываем:

• описание проблемы,

• критичность проблемы,

• критичность (значимость) сценария,

• продуктовое направление,

• ответственного за задачу.

Проект Rustore Inbox стал входной точкой для обсуждения и приоритизации задач. Теперь продуктовая команда смогла:

• привязать найденную UX-проблему как RSI-задачу к эпику,

• увидеть её на доске проекта,

• забрать в бэклог и учесть при планировании.

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

Год третий

Мы замкнули процесс. Теперь разбор RSI стал частью еженедельного дизайн-ревью, а сам UX-долг — видимым и управляемым через специальный дашборд.

Вот как теперь работает наш цикл:

• После исследования — появляются задачи RSI в проекте Rustore Inbox.

• Продукт — забирает RSI, привязывает к эпику.

• Дизайнер — отмечает RSI на макетах, предлагает решения.

• На дизайн-ревью — обсуждаем реализацию, валидируем подход.

• После внедрения — продукт закрывает RSI, исследователь проверяет прод и оставляет комментарий.

• Перед новым кварталом — проводим check-up UX-здоровья продукта с помощью дашборда и проводим приоритизацию продуктового бэклога.

Теперь RSI — это не просто «реестр UX-боли», а полноценный инструмент управления качеством. Мы планируем и разбираем UX-долг от наиболее больного к наименее. И главное: теперь это не просто инициатива исследовательской команды, а неотъемлемая часть работы всей продуктовой команды.

_{Мы рекомендуем команде разбирать проблемы в зависимости от критичности проблемы (степени боли) и от критичности (значимости) сценария, в которых они находятся:}

_{Первая очередь- высококритичные проблемы в высококритичных сценариях.}

<sub>Вторая очередь
- среднекритичные проблемы в высококритичных сценариях
- высококритичные проблемы в среднекритичных сценариях
- среднекретичные проблемы в среднекритичных сценариях</sub>

<sub>Третья очередь
- высококритичные проблемы в низкокритичных сценариях
- среднекритичные проблемы в низкокритичных сценариях</sub>

_{Низкокритичные проблемы в низкокритичных сценариях — разбираем заодно.}

_{Идеальных моделей, как и бюрократии Вебера, в природе не существует. Поэтому порядок разбора долга вполне может формироваться из продуктового плана и приоритета задач: «Планируем реализовать фичу Х, к ней относятся RSI-1, 2, 3 — возьмём их в этот цикл». Это тоже — нормально. Главное, что дело движется.}

_{Об оценке критичносности (значимости) сценариев рассказывали в статье на Хабре.}

Что нам это дало: эффект от процесса

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

Иногда мы ещё спотыкаемся, но эти изменения  — не просто улучшения, а признаки взросления команды и продукта. 

Прозрачность

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

• Исследователь видит: «Эта проблема учтена. Её решают. Вот её решение на макете, вот оно в проде. А тут можно посмотреть количественный результат».

• Продакт видит: «Эта проблема в моём бэклоге. Эту пока отложим. А эта пойдёт в следующий цикл».

Вовлечённость

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

• Дизайнер приходит на ревью не просто с макетом, но и с RSI: какую проблему решил, как её учёл.

• Продукт обсуждает RSI заранее — до старта разработки, а не после релиза.

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

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

Предсказуемость

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

Меньше боли, меньше дыма

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

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

Как начать у себя

Если вы дочитали до этого места — скорее всего, у вас уже есть UX-долг. А может, даже десятки зафиксированных ux-проблем, которые пока не ясно , как забрать в работу. И это нормально. Это уже повод задуматься, как сделать UX-долг видимым и управляемым.

 Если хотите начать — начните с малого:

• Спросите себя: где живут проблемы после исследований и что с ними происходит?

• Проверьте: кто в команде точно их видит?

• Подумайте: как упростить вход — формат, язык, канал?

• Найдите пространство: где обсуждать, приоритизировать, проверять.

• И начните цикл: фиксация → обсуждение → решение → проверка.

UX-зрелость — это не чеклист. Это путь. И в этом пути нет единственного верного маршрута. Но если движение началось — значит, вы уже на правильной дороге. 

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

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