На фоне OKR (objective key results), метрик и релизов UX почти всегда живёт где-то сбоку. Формально все согласны, что «UX важен», но на практике он часто остаётся вне мейнстрима и воспринимается как что-то полезное, но расплывчатое: на уровне целей вклад UX-практик в интерфейсные решения редко отображается в результатах и не формализован, а эффект работы над UX-зрелостью сложно измерим. В таких условиях UX держится на отдельных энтузиастах, и без связи с целями продукта культура не масштабируется, она выгорает.
Для этого мы в RuStore за последние три года осознанно научились управлять UX-зрелостью: доказали ценность исследований и поставили их на поток, научились работать с UX-долгом, собрали Atomic Research, внедрили доступность и быстрые тестирования интерфейса. Но со временем возник новый вопрос: как понять, куда развиваться дальше и как соотнести всё это с OKR и целями продукта, а не с личным энтузиазмом нашей UX-команды?
В статье отвечу на этот вопрос и расскажу про следующий шаг — как собрать всё это в осмысленную систему, чтобы: видеть, где UX действительно встроен в ежедневные процессы, а где всё ещё держится на личной инициативе; измерять развитие не кейсами, а наблюдаемым поведением команды; и наконец — связать UX-культуру с продуктовыми и бизнес-целями.
UX-зрелость начинается не с эмпатии, а с процессов
UX-зрелость продукта — это когда пользовательский опыт перестаёт быть красивой метафорой из презентации и превращается в конкретику: в последовательность действий, задач, решений и измеримых результатов. По сути, это отражение того, как команда работает с опытом пользователя в ключевых практиках или компетенциях и какие устойчивые привычки формирует.
У нас это проявляется следующим образом (в другой команде перечень может выглядеть иначе).
Как планируем исследования. Появляются ли задачи и брифы заранее, встроены ли Discovery и Delivery в цикл разработки, связаны ли гипотезы с roadmap и метриками — или ресёрч вызывают «на подхват» в последний момент.
Как работаем с результатами и UX-долгом. Превращаются ли выводы в приоритезированный список задач — или остаются «где-то в отчёте».
Как взаимодействуем с пользователями. Участвует ли команда в интервью и встречах эмпатии, проводит ли быстрые проверки интерфейса и фиксирует наблюдения — или слышит пользователя только через пересказ исследователя.
Как пользуемся базами знаний. Обращаемся ли сначала к Confluence, Atomic и дашбордам, чтобы не тратить ресурсы на уже проверенное — или каждый раз начинаем с чистого листа.
Что происходит с насмотренностью. Есть ли в команде обмен референсами и кейсами, которые помогают принимать решения — или всё держится на паре энтузиастов.
Как устроена коммуникация по UX. Обсуждаем ли цели, риски, UX-долг и метрики на дизайн-ревью, сопровождаем ли решения от требований до пост-релиза — или просто передаём макеты со словами «сделайте как тут».
Как взаимодействуем с дизайн-системой и визуальной консистентностью. Учитываем ли её ограничения, поднимаем ли визуальные и a11y-риски до релиза — или решаем точечно, обходя систему.
Как учитываем доступность.* Попадают ли требования в брифы и макеты, заводятся ли задачи по визуальной или невизуальной доступности, проверяются ли базовые вещи вроде контраста и фокуса.
Как используем ИИ.*Помогает ли ИИ быстрее и глубже прорабатывать брифы, сценарии и гипотезы с пониманием ограничений — или это пока игрушка и источник слепого копипаста.
*Такие столпы, как насмотренность, коммуникация по UX, доступность и ИИ, могут быть надстройкой и встроены в другие уровни — нам просто так проще ориентироваться.
Матрица UX-зрелости: продуктовый конструктор, а не модель из учебника
Классические maturity-модели (NN/g, консалтинг и др.) обычно смотрят на UX-зрелость на уровне компании: оценивают процессы, роли, лидерство, стратегию. Это полезная рамка, но в ежедневной работе конкретной продуктовой команды её часто недостаточно.
В реальности нас интересует более приземлённая оптика: как люди в конкретном продукте принимают решения, как они на самом деле работают с пользователем, и что прокачивать дальше, где именно системе не хватает опоры.
Матрица, о которой я рассказываю, — это честный инструмент оценки UX-зрелости, основанный не на теории, а на реальных практиках, ограничениях и целях. В её основе — конкретный продуктовый контур.
Она устроена так:
Построена вокруг конкретного продукта, его целей и метрик, а не про компанию в целом.
Уровни описаны через наблюдаемое поведение сотрудников, а не через абстрактные стадии.
Критерии собраны из реальных практик RuStore, а не из учебных моделей.
Продумана как конструктор: её можно разобрать, убрать лишнее, добавить своё и собрать под другую команду.
Здесь базовой единицей является поведение каждого человека внутри продуктового контура. Поэтому матрица построена так, что по каждой практике можно определить уровень конкретного сотрудника. Это позволяет вести предметный диалог тимлид ↔ специалист и точнее видеть зоны роста. Далее оценки собираются в изображение более крупного масштаба:
уровень по практике → у конкретного сотрудника;
уровни сотрудников → формируют профиль команды;
профиль команды → ложится в общую оценку UX-зрелости продукта.
Иными словами, когда далее в тексте звучит термин «UX-зрелость сотрудника», речь не про отдельную HR-модель, личную оценку или грейд, а способ детализировать зрелость продукта через поведение сотрудников в команде.
В нашей версии системы есть четыре уровня:
Новичок — входит в контекст продукта, знакомится с UX-практиками, но ещё не успевает полноценно их применить.
Базовый — понимает процессы, знает, «как у нас принято», и способен стабильно работать в этих рамках.
Продвинутый — не просто следует процессу, а инициирует исследования, умеет интерпретировать результаты и встраивать UX-практики в продуктовый цикл так, чтобы они влияли на решения.
Лидерский — поддерживает высокий личный стандарт, развивает других, удерживает системность и постепенно помогает команде выйти на следующий уровень UX-зрелости.
Важно: матрица — это не табель успеваемости. Она не привязана жёстко к грейдам*. К примеру, один и тот же сотрудник может быть продвинутым в работе с пользователями, но находиться лишь на начальном уровне в работе с базами знаний.
*В другом кейсе матрице ничто не мешает привязаться к грейдам или KPI, но важно сначала договориться, какое именно поведение вы хотите видеть более зрелым, а уже потом добавлять к этому метрики.
Калькулятор UX-зрелости продукта
Как считаем UX-зрелость
Технически всё просто: внутри каждого уровня есть набор критериев, которые мы оцениваем по бинарному принципу: 1 — да, 0 — нет. «Чем больше сила, тем больше ответственность», поэтому — чем выше уровень, тем строже требования:
уровень «Новичок / Базовый», если выполнено ≥ 60% критериев;
уровень «Продвинутый / Лидерский», если выполнено ≥ 80% критериев.
Сначала оцениваем каждого сотрудника: определяем его уровень как среднее по всем практикам: 1 — новичок, 2 — базовый, 3 — продвинутый, 4 — лидерский.
Затем считаем зрелость команды. Для этого берём среднее по сотрудникам и отдельно по каждой практике. Так формируется распределение зрелости в нескольких разрезах: по продукту, по команде и по конкретному человеку.
Формулы дают направление, а выводы формируются в диалоге. На performance review тимлид может использовать матрицу как дополнительный инструмент, а сотрудник — прийти со своими примерами и оспорить оценку, если считает, что его вклад недооценён.
Самое сложное здесь — не формулы, а сбор данных. Мы договорились так: исследователи фиксируют наблюдения по своим проектам, перед performance review сводят их по сотрудникам и передают тимлидам на сверку.
Порог 60% и 80% защищает от мелких разночтений в понимании критериев. Один человек мог выполнить что-то иначе, кто-то мог забыть зафиксировать — модель не рушится, общая картина сохраняется.
Зачем исследовательскому лиду матрица UX-зрелости
Для UX-лида матрица — это инструмент, который помогает наконец связать собственные усилия с реальной культурой команды, а не действовать в режиме нескончаемых инициатив. Что даёт матрица:
Предметная обратная связь. Вместо «команда мало вовлечена в UX» — «в этих практиках у нас базовый уровень, вот что делаем и чего пока не делаем».
Ставить цели осознанно. Не «на ощущениях», а опираясь на карту: например, увеличить долю сотрудников с продвинутым уровнем в работе с пользователями.
Сделать вклад практик видимым. Быстрые проверки гипотез, эмпатия, развитие базы знаний, использование ИИ-инструментов — всё это двигает конкретные уровни зрелости, а не просто происходит.
В итоге снижается ощущение невидимого труда и риск выгорания.
Зачем тимлидам продукта и дизайна матрица UX-зрелости
Для PM, HoD или CPO матрица помогает увидеть, как UX реально встроен в работу продукта:
Понимание сильных и слабых зон. Например: команда уверенно планирует исследования, но почти не работает с базами знаний, и это влияет на скорость принятия решений.
Осмысленная постановка целей и подбор людей. Вместо «нужно прокачать UX» — конкретика: кого вести в уровень «продвинутый», кому можно давать задачи с высокой неопределённостью, а кому сначала нужно выстроить опору в базовых практиках.
Предметная обратная связь и меньше микроменеджмента. Вместо «ты слабо участвуешь в исследованиях» — «по этим критериям ты пока на базовом уровне, чтобы вырасти — нужно сделать вот это». Матрица помогает договориться, где команда берёт ответственность сама, где нужен ресёрч, а где — поддержка тимлида.
На уровне продукта рост UX-зрелости даёт прямой эффект: ускоряет проверки гипотез, повышает качество обсуждений, снижает риск конфликтов между ролями, поддерживает системность, масштабируемость и адаптивность дизайна, опираясь на данные и наблюдения, а не только на вкусовщину.
Мини-кейс: как матрица помогает выбрать фокус
Когда мы впервые посчитали зрелость по матрице, результат оказался неожиданным — мы увидели просадку в работе с базами знаний. По ощущениям казалось, что все всё знают про Atomic. Но когда подсчитали, оказалось:
в планировании и работе с пользователями у команды в среднем базовый или продвинутый уровень;
а в столпе «Работа с базами знаний» — почти у всех базовый с просадками до уровня новичка.
При этом именно использование базы напрямую влияет на скорость и качество принятия решений: если знания не переиспользуются, команда тратит время на повторные исследования.
Дальше началась как раз связь с OKR, ради которой всё и затевалось. В продуктовых целях на тот момент стояли:
C (Company Objective) — кратный рост бизнеса и выход на новые платформы.
GR (Goal Result) — укрепить уровень UX-экспертизы и знания о пользователе в продукте.
KR (Key Result) — снизить себестоимость взвешенной фичи.
Матрица подсветила, что здесь один из самых дешёвых рычагов — научить людей хорошо пользоваться Atomic и дашбордами. Когда поговорили с теми, кто в базе почти не бывает, выяснилось, что проблема не в «лень читать», а в двух вещах: онбординг новых сотрудников и удобство самого инструмента.
Поэтому в цели следующего квартала добавили вполне конкретное:
KR — увеличить долю сотрудников с продвинутым уровнем по работе с базами знаний на 30%;
KR — интегрировать Atomic Research в ИИ-инструмент, чтобы база была не только полезной, но и удобной.
С чего начать путь к матрице
Если сильно упростить логику Марка Розина, описанную в «Путешествии по спирали 2.0», компании сначала живут в парадигме выживания: сделать, успеть, занять место на рынке, доказать жизнеспособность продукта. Разговоры о том, почему мы принимаем те или иные решения, появляются позже — когда базовые риски уже сняты. И матрица UX-зрелости становится актуальной именно в этот момент. Контекст меняется: у команды впервые появляется пространство думать не только о скорости и выживании, но и о культуре, знаниях и качестве продуктовых решений. UX-культура перестаёт быть роскошью и становится нормальной частью управления продуктом.
Если вы чувствуете, что команда уже на этом рубеже, можно переходить от размышлений к действиям. Ниже — как можно пройти этот путь.
Шаг 1. Определите точку старта
Когда я пришла в RuStore три года назад, продукт только проходил первые тесты friends&family. Главный вопрос звучал просто: «он вообще взлетит?». И UX-команде тогда нужно было не «строить культуру», а показать, что исследования ускоряют развитие продукта, а не тормозят его. Для этого было нужно собрать команду, которая умеет работать системно, поставить исследования на поток и связать ресёрч с roadmap.
Если вы узнаёте себя в этом описании — матрица пока не в приоритете. Сначала важно:
наладить базовый поток исследований под ключевые продуктовые решения;
договориться, на какие вопросы отвечает ресёрч и как снижает риски;
объяснить бизнесу, где UX-исследования экономят деньги и время.
Шаг 2. Сформируйте свой must-have минимум
Когда наши исследования встроились в цикл разработки, стало ясно: важна не только скорость проектов, но и то, что происходит с инсайтами после отчёта. От этого мы начали строить столпы UX-культуры:
работа с UX-долгом, чтобы проблемы не терялись и решались;
база исследований в формате Atomic, к которой возвращаются;
доступность как часть гигиены, а не отдельный разовый проект;
демократизация знаний для самостоятельной проверки гипотез;
встречи эмпатии и участие в интервью, чтобы не жить в ИТ-пузыре.
На этом этапе важно честно оценить каждую практику: она у вас отсутствует, существует локально или работает системно.
Шаг 3. Перейдите к управлению зрелостью
Когда минимальный must-have практик заработал, возникает следующий вопрос: что именно развивать дальше. В этот момент чаще всего не хватает ясности — где команда уже на уровне нормы, а где до базовой «гигиены» ещё далеко. И главное — как всё это померить и честно привязать к OKR, а не жить в режиме «мы тут развиваем культуру».
На этом этапе необходимо решение, которое поможет выбрать фокус. Для нас таким инструментом стала матрица UX-зрелости продукта. Мы собрали её на основе реальных практик, несколько раз прогнали внутри отдела, потом через продукт, дизайн и тимлидов, выкинули лишнее, упростили формулировки и добавили индикаторы (что именно нужно делать, чтобы «засчитать» единицу в ячейке). В результате матрица стала мостиком между «работаем по ощущениям» и «действуем осознанно», а также опорой при разговоре о развитии и постановке целей, причём не только продуктовых метрик.
Если вы уже на этом уровне — можно собирать собственную матрицу.
Минимальный старт:
выберите 3-6 практик UX-зрелости, которые у вас действительно есть;
опишите для каждой минимум два уровня поведения: что считается гигиеной и что — зрелостью;
примерьте матрицу к команде и выберите 1–2 столпа в фокус на ближайший период.
Дальше можно докручивать уровни, считать среднее по команде, подключать цели и обучение. Главное — не ради самой матрицы, а ради одного эффекта: чтобы UX развивался не интуитивно, а так же управляемо, как метрики продукта.
Посмотреть, как работает калькулятор UX-зрелости продукта, и скачать его можно по ссылке.
Спасибо всем, кто помог вычитать матрицу и довести её до измеримых, рабочих формулировок.
Екатерина Бессчётнова
Руководитель отдела UX-исследований RuStore