Бен Томпсон пытается систематизировать подходы разных компаний в области ИИ.

Он предлагает 2х2 матрицу с разбивкой по «философии в отношении ИИ» и «влияние на существующую бизнес-модель».

Если супер-кратко, то есть два лагеря:

1. Софт (или ИИ в контексте 2025г от Рождества Христова) — это «the bicycle of the mind» как однажды выразился Стив Джобс еще до того, как стал носить черные водолазки. То есть, это человеческий усилитель.

2. Софт/ИИ — это личный слуга, который делает вещи за человека.

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

Бен подметил эти два лагеря еще в 2018 (а может и ранее) и периодически ссылается на это в текстах и развивает мысль.

Борьба за трактовки и интерпретации как может и должен выглядеть прислужливый ИИ разгорячилась где-то в 2022-м вместе с бумом LLM и технологии трансформеров.

Источник бума технооптимисты, учёные и инженеры во главе с Эндрю Ыном (Andrew Ng). В 2024-м он предложил свои дизайн-паттерны для агентов. Технари взяли их на вооружение и понесли в треды на твиттере и в презентации к инвесторам. Anthropic нанимает штатного философа, чтобы стройно излагать кто они и зачем.

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

• книга Designing Agentive Technology: AI That Works for People (статья от автора)
• исследования и гайдбуки от People AI Research Group из Google
• еще в 2019м на ACM SIGCHI учёные и практики рассказывали как систематизируют опыт и делают полезные умные продукты.

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

• sentient design (автора)
• в январе ждем Designing Assistant Technology: AI That Makes Us Smarter

Если максимально упростить, то:

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

Кто победит? Как говорится, it depends.

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

Предлагается построить мостик от тех.ресерча (research scientists) к продуктовым командам и обратно.

В этой первой статье описана ментальная модель для ресерчеров: исследование — это продукт учёных, продуктовая команда — это клиенты.

В такой картине мира:

research is a product with Product teams as customers and users.

А отталкиваясь от этой идеи можно начать задавать правильные вопросы с точки зрения полезности проводимой работы (адаптированный список из книги Inspired)

Looking through the lens of the Product team being the customer, we can reformulate the risks as follows:
Value Risk: Will customers Product teams find the product research valuable enough to buy or use?
Usability Risk: Can users Product teams easily understand and interact with the product research?
Feasibility Risk: Can the product research be done with available resources?
Business Viability Risk: Does the product research align with the company’s overall business strategy and goals?

Источник: Bridging the Product & Research gap — Part I: Demystifying Product for Researchers

P.S.
Жду вторую часть материала про то, на что продактам следует обращать внимание при работе с учеными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So What?

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

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

Это, пожалуй, самая познавательная для меня статья из 2021. Не помню, почему не делился раньше, но исправляюсь.

Она больше про проектирование, а не аналитику, но позволяет взглянуть на продуктовую работу под другим углом.

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

Кратко пересказывать не буду. Это достойно полного прочтения

https://stephenanderson.medium.com/when-customer-journeys-dont-work-arcs-loops-terrain-4f7f8ac6df4e

Кевин Дэйм рассказал о проблеме нехватки времени на продумывание вижена в продуктовых командах YouTube.
Причина — скиллсет команд в Google заточен на итерации и быструю проверку гипотез. Такой подход называется versioning. И он оправдывает себя в приложениях с миллиардами пользователей, где даже мелкие изменения могут дать большой импакт.

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

Ключевые слайды

Product Visioning at Google — https://www.youtube.com/watch?v=fMCc89kO5BI
The Power of Visioning — https://design.google/library/youtube-visioning/

В феврале на Flo Data Meetup я рассказывал про кейс с работы. В нём я применил «классические» методы продуктового анализа и теорию графов.

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

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

Видео содержит:
— Вводную про продуктовые подходы
— Небольшой обзор на науку Human-Computer Interaction, из которой я люблю брать новые идеи
— Информацию про продукт
— Вопросы на которые стейкхолдеры хотели получить ответы
— Как я перевёл эти вопросы на язык данных и как начал ресерч
— Почему не хватило «классических» методов
— Минимум про матрицы и теорию графов
— Сниппет кода, который поможет самому сделать похожий ресерч
— Как я интерпретировал полученные данные
— Что мы сделали с инсайтами и какой получили эффект в метриках
— Книжки для самообразования
— QnA секцию, из которой вы сможете немного узнать про нюансы работы с данными в Flo + немного обсудили филосовские вопросы 🙂

Seekers, Providers, Welcomers, and Storytellers: Modeling Social Roles in Online Health Communities я рекомендую прочитать тем, кто занимается продуктами с групповыми/социальными фичами: Q&A-сервисы, ПО для коллективной работы, мультиплеерные игры, «социальный» e-commerce и т. д.

Группа ученых из Carnegie Mellon и Stanford решила изучить феномен «успеха» крупнейшего форума по теме рака в мире — Cancer Survivor Network (CSN). Сайт существует с начала 2000-х и стал самым крупным в своем сегменте. Было много аналогичных площадок, но все рано или поздно затухали, а CSN развивается и по сей день.

У социологов возникла гипотеза — на форуме сложилась определенная структура социальных ролей, которая обеспечивала «баланс» в сообществе и позволила ему развиваться. Осталось ее проверить на данных, которые были предоставлены American Cancer Society (а это вся переписка на сайте с 2003 по 2018 гг).

Но для начала надо формально определить, чем является «социальная роль» на данных. Для этого они обратились к теории. Социальная роль в науке определяется 4 факторами:

1. Цель — у индивида в сообществе есть цель, которую он преследует исходя из собственных интересов.
2. Взаимодействия — роль контактирует с другими участниками сообщества. На форуме эти взаимодействия проявляются по-разному: старт новой темы обсуждений, написание ответа, лайк комментария или обращение в директ.
3. Ожидания — социальные роли при взаимодействии рассчитывают на определенную обратную связь. Например, на работе начальник и подчиненный знают чего ждать друг от друга и соответственно подбирают стиль общения. В онлайн-сообществах обычно нет явно формализованных ролей и только «старожилы» знают как и с кем общаться. Например, из-за этого новички на StackOverflow часто стесняют вступать в разговоры и задавать вопросы.
4. Контекст — некоторые роли могут существовать только при определенных условиях. Например, «поставщик информации» существует во многих типах сообществах, включая Q&A сервисы, рабочие группы и форумы. А вот «коммитер» — это специфичная роль для сообщества разработчиков (GitHub, Bitbucket). Приватность также играет большое значение. Поведение человека на публике обычно отличается от его поведения наедине или с родными.

Кратко про технические моменты:

1. При помощи кластеризации решили определить какие вообще есть роли, т. к. «доменные эксперты» (модераторы и другие сотрудники CSN) сами до конца не могли однозначно ответить на этот вопрос. Разметки не было.
2. В реальной жизни человек принадлежит к нескольким ролям одновременно. Например, на работе я одновременно «аналитик» и «спамер в slack». Чтобы учесть это, была использована Gaussian Mixture Model (GMM), которая позволяет отнести объект к нескольким группам с определенной вероятностью.
3. Для «генерации фич» были использованы подходы из сетевого анализа (SNA) и обработки текста (NLP). Всего было сделано 83 признака.
4. Количество кластеров — это гиперпараметр модели, которые исследователи сами могли задавать. Они пробовали находить от 2 до 20 кластеров. После «игры» с данными, количество от 10 до 15 показалось им «адекватным».

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

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

1. Основная гипотеза про «баланс» ролей в сообщество подтвердилась.
2. Нашли свое доказательство «на данных» несколько теорий из социологии, что также сработало как доп.фактор валидации модели.
3. Нашли «путь успешного пользователя» форума, который становится костяком сообщества. Как следствие, смогли лучше понять retention/churn.

So What?

1. Исследователи разработали рабочий подход к нахождению «социальных ролей». Они заявляют, что эта методология универсальна и может быть использована в других предметных областях. На работе я уже частично использовал методы из этого ресерча (привет, Алися!) и получил интересные результаты.
2. Найдя роли в своих продуктах, можно будет 1) определить хорошие Health-метрики, 2) более четко формулировать и проверять продуктовые гипотезы, 3) системно развивать социальную составляющую продукта.

Ребята из QIWI позвали рассказать о количественных исследованиях пользователей. Сделал обзорный доклад и за час осветил несколько тем:

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

Запись доклада с QIWI Кухни.
Ссылка на Google Slides.
Список блогов по теме.

Cтатья, где объясняют фреймворк по принятию решений.

Автор цитирует мысль Джефа Безоса из письма инвесторам от 2016г и приводит два типа решений:

1. Необратимые решения
2. Обратимые решения (decisions are like walking through a door — if you don’t like the decision, you can always go back)

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

Для поиска этих оттенков предлагается использовать вот такую хитрую шкалу.

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

1. Чем менее важно решение, тем меньше нужно для него информации.
2. Сбор информации подчиняется закону Парето — 80% информации найти легко, а остальные 20% добываются с трудом.
3. Большинство решений не так важны.

Закон Парето в действии

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

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