Product × Science: заметки с тегом UX

UX-помехи как инструмент сбора сигнала для алгоритмов

Sun, 20 Aug 2023 22:35:00 +0300

Ключевые идеи из статьи Using Friction As A Feature In Machine Learning Algorithms, дополненные небольшими фатками автора из личного опыта.

NB! Слово «friction» в переводе с английского означает «трение» или «разногласие», что не совсем подходит в контексте пользовательского опыта. Поэтому далее по тексту я буду переводить «friction» как «помеху», т. к. счел это более подходящим вариантом. Теперь про идеи из статьи...

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

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

Поэтому иногда проектироващики осознанно вставляют юзерам палки в колеса:

Заставлять настраивать и/или собирать доп.инфу перед начало использования приложения (ох уж эти любимые N экранов в первой сессии, которые большинство людей пролистывают не глядя...)
Подталкивать к определенным действиям при помощи механик из поведенческой экономики (интересующиеся могут поискать Nudge Theory)
«Защита от дурака» при критический действиях (напр., удаление данных)

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

2. UX-помехи позволяют отделять «сигнал» от «шума» и повышать качество рекомендаций

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

Цикл обратной связи типичного сервиса с движком рекомендаций

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

TikTok взял эту механику на вооружение и довел до совершенства для своих целей — быстрее подстроиться под вкусы пользователя и затянуть в продукт. Но как это сработало?

TikTok не стал использовать «традиционный» дизайн в виде витрины контента, который:

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

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

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

В марте 2023 музыкальный сервис Spotify выкатил редизайн своего продукта, в котором показал ленту а-ля TikTok. Верховный продуктолог и по совместительству глав.инженер сервиса, обстоятельно объяснил в интервью почему они радикально меняют интерфейс.

“Секрет того, почему некоторые из продуктов так хороши в рекомендациях, на самом деле заключается не в том, что у них лучшие алгоритмы. Это те же самые алгоритмы с более эффективным пользовательским интерфейсом”.
— Густав Седерстрем в статье The Verge “Почему Spotify хочет выглядеть как TikTok”

Интересно, что их редизайн собирает хейт по интернету. Например, Mashable назвал новый интерфейс Spotify одним из худших обновлений 2023 года. Но руководство музыкального сервиса готово мириться с критикой, т. к. в долгосроке верит в правильность своего решения.

So What?

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

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

«Долина ужаса» в рекомендательных системах

Sun, 02 Jul 2023 00:00:00 +0300

Источник: This is Personal: The Do’s and Don’ts of Personalization in Tech

Подход к исследованию в зависимости от ситуации

Tue, 25 Apr 2023 00:00:00 +0300

Jeanette Fuccella составила фрейморк для приоритизация исследований. Схема на картинке довольно говорящая, но вот две статьи для погружения:

Data Enabled Design

Tue, 21 Dec 2021 01:00:00 +0300

Рассказ о том, где и как использовать дата саенс в дизигн, а дизигн в дата саенсе.
https://uxdesign.cc/why-design-needs-data-af3d47584847

Мне вот эта фраза из статьи прям резонирует

I’ve just realized that data and data literacy is an important part of designing at scale.

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

Например, сам автор, судя по его портфолио, работает в каком-то R&D поле, где смешиваются физическое и цифровое пространство.

Схожий кейс, но только развернутый на 300+ страниц, продвигается отделом Data Enabled Design из Philips.
Они делают всякие умные устройства для дома (называют это “intelligent ecosystems”) и в рамках таких проектов прибегают к смешанным ресерчам.

Прототипируем умные продукты

Fri, 18 Jun 2021 00:00:00 +0300

Последние полгода много работаю с фичами и продуктами на основе машинного обучения. В основном с рекомендательными системами.

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

Для классического софта можно реализовать прототип с заранее заскриптованным сценарием и прогнать его на юзер тестинге.

С рекомендациями так просто не получится. Сам формат фичи подразумевает подстройку под действия конкретного респондента. Заранее прописать прописать все сценарии вряд ли получится (ну может только в очень узкой области, но тогда скорее всего и ML там не нужен, а хватит эвристики).

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

Детализированности прототипа с точки зрения UI

Детализированности прототипа с точки зрения данных

По-сути, Google подменяют «дорогую» разработку на дешевую. У них есть команда UX Engineering, которая и делает прототипы, которыми может управлять человек. Думаю, мало у кого есть возможность делать такие прототипы, а ML как-то тестировать же хочется.

Пока мне не попадалось «дешевых» способов тестировать ML без разработки (зато более менее понятно как это делать в проде имея систему для АБ-тестов).

https://design.google/library/simulating-intelligence/

Гид по UX-метрикам

Fri, 25 Oct 2019 01:00:00 +0300

Что такое «метрика»?

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

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

Вот как описывают фидбек на «общем уровне»

Feedback is as a generic method of controlling a system by using past results to affect future performance. Approaches which keep a system operating within tight parameters, demonstrate negative feedback. That’s not pessimistic or bad feedback, but feedback that prompts the system to maintain control. Negative feedback is actually good feedback because it yields greater efficiency and performance. Positive feedback, by contrast, causes the system to keep going, unchecked. Like a thermostat that registers the room as too warm and cranks up the furnace, it’s generally meant to be avoided.

“Negative feedback is actually good feedback because it yields greater efficiency and performance.” — James Watt, Scottish inventor & mechanical engineer.

Число в вакууме не несет смысла. Для получения пользы от метрики мы должны сравнить ее с другим показателем. Примеры:

сравнивая свои показатели со стандартами (бенчмарками) индустрии, можно понять наше положение на рынке.
отслеживая показатели во времени, можно понять как развивается наша компания относительно «прошлой» себя.

Свойства хорошей метрики

Консистентность (воспроизводимость) результатов (англ. reliability) — если повторить исследование/эксперимент, то мы получим те же числа.
Валидность (англ. validity) — мы уверены, что метрика измеряет именно то, что мы хотим замерить.
Чувствительность (англ. sensitivity) — метрика хорошо реагирует на изменения.

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

Метрики в UX

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

UX-метрики оценивают качество взаимодействия человека с интерфейсом при выполнении определенной задачи. Понятие «задачи» многогранно, обычно выделяют три уровня. Естественно, границы уровней размыты. Разберем на примере поискового продукта:

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

Альтернативная классификация:

микро- и мезо-уровни еще иногда называют юзабилити-метриками.
макро-уровень иногда называют Customer Experience (CX-метрики). Такие метрики можно использовать на уровне всего продукта или бизнеса.

User Experience vs. User Centric

Эти понятия легко спутать. UX-метрики это подмножество User Centric метрик. Но не все User Centric метрики являются UX.

Примеры User Centric показателей, которые не являются UX-метриками:

User-Level LTV — показывает сколько мы заработаем с определенного пользователя безотносительно используемого продукта/услуги.
Количество сессий на человека — показывает активность человека в продукте, но ничего не говорит про «качество» это взаимодействия.
Средняя скорость загрузки страницы на человека — замеряет техническое свойство продукта, но не говорит о том, как пользователь это воспринимает.
NPS — замеряет лояльность потребителей к бизнесу, но не говорит о качестве реализации конкретной задачи или сценария.

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

Списки User Centric метрик

System Usability Scale (SUS)

Самый известный и, наверное, старый способ измерения удовлетворения от интерфейса — это опросник System Usability Scale (SUS).

После работы в системе, респондент проходит опрос из 10 вопросов. По определенной формуле считается показатель, который лежит в диапазоне от 1 до 100. Он характеризует сложность интерфейса:

1 — непонятно, от слова «совсем»
100 — «божественный» UX

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

Single Ease Question (SEQ)

После совершения целевого действия, пользователя можно спросить вот такой вопрос:

seq-high-res.jpg

Доказано, что более легкие задачи делаются быстрее и бОльшее количество человек их заканчивает, т. е. выше конверсия.

Концепция «простоты использования» используется во многих других метриках. Например, за метрикой Customer Effort Score стоит простая идея, что чем проще пользоваться продуктом или услугой тем более лояльными будут клиенты. Но мне удалось найти какие-либо подтверждения на этот счет (хотя мысль логичная).

Также, между одним вопросом про «простоту использования» с огромным SUS есть корреляция 90%. Это еще один «плюсик в карму» для этой метрики.

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

Usability Metric for User Experience (UMUX)

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

В UMUX четыре вопроса, а в усовершенствованной версии UMUX-Lite их два:

Доказано, что UMUX-Lite может заменять SUS и при этом не терять в точности оценки. Два вопроса проще «уместить» в интерфейс продукта и начать спрашивать online, чем пользуются продуктовые компании.

Пример из жизни: как исследуют пользователей, расставляют приоритеты и снимают метрики в Atlassian.

Customer Satisfaction Score (CSAT)

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

How would you rate your overall satisfaction with the [goods/service] you received?

Но есть примеры, когда CSAT измеряется уровне всего продукта или компании. American Customer Satisfaction Index уже больше 20 лет каждый год опрашивает сотни тысяч американцев на предмет удовлетворенностью продуктами или услугами компаний из разных сфер и индустрий.

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

Single Usability Metric (SUM)

Это 6 показателей, которые по хитрой формуле превращаются в число от 1 до 100. Эти показатели включают в себя:

Метрики на основе поведения респондентов
- Справился ли респондент с задачей
- Фактически проведенное время над задачей
- Количество ошибок
Субъективные метрики-опросы с 5-бальной шкалой для ответа:
- Воспринимаемое время над задачей
- Воспринимаемая сложность
- Удовлетворенность (тот же самый CSAT)

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

К счастью, Microsoft поделилась своим 2.5-летним опытом ее использования. Инсайты:

Шкала от 1 до 100 непонятна стейкхолдерам. Где отсечка, после которой «все хорошо?»

Фактическое и воспринимаемое время над задачей не всегда коррелируют. Люди иногда отвлекаются или просто «тупят», но при этом считают, что с задачей справляются быстро. Время — это шумная метрика.

Количество ошибок на практике заранее неизвестно наперед. Поэтому с точки зрения метрики это просто шум.

Net Promoter Score (NPS)

Очень популярная метрика лояльности потребителя к бренду или услуге. Поэтому остановимся на ней подробнее.

У этой метрики есть «набирающий популярность брат» Actual NPS (aNPS), который пытается устранить одну из ошибок NPS — спрашивать про мнение и будущее.

Но это не самая главная беда этой метрики в контексте измерения UX. Бренд «собирает» под собой не только продукт с его дизайном, но и работу поддержки/отдела продаж и новости о бренде.

Слишком много факторов влияет на NPS.

На практике мы получаем слабую чувствительность к UX-изменениям. Сторонними исследователя установлено, что «вклад» UX в NPS составляет не более 66%.

Но есть ситуации, когда NPS можно использовать как UX-метрику:

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

Примеры, когда NPS подходит и не подходит как UX-метрика.

Порекомендуете ли вы AdBlock друзьям или коллегам?
- ОК, т. к. основной сценарий в AdBlock — это блокировка рекламы на сайтах. Однозначная ассоциация.
Порекомендуете ли вы Wrike друзьям или коллегам?
- НеОК
  - Wrike это продукт с множеством макро-задач внутри: планирование проектов, управление ресурсами, хранилище документации. Как понять, UX какого сценария дает больший вклад?
  - Wrike используется для управления проектами и людьми. Есть люди, которые просто не любят работать, поэтому будут ставить плохие оценки в NPS даже если продукт будет идеален.
  - Wrike это b2b-компания, в которой «продуктом» является не только сайт, но и поддержка, обучающие материалы и размер скидки, который может дать отдел продаж.
  - Основные покупатели Wrike — топ-менеджеры. Рядовые сотрудники могут просто не иметь знакомых топ-менеджеров, которые ищут систему управления проектами. Некому рекомендовать.
  - Некоторые люди «оставляют работу на работе» и не рекомендуют друзьям рабочие инструменты. А все коллеги и так уже пользуются этой системой.

Некоторые компании пытаются «уточнять» NPS и спрашивать про конкретный опыт в продукте. Но это тогда уже не NPS, а что-то другое. Примеры:

С какой вероятностью вы порекомендуете продавать товары на Авито друзьям или коллегам?
Порекомендуете ли вы слушать музыку в Spotify друзьям или коллегам?

Другие метрики

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

Language Quality Survey (LQS) — метрика качества локализации
Lostness — метрика качества навигации в продукте
SUPR-Q, qxScore, User Experience Questionnaire (UEQ) и AttrakDiff — опроссники, которые продвигают идею единого числа в UX для всего и вся.
И еще сотни других метрик...

Фреймворки и подходы

Метрик много, но не всегда понятно какую использовать под вашу задачу. Google в 2010 году опубликовала научную работу по HEART — подход, который помогает выбрать метрику для измерения пользовательского опыта под разными углами. Фреймворк был опробован на 20 проектах внутри Google, а затем пошел “во вне” компании.

HEART комбинирует мнения пользователей через опросы и поведенческие продуктовые метрики

Tomer Sharon, бывший UX Researcher в Google и WeWork и нынешний глава по ресерчу в Goldman Sachs, расписал подробно про каждый “срез” сквозь призму своего опыта и дает примеры метрик:

Как и многое из Google, этот подход стал набирать популярность. Но это не единственное, что придумало человечество.

Главные Концепции

Как можно было заметить, UX-метрики работают с разными абстракциями:

Простота
Функциональность
Удовлетворенность
Желание использовать в будущем / Лояльность
Значимость (относительно новая концепция, которую хотят начать измерять)
Изучаемость / Простота обучения
Готовность делегировать (upd. от 19.01.2026)

Есть две модели, которые пытаются расположить их в иерархию и понять влияние друг на друга:

American Customer Satisfaction Index (ACSI)
Technology Acceptance Model (TAM)

Вот неполная схема взаимосвязи метрик

Запомнить

Метрика нужна, чтобы собирать обратную связь из внешнего мира и корректировать свои планы. Числа без привязки к контексту никому не интересны.
User Experience — это очень широкая область, поэтому и метрики в нем совершенно разные. Они могут фокусироваться на удобстве микро-взаимодействий пользователя с системой и на долгосрочных целях человека в продукте. Единого термометра не изобрели (хотя многие пытаются). Главное — UX-метрики замеряют восприятие человека.
Сделать достоверную метрику очень сложно. Изучите стандартные способы измерения пользовательского опыта, которые используется повсеместно. Не придумывайте велосипед.
Для систематизации работы используйте HEART-фреймворк от Google. Освоив этот инструмент, пробуйте новый или придумайте свой подход.
Все измерения в UX крутятся вокруг ограниченного набора концепций. Будут придуманы новые метрики, а концепции будут неизменны.

Статья впервые была опубликована в старом блоге по ссылке https://www.martsen.me/blog/quantifying-the-user-experience

Исследования, приоритеты и метрики в Atlassian

Thu, 24 Jan 2019 20:00:00 +0300

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

Проблема на уровне бизнеса

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

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

Спрашивать NPS внутри продукта — нормальная практика. А вот запросить доп.информацию о юзере и назначить интервью в том же окошке— это интересно :)

Метрики

NPS (индекс лояльности) — это главная метрика Atlassian. Важнее продаж, выручки, LTV и размера месячной аудитории. Но она не подходит для оценки релизов:

NPS — это интегральная метрика, на которую влияют многие аспекты бизнеса, а не только удобство продукта.

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

Продуктовым команда была нужна метрика, которая позволит напрямую оценить изменения на юзабилити. Индустриальным стандартом для этой цели является System Usability Scale (SUS).

Придуманный в 1986 году опросник оценки удобства пользования.

Главная проблема SUS при использовании в качестве in-product опроса— количество вопросов сильно прерывает работу пользователей, что снижает количество заполненных анкет.

Исследователи компании предложили использовать более компактные юзабилити-метрики: UMUX и UMUX-Lite. В них всего 4 и 2 вопроса соответственно, что позволяет разместить эти опрос внутри продукта и получать хорошую конверсию в ответ. Притом, ранние исследования доказали сильную корреляцию между этими метриками, SUS и NPS.

Вопросы из UMUX-Lite

Была проведена серия экспериментов, где последовательно спрашивали UMUX-Lite и NPS. Была найдена относительно сильная линейная зависимость между этими метриками (R² = 0.62), что позволило UMUX-Lite стать “мостиком” для NPS. Продуктовым командам выдали формулу “перегонки” из одного значения в другое: NPS = 3.18 ∗ (UMUX-Lite) − 200.6. Это позволило выставлять реалистичные цели на релизы.

NB! Не переиспользуйте эту формулу у себя. Установите свой процесс замера этих метрик и на своей аудитории найдите формулу зависимости.

Приоритизация инициатив

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

Reliability — требования к надежности.
Usability — требования к удобству использования.
Functionality — функциональные требования.

Каждая тема содержит иерархию из категорий и отдельных фичей.

Продуктовая команда Atlassian получает около 2000 комментариев в месяц. Для тэгирования (кодинга) такого объема информации ребята взяли к себе несколько стажеров. Разметка идет в общем Google Spreadsheet. Каждый комментарий может быть включен в 3 категории и обязательно назначается на ответственную команду.

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

Feature 1 — хороший кандидат для исправления. Большое количество аудитории часто ей пользуется и доля негативных комментов (Pain Index) тоже высока.

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

Числа в ячейках — это количество детракторов, которые упомянули о проблеме

Инструмент мониторинга: UX ScoreCard

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

Например, NPS мы можем получить только после выпуска продукта. Или метрики в стиле “время на выполнения задачи” хорошо замеряются в юзабилити-тестах, но не всегда четко отслеживаются “в бою”, т. к. мы не знаем контекст пользователя. Исключением, конечно, являются страницы с четкими Call to Action.

Поэтому в Atlassian используют два дашборда:

Early Signal Testing Scorecard (ESTS) — для дизайн-команды выносят метрики, которые помогают принимать решения на этапе разработки. Для этого они создали собственный мини-фреймворк — Early Signal Testing (никаких откровений особо по ссылке нет, но можно пощелкать презентацию).
Instrumented Scorecard — для продуктовой команды, когда фича уже в проде. Сюда выносят метрики, которые составлены по Google HEART и UMUX-Lite (это, видимо, замеряет Happiness).

Early Signal Testing Scorecard отображает метрики по новым и текущим юзерам

Находим эффект от продуктовых изменений в UMUX-Lite

Продуктологам хочется понимать “стрельнул” ли апдейт. Для этого аналитик строит линейную модель, которая пытается предсказать значение UMUX-Lite.

Линейные модели — не самые точные ML-алгоритмы, зато очень легко интерпретируются, что и нужно в работе над продуктом. Можно посмотреть, дал ли апдейт ожидаемый вклад. Ну или можно воспользоваться A/B-тестами.

Вывод

Анализ комментариев из NPS позволил подсветить проблемные места продукта. Через процесс кодинга удалось “оцифровать” жалобы клиентов и использовать количество жалоб как один из факторов в расстановке приоритетов.

Проблема медленной реакции NPS на изменения была решена созданием отдельной метрики для продуктовых команд.

UMUX-Lite стал мостиком между дизайнерами, продуктологами и бизнесом, который позволил быстрее получать обратную связь на релизы и понимание вклада в цель компании.
Более подробнее про метрику и методологию можно прочитать здесь: Measuring Usability: From the SUS to the UMUX-Lite.