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

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

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

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

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

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

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

В планах — продолжать играться со сценариями для голосовых интерфейсов. Хочу посмотреть, рабочая ли это вообще вещь, а для этого надо попробовать сделать еще парочку сценариев.

У меня в очереди стоит что-то типа: «Посмотри, какие ОФЗ сейчас дают выше 14% — хочу взять тысяч на 300, желательно с погашением не раньше 2027», «Уточни у банка, можно ли изменить время инкассации с 18:00 на 20:00 — магазины закрываются поздно, кассиры ждут». Полагаю, они будут длиннее, и возникнет необходимость в новых вариантах сообщений и типах данных. Если руки дойдут, потом расскажу, что получилось.

И немного деталей реализации. Сборка всего и отдельных элементов — это Figma. Для сценария чата я использовал HTML с библиотекой GSAP, которая отвечает за анимацию. Весь код собран в Claude.

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

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

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

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

The post Что я узнал, делая прототип банкового чата с ИИ first appeared on Блог Дмитрия Подлужного: о работе и около нее.

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

Есть интересная статья с критикой Agile «Agile Is Dead. AI Killed It. Welcome Back, Waterfall.»

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

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

Kent Beck (один из авторов Agile-манифеста) предполагает, что внедрение AI может столкнуться в организациях с противодействием, потому что не всегда люди заинтересованы в ускорении и удешевлении процессов. Это из разговора Kent Beck и Martin Fowler на Pragmatic Summit. Там же Kent Beck говорит о том, что возвращается тенденция к программистам-интровертам, которые не любят и не хотят частого общения, что было нормой до недавнего времени. Сейчас можно сфокусироваться на нескольких коллегах и нескольких агентах, а задачей компании становится создание безопасной позитивной атмосферы для функционирования таких производственных единиц.

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

При этом, если описывать задачи в формате User Stories или JTBD, то будешь получать от AI простые решения. Надо уходить в детальное описание того, что требуется получить.

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

1. Функциональные требования — 1–2 предложения, которые формируют бэклог проекта.
2. Описание решения — 1–2 абзаца в свободной форме, возможность задать нюансы процесса или технологии, которые я хочу, чтобы использовались в решении задачи.
3. Доработанные функциональные требования — 2–3–4 страницы. Вариант требований, который первоначально готовит AI на основе моего описания, который я потом дорабатываю с учетом нужного фокуса. Именно эти функциональные требования идут в AI для кодирования проекта.

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

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

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

The post AI убивает Agile first appeared on Блог Дмитрия Подлужного: о работе и около нее.

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

Indi Young в своей статье «I Trained It to Copy Your Style» как раз пишет о том, что это безответственно — тратить столько ресурсов на «вау»-эффекты. Она вообще рассматривает это с позиции того, как много вреда ИИ наносит людям: среде обитания, традициям, отношениям и т. д., — и что важно найти способ сохранять человечность в меняющемся мире. Кстати, я как раз студентам говорил, что, возможно, писать «спасибо» — это и есть способ сохранения традиционных укладов даже в новом цифровом пространстве, и не надо этого избегать.

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

ИИ подорвал концепцию авторских прав

Недавно в гостях мне старый рок-музыкант запустил пару песен, которые он написал в Suno. И объяснил, что вот альбом допишет и отдаст своим знакомым рокерам, которые все еще выступают на разных небольших площадках — будет у них новый материал для исполнения. В Японии создатель ИИ-группы Neon Oni нанял живых музыкантов, чтобы давать концерты.

Это первые пришедшие на память примеры, когда роль автора размывается. Быть может, в музыке это чувствуется ярче, потому что нам сложно отличить генеративный контент от человеческого. Есть исследования, которые говорят, что 97 % тестируемых не смогли отличить ИИ-музыку от человеческой. И по данным Deezer до 39 % музыки — это полностью генеративная музыка, которую они отфильтровывают. Но я подозреваю, что это просто плохо сделанная генерация, а еще столько же спокойно проходит и монетизируется в стриминге.

ИИ перекроил поисковый и реферальный трафик

Все знают о том, что органический трафик падает — и упал сильно. Есть разные оценки, но где-то с 2023 по 2026 год переходы из Google уменьшились на 42 %. А если в выдаче есть ИИ-ответ, то трафик для первых позиций падает на 60 %.

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

Причем все это не конечные цифры. Можно уверенно утверждать, что когда мы будем сравнивать органический трафик в 2027 относительно 2026 года, то снова увидим двукратное падение. И так будет в 2028, 2029 и 2030 годах.

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

ИИ стал беспрецедентным инструментом обмана

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

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

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

ИИ концентрирует богатство

По прогнозам, ИИ даст прирост мирового ВВП на 15 % в течение 10 лет. И владеть инструментами этого роста будет горстка людей. Ну, может, за исключением китайских ИИ, потому что там в итоге всем владеет партия.

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

Поезд уже на полном ходу…

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

The post Цена ИИ-прогресса first appeared on Блог Дмитрия Подлужного: о работе и около нее.

First STAIR: Время, Стоимость, Эффективность

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

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

В качестве простой цели можно поставить экономию времени. Минимальная цель — это 4 часа в неделю на сотрудника, но в качестве оптимальной цели — 10 часов в неделю на сотрудника (см. The AI Proficiency Report). 

Какие еще могут быть легко достижимые цели:

• Ускорение разработки программного обеспечения на 30%
• Ускорение модернизации устаревших приложений в 2 раза
• Увеличение скорости тестирования на 30%
• Сокращение среднего времени решения задач в поддержке на 25%

Second STAIR: Качество, Улучшение отдачи

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

На этом уровне AI способен стать фактором конкурентного преимущества.

Сейчас все больше появляется стартапов, которые обещают новый качественный результат, например, от автоматизации поддержки (decagon.ai) до предиктивной аналитики оттока (churned.io) и т.д. И большая четверка (Deloitte, PwC, EY, KPMG) активно продвигает именно этот нарратив, они делают ставку на AI агентов. 

Third STAIR: Новая система

Третья ступень — это стратегическая трансформация.

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

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

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

The post Фреймворк внедрения AI first appeared on Блог Дмитрия Подлужного: о работе и около нее.

Парадокс раздутых продуктов

В современных приложениях множество функций, о которых я даже не знаю. Со временем в голове сложилась четкая схема: какие приложения для чего, — и эту модель очень сложно изменить.

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

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

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

Но так ли хорошо размывать фокус приложения? Превращать небольшое функциональное решение в большое и не всегда полезное?

Так ли опасно остановить функциональную экспансию и вернуться к приложениям, сфокусированным на главном?

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

Может, пора спрашивать пользователей не «Что добавить?», а «Что убрать?»

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

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

The post Пора ли спрашивать «Что убрать?» first appeared on Блог Дмитрия Подлужного: о работе и около нее.

В моем примере вся работа разбита на этапы.

Этап 1. Определяем сегменты

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

Что мы должны понимать о сегменте? Особенности поведения, маркеры поведения, мотивы поведения, долю сегмента в аудитории.

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

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

Этап 2. Смотрим в цифры

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

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

Этап 3. Формулируем гипотезы

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

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

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

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

The post Как менять сайт на основе поведенческой модели пользователей? first appeared on Блог Дмитрия Подлужного: о работе и около нее.

Суть фреймворка

SAFE-BOLD — это шкала, где с одной стороны находятся идеи «SAFE» — безопасные, предсказуемые, простые. С другой стороны — идеи «BOLD» — смелые, нестандартные, рискованные. Цель фреймворка — сместить командное мышление в сторону BOLD и стимулировать создание значимых и запоминающихся предложений.

Идеи, которые ближе к BOLD, обладают четырьмя характеристиками:

• Big (Значимые): масштабные, стратегические решения.
• Outperform (Рискованные): идеи с потенциалом высокого эффекта, но и высоким риском.
• Leading-edge (Инновационные): передовые и оригинальные.
• Difficult (Сложные): требующие усилий для реализации.

Напротив, SAFE-идеи:

• Small (Незначительные): локальные, очевидные.
• Achievable (Достижимые): с минимальным риском.
• Follower (Последовательные): основанные на известных решениях.
• Easy (Простые): легко реализуемые.

Фреймворк помогает сохранять оригинальность идей и не допускать их упрощения на этапе доработки.

Четыре измерения фреймворка

Каждая идея оценивается по следующим шкалам:

1. Scale (Масштаб):
   • Small: решает частную проблему, локальное улучшение.
   • Big: влияет на стратегические цели, предлагает широкие изменения.
2. Risk (Риск):
   • Achievable: минимальные риски, высокая предсказуемость.
   • Outperform: значительный риск, но и высокий потенциал выгоды.
3. Innovativeness (Инновационность):
   • Follower: повторение уже опробованных решений.
   • Leading-edge: новые, нестандартные подходы.
4. Difficulty (Сложность реализации):
   • Easy: быстрое и простое внедрение.
   • Difficult: требует усилий, ресурсов, возможно — организационных изменений.

Как использовать SAFE-BOLD

1. Сформулируйте идею (например, коммерческое предложение или концепт обучения).
2. Презентуйте идею команде.
3. Оцените идею по каждой из четырёх шкал.
4. Если идея слишком «SAFE», обсудите, как сместить её в сторону «BOLD»: добавить масштаба, инновационности, риска или сложности.

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

Преимущества и ограничения

Преимущества:

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

Ограничения:

• Требуется баланс между смелостью и реалистичностью: чрезмерно «BOLD» идея может быть невыполнимой.
• Возможно сопротивление со стороны участников, склонных к более осторожному подходу.
• Фреймворк требует вовлеченности и готовности к обсуждению рисков, что не всегда возможно в консервативной среде.

В заключение

SAFE-BOLD — это простой визуальный инструмент, который помогает командам генерировать нестандартные, значимые идеи и структурировать обсуждение. Использование шкал SAFE-BOLD обеспечивает порядок и фокус, необходимые для эффективного мозгового штурма. Такой подход помогает создавать провокационные решения, адаптированные под задачи клиента, а также обучать его новой проблеме. Это усиливает контроль над продажей, позволяя менять мышление и поведение клиента. Разработка предложения с чертами BOLD — большого, рискованного, инновационного и сложного — демонстрирует экспертность команды и позволяет выделиться на фоне конкурентов за счёт уникального взгляда на проблему и нестандартного подхода к её решению.

• Шаблон SAFE-BOLD framework в Miro

The post Фреймворк, который помогает создавать нестандартные идеи first appeared on Блог Дмитрия Подлужного: о работе и около нее.

Первое исследование изучало влияние генеративных ИИ на студентов в процессе написания эссе. Оценивали как итоговые тексты, так и когнитивные изменения при помощи электроэнцефалографии и опросов. В результате оказалось, что постоянное использование генеративных ИИ снижало нейронную связность, ослабляло память и снижало чувство авторства. Итоговые работы становились менее разнообразными и менее креативными. Зафиксированное снижение когнитивных способностей исследователи назвали «когнитивным долгом». Речь идет не о том, что люди «тупеют», но об устойчивом снижении вовлеченности и самостоятельности, что и показали результаты исследования.

В исследовании MIT (Your Brain on ChatGPT) участвовали 54 студента, которые в течение четырех сессий писали эссе с помощью ChatGPT, поисковых систем или без инструментов. Участников подключали к электроэнцефалографу, анализировали нейронную активность и проводили пост интервью. Последняя сессия позволила сравнить, как меняется когнитивная активность после многократного использования ИИ: у студентов, привыкших к LLM, зафиксировали снижение памяти, вовлеченности и оригинальности текстов.

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

В исследовании The Impact of Generative AI on Critical Thinking приняли участие 319 специалистов из разных отраслей. Они описали 936 реальных рабочих задач, в которых использовали генеративный ИИ, и оценили уровень критического мышления, когнитивных усилий и уверенности в себе и ИИ. Анализ показал, что высокая уверенность в генеративных ИИ связана с меньшим проявлением критического мышления и снижением усилий, направленных на осмысление и проверку информации.

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

Исследования

• Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task,
• The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers

The post Использование LLM несет не только пользу, но и издержки first appeared on Блог Дмитрия Подлужного: о работе и около нее.

Особенности проектирования интерфейсов для интерактивных экранов

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

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

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

Учитывайте расположение экрана

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

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

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

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

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

Учитывайте физический опыт

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

Рекомендации:

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

Учитывайте поле зрения

При проектировании интерфейсов для интерактивных экранов важно учитывать, как пользователь воспринимает информацию визуально. Чаще всего такие экраны имеют большие размеры, но пользователь находится перед ними на сравнительно небольшом расстоянии — примерно 40–80 сантиметров, что соответствует длине вытянутой руки.

А наше поле зрения ограничено: наиболее четко мы воспринимаем объекты в угле около 30 градусов. Это значит, что для охвата всего экрана пользователю приходится двигать глазами или даже поворачивать голову, особенно если информация расположена за пределами удобной зоны восприятия (примерно 30–40 сантиметров в ширину). Это может создавать дополнительные нагрузки при взаимодействии с интерактивным экраном, чего лучше избегать.

Рекомендации:

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

Учитывайте особенности интерфейса

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

Рекомендации:

• Обеспечьте масштабируемость интерфейса. Проверьте, что элементы адаптируются к размеру экрана, а шрифты и кнопки остаются читаемыми и удобными на типичном расстоянии (40–80 см).
• Делайте навигацию простой. Интерактивный экран — не энциклопедия, его цель — решать конкретные задачи. Четко определите, какую информацию он должен предоставлять, и не перегружайте интерфейс. Больше — не значит лучше!
• Разделяйте контент и навигацию. Лучше сделать макеты упрощенными и обеспечить различимость интерактивных элементов.
• Используйте анимацию и движение, чтобы привлечь внимание пользователя к определенным элементам.
• Обеспечьте заметный отклик системы. Простые анимации помогут пользователю понимать, что система реагирует на его действия.
• Сделайте экранную клавиатуру подвижной. Пусть пользователь сможет перемещать ее в удобное место на экране (особенно важно для пользователей разного роста).
• Оптимизируйте перетаскивание объектов. Регулируйте ускорение и замедление элементов, чтобы они были удобны в управлении.
• Увеличивайте активные зоны. Кликабельная зона должна быть больше самого элемента, особенно если пользователь смотрит на него под углом.

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

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

Рекомендация:

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

Учитывайте особенность сценариев

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

Рекомендации:

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

Заключение

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

The post Проектирование для интерактивных экранов first appeared on Блог Дмитрия Подлужного: о работе и около нее.

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

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

В моём понимании, проектирование интерфейсов — это прежде всего навык, требующий особого подхода к решению задач, который нарабатывается через практическую работу. В соответствии с этим я подготовил презентации для трёх занятий, общим объёмом около 210 слайдов, и выделив при этом 35% времени на практические задания, чтобы слушатели могли закрепить материал на практике.

Краткий обзор лекций

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

Первая часть программы была посвящена истории человеко-ориентированному подходу в дизайне, подчёркивая, что многие современные концепции дизайна имеют глубокие исторические корни. Я использовал ключевые моменты для иллюстрации эволюции продуктового дизайна, начиная с Генри Дрейфуса и его знаковой работы «Дизайн для людей» (Henry Dreyfuss «Designing for People», 1955), и завершая стандартом ISO 9241-210 о человеко-ориентированных процессах проектирования интерактивных систем («Human-centred design processes for interactive systems», 2010) и «Руководством по доступности веб-контента» («Web Content Accessibility Guidelines 1.0», 1999).

Второй блок был посвящен моей любимой модели — «Элементы пользовательского опыта» Джеси Гарретта (Jesse Garrett «The Elements of User Experience», 2000). Эта модель, на мой взгляд, является одной из лучших для демонстрации процесса формирования пользовательского опыта как сложной, многоуровневой задачи, требующей различных уровней абстракции. Она помогает избежать ошибочного суждения, когда продукт рассматривается исключительно через призму его внешнего вида и дизайна. Я постоянно подчёркиваю, что дизайн современного цифрового продукта — это результат коллективных усилий команды, где каждый участник вносит важный вклад. Эту идею я пытался донести до слушателей. Модель Гарретта отлично помогает это понять и объяснить.

Третий блок был посвящён принципам доступности, теме, актуальность которой неуклонно растёт, но которая часто остаётся без внимания. Мы рассмотрели базовые принципы обеспечения доступности, изложенные во второй редакции Руководства по обеспечению доступности контента (WCAG). Для меня было важно донести до слушателей, что обеспечение доступности — это работа, которая требует комплексного подхода, внедрения в корпоративную культуру, и не должна ограничиваться лишь декларативными заявлениями.

Четвёртый блок был посвящён анализу двух подходов к проектированию интерфейсов: экспертному, основанному на требованиях, и практике совместного проектирования. Я использовал карту дизайнерских исследований Элизабет Сандерс (Liz Sanders «Map of design research», 2008) в качестве примера для демонстрации разнообразия методов решения дизайнерских задач. Хотя эта карта и не является прямым руководством по проектированию, я рассматриваю её как обзор подходов к продуктовому дизайну в более широком контексте. По моему мнению, квалифицированный специалист должен быть способен применять различные методики для разработки интерфейсов, выбирая наиболее подходящие в зависимости от конкретной задачи и особенностей команды. В рамках практических занятий мы рассмотрели оба метода, чтобы понять, как каждый из них способствует достижению итогового решения. Оба метода включают в себя уникальный набор практик и инструментов, которые могут как пересекаться, так и дополнять друг друга, обеспечивая тем самым комплексный подход к проектированию интерфейса.

Для объяснения проектирования на основе требований мне необходимо было дать несколько ключевых понятий: требования, информационная архитектура, роли, сценарии, декомпозиция. Это большие темы, и, по большому счету, для них нужно было бы гораздо больше времени для детального изучения, но пришлось пробежаться по верхам.  Я старался закрепить понимание этих концепций у слушателей с помощью практических заданий. В аудитории это было на листах бумаги, в онлайн-формате – с использованием Miro.

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

Хотя времени на полноценную сессию в формате дизайн-мышления в рамках лекций не хватало, я выбрал ключевые элементы этого подхода и предоставил инструменты для совместной работы, чтобы участники могли двигаться по процессу. Три основных инструмента, использованных в курсе, включали «Карту эмпатии» Дейва Грея (Dave Gray «Empathy Map», 2017), «Пользовательские истории» Алистера Коберна (Alistair Cockburn «User Stories», 1998) и раскадровки. Хотя за раскадровками не стоит один автор, я использовал иллюстрацию Бена Клозера (Ben Crothers), вдохновлённую базовой сюжетной аркой Густава Фрейтага (Gustav Freytag «Technique of the Drama: An Exposition of Dramatic», 1863), которая эффективно помогает разработке нарратива. Эти инструменты позволили участникам глубже погрузиться в процесс создания дизайна продукта, уделяя внимание эмпатии к пользователю, его потребностям и способам поэтапного продвижения к прототипу интерфейса.

В итоге

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

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

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

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

• Henry Dreyfuss «Designing for people», HathiTrust https://babel.hathitrust.org/cgi/pt?id=mdp.39015031567053&seq=6  
• ГОСТ Р ИСО 9241-210-2016 Человеко-ориентированное проектирование интерактивных систем https://docs.cntd.ru/document/1200141127    
• ISO 9241-210. Планирование и внедрение Human-Centered Design https://habr.com/ru/articles/258635/  
• Web Content Accessibility Guidelines https://www.w3.org/TR/WCAG21/ 
• Jesse Garrett «The Elements of User Experience» www.jjg.net/elements/pdf/elements.pdf 
• Liz Sanders «An Evolving Map of Design Practice and Design Research» https://www.dubberly.com/articles/an-evolving-map-of-design-practice-and-design-research.html 
• Dave Gray «Updated Empathy Map Canvas» https://medium.com/@davegray/updated-empathy-map-canvas-46df22df3c8a 
• User story https://en.wikipedia.org/wiki/User_story 
• Ben Crothers «How to construct a great story» https://www.goodreads.com/author/show/17045638.Ben_Crothers/blog 
• Gustav Freytag “Technique of the Drama: An Exposition of Dramatic” https://books.google.ru/books?id=oLxinAdZ_IMC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

The post От теории к практике: как я преподавал проектирование интерфейсов в Высшей школе бизнеса НИУ-ВШЭ first appeared on Блог Дмитрия Подлужного: о работе и около нее.