На фоне OKR (objective key results), метрик и релизов UX почти всегда живёт где-то сбоку. Формально все согласны, что «UX важен», но на практике он часто остаётся вне мейнстрима и воспринимается как что-то полезное, но расплывчатое: на уровне целей вклад UX-практик в интерфейсные решения редко отображается в результатах и не формализован, а эффект работы над UX-зрелостью сложно измерим. В таких условиях UX держится на отдельных энтузиастах, и без связи с целями продукта культура не масштабируется, она выгорает.

Для этого мы в RuStore за последние три года осознанно научились управлять UX-зрелостью: доказали ценность исследований и поставили их на поток, научились работать с UX-долгом, собрали Atomic Research, внедрили доступность и быстрые тестирования интерфейса. Но со временем возник новый вопрос: как понять, куда развиваться дальше и как соотнести всё это с OKR и целями продукта, а не с личным энтузиазмом нашей UX-команды?

В этой статье я, Екатерина Бессчётнова, руководитель отдела UX-исследований RuStore, отвечу на этот вопрос и расскажу про следующий шаг — как собрать всё это в осмысленную систему, чтобы: видеть, где UX действительно встроен в ежедневные процессы, а где всё ещё держится на личной инициативе; измерять развитие не кейсами, а наблюдаемым поведением команды; и наконец — связать UX-культуру с продуктовыми и бизнес-целями.

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

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

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

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

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

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

В продуктово-исследовательском мире есть 2 проблемы:

1. Хаотично пополняющийся бэклог исследователя
2. ТТМ (Time to market) продукта, которому необходимо сократить этап discovery (поиска и анализа)

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

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

Если вы когда-нибудь занимались тестированием прототипов на респондентах, то наверняка замечали, что люди подсознательно сразу воспринимают прототип как готовый продукт и не «делают скидку» на все его условности. Опечатки, дублирование информации, шаблонный текст, тупиковые пути, долгая загрузка и прочие особенности прототипов отвлекают респондентов от реальных недостатков и могут восприниматься как ошибка интерфейса. Наверняка вы хотите не собирать отзывы об очевидных огрехах работы прототипа, а сосредоточиться на поиске возможных проблем при взаимодействии пользователей с конечным продуктом. А чтобы люди не отвлекались на косяки прототипов, нужно создавать их по некоторым правилам.