«UX меняет адрес: от удобства к мотивации пользователя
Расходы на софт измеряются триллионами долларов, но и вендоры, и их клиенты упираются в один и тот же вопрос: как добиться того, чтобы продуктом действительно пользовались.
Продукт не создаёт потребность, он может лишь попасть в существующую. Поэтому бесконечная оптимизация характеристик (605 метрик, 104 определения UX) сама по себе ничего не гарантирует.
Спросить про потребность напрямую не получится: до появления предмета потребность не названа, и пользователь описывает её через продукты, которые уже видел.
Косвенный индикатор попадания — принятие технологии. TAM раскладывает его на воспринимаемую полезность и воспринимаемую лёгкость использования и объясняет около 40% дисперсии.
Но TAM статична. На что жать — на полезность или на удобство — подсказывает тип мотивации: контролируемая мотивация связана с полезностью, автономная — с лёгкостью использования.
UX не отменяется, а меняет адрес: через опыт взаимодействия он удовлетворяет три базовые психологические потребности (автономия, компетентность, связанность) и тем самым сдвигает мотивацию к автономной.
В 2025 году, по подсчётам Gartner, глобальные расходы на ИТ составили 5 трлн 577 млрд долларов США. Почти половина этой суммы — 2 трлн 763 млрд — пришлась на две категории: собственно софт (1,271 трлн) и ИТ-услуги (1,492 трлн), куда входят разработка, внедрение и поддержка систем. Остальное — это железо, устройства и услуги связи. За этими цифрами стоит один вопрос, объединяющий и вендоров, и их клиентов: как оправдать такие затраты?
Производители софта отвечают на него через продукт и его характеристики — те, что дадут пользователям возможность закрыть свои потребности. Бизнес, который планирует внедрять систему автоматизации, отвечает иначе: нужно, чтобы система использовалась по назначению и с максимальной отдачей.
Но и первые, и вторые упираются в проблемы, которые принято решать по старинке. Продукт по-прежнему строится вокруг UX-метрик, почти никогда не связанных с реальной экономикой, а успешные кейсы плохо переносятся между проектами (подробнее здесь). Внедрение же идёт добровольно-принудительно: решение принимается сверху и редко встречает поддержку снизу.
Этот разрыв знаком каждому, кто работал в корпоративном контуре:
CRM, которую руководство считает единым источником правды, тогда как менеджеры по продажам продолжают вести сделки в личных таблицах и заполняют карточки в последнюю неделю квартала;
тайм-трекер, в который часы вносятся в пятницу вечером одним движением и примерно наугад;
корпоративный мессенджер, проигравший личным чатам в Telegram или WhatsApp, потому что «там и так все есть»;
ERP, которую внедряли два года, а рядом с ней живёт теневой контур из Excel-файлов, где и происходит настоящая работа.
Во всех четырёх случаях формальные метрики внедрения выглядят прилично: лицензии закуплены, пользователи заведены, MAU есть. Работа при этом происходит не в системе.
Но что, если обе проблемы — и продуктовую, и внедренческую — можно решить, поставив во главу угла не функционал, а мотивацию пользователя?
Продукт и потребности
Годами разработка ИТ-решений шла по пути поиска оптимальных характеристик продукта через исследования пользовательского опыта. Сначала мы выделили удобство использования, надёжность, поддерживаемость и безопасность. Затем начали дробить их на более мелкие составляющие: внутри usability появились «защита от дурака», эстетика интерфейса, доступность. И это далеко не полный список — сегодня в нашем распоряжении оказалось около 605 метрик из 64 научных публикаций, более 200 методов исследования и 104 определения UX.
Но в поисках идеального сочетания характеристик, которое сделает продукт успешным, мы упустили главное. Продукт сам по себе не создаёт у человека потребность — он может лишь удовлетворить уже существующую. Поэтому у каждого из нас найдётся пара примеров того, как приложение было сделано по уму, но так и не взлетело. И конкуренция на рынке, отсутствие бюджета на маркетинг или COVID могут быть здесь ни при чём. Продукт просто не закрывал потребность, которая у пользователей была, — или закрывал ту, которой у них не было.
Здесь нужна небольшая оговорка. В редких случаях продукт действительно формирует новые когнитивно-технологические зависимости и сенсорные нормы. GPS-навигация и «эффект Google» — яркие примеры того, как внешняя технология берёт на себя выполнение функции (ориентация в пространстве, память), в результате чего соответствующая зона мозга снижает активность, а нейронные связи ослабевают. Но такие продукты — крайне редкие истории, о которых стоит поговорить отдельно. Наш типовой продукт на такое не претендует: это SaaS-решение для малого или среднего бизнеса, корпоративная система автоматизации или мобильное приложение для медитации.
Значит ли это, что всё, что мы узнали в рамках традиционного UX-подхода, бесполезно? Отнюдь — и мы увидим это дальше. UX не исчезает из схемы, он меняет в ней адрес.
Принятие технологии
«Люди не знают, чего они хотят, пока вы им это не покажете». Стив Джобс
Казалось бы, потребность можно выявить напрямую — просто спросив пользователя. Однако у такого подхода есть два принципиальных ограничения.
Во-первых, прямой опрос плохо масштабируется. Он работает, когда целевая аудитория относительно небольшая и обозримая. Когда у продукта тысячи или миллионы потенциальных пользователей, перенос выводов с небольшой выборки на всю ЦА становится занятием весьма противоречивым: речь идёт не о биологически или социально обусловленных потребностях, которые у людей более или менее общие, а о функциональных потребностях применительно к софту — а они сильно зависят от роли, контекста и задачи.
Во-вторых — и это важнее — потребность плохо поддаётся прямому называнию. До встречи со своим предметом она существует как неопределённое состояние напряжения: человек чувствует, что что-то не так, но не знает, что именно ему нужно. Направленность потребность приобретает только тогда, когда находит предмет, способный её удовлетворить. Это и есть опредмечивание, и продукт как раз выступает таким предметом: он предлагает конкретный способ реализации потребности и тем самым позволяет пользователю её осознать.
Отсюда практическое следствие. Когда мы спрашиваем «что вам нужно?», пользователь отвечает в терминах предметов, которые уже знает: он описывает знакомые продукты, их функции и их недостатки. Просьба «сделайте лошадь быстрее» — не ошибка респондента, а единственная доступная ему форма ответа. Потребность при этом продукт не создаёт — он даёт ей предмет и делает её видимой. В этом смысле фраза Джобса не о том, что потребности нет, а о том, что до появления предмета она не названа.
Если напрямую не получается, остаются косвенные методы. Одно мы можем сказать более или менее уверенно: экономическая успешность продукта зависит от того, пользуются им или нет. А если так, то отдельные характеристики продукта нас уже не очень интересуют. Для нас продукт — это целостная технология, которая направлена на удовлетворение функциональной потребности пользователя и имеет у него некоторую степень принятия. И чем выше степень принятия, тем точнее мы попали в потребность.
Цену этого хода стоит оговорить сразу. Принятие — косвенный индикатор, а не измерение потребности: мы наблюдаем не саму потребность, а то, насколько уверенно пользователь выбирает наш продукт в качестве её предмета. Зато этот индикатор измерим и сопоставим между релизами и продуктами — чего не скажешь о прямых вопросах про потребности.
Именно такая логика заложена в Technology Acceptance Model (TAM) — модель была создана в 1989 году, чтобы объяснять и предсказывать принятие технологий пользователями. Базовая TAM состоит из двух конструктов.
Первый — воспринимаемая полезность (perceived usefulness) — показывает, насколько, по мнению пользователя, технология повышает его эффективность. Именно она теснее всего связана с потребностью, поскольку позволяет оценить, насколько продукт её закрывает.
Второй — воспринимаемая лёгкость использования (perceived ease of use) — говорит о том, насколько использование свободно от усилий. Этот конструкт отвечает за то, насколько правильно мы поняли пользовательские сценарии и реализовали их в продукте.
Таким образом, намерение использовать продукт (behavioral intention) складывается из сопоставления получаемой пользы и затраченных усилий. А намерение напрямую связано с наблюдаемыми параметрами использования — частотой и продолжительностью. TAM объясняет около 40% дисперсии принятия технологии, и воспринимаемая полезность в ней — самый сильный предиктор намерения.
И это неспроста: ради удовлетворения потребности людям приходится пользоваться далеко не самыми быстрыми, удобными и эстетичными продуктами.
Бухгалтер работает в 1С, а не в приложении с идеальным интерфейсом, потому что отчётность сдаётся в понятном налоговой формате.
Финансовый аналитик собирает модель в Excel, хотя там нет ни версионирования, ни валидации, — потому что на выходе нужен файл, который примет и проверит любой коллега.
Разработчик заполняет тяжёлый workflow в трекере, потому что иначе релиз не пройдёт процедуру приёмки.
Пассажир проходит через интерфейс бронирования из нулевых, если на этом рейсе лучшая цена и расписание.
Во всех случаях полезность перевешивает неудобство. Обратное, кстати, работает хуже: безупречный интерфейс редко компенсирует отсутствие пользы.
Измеряется TAM опросником — короткими утверждениями со шкалой Ликерта (обычно от 1 «полностью не согласен» до 7 «полностью согласен»), где в текст подставляется название конкретной системы. Формулировки из исходной работы 1989 года звучат примерно так.
Воспринимаемая полезность:
«Использование [системы] позволило бы мне выполнять рабочие задачи быстрее».
«Использование [системы] повысило бы мою производительность».
«Использование [системы] улучшило бы качество моей работы».
«Я считаю [систему] полезной в моей работе».
Воспринимаемая лёгкость использования:
«Мне было бы легко научиться работать с [системой]».
«Мне легко добиться от [системы] того, что мне нужно».
«Моё взаимодействие с [системой] понятно и прозрачно».
«Я считаю [систему] простой в использовании».
Намерение использовать:
«Я собираюсь пользоваться [системой] в течение следующих трёх месяцев».
«При возможности выбора я предпочту [систему] другим инструментам».
Мотивация
Нам как практикам неинтересна статичная оценка полезности и простоты использования нашего продукта. Мы хотим понять, как на эти оценки повлиять и в конечном итоге приблизить продукт к потребности пользователя. Поэтому одной TAM недостаточно: она ничего не говорит о том, почему у человека формируется та или иная оценка. Одним и тем же продуктом можно пользоваться по принуждению и по собственной инициативе — и оценки будут разными.
Тот же таск-трекер: разработчик, который проставляет статусы, потому что иначе придёт тимлид, и тимлид, который держит там план спринта, потому что без доски не видит картину.
Та же корпоративная LMS: обязательный курс по информационной безопасности, который проходят в последний день, и курс по новому инструменту, на который записались сами.
Тот же BI-дашборд: руководитель, который открывает его перед советом директоров, и аналитик, который живёт в нём каждый день.
Продукт один, функциональность одна. Полезность, удобство и — главное — устойчивость использования разные.
На помощь приходит мотивация, определяющая направленность, организованность, активность и устойчивость поведения. Разобраться с ней поможет теория самодетерминации (Self-Determination Theory, SDT), которая различает амотивацию, внешнюю и внутреннюю мотивацию. На крайнем левом конце континуума самодетерминации находится амотивация — состояние отсутствия намерения действовать. На крайнем правом — внутренняя мотивация, то есть выполнение деятельности ради удовлетворения, присущего самой деятельности. Но именно эти полюса континуума интересуют нас меньше всего.
Амотивация означает, что никакого использования продукта не будет вообще: сотруднику выдали доступ к дашборду, он открыл его один раз, не увидел связи между цифрами и своей работой и больше не возвращался. Здесь не поможет ни редизайн, ни обучение — работать надо с тем, зачем этот человек вообще должен туда заходить.
Внутренняя мотивация, наоборот, делает принятие практически безусловным: в Figma, Notion, Strava или игру человек заходит потому, что сам процесс ему нравится, и ради этого готов терпеть многое. Проблема в том, что на внутреннюю мотивацию нельзя рассчитывать по заказу. Согласно SDT, она возникает только там, где деятельность сама по себе обладает интересом, новизной, вызовом или эстетической ценностью. Большая часть корпоративного софта — согласование счетов, учёт рабочего времени, заполнение регламентов — такими свойствами не обладает. Поэтому надежда «сделаем так, чтобы пользователю это нравилось само по себе» для B2B-продукта обычно нереализуема.
Остаётся самое практичное — внешняя мотивация, которая обозначает выполнение деятельности ради некоего отделимого результата. Она неоднородна и распадается на четыре типа, различающихся степенью автономии.
Внешняя регуляция (external regulation) — наименее автономная форма, когда поведение выполняется для удовлетворения внешнего требования или в обмен на вознаграждение. Это CRM, в которой считается бонус, и сделка без карточки в системе просто не существует для расчёта. Это тайм-трекер, без заполнения которого не закрывается табель. Это сервис расходов, через который только и можно получить компенсацию за командировку. Продуктовая команда должна понимать цену такой мотивации: использование держится ровно до тех пор, пока держится требование. Отменили привязку бонуса — и метрики складываются в течение месяца, хотя до этого выглядели здоровыми.
Интроецированная регуляция (introjected regulation) — относительно контролируемая форма регуляции, при которой поведение выполняется, чтобы избежать чувства вины или тревоги либо чтобы испытать гордость. Регуляция здесь уже внутри человека, но ещё не стала его собственной. Так работают публичные дашборды и лидерборды, где пустая колонка напротив твоего имени видна всей команде; так работают стрики в Duolingo, где главный аргумент продолжать — не потерять накопленное; так работает неловкость от того, что ты единственный в отделе не заполнил профиль. Использование получается устойчивее, чем на внешней регуляции, но оплачивается тревогой — а значит, рано или поздно приводит к выгоранию, избеганию или имитации активности.
Регуляция через идентификацию (identified regulation) — осознанное принятие ценности поведенческой цели, при котором действие признаётся или воспринимается как личностно значимое. Менеджер по продажам ведёт CRM не из-за бонуса, а потому что сам видел: сделки с полной историей касаний закрываются чаще. Аналитик пишет документацию, потому что через полгода сам же будет её читать. Такой пользователь не нуждается во внешнем контроле — но и спрашивает с продукта по-другому: он держит инструмент ровно до тех пор, пока тот выполняет обещание, и уходит молча, когда перестаёт.
Интегрированная регуляция (integrated regulation) — наиболее автономная форма внешней мотивации. Интеграция происходит, когда идентифицированные регуляции полностью ассимилируются личностью, то есть были оценены и приведены в соответствие с другими её ценностями и потребностями. На практике это момент, когда инструмент становится частью профессиональной идентичности: «я человек, который планирует» — и таск-менеджер уже не инструмент дисциплины, а способ работать; дизайнер поддерживает дизайн-систему, потому что аккуратная библиотека компонентов — часть его представления о качестве. Это самый дорогой для конкурента тип пользователя: максимальное удержание, низкая чувствительность к цене и источник рекомендаций.
Внешнюю мотивацию принято делить на две группы. Автономная мотивация включает регуляцию через идентификацию и интегрированную регуляцию (а за пределами внешней мотивации — ещё и внутреннюю), контролируемая мотивация состоит из внешней и интроецированной регуляции.
Это деление важно потому, что от него зависит не только наличие деятельности, но и её характер. По мере того как человек интернализует регуляцию и ассимилирует её, он испытывает большую автономию в действии — и ведёт себя иначе: дольше сохраняет поведение без внешней поддержки, вовлекается глубже, выдаёт результат лучшего качества и чувствует себя при этом лучше. Контролируемая мотивация тоже даёт поведение, но другое: формальное соответствие требованию, минимально достаточное усилие и больше негативных эмоций. Исследования реакции сотрудников на внедрение новых ИТ-систем показывают ровно это: охотно и с удовольствием системой пользовались только те, у кого была высокая автономная мотивация и низкая внешняя регуляция.
Мотивация и принятие технологии
Важно понимать, что использование технологий, как и большинство других занятий, обычно мотивировано сразу несколькими видами регуляции. Но каждый тип по-своему связан с принятием технологии. Контролируемая мотивация связана с воспринимаемой полезностью и не связана с воспринимаемой лёгкостью использования: представление о пользе формируется извне — руководителем, коллегами, регламентом, — а вот суждение об удобстве человек выносит сам. Автономная мотивация, напротив, сильнее связана с воспринимаемой лёгкостью использования, чем с воспринимаемой полезностью: в пользе такой пользователь уже убеждён.
Отсюда следует вполне практический вывод: приоритет между полезностью и удобством зависит не от продукта, а от того, с какой мотивацией пользователь к нему приходит.
Self-service SaaS: человек нашёл сервис сам, зарегистрировался сам и платит сам. Его не надо убеждать в пользе — он пришёл за ней. Зато он отваливается на трении: на импорте данных, на пустом состоянии, на третьем шаге онбординга, на медленной загрузке. Рычаг здесь — time to first value и лёгкость использования.
Корпоративное внедрение сверху: доступ выдали, пользоваться обязали. Такой пользователь не сомневается, что будет заходить в систему, — он сомневается, что в этом есть смысл. Полировка интерфейса на его оценку почти не повлияет; повлияет доказательство пользы в его собственных терминах: сколько времени он сэкономил, сколько шагов согласования исчезло, что ему больше не нужно делать руками.
Внутренний инструмент для разных ролей: аналитику, который живёт в дашборде, критичны скорость фильтров и предсказуемость выгрузки; руководителю, который заходит раз в месяц, — то, что цифра на экране отвечает на его вопрос. Один продукт, два разных приоритета в бэклоге.
Оговорка, без которой этот вывод легко испортить: «не связана» означает отсутствие статистической связи с оценкой, а не разрешение пренебречь удобством. Неудобный продукт при контролируемой мотивации не перестанет казаться полезным — он просто обрастёт обходными путями: теневым Excel, заполнением в последний день, копипастом из мессенджера. Речь о приоритете аргументации и бэклога, а не о праве делать плохие интерфейсы.
К счастью для практиков, инструмент замера уже существует. User Motivation Inventory (UMI) — многомерная шкала мотивации из 18 пунктов, основанная на теории самодетерминации и созданная специально для изучения мотивации пользователей. Она измеряет внутреннюю мотивацию, интегрированную, идентифицированную, интроецированную и внешнюю регуляцию, а также амотивацию — по три утверждения на каждый из шести конструктов. UMI разрабатывалась для измерения общей мотивации к взаимодействию с конкретной технологией, то есть встаёт рядом с TAM и отвечает на вопрос «почему», пока TAM отвечает на вопрос «насколько».
Новое место UX
Итак, принятие технологии позволяет нам понять, насколько и в каких аспектах удовлетворена функциональная потребность пользователей. А мотивация говорит о том, на чём стоит сфокусировать внимание: на полезности или на простоте использования. Но для полноты картины осталось понять, как продукт может влиять на саму мотивацию. И вот здесь UX находит своё место. А проводником изменений выступают базовые психологические потребности, на которые влияет непосредственный опыт взаимодействия с продуктом.
Здесь схема перестаёт быть линейной: продукт стоит в конце цепочки как её результат, но через опыт взаимодействия он же влияет на мотивацию — то есть на одно из предшествующих ему звеньев. Это не ошибка, а обратная связь, и именно она даёт продуктовой команде рычаг. Функциональную потребность мы изменить не можем, мотивацию — можем.
Согласно SDT, существует три врождённые и универсальные психологические потребности: автономия (я сам решаю), компетентность (у меня получается) и связанность (я не один, меня принимают). Если потребности удовлетворены, мотивация может перейти от контролируемой к автономной; если фрустрированы — сдвинуться в обратную сторону.
Для продукта это означает, что мотивацией нельзя распорядиться напрямую, но можно спроектировать опыт, который её сдвигает. Автономия — это настоящий выбор вместо единственного пути: настраиваемые представления, отменяемые действия, возможность пропустить шаг, объяснение «зачем» вместо предписания «сделай», отсутствие тёмных паттернов и принудительных модальных окон. Компетентность — это короткий путь к первому результату, понятная обратная связь на каждое действие, видимый прогресс, ошибки, которые можно исправить без потерь, и постепенно открывающаяся сложность вместо стены возможностей на старте. Связанность — это видимая команда и общие артефакты, признание вклада, человеческая, а не безличная поддержка, живое сообщество вокруг продукта.
Заметим, что это те же самые вещи, которыми UX-дизайн занимался всегда. Меняется не набор инструментов, а то, за что они отвечают: не за абстрактное удобство, а за конкретный механизм — удовлетворение базовых потребностей, сдвиг мотивации к автономной и, через него, рост принятия. Именно это и даёт UX-метрикам ту связь с использование продукта, которой им обычно не хватает.
А теперь финальный штрих: мы берём наши продуктовые метрики и накладываем их на три базовые психологические потребности.
Заключение
Схема, которую мы собрали, читается справа налево. В конце стоит продукт, перед ним — принятие технологии, перед принятием — мотивация, а в самом начале — функциональная потребность, о которой нельзя спросить напрямую. Из этой схемы следуют три практических вывода.
Первый: попытки создать продукт без понимания мотивации и принятия не имеют смысла. Можно сколь угодно долго подбирать характеристики из 605 доступных метрик, но продукт не создаёт потребность — он лишь попадает или не попадает в существующую. Без ответа на вопросы «какую потребность мы закрываем» и «с какой мотивацией человек к нам приходит» оптимизация характеристик превращается в перебор вариантов наугад.
Второй: индикатором попадания в потребность служит принятие. Саму потребность измерить не получится, а вот степень принятия технологии измерима, сопоставима между релизами и продуктами и разложима на воспринимаемую полезность и воспринимаемую лёгкость использования. Это даёт продуктовой команде то, чего не даёт прямой опрос: воспроизводимый замер с понятной связью с частотой и продолжительностью использования. При этом принятие остаётся косвенным индикатором — TAM объясняет около 40% дисперсии, так что низкое принятие точно сигнализирует о проблеме, а высокое не гарантирует, что мы поняли потребность до конца.
Третий: доработка продукта должна учитывать текущую мотивацию пользователей. Один и тот же бэклог даёт разный результат в зависимости от того, кто перед нами. Пользователю с контролируемой мотивацией нужно доказательство пользы в его собственных терминах; пользователю с автономной мотивацией — снятие трения. А если мы хотим не подстраиваться под мотивацию, а менять её, рычаг один: опыт взаимодействия, который удовлетворяет автономию, компетентность и связанность. Это и есть новое место UX — не самостоятельная цель и не набор метрик ради метрик, а механизм, через который продукт сдвигает мотивацию и тем самым повышает собственное принятие.
Практический минимум из всего сказанного выглядит так: замерять не только воронку и UX-метрики, но и принятие (TAM) вместе с мотивацией (UMI); сегментировать пользователей не только по роли и тарифу, но и по типу регуляции; и проверять каждую фичу вопросом не «стало ли удобнее», а «какую базовую потребность это поддерживает и куда сдвигает мотивацию».
Что почитать
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.