NN/g: Начинайте не с AI, а с проблемы

Калеб Спонхейм, специалист по пользовательскому опыту в Nielsen Norman Group, излагает 4-минутный аргумент в пользу принципа, который кажется очевидным, но систематически нарушается на практике: при создании AI-функций начинайте с проблемы, которую нужно решить, а не с доступной технологии.

Видео адресовано дизайнерам, product manager’ам и стратегам, которых подталкивают добавить AI в существующие продукты или создать AI-нативные функции. Наиболее полезно на ранних этапах проекта, до принятия решений по инструментарию, а также для команд, испытывающих внутреннее давление с требованием выпустить что-то AI-powered без чёткого пользовательского обоснования.

Ключевые тезисы:

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

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