Когда воображение не справляется с перегрузкой. Недавно наткнулся на исследование (The capacity limits of moving objects in the imagination) о том, как мы отслеживаем объекты в воображении. Суть исследования была проста, испытуемых просили представить окончания событий, которые они не видели целиком, событием были движущиеся объекты.

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

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

Игровые интерфейсы? Возможно. Но думаю, там это давно известно на уровне эмпирики.

В других областях когнитивная перегрузка давно уже используется, например, у тех же фокусников. Да и даже Гурджиев построил свою практику танцев на когнитивной перегрузке.

В итоге остаётся ощущение, что исследование скорее подтверждает то, что люди интуитивно знали давно.

О разнице между фактическим временем выполнения задачи и календарным временем проекта. Недавно работал над небольшой задачей. По факту ушло 9 часов чистой работы. По календарю - 22 дня.

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

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

На второй итерации прототипа я не стал тратить время на новую встречу, а записал видео с презентацией и разослал заинтересованным сторонам. Это ускорило сбор обратной связи. Были комментарии, под которые я сделал третью версию прототипа.

Здесь стоит отметить важную вещь: дизайн-решение - это почти всегда набор компромиссов. Я старался не ломать существующую дизайн-систему, но вследствии этого, в прототип просочились устаревшие решения. Это было одно из возможных решений, но не всем это нравилось. Потребовалась еще одна встреча, чтобы определиться с приоритетами - сохраняем дизайн-систему или делаем новые компоненты невзирая на сопутствующие издержки. Так прошла вторая неделя.

Четвёртую версию прототипа я сделал не сразу, пара дней ушла на другие задачи. В итоге, подготовил прототипы, записал видео с презентацией, разослал. Через два дня получил подтверждение: “Ок, забираем в работу”. Еще неделя.

В итоге: Задача решена. В эстимейт уложился (он был 2-12). Проект длился три недели, кажется, что не быстро, но никто не торопил. Команде придется доработать дизайн-систему под новые элементы: дополнительная работа для дизайнеров и разработчиков.

Общий результат по задаче не лучший, но, как по мне, вполне рабочий. Из выводов - нужно быть честным в оценке и учитывать не только “сколько займёт сделать”, но и “сколько займёт согласовать”.

Еще один простой эксперимент в Figma Make c вайбкодингом. Ничего конкретного, просто ради забавы. У меня на текущий результат ушло 13 запросов, в основном, чтобы уточнить физику объектов. Но, если вы захотите попробовать у себя такое сделать, то вот вам краткий промт:

Создай веб-приложение с полноценной 2D физической системой из 15 квадратных блоков разного размера и цвета. Блоки подчиняются гравитации, имеют инерцию и трение, отскакивают от границ контейнера с коэффициентом восстановления. При столкновении блоков друг с другом происходит отражение вектора движения с передачей импульса - неподвижный блок получает часть энергии движущегося по направлению первоначального вектора с коэффициентом затухания 0.4, что создает эффект домино и цепные реакции.

Пользователи могут захватывать и перетаскивать блоки мышью, при отпускании блок получает скорость на основе истории движения мыши для реалистичного эффекта "броска". Система включает детектирование коллизий между всеми объектами, разделение перекрывающихся блоков пропорционально их массе (зависящей от размера), ограничение максимальной скорости и автоматическую остановку анимации при отсутствии движения для оптимизации производительности.

Немного о генеративном ИИ. Готовя доклад об интеграции генеративных ИИ в интерфейсы современных цифровых продуктов (он был в июне в рамках фестиваля Среда), я наткнулся на множество материалов, касающихся не столько дизайна, сколько поведенческих аспектов взаимодействия человека и ИИ.
Все чаще поднимаются темы доверия, контроля, прозрачности, а также того, как проектировать системы, чтобы эти качества обеспечивать. Каждую неделю появляются новые статьи и размышления. И нет ощущения, что этот поток скоро иссякнет.

Мы находимся в эпицентре глубоких изменений. Пока не видно даже намека на точку, в которой можно было бы сказать: «Да, мы все поняли и теперь знаем, чего ждать».

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

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

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

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

В выступлении «Building Faster with AI» на Youtube доктор Эндрю Нг (Andrew Ng) делится принципами, которые помогут стартапам двигаться быстрее при создании продуктов при использовании ИИ. Я пару выписал:

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

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

Когда у вас много гипотез, фокусируйтесь на одной, но отказывайтесь от неё, если данные показывают ошибку в выбранном направлении, и берите в работу следующую.

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

Если для разработки кода ИИ ускоряет работу на 30–50%, то при работе над грубыми прототипами ускорение в 10+ раз. Этим надо пользоваться.

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

Код уже не так ценен, как раньше, не надо за него цепляться.

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

Бутылочное горлышко продуктов сдвигается от инженерии к менеджменту. Если раньше на одного PM приходилось 6–7 разработчиков, то, возможно, мы двигаемся к ситуации, когда соотношение будет 1 к 0,5.

Фокусируйтесь на разработке продукта, который любят пользователи, а потом уже думайте о каналах, ценообразовании, безопасности и т.д.

Немного про А/Б тестирование.
Компания добавила фильтр «Какой размер вам нужен?» на страницы с товарами (обувь) в верхней части каталога. Целью было упростить выбор, опираясь на закон Хика: чем больше вариантов одновременно приходится обрабатывать, тем дольше принимается решение.

С одной стороны, фильтром активно пользовались (29% click rate), но в целом результат оказался негативным

Ключевые метрики резко упали:
Доход на пользователя: -8,38%; Конверсия: -5,21%;
Средний чек: -3,26%;
На десктопе падение дохода достигло -14,02%.

Компания считает, что причиной падение стало то, что иногда большой выбор – это хорошо.

При всей интересности кейса к нему можно задать несколько вопросов.

- Насколько корректно был спланирован A/B-тест? Без понимания технической составляющей того, как проводилось тестирование, трудно оценить его достоверность.

- Могли ли технические факторы (скорость загрузки, работа фильтра) повлиять на результат? Важно проверить, чтобы внешние факторы не влияли на проведение теста.

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

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

Я решил попробовать перенести исполняемые скрипты из вайбкод платформы в no-code. В моем случае: из Figma Make во Framer (вот что вышло).

Framer выбрал почти случайно. Сначала думал про Webflow, но там в бесплатной версии нет доступа к кастомным блокам. А во Framer они есть — и это решило вопрос.

Сам процесс выглядел так:

Сначала сделал копию разработанного проекта в Figma Make, чтобы не поломать исходник. Потом попросил систему переписать код под интеграцию во Framer. Она выдала отдельные файлы для компонентов и инструкцию по переносу. Так как с Framer я до этого не работал, то это оказалось очень полезно.

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

Пробовал уточнить через Figma Make, но ответы были путаные. Жаль, что во Framer нет встроенного агента для правки кода. Пришлось идти в обход. После пяти неудачных попыток ChatGPT выдал рабочий вариант кода.

Результат можно посмотреть по ссылке: https://joyous-task-391568.framer.app/

Выводы:

Вручную я бы не сделал такой код за вечер. С ИИ получилось раз в 20 быстрее. Под реальную задачу, где важны нюансы, это может и не сработать. Но для экспериментов ценнее скорость.

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

Немного о брендинге. Недавно наткнулся на исследование 2023 года «The effect of brand names and logos’ figurativeness on memory: An experimental approach». Оно изучало, как название бренда и логотип влияют на три вещи: запоминание (recall), узнавание (recognition) и ассоциации (associations).
В эксперименте использовали вымышленные бренды. Меняли названия и логотипы, смотрели, как люди реагируют. Результаты оказались для меня интересными.

Фигуративные (образные) названия и логотипы, особенно связанные с природой (животные, растения), запоминаются лучше. Они вызывают больше ассоциаций. Но куда важнее — как название и логотип работают вместе.

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

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

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

Правильно подобранные название и логотип дают компании фору пользовательского внимания. В два раза больше внимания и узнаваемости — это серьезное преимущество. И, используя данные исследования как референс, можно посчитать ROI и другие показатели, связанные с вложением в бренд.

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

Здесь можно найти экспертов по самым разным направлениям: от дизайнеров до AI-инженеров с опытом работы в крутых компаниях. Отличное место для тех, кто только начинает карьеру, или для тех, кто хочет получить экспертное мнение по интересующим вопросам, чтобы найти для себя ментора.

Мне сам проект очень нравится, и я уже второй год там участвую. Вы все еще можете там пообщаться со мной там.

Посмотрел OpenAI DevDay 2025.
Впечатляет, как далеко шагнули возможности ChatGPT.

Apps in ChatGPT открывают новый уровень интеграции, теперь приложения смогут использовать LLM напрямую, а сами модели, работать внутри них.

Agent Kit позволит без кода создавать собственных агентов прямо в ChatGPT. Когда смотришь на этот инструмент, кажется, что многие привычные способы решения бизнес-задач просто устареют.

Для разработчиков самое интересное — Codex. Он обещает упростить создание ПО и, похоже, серьезно изменить рынок. Не знаю, разрушит ли он вайб платформы, но конкуренцию точно усилит. Уже сейчас видно, что время на разработку новых продуктов можно смело сокращать вдвое. Хоть найти product-market fit все так же непросто, но создавать продукты стало куда легче.

Лучше, конечно, посмотреть самим и составить свое мнение https://www.youtube.com/watch?v=hS1YqcewH0c

Еще хочу обратить внимание на один фрагмент из выступления доктора Эндрю Нг (Andrew Ng) «Building Faster with AI» на YouTube.

В нем он рассказывает про то, как собирать обратную связь о продукте — и насколько это важно, чтобы принимать правильные решения.
Я отметил этот фрагмент потому что часто встречаю материалы, где специалисты уверяют: «надо глубоко погружаться в исследования, иначе никак». А мне ближе подход Эндрю Нг, когда есть понимание, что можно использовать разные способы получить фидбэк, и у каждого способа своя точность и скорость, и в стартапе приоритет лучше отдавать скорости. Недаром он говорит о том, что в AI Fund запускают в среднем один стартап в месяц.

Варианты получения отзывов о продукте:

- Поиграться с продуктом самому (самый быстрый способ, 10 минут).
- Попросить мнение у 3 друзей или коллег (~ 0,5 дня).
- Спросить 3–10 незнакомцев, например, в кафе или в лобби отеля (~1 день).
- Отправить прототип группе из ~100 тестировщиков (~1 неделя).
- Отправить прототип 1 000 пользователям, чтобы получить качественные или количественные отзывы (~2 недели).
- И, наконец, полноценный запуск с A/B-тестом. Это самый медленный вариант, хотя часто о нем говорят как о лучшем и самом точном решении (2+ месяца).

Про Walmart, OpenAI и причем тут Клейтон Кристенсен. Walmart заявила о партнерстве с OpenAI, чтобы продавать товары прямо в ChatGPT. Это событие оказалось настолько значимым, что подтолкнуло акции Walmart на 5 % вверх, а это ни много ни мало, прирост почти на 41 миллиард долларов.

Финансовые аналитики позитивно восприняли новость, а на Reddit к ней отнеслись в основном скептически. Популярно мнение, что это следствие раздувания ИИ-пузыря и никакой новой ценности в сотрудничестве компаний не будет.

Но очевидно, что сотрудничество OpenAI с крупнейшим в США ритейлером — это продолжение стратегии по интеграции покупок в чат через функцию Instant Checkout, которая позволяет оформлять и оплачивать покупки прямо в чате.

Сам Instant Checkout представляет собой протокол агентской коммерции, который позволяет любому розничному продавцу или бизнесу интегрировать свои товары в ChatGPT. И этот протокол может стать началом нового этапа в развитии онлайн-торговли: подорвать доходы поисковиков, подорвать позиции маркетплейсов, поменять правила игры для всей онлайн-торговли. В общем, пример подрывной инновации.

Подрывная инновация — это создание нового способа взаимодействия с продуктом или брендом, который делает старые подходы устаревшими. Идея подрывной инновации была предложена Клейтоном Кристенсеном (Clayton M. Christensen) в 1995 году и подробно описана в книге «Дилемма инноватора» (The Innovator’s Dilemma). Книга есть на русском языке и считается бестселлером в области бизнес-литературы.

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

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

Вот к последнему посту иллюстрация роста трафика в США от ИИ систем к продавцам.

Про новое SEO. Я еще для себя не определился, какой термин стоит использовать: GEO (Generative Engine Optimization), AEO (Answer Engine Optimization) или какой-то другой. Думаю, что в итоге закрепится только один вариант. Но сути это не меняет: под AI-запросы все равно придется проводить специальную работу по оптимизации, если хочется оставаться в поле видимости пользователей.

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

Новое исследование Omnisend показывает: пользователи, по крайней мере в США, все чаще обращаются к LLM для поиска и выбора товаров. И главное — находят этот процесс удобным. А это значит, что тренд будет только расширяться. По мере того как новые LLM-инструменты станут доступнее, они быстро охватят и другие страны.

В июле 2025 года Omnisend опросили 4000 взрослых из США, Великобритании, Канады и Австралии о том, как они используют ИИ при онлайн-покупках. Краткие выводы такие:

- около 50% онлайн-покупателей в каждой стране используют GenAI для e-commerce-задач хотя бы раз в месяц;
- каждый четвертый утверждает, что ChatGPT предлагает товары лучше, чем Google;
- около 27–29% отмечают, что AI делает процесс онлайн-шопинга менее утомительным.

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

Бояться пока нечего. Сейчас важно готовиться к новой реальности и выстраивать стратегию оптимизации и продвижения с учетом AI.

Сегодняшний эксперимент с V0 был про создание связанной системы из двух экранов.

На первом — пульт, который можно открыть на мобильном.
На втором отображаются 3D объекты, которыми можно управлять с пульта.

Интерфейсы связаны через простой серверный API с синхронизацией каждые 100 миллисекунд. Этого достаточно, чтобы все выглядело плавно, без задержек.

Отрисовка через на Three.js. Простые фигуры строятся прямо в браузере. Уточка загружается из локального файла, а последний объект загружается по URL из внешнего источника.

Вот такой эксперимент за $1,75 на V0. Пока не придумал, как это может пригодиться, но мне нравится сама возможность создания простой мультиэкранности.

Это в продолжении прошлого поста, отвечая на комментарий Anton Korenyako в LinkedIn: “А как быстро у v0 получится реализовать трекбол на экране телефона?”

Задачка с трекболом оказалась с подвохом.

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

Но все решает формулировка задачи.

Во всех первых попытках системы выдавали результат вроде вращающегося глобуса, построенного на изменении углов Эйлера. На практике это оказалось неудачным решением. Такой подход крутит шар вокруг фиксированных осей X и Y, что быстро приводит к коллизиям и неестественному поведению.

После нескольких экспериментов я уточнил постановку.

Теперь вращение реализовано через ориентированную систему на основе нормалей касания. При касании определяется нормаль в точке пересечения луча и сферы. Далее между стартовой и текущей нормалями вычисляются ось и угол вращения. В итоге получается эффект катящегося шара и точка контакта остается под пальцем, как при реальном взаимодействии.

В итоге потратил 4 запроса на $0.45. И еще пару часов GPT пытаясь понять, как от начального решения перейти к работающему.

Результат можно попробовать самому https://v0-smartphone-trackball-ui.vercel.app/

Для тех, кто хочет улучшить производительность своих команд программистов, рекомендую видео с Nicole Forsgren автором нескольких книг и Senior Director of Developer Intelligence в Google «How to measure AI developer productivity in 2025».

Я сделал для себя несколько заметок, но вам, возможно, будут интересны другие тезисы.

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

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

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

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

В чем люди ошибаются, пытаясь измерить прирост своей продуктивности с использованием ИИ? Количество строк кода — плохой показатель на сегодня. и другие прежние метрики уже плохо работают. Мы можем отследить код, написанный людьми и сгенерированный ИИ, и понять, какой процент кода “выживает”. На основе этого можно оценивать качество. Это немного, но шаг в правильном направлении.

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


Похоже, предел человека — это около четырех часов продуктивной работы в день. Это отсылка к большой работе Глории Марк (Gloria Mark), посвящённой изучению влияния цифровых технологий на внимание, многозадачность и рабочие процессы. Книга вышла и на русском языке: «Метавнимание. Как сохранять продуктивность и удерживать фокус в цифровой реальности».

Чтобы добраться до продуктивного состояния потока, нужно потратить час или два. Но сейчас вся работа с ИИ идет прерывистыми блоками. Нужны инструменты, которые помогут облегчить погружение в поток и возвращение к нему с помощью ИИ. Эта область пока ждет исследований и ответов.

Большинство команд может двигаться быстрее. Но не всегда прирост скорости — это благо. Можно выпускать мусор каждый день, но зачем? Нужна стратегия и умная команда менеджеров, чтобы понимать, что выпускать и с чем экспериментировать.

Какие показатели можно использовать для оценки продуктивности с применением ИИ? Одним из них может быть способность быстро экспериментировать и тестировать. Но это сложно напрямую связать с работой ИИ в руках конкретного разработчика.

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

Как показать эффективность внедрения ИИ для бизнеса? Все зависит от приоритетов бизнеса, какой бы ни была цель — рост доли рынка, прибыль или экономия — под каждую можно подобрать свои метрики.

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

Хорошую тему поднял Якоб Нильсен в статье “Slow AI: Designing User Control for Long Tasks”. Он рассуждает о пользовательском опыте при выполнении долгих задач, характерных для современных ИИ-систем.

Вот несколько идей из статьи, которые мне показались особенно интересными.

Сегодня агенты не всегда отвечают мгновенно. Мы ждем генерации картинки минуты, а создание видео десятки минут. Уже сейчас ИИ может работать над задачами по 30 часов, и со временем этот срок может растянуться на дни или даже недели. Возможно, однажды мы доживем до момента, когда ИИ будет выполнять задачи годами и все будет происходить без участия человека.

Такой “медленный ИИ” создает новые UX-проблемы: потерю контроля, снижение фокуса, риск сбоев. Это требует другого подхода к проектированию интерфейсов.

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

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

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

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

Хорошо, если большая задача разбивается на предсказуемые фрагменты продолжительностью 5–15 минут. Тогда ее проще восстанавливать при сбое и легче контролировать прогресс выполнения.

Чтобы сохранить контроль над процессом, система должна показывать промежуточные результаты. Это будет снижать тревожность пользователей и даст уверенность, что все идет по плану.

Когда пользователь возвращается к задаче после перерыва, система должна помочь ему быстро восстановить/вспомнить контекст задачи (context reboarding). Уведомления, письма и сообщения тоже стоит писать так, чтобы напоминать, о какой задаче идет речь.

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

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

К тендеру я готовил презентацию с разными подходами и предложениями по изменению дизайна сайта, которые должны были повлиять на поведения посетителей. Изменения были обоснованными, в базе были метрики и мы показывали ожидаемые изменения при внедрении тех или иных решений.
Но когда речь идет о проектах с MAU в 10–20 миллионов пользователей, нужны не только быстрые улучшения. Важно думать о решениях, которые обеспечат рост аудитории на горизонте в год-два. Только так можно оправдать инвестиции в редизайн.

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

Так родилась идея добавить на сайт онлайн-игры. Для меня это был очевидный ход, потому что пример New York Times давно показал, что это работает. Но, как оказалось, не все знакомы с их результатами.
Мини-игры у NYT расположены внизу главной страницы, они встроены в рассылки и доступны подписчикам. Они стали не только инструментом вовлечения, но и драйвером роста платных подписок.

Axios писал об этом в статье “Games are helping the New York Times thrive amid media chaos”. В 2023 году в игры NYT сыграли более 8 миллиардов раз, а это около 22 миллионов игр в день. И для издательства цель не в том, чтобы стать игровой компанией, а в том, чтобы добавить ценности помимо основного продукта и стать частью повседневной жизни пользователей.
Мое предложение не было самым коротким путем к росту аудитории, но, как мне кажется, это пример того, как можно взять уже работающую идею и адаптировать под себя. И пусть это требует затрат, но изменить поведение пользователей, не меняя само содержание предложения, почти невозможно.

Вот такая история на сегодня. Хорошего всем дня 🙂