This media is not supported in your browser
VIEW IN TELEGRAM
Про нижнее меню на сайтах сегодня решил написать после того, как натолкнулся на свою концепцию трехлетней давности.
Это вариант для сайта страховой, когда на главной странице внизу можно использовать дополнительное меню действия, такой вариант Floating Action Button.
Основная идея была: упростить навигацию для лояльных пользователей, а за счет наглядности снизить когнитивную нагрузку. Я исходил из пользовательского поведения: на сайты страховых компаний люди заходят редко и надо помочь клиентам сделать нужные шаги, чуть-чуть сместив объем информации на странице в пользу клиентов.
Когда я это делал, то столкнулся с проблемой, что хотя в сети мобильных пользователей больше, чем десктопных, но обоснованных подходов, как сделать мобильную навигацию нет.
Выбор был между тем, чтобы смещать навигацию вниз и делать ее полностью нижней, оставлять полностью вверху, найти компромисс между двумя вариантами.
Было несколько исследований, которые показывали, что использование свернутой навигации создает более плохой пользовательский опыт. Например, статья «Hamburger Menus and Hidden Navigation Hurt UX Metrics» напрямую указывает, что по результату проведенных в лаборатории исследований скрытая навигация (в бургер) приводит к усложнению выполнения задач, увеличению времени выполнения и т.д.
Но если мы посмотрим на рекомендации Google (Material Design) и Apple (Human Interface Guidelines) , то мы не найдем там отдельных рекомендаций для навигации по сайтам. Там есть рекомендации по использовании нижней навигации в мобильных приложениях. При этом там можно обратить внимание на такие моменты: ограниченное количество пунктов 3-5, равнозначность разделов, использование панели для навигации, а не для выполнения действий. И эти рекомендации хорошо ложатся на логику приложений с ограниченным ясным функционалом, чего не скажешь про сайты.
Хотя аргумент - сделаем как в приложении, мне приходилось слышать чаще всего. Как правило, те, кто делает такие предложения, не рассматривают аудиторию на сайте и в приложении, как разную, что довольно наивно.
Если посмотреть на Google Store, Apple, Amazon, Facebook и т.д., то эти компании не переносили на сайтах меню вниз, хотя в приложениях его используют. Для таких сайтов изменение даже на 1% это миллионы долларов, и я предполагаю, что такие компании точно должны были протестировать идею сделать навигацию, как в приложении. И раз до сих пор не сделали, то скорее всего это мешает продажам и другим важным метрикам.
Правда на это всегда есть Озон, Яндекс Маркет, Алиэкспресс и т.д., у которых на сайте все как в приложении. И почему-то я убежден что такое решение, основано не на исследованиях, а на волюнтаристском решении дизайн-директора или CEO этих компаний.
У меня был подобный опыт. В проекте для большого российского ecom с MAU в несколько миллионов, для которого я делал проектирование, я предлагал в мобильной версии сайта делать верхнюю навигацию, но компания решила сделать, как в приложении, и продавила себе нижний тулбар. После запуска новой версии сайта все показатели просели. Это невозможно объяснить только изменением навигации, но и она, на мой взгляд, приложила к этому руку. Все что непривычно - роняет поведенческие метрики. И пока для массового пользователя нижняя навигация на сайтах непривычна.
И если у вас есть свежие исследования про нижнюю навигацию на сайтах, то поделитесь пожалуйста.
Это вариант для сайта страховой, когда на главной странице внизу можно использовать дополнительное меню действия, такой вариант Floating Action Button.
Основная идея была: упростить навигацию для лояльных пользователей, а за счет наглядности снизить когнитивную нагрузку. Я исходил из пользовательского поведения: на сайты страховых компаний люди заходят редко и надо помочь клиентам сделать нужные шаги, чуть-чуть сместив объем информации на странице в пользу клиентов.
Когда я это делал, то столкнулся с проблемой, что хотя в сети мобильных пользователей больше, чем десктопных, но обоснованных подходов, как сделать мобильную навигацию нет.
Выбор был между тем, чтобы смещать навигацию вниз и делать ее полностью нижней, оставлять полностью вверху, найти компромисс между двумя вариантами.
Было несколько исследований, которые показывали, что использование свернутой навигации создает более плохой пользовательский опыт. Например, статья «Hamburger Menus and Hidden Navigation Hurt UX Metrics» напрямую указывает, что по результату проведенных в лаборатории исследований скрытая навигация (в бургер) приводит к усложнению выполнения задач, увеличению времени выполнения и т.д.
Но если мы посмотрим на рекомендации Google (Material Design) и Apple (Human Interface Guidelines) , то мы не найдем там отдельных рекомендаций для навигации по сайтам. Там есть рекомендации по использовании нижней навигации в мобильных приложениях. При этом там можно обратить внимание на такие моменты: ограниченное количество пунктов 3-5, равнозначность разделов, использование панели для навигации, а не для выполнения действий. И эти рекомендации хорошо ложатся на логику приложений с ограниченным ясным функционалом, чего не скажешь про сайты.
Хотя аргумент - сделаем как в приложении, мне приходилось слышать чаще всего. Как правило, те, кто делает такие предложения, не рассматривают аудиторию на сайте и в приложении, как разную, что довольно наивно.
Если посмотреть на Google Store, Apple, Amazon, Facebook и т.д., то эти компании не переносили на сайтах меню вниз, хотя в приложениях его используют. Для таких сайтов изменение даже на 1% это миллионы долларов, и я предполагаю, что такие компании точно должны были протестировать идею сделать навигацию, как в приложении. И раз до сих пор не сделали, то скорее всего это мешает продажам и другим важным метрикам.
Правда на это всегда есть Озон, Яндекс Маркет, Алиэкспресс и т.д., у которых на сайте все как в приложении. И почему-то я убежден что такое решение, основано не на исследованиях, а на волюнтаристском решении дизайн-директора или CEO этих компаний.
У меня был подобный опыт. В проекте для большого российского ecom с MAU в несколько миллионов, для которого я делал проектирование, я предлагал в мобильной версии сайта делать верхнюю навигацию, но компания решила сделать, как в приложении, и продавила себе нижний тулбар. После запуска новой версии сайта все показатели просели. Это невозможно объяснить только изменением навигации, но и она, на мой взгляд, приложила к этому руку. Все что непривычно - роняет поведенческие метрики. И пока для массового пользователя нижняя навигация на сайтах непривычна.
И если у вас есть свежие исследования про нижнюю навигацию на сайтах, то поделитесь пожалуйста.
👍1
В проектировании интерфейсов фокус-группа не всегда такая, как в маркетинговых исследованиях. Недавно наткнулся на статью в UX Magazine про использование юзабилити-тестов и фокус-групп — «Usability Tests vs. Focus Groups» , и это напомнило мне опыт использования фокус-группы в B2B-проекте для Mercedes-Benz Rus.
На мой взгляд, работа с фокус-группой — это эффективный инструмент в B2B-проектах или проектах, где в качестве конечных пользователей выступают руководители высокого уровня. Хотя бы потому, что ее проще организовать, особенно когда сам бизнес-заказчик заинтересован в хорошем результате проекта.
В 2018 году я проектировал интерфейс внутренних систем для Mercedes-Benz Rus. Это должен был быть набор инструментов, к которому получали доступ как сотрудники компании, так и дилеры. Причем подразумевался разный уровень доступа для разных должностей.
С одной стороны, было очевидно, что нужно вовлекать пользователей в проект, но CEO компаний не очень охотно идут на контакт. У всех нет времени, желания общаться, тем более с какими-то там UX-дизайнерами. Но вот приехать в офис Mercedes и поучаствовать во встрече, посвященной будущей системе, которую они потом будут использовать, — это совсем другое дело.
Но чтобы провести встречу с пользой, нужно что-то показывать. Люди обычно не способны представить будущую систему и качественно о ней рассуждать, но они гораздо лучше включаются в разговор, когда им что-то демонстрируют.
Для такой встречи нужно уже иметь готовый прототип с высокой степенью функциональности. Но, как ни странно, лучше отказаться от идеи показывать проект в дизайне. Когда люди видят дизайн, у них отключается критическое мышление. И хотя демонстрация прототипов с условными элементами не так эффектна, но она позволяет получить более качественное обсуждение проекта.
А чтобы разговор был управляемым, нужен опытный модератор. Важно, чтобы у всех была возможность высказаться. Потому что самое ценное в таком общении — это сами люди. Важно их мнение и возможность задавать им вопросы. Как правило, при живом обсуждении, когда участники действительно включены в процесс, можно получить куда больше ценной информации, чем в рамках формального разговора.
Пара итоговых советов по проведению фокус-группы для обсуждения концепции B2B-проекта:
— Подготовить прототип, достаточно детализированный и интерактивный, чтобы можно было обсуждать ключевые идеи. Не стоит пытаться охватить весь проект, лучше сосредоточиться именно на самом важном.
— Пригласить представителей целевой аудитории среди компаний-партнеров и за счет силы бренда обеспечить вовлеченный диалог. Важно, чтобы участники действительно относились к той аудитории, для которой делается проект.
— Нужен модератор, который сможет управлять процессом: вовлечет всех в разговор и не даст кому-то перетягивать одеяло на себя.
— Задать хорошие вопросы и дать возможность всем высказаться.
Не уверен, насколько этот подход масштабируется на B2B проекты без сильного бренда-заказчика. Но в ситуации, когда проблемен доступ к пользователям, фокус-группа может оказаться хорошим работающим инструментом.
На мой взгляд, работа с фокус-группой — это эффективный инструмент в B2B-проектах или проектах, где в качестве конечных пользователей выступают руководители высокого уровня. Хотя бы потому, что ее проще организовать, особенно когда сам бизнес-заказчик заинтересован в хорошем результате проекта.
В 2018 году я проектировал интерфейс внутренних систем для Mercedes-Benz Rus. Это должен был быть набор инструментов, к которому получали доступ как сотрудники компании, так и дилеры. Причем подразумевался разный уровень доступа для разных должностей.
С одной стороны, было очевидно, что нужно вовлекать пользователей в проект, но CEO компаний не очень охотно идут на контакт. У всех нет времени, желания общаться, тем более с какими-то там UX-дизайнерами. Но вот приехать в офис Mercedes и поучаствовать во встрече, посвященной будущей системе, которую они потом будут использовать, — это совсем другое дело.
Но чтобы провести встречу с пользой, нужно что-то показывать. Люди обычно не способны представить будущую систему и качественно о ней рассуждать, но они гораздо лучше включаются в разговор, когда им что-то демонстрируют.
Для такой встречи нужно уже иметь готовый прототип с высокой степенью функциональности. Но, как ни странно, лучше отказаться от идеи показывать проект в дизайне. Когда люди видят дизайн, у них отключается критическое мышление. И хотя демонстрация прототипов с условными элементами не так эффектна, но она позволяет получить более качественное обсуждение проекта.
А чтобы разговор был управляемым, нужен опытный модератор. Важно, чтобы у всех была возможность высказаться. Потому что самое ценное в таком общении — это сами люди. Важно их мнение и возможность задавать им вопросы. Как правило, при живом обсуждении, когда участники действительно включены в процесс, можно получить куда больше ценной информации, чем в рамках формального разговора.
Пара итоговых советов по проведению фокус-группы для обсуждения концепции B2B-проекта:
— Подготовить прототип, достаточно детализированный и интерактивный, чтобы можно было обсуждать ключевые идеи. Не стоит пытаться охватить весь проект, лучше сосредоточиться именно на самом важном.
— Пригласить представителей целевой аудитории среди компаний-партнеров и за счет силы бренда обеспечить вовлеченный диалог. Важно, чтобы участники действительно относились к той аудитории, для которой делается проект.
— Нужен модератор, который сможет управлять процессом: вовлечет всех в разговор и не даст кому-то перетягивать одеяло на себя.
— Задать хорошие вопросы и дать возможность всем высказаться.
Не уверен, насколько этот подход масштабируется на B2B проекты без сильного бренда-заказчика. Но в ситуации, когда проблемен доступ к пользователям, фокус-группа может оказаться хорошим работающим инструментом.
This media is not supported in your browser
VIEW IN TELEGRAM
Прототипы интерфейсов я делаю так давно, что первые из них собирал ещё в InDesign — старички могут всплакнуть, вспомнив это далекое время. И на протяжении всего этого пути я придерживался идеи, которую настойчиво транслировал вокруг себя, что хороший прототип должен быть черно-белым или, в крайнем случае, монохромным.
Цвет же я использовал как маркер, чтобы сделать кликабельные элементы в прототипах заметнее. И такого подхода было достаточно и для больших, и для маленьких корпоративных заказчиков. В конечном счёте, такие же рекомендации можно найти у Microsoft, IBM, NNgroup и других.
Время от времени возникала необходимость объяснять, зачем прототипы именно такие и почему мы не делаем сразу дизайн. Но в целом это не вызывало особых сложностей. Был общий консенсус, что все заинтересованы в качестве, а обсуждать упрощенный прототип без цвета и изображений по существу гораздо эффективнее, чем делать это на уровне дизайна.
Но в последние годы, наверное, уже года три, мне всё чаще приходится делать прототипы в цвете. И они всё больше начинают походить на дизайнерские решения. Причем в определенной степени сейчас это мой осознанный выбор. Размышляя о коммуникации с заказчиком, мне приходится признавать, что теперь эффективнее показать что-то с визуальным решением, чем монохромный вариант.
Для себя я объясняю это тем, что по какой-то неведомой космической причине корпоративные заказчики все реже считают итерационный подход хорошим и правильным. И все чаще склонны думать, что проект возникает сразу — целиком и полностью, во всей визуализации.
Желание критически относиться к дизайну, обсуждать прототип, искать лучшее решение становится все более редким явлением. Нужно либо сделать сразу «хорошо», с тем самым вау-эффектом, либо попасть в ожидаемое решение. И уже не так важно, будет ли это решение по верхней границе ожиданий или по нижней.
Вполне возможно, что мой опыт работы в агентстве накладывает отпечаток на такое восприятие.
Мне трудно точно определить причину, почему так происходит или почему это именно так ощущается. Но в качестве ответной реакции возникает чувство необходимости делать что-то похожее на дизайн. Проще всего это делать, когда есть дизайн-система, в такой ситуации можно хотя бы частично наследовать элементы. Сложнее, когда нет почти ничего.
В результате получаются вот такие high-detail прототипы, как в примере. Это был небольшой кусочек решения для B2B системы лояльности.
Вы замечаете, что клиенты стали по-другому относиться к итерационности? Или у вас все еще работают классические монохромные прототипы?
Цвет же я использовал как маркер, чтобы сделать кликабельные элементы в прототипах заметнее. И такого подхода было достаточно и для больших, и для маленьких корпоративных заказчиков. В конечном счёте, такие же рекомендации можно найти у Microsoft, IBM, NNgroup и других.
Время от времени возникала необходимость объяснять, зачем прототипы именно такие и почему мы не делаем сразу дизайн. Но в целом это не вызывало особых сложностей. Был общий консенсус, что все заинтересованы в качестве, а обсуждать упрощенный прототип без цвета и изображений по существу гораздо эффективнее, чем делать это на уровне дизайна.
Но в последние годы, наверное, уже года три, мне всё чаще приходится делать прототипы в цвете. И они всё больше начинают походить на дизайнерские решения. Причем в определенной степени сейчас это мой осознанный выбор. Размышляя о коммуникации с заказчиком, мне приходится признавать, что теперь эффективнее показать что-то с визуальным решением, чем монохромный вариант.
Для себя я объясняю это тем, что по какой-то неведомой космической причине корпоративные заказчики все реже считают итерационный подход хорошим и правильным. И все чаще склонны думать, что проект возникает сразу — целиком и полностью, во всей визуализации.
Желание критически относиться к дизайну, обсуждать прототип, искать лучшее решение становится все более редким явлением. Нужно либо сделать сразу «хорошо», с тем самым вау-эффектом, либо попасть в ожидаемое решение. И уже не так важно, будет ли это решение по верхней границе ожиданий или по нижней.
Вполне возможно, что мой опыт работы в агентстве накладывает отпечаток на такое восприятие.
Мне трудно точно определить причину, почему так происходит или почему это именно так ощущается. Но в качестве ответной реакции возникает чувство необходимости делать что-то похожее на дизайн. Проще всего это делать, когда есть дизайн-система, в такой ситуации можно хотя бы частично наследовать элементы. Сложнее, когда нет почти ничего.
В результате получаются вот такие high-detail прототипы, как в примере. Это был небольшой кусочек решения для B2B системы лояльности.
Вы замечаете, что клиенты стали по-другому относиться к итерационности? Или у вас все еще работают классические монохромные прототипы?
💅2
Media is too big
VIEW IN TELEGRAM
Собрал прототип с Three.js и отслеживанием лица через камеру — изображение поворачивается, следуя за движением головы. Подход называется head-coupled perspective: экран становится "окном" в 3D-пространство, реагируя на позицию наблюдателя.
Это заготовка для другого проекта, где планирую использовать 3D-персонажа в качестве аватара. Главный вопрос сейчас: насколько убедительно работает эффект присутствия при таком трекинге, или ощущения будут слишком грубыми из-за тормозов и точности детекции.
Попробовать вживую можно здесь: https://v0-3-d-head-tracking-hj.vercel.app/
Видео на ютюб https://youtu.be/9VANZX7oumE
Это заготовка для другого проекта, где планирую использовать 3D-персонажа в качестве аватара. Главный вопрос сейчас: насколько убедительно работает эффект присутствия при таком трекинге, или ощущения будут слишком грубыми из-за тормозов и точности детекции.
Попробовать вживую можно здесь: https://v0-3-d-head-tracking-hj.vercel.app/
Видео на ютюб https://youtu.be/9VANZX7oumE
🤷♂1❤1
Собрал на Behance новый кейс: Marketing agency website prototyping
Это проект прошлого года — небольшой, даже крошечный сайт для маркетингового агентства. Расскажу о двух идеях, которые определили архитектуру сайта: пирамида контента и открытость коммуникации.
Во-первых, я предлагал фокусироваться на идее постепенной подачи контента (progressive disclosure). Это актуально как с точки зрения переходов между страницами, так и при скролле.
По сути, постепенная подача отражает простое правило для интернет-текстов: важное рассказываем сразу, иначе люди могут это не прочитать. Здесь этот принцип распространен на весь контент. Нужно, чтобы даже в условиях ограниченной по времени сессии, потенциальный клиент узнал о компании то, что мы бы хотели ему рассказать, и поэтому имеет значение, что человек увидит на первом экране, что при скролле.
Но сначала нужно определиться с тем, что именно важно. И вот тут становится сложнее — здесь требуется осмысленное решение, хорошо бы, чтобы оно базировалось на понимании поведения пользователей, но, с другой стороны, через подачу информации мы как раз и способны управлять поведением пользователей.
Я предположил, что кейсы могут быть ключевым звеном в рассказе о компании. Но текущие кейсы компании пришлось бы немного переработать: как минимум, требовалось вынести результат в заголовок. И в данном случае это не попытка самовосхваления, а экономия времени клиента. Результат в заголовке снижает усилия пользователя, необходимые для интерпретации информации, и сразу отвечает на вопрос: «а вы вообще что умеете?»
Вторая идея — открытость, возможность понимать, с кем клиент будет общаться. На мой взгляд, для некоторых регионов особенно важно учитывать культурные ожидания, чтобы усилить свою позицию и сформировать доверие. Если бы речь шла о коротком названии для коммуникативной стратегии для сайта, я бы ее назвал Trust-Based Communication.
С другой стороны, важно в принципе понимать роль сайта в коммуникации с клиентом. Она может оказаться не такой значимой, как раньше, и не такой значимой, к сожалению, как мне бы хотелось. Сайт скорее может выступать фильтром для отбора перед дальнейшим общением, чем инструментом онлайн-продаж сложных услуг. Причем это двунаправленный инструмент. Он «продает» компанию клиентам, но и позволяет отобрать клиентов, с которыми хочется работать.
Впрочем, даже хорошо спроектированный сайт — это только часть коммуникации. Если у вас хватает ресурсов, то надо заниматься проектированием всей коммуникационной цепочки, в которую входят SEO, AEO, реклама, онлайн-площадки, мессенджеры, видео платформы, социальные сети, сам сайт, email и другие каналы. И смотреть на это с точки зрения единой, измеримой картины, решающей общую стратегическую задачу.
Это проект прошлого года — небольшой, даже крошечный сайт для маркетингового агентства. Расскажу о двух идеях, которые определили архитектуру сайта: пирамида контента и открытость коммуникации.
Во-первых, я предлагал фокусироваться на идее постепенной подачи контента (progressive disclosure). Это актуально как с точки зрения переходов между страницами, так и при скролле.
По сути, постепенная подача отражает простое правило для интернет-текстов: важное рассказываем сразу, иначе люди могут это не прочитать. Здесь этот принцип распространен на весь контент. Нужно, чтобы даже в условиях ограниченной по времени сессии, потенциальный клиент узнал о компании то, что мы бы хотели ему рассказать, и поэтому имеет значение, что человек увидит на первом экране, что при скролле.
Но сначала нужно определиться с тем, что именно важно. И вот тут становится сложнее — здесь требуется осмысленное решение, хорошо бы, чтобы оно базировалось на понимании поведения пользователей, но, с другой стороны, через подачу информации мы как раз и способны управлять поведением пользователей.
Я предположил, что кейсы могут быть ключевым звеном в рассказе о компании. Но текущие кейсы компании пришлось бы немного переработать: как минимум, требовалось вынести результат в заголовок. И в данном случае это не попытка самовосхваления, а экономия времени клиента. Результат в заголовке снижает усилия пользователя, необходимые для интерпретации информации, и сразу отвечает на вопрос: «а вы вообще что умеете?»
Вторая идея — открытость, возможность понимать, с кем клиент будет общаться. На мой взгляд, для некоторых регионов особенно важно учитывать культурные ожидания, чтобы усилить свою позицию и сформировать доверие. Если бы речь шла о коротком названии для коммуникативной стратегии для сайта, я бы ее назвал Trust-Based Communication.
С другой стороны, важно в принципе понимать роль сайта в коммуникации с клиентом. Она может оказаться не такой значимой, как раньше, и не такой значимой, к сожалению, как мне бы хотелось. Сайт скорее может выступать фильтром для отбора перед дальнейшим общением, чем инструментом онлайн-продаж сложных услуг. Причем это двунаправленный инструмент. Он «продает» компанию клиентам, но и позволяет отобрать клиентов, с которыми хочется работать.
Впрочем, даже хорошо спроектированный сайт — это только часть коммуникации. Если у вас хватает ресурсов, то надо заниматься проектированием всей коммуникационной цепочки, в которую входят SEO, AEO, реклама, онлайн-площадки, мессенджеры, видео платформы, социальные сети, сам сайт, email и другие каналы. И смотреть на это с точки зрения единой, измеримой картины, решающей общую стратегическую задачу.
Behance
Marketing agency website prototyping - Podluzny Dmitriy
👍2
«Большинству людей ремесло неинтересно. Им важны кратчайшие пути» — простая идея, но редко можно встретить людей, которые считали бы так же. Сейчас, особенно в ИТ, доминируют короткие пути. А с появлением LLM короткие пути стали даже новыми достижениями. Но медленное мышление, медленное продвижение дают более качественный результат просто потому, что хватает времени на то, чтобы обратить внимание на многие детали.
👍1
Media is too big
VIEW IN TELEGRAM
Пятничные вайб-эксперименты продолжаются миксом из подключаемой камеры, предобученной модели для распознавания частей лица и голосового ввода.
В итоге всё это собралось в примитивную игру, в которой на пользователя летят враги, а курсор можно наводить с помощью положения глаз и стрелять через голосовую команду — попросту повышая голос. Я настроил порог звука довольно низко, поэтому можно просто говорить, и будут происходить выстрелы. Ограничений на количество выстрелов нет, да и оружие только одно. Хотя я думал над тем, чтобы добавить голосовые команды для управления перезарядкой или разными типами выстрелов, но тогда я бы завис на этом проекте дольше.
Результаты 100 лучших игр записываются в базе данных. Используется Supabase, потому что подключение к ней очень простое и сразу доступно в V0.
Проект доступен по адресу https://v0-face-mesh-with-rays.vercel.app/. Он также выложен в моих темплейтах, если захотите в нём поковыряться https://v0.app/templates/face-mesh-with-rays-UqYWZqpNUBO .
Видео на YouTube https://youtu.be/fvZ1ssbiLO0
В итоге всё это собралось в примитивную игру, в которой на пользователя летят враги, а курсор можно наводить с помощью положения глаз и стрелять через голосовую команду — попросту повышая голос. Я настроил порог звука довольно низко, поэтому можно просто говорить, и будут происходить выстрелы. Ограничений на количество выстрелов нет, да и оружие только одно. Хотя я думал над тем, чтобы добавить голосовые команды для управления перезарядкой или разными типами выстрелов, но тогда я бы завис на этом проекте дольше.
Результаты 100 лучших игр записываются в базе данных. Используется Supabase, потому что подключение к ней очень простое и сразу доступно в V0.
Проект доступен по адресу https://v0-face-mesh-with-rays.vercel.app/. Он также выложен в моих темплейтах, если захотите в нём поковыряться https://v0.app/templates/face-mesh-with-rays-UqYWZqpNUBO .
Видео на YouTube https://youtu.be/fvZ1ssbiLO0
🔥2😁1
Вышло большое исследование Section об использовании ИИ в работе (опросили 5000 специалистов из США, Великобритании, Канады). Картина в общем повторяет то, о чем писали EY и MIT в прошлом году: использование широкое, эффективность низкая. Меньше 15% применяют ИИ с реальной пользой для работы. И только 2% используют продвинутым образом — так, что это идёт на благо организации, а не только повышает личную производительность.
Отчет здесь: https://www.sectionai.com/ai/the-ai-proficiency-report
Сейчас в больших компаниях активно смотрят на использование ИИ, но частота доступа к инструменту уже не надежный индикатор. Появляется понимание, что нужно отслеживать время, сэкономленное каждым сотрудником, качество сценариев использования и их влияние на результаты бизнеса. То есть персональную продуктивность, которая базируется не на активности, а на влиянии этой активности на показатели бизнес.
Что обычно делают с ИИ люди и делаю ли я это? В скобках в скобках процент от общего числа, кто так поступает.
Google search replacement (14.1%) – я еще не заменил Google на LLM, но регулярно использую LLM для поиска. Особенно когда надо найти ссылки на факты для какого-то отрывка текста или подобрать материалы по теме.
Draft generation (9.6%) – чаще не для драфтов, а для постредактирования. В Claude у меня настроены Projects под редактирование текстов с разными промтами: для социальных сетей, для маркетинга, для технических текстов.
Grammar and tone editing (5.7%) – да, делаю это. У меня появился лайфхак – я пишу вначале что думаю, даже с бранной лексикой, а потом LLM правит мне текст на корректный. Это иногда помогало в переписках.
Basic data analysis (3.8%) – мне пару раз нужно было посчитать статистику, и я использовал https://julius.ai/, правда это уже не простая аналитика, а продвинутая. Кстати, рекомендую, хороший проект.
Code generation (3.3%) – ну я пишу кучу вайб-кода и даже пару раз пробовал писать код в Cursor и Visual Studio. Но это все-таки только по крайней необходимости.
Ideation & brainstorming (3.2%) – регулярно использую, например, если надо посмотреть со стороны на задачу. В последний раз мы с коллегой обсуждали приложение, а после того как составили общее описание, я попросил найти области, где тот же функционал может оказаться полезным. И была хорошая идея. Вообще, если вы знакомы с креативными методами типа Шести шляп, SCAMPER, то не составит труда использовать LLM во всю силу.
Meeting support (2.7%) – вот этого почти не делаю, потому что у меня нет встреч. Хотя вижу, что запись и транскрибация встреч стали новой нормой.
Document summarization (2.0%) – иногда делаю, когда надо сжать текст до определенного количества знаков.
Learning and skill development (1.6%) – приходится, чтобы понять, как работает та или иная часть кода, или чтобы найти алгоритм, который можно использовать в очередном вайб-эксперименте.
Task and process automation (1.6%) – вот тут мне нечего сказать. Хоть у меня есть какие-то инструменты, облегчающие рутину, но ничего еще не автоматизировал. Даже попытка сделать через IFTTT связку двух своих платформ ничем не завершилась.
Отчет здесь: https://www.sectionai.com/ai/the-ai-proficiency-report
Сейчас в больших компаниях активно смотрят на использование ИИ, но частота доступа к инструменту уже не надежный индикатор. Появляется понимание, что нужно отслеживать время, сэкономленное каждым сотрудником, качество сценариев использования и их влияние на результаты бизнеса. То есть персональную продуктивность, которая базируется не на активности, а на влиянии этой активности на показатели бизнес.
Что обычно делают с ИИ люди и делаю ли я это? В скобках в скобках процент от общего числа, кто так поступает.
Google search replacement (14.1%) – я еще не заменил Google на LLM, но регулярно использую LLM для поиска. Особенно когда надо найти ссылки на факты для какого-то отрывка текста или подобрать материалы по теме.
Draft generation (9.6%) – чаще не для драфтов, а для постредактирования. В Claude у меня настроены Projects под редактирование текстов с разными промтами: для социальных сетей, для маркетинга, для технических текстов.
Grammar and tone editing (5.7%) – да, делаю это. У меня появился лайфхак – я пишу вначале что думаю, даже с бранной лексикой, а потом LLM правит мне текст на корректный. Это иногда помогало в переписках.
Basic data analysis (3.8%) – мне пару раз нужно было посчитать статистику, и я использовал https://julius.ai/, правда это уже не простая аналитика, а продвинутая. Кстати, рекомендую, хороший проект.
Code generation (3.3%) – ну я пишу кучу вайб-кода и даже пару раз пробовал писать код в Cursor и Visual Studio. Но это все-таки только по крайней необходимости.
Ideation & brainstorming (3.2%) – регулярно использую, например, если надо посмотреть со стороны на задачу. В последний раз мы с коллегой обсуждали приложение, а после того как составили общее описание, я попросил найти области, где тот же функционал может оказаться полезным. И была хорошая идея. Вообще, если вы знакомы с креативными методами типа Шести шляп, SCAMPER, то не составит труда использовать LLM во всю силу.
Meeting support (2.7%) – вот этого почти не делаю, потому что у меня нет встреч. Хотя вижу, что запись и транскрибация встреч стали новой нормой.
Document summarization (2.0%) – иногда делаю, когда надо сжать текст до определенного количества знаков.
Learning and skill development (1.6%) – приходится, чтобы понять, как работает та или иная часть кода, или чтобы найти алгоритм, который можно использовать в очередном вайб-эксперименте.
Task and process automation (1.6%) – вот тут мне нечего сказать. Хоть у меня есть какие-то инструменты, облегчающие рутину, но ничего еще не автоматизировал. Даже попытка сделать через IFTTT связку двух своих платформ ничем не завершилась.
❤1🤪1
Вокруг много пишут об ИИ, но не так много примеров, которые рассказывают о реальном опыте, а не просто о теоретических изысканиях. Поэтому материал от технической команды The New York Times — «How The New York Times is scaling Unit Test Coverage using AI Tools» мне кажется интересным. Они пишут о том, как использовали LLM-модели, чтобы наладить тестирование своих продуктов.
Причем они не просто рассказывают об успешном результате, но и описывают весь путь. Это полезная история, потому что она не про то, как сделать очередной «тетрис» или закодить страницу сайта с нуля, а про проведение работ на базе большой существующей инфраструктуры и использование ИИ для упрощения рутинных задач.
В примере NYTimes улучшение качества тестов происходит силами самого агента, а итоговый промпт составляет около семи страниц — они написаны ИИ и уточнены человеком. Но, чтобы добиться этого, команда прошла путь проб и ошибок и в итоге делится рекомендациями по составу промпта.
Интересно, что в статье есть отсылка и к экономии времени, которой удалось достичь за счет внедрения ИИ-тестов: «The time required to add or improve unit tests shrank from weeks to hours», — то есть сокращение времени с недель до часов. Для небольшой команды такая экономия времени весьма значительна.
В качестве оффтопа. Недавно я говорил со своим знакомым, который рассказал, как внутри большой финансовой компании использует Qwen AI от Alibaba для того, чтобы покрыть технической документацией все подсистемы, с которыми его подразделение работает (на уровне Solution Architecture, C4, Developer Guide). За счет дообучения Qwen через несколько циклов обучения модель начала готовить описание системы нужной детализации и глубины, и все это без привлечения людей.
Если у вас есть примеры, как вы используете ИИ в рутинных задачах, поделитесь.
Причем они не просто рассказывают об успешном результате, но и описывают весь путь. Это полезная история, потому что она не про то, как сделать очередной «тетрис» или закодить страницу сайта с нуля, а про проведение работ на базе большой существующей инфраструктуры и использование ИИ для упрощения рутинных задач.
В примере NYTimes улучшение качества тестов происходит силами самого агента, а итоговый промпт составляет около семи страниц — они написаны ИИ и уточнены человеком. Но, чтобы добиться этого, команда прошла путь проб и ошибок и в итоге делится рекомендациями по составу промпта.
Интересно, что в статье есть отсылка и к экономии времени, которой удалось достичь за счет внедрения ИИ-тестов: «The time required to add or improve unit tests shrank from weeks to hours», — то есть сокращение времени с недель до часов. Для небольшой команды такая экономия времени весьма значительна.
В качестве оффтопа. Недавно я говорил со своим знакомым, который рассказал, как внутри большой финансовой компании использует Qwen AI от Alibaba для того, чтобы покрыть технической документацией все подсистемы, с которыми его подразделение работает (на уровне Solution Architecture, C4, Developer Guide). За счет дообучения Qwen через несколько циклов обучения модель начала готовить описание системы нужной детализации и глубины, и все это без привлечения людей.
Если у вас есть примеры, как вы используете ИИ в рутинных задачах, поделитесь.
👍1
Media is too big
VIEW IN TELEGRAM
Второй подход к игровому экспериментальному интерфейсу с управлением с камеры. На этот раз внес изменения в механику управления. Прицел теперь управляется поворотом головы по горизонтали и вертикали.
По-хорошему, нужно бы еще учитывать наклон головы и ее смещение, но с наскока такую математику не удалось встроить.
Но, с другой стороны, только экспериментально удается почувствовать, чего не хватает в динамике интерфейса. Даже в масштабах такого примитивного игрового механизма вариативная сложность уже настолько велика, что в голове или в статическом варианте невозможно представить реальный опыт игрока.
Заодно я понял, а точнее, почувствовал, еще одну неочевидную для меня вещь: управление частями тела создает высокую физическую и когнитивную нагрузку.
Тяжело все время ворочать головой, быстро устает шея. Хоть в интерфейсах из фантастики люди норовят руками управлять объектами в воздухе, но это не работает, потому что энергозатратно.
Хотя я все еще могу представить интересный интерфейс, который будет управляться взглядом, но для этого нужна большая точность управления, и задачи должны быть иными.
В общем, смотрите на мой результат, и если нужно, то можете брать темплейт проекта и экспериментировать сами.
Рабочий проект на V0, Темплейт на V0
Видео на Ютюб https://youtu.be/ypzkaIX5X-Y
По-хорошему, нужно бы еще учитывать наклон головы и ее смещение, но с наскока такую математику не удалось встроить.
Но, с другой стороны, только экспериментально удается почувствовать, чего не хватает в динамике интерфейса. Даже в масштабах такого примитивного игрового механизма вариативная сложность уже настолько велика, что в голове или в статическом варианте невозможно представить реальный опыт игрока.
Заодно я понял, а точнее, почувствовал, еще одну неочевидную для меня вещь: управление частями тела создает высокую физическую и когнитивную нагрузку.
Тяжело все время ворочать головой, быстро устает шея. Хоть в интерфейсах из фантастики люди норовят руками управлять объектами в воздухе, но это не работает, потому что энергозатратно.
Хотя я все еще могу представить интересный интерфейс, который будет управляться взглядом, но для этого нужна большая точность управления, и задачи должны быть иными.
В общем, смотрите на мой результат, и если нужно, то можете брать темплейт проекта и экспериментировать сами.
Рабочий проект на V0, Темплейт на V0
Видео на Ютюб https://youtu.be/ypzkaIX5X-Y
Просто чтобы расширить ваш кругозор. Проект и смешной, и серьёзный — это панель мониторинга в реальном времени пиццерий вокруг Пентагона.
Есть версия, что когда США что-то затевают, количество заказываемых пицц вырастает. Теория довольно сомнительная, но сам проект милый, и там есть русский интерфейс.
Наслаждайтесь https://www.pizzint.watch/
Есть версия, что когда США что-то затевают, количество заказываемых пицц вырастает. Теория довольно сомнительная, но сам проект милый, и там есть русский интерфейс.
Наслаждайтесь https://www.pizzint.watch/
Совсем недавно Revolut обозначил свою стратегию по интеграции своих сервисов в AI-платформы. Подробнее об этом в «Revolut to Enable Frictionless Checkout Across All Agentic Commerce Platforms for the UK and EEA».
Меня зацепила фраза генерального менеджера по эквайрингу Алекса Кодина: «Будущее шоппинга — это не веб-сайт, а общение. Мы стремимся выйти за рамки модели "кликни и оплати" и перейти в мир, где ваш AI-помощник упрощает процесс оформления заказа».
После размышлений я понял, что Revolut ожидает в первую очередь не того, что путь оформления заказа на сайте дополнится AI-инструментами, а того, что произойдёт ощутимый переход от традиционного e-commerce, к модели построенной на чатах.
Привычная воронка «поисковик → сайт → корзина → оплата» схлопывается в один запрос к AI. Пользователь пишет «найди мне беспроводные наушники до 10 000 рублей с шумоподавлением», агент находит, сравнивает и оформляет покупку — все внутри чата, без перехода на сторонние площадки.
Если эти ожидания оправдаются, маркетплейсы и агрегаторы первыми почувствуют конкуренцию со стороны AI-сервисов и агентов.
И данные показывают, что это не фантазия. По статистике Adobe for Business для американского рынка, трафик для розничной торговли от ИИ вырос за год на 693% (в обложку я взял цифры из этого отчета).
Другие отрасли тоже не отстают: туризм — рост на 539%, финансовые услуги — на 266%, IT — на 120%, медиа и развлечения — на 92%.
Но еще важнее качество этого трафик, конверсия от ИИ-переходов в среднем выше, чем от обычного трафика (до +30-50%). Улучшается не только конверсия, но и удержание, отток, глубина просмотра, время на сайте — подробнее смотрите здесь.
На мой взгляд, уже скоро AI-платформы, будь то ChatGPT, Gemini или Perplexity, замкнут на себе покупательский трафик, стараясь минимально выпускать пользователя на стороннюю площадку. И в этой ситуации банк, который будет готов к взрывному росту продаж через чаты и агентов, получит колоссальное преимущество. И к этому Revolut уже готов.
Кстати, кто-нибудь знает, делают ли что-то российские банки в области интеграции с ИИ, или это не наш путь?
Меня зацепила фраза генерального менеджера по эквайрингу Алекса Кодина: «Будущее шоппинга — это не веб-сайт, а общение. Мы стремимся выйти за рамки модели "кликни и оплати" и перейти в мир, где ваш AI-помощник упрощает процесс оформления заказа».
После размышлений я понял, что Revolut ожидает в первую очередь не того, что путь оформления заказа на сайте дополнится AI-инструментами, а того, что произойдёт ощутимый переход от традиционного e-commerce, к модели построенной на чатах.
Привычная воронка «поисковик → сайт → корзина → оплата» схлопывается в один запрос к AI. Пользователь пишет «найди мне беспроводные наушники до 10 000 рублей с шумоподавлением», агент находит, сравнивает и оформляет покупку — все внутри чата, без перехода на сторонние площадки.
Если эти ожидания оправдаются, маркетплейсы и агрегаторы первыми почувствуют конкуренцию со стороны AI-сервисов и агентов.
И данные показывают, что это не фантазия. По статистике Adobe for Business для американского рынка, трафик для розничной торговли от ИИ вырос за год на 693% (в обложку я взял цифры из этого отчета).
Другие отрасли тоже не отстают: туризм — рост на 539%, финансовые услуги — на 266%, IT — на 120%, медиа и развлечения — на 92%.
Но еще важнее качество этого трафик, конверсия от ИИ-переходов в среднем выше, чем от обычного трафика (до +30-50%). Улучшается не только конверсия, но и удержание, отток, глубина просмотра, время на сайте — подробнее смотрите здесь.
На мой взгляд, уже скоро AI-платформы, будь то ChatGPT, Gemini или Perplexity, замкнут на себе покупательский трафик, стараясь минимально выпускать пользователя на стороннюю площадку. И в этой ситуации банк, который будет готов к взрывному росту продаж через чаты и агентов, получит колоссальное преимущество. И к этому Revolut уже готов.
Кстати, кто-нибудь знает, делают ли что-то российские банки в области интеграции с ИИ, или это не наш путь?
🔥1
Прочитал интересную статью с критикой дриббл-дизайна — «Designing for Dribbble Killed Real Web Creativity».
Это не первый раз, когда звучит критика дизайна, представленного на Dribbble. Сам много раз говорил в разных аудиториях, что на Dribbble мы часто видим примеры дизайна, сделанного не для того, чтобы работать, а только для того, чтобы впечатлять.
В статье есть такой пассаж: «Dribbble приучил целое поколение дизайнеров ценить эстетику больше, чем пользовательский опыт, качество — больше, чем цель, аплодисменты — больше, чем пользователей».
Но мне кажется, несправедливо винить площадку, которая дала дизайнерам возможность делиться своими работами. То, в чем автор обвиняет Dribbble, скорее результат отбора бизнесом.
Мы находимся в странной ситуации, когда для большинства владельцев бизнеса дизайн не так важен для экономических результатов, как того хотелось бы умным дизайнерам. Поэтому яркие варианты оплачиваются с большим успехом, чем продуманные решения, даже когда эти решения обоснованы.
Мне кажется, сам подход к организации работы над дизайном, который сейчас доминирует, и обеспечивает такой результат. Это подход разового наскока на дизайн — например, в виде тендера или концепт-арта, но обязательно с сильной визуальной составляющей. Из-за этого вместо итерационного подхода, который подразумевает постоянную рефлексию и оценку решений, фокус сместился на эстетику и создание дизайн-систем.
У меня был хороший кейс, когда перестановка двух фраз меняла конверсию в следующий шаг почти на 20%. Но в ситуации зацементированного в дизайн-системе представления о продукте никому обычно не приходит в голову, что делать дизайн — это в том числе и менять что-то за счет простой перестановки элементов.
Пределом доказательства хорошего выбора решения стала отсылка к такому же решению у другой компании или на Dribbble. Бизнес хочет надежные решения, а красивое, в силу когнитивных искажений, воспринимается как более надежное. В итоге дизайнеры делают то, за что готовы платить, то есть «как у других» и «как на Dribbble».
В общем, как по мне, Dribbble не виноват, а дизайн у нас такой, потому что именно за такой дизайн платят. И, в принципе, он гораздо лучше того, что был 15 лет назад.
Тут надо было бы закончить чем-то умным, но ничего лучше не придумал, чем вставить картинку с Dribbble, которая ничего не означает.
Это не первый раз, когда звучит критика дизайна, представленного на Dribbble. Сам много раз говорил в разных аудиториях, что на Dribbble мы часто видим примеры дизайна, сделанного не для того, чтобы работать, а только для того, чтобы впечатлять.
В статье есть такой пассаж: «Dribbble приучил целое поколение дизайнеров ценить эстетику больше, чем пользовательский опыт, качество — больше, чем цель, аплодисменты — больше, чем пользователей».
Но мне кажется, несправедливо винить площадку, которая дала дизайнерам возможность делиться своими работами. То, в чем автор обвиняет Dribbble, скорее результат отбора бизнесом.
Мы находимся в странной ситуации, когда для большинства владельцев бизнеса дизайн не так важен для экономических результатов, как того хотелось бы умным дизайнерам. Поэтому яркие варианты оплачиваются с большим успехом, чем продуманные решения, даже когда эти решения обоснованы.
Мне кажется, сам подход к организации работы над дизайном, который сейчас доминирует, и обеспечивает такой результат. Это подход разового наскока на дизайн — например, в виде тендера или концепт-арта, но обязательно с сильной визуальной составляющей. Из-за этого вместо итерационного подхода, который подразумевает постоянную рефлексию и оценку решений, фокус сместился на эстетику и создание дизайн-систем.
У меня был хороший кейс, когда перестановка двух фраз меняла конверсию в следующий шаг почти на 20%. Но в ситуации зацементированного в дизайн-системе представления о продукте никому обычно не приходит в голову, что делать дизайн — это в том числе и менять что-то за счет простой перестановки элементов.
Пределом доказательства хорошего выбора решения стала отсылка к такому же решению у другой компании или на Dribbble. Бизнес хочет надежные решения, а красивое, в силу когнитивных искажений, воспринимается как более надежное. В итоге дизайнеры делают то, за что готовы платить, то есть «как у других» и «как на Dribbble».
В общем, как по мне, Dribbble не виноват, а дизайн у нас такой, потому что именно за такой дизайн платят. И, в принципе, он гораздо лучше того, что был 15 лет назад.
Тут надо было бы закончить чем-то умным, но ничего лучше не придумал, чем вставить картинку с Dribbble, которая ничего не означает.
🔥3
Media is too big
VIEW IN TELEGRAM
Сегодня пример проекта как раз в парадигме вайбкодинга для своих нужд.
С утра решил сделать для своего блога новую страницу, и по ходу дизайна родилась идея добавить туда простую анимацию. Но я захотел, чтобы на анимации был прыгающий человек. В итоге за 40 минут на V0 я собрал проект, который из видео делает SVG-анимацию.
Не все работает идеально, но для проектов под себя идеальная работа и не нужна. Зато результат в итоге получился именно такой, какой мне нужен на данный момент.
Ссылка на конечный проект: https://v0-video-to-svg-animation.vercel.app/
Видео на ютюбе https://youtu.be/__Is1YJA3rg
С утра решил сделать для своего блога новую страницу, и по ходу дизайна родилась идея добавить туда простую анимацию. Но я захотел, чтобы на анимации был прыгающий человек. В итоге за 40 минут на V0 я собрал проект, который из видео делает SVG-анимацию.
Не все работает идеально, но для проектов под себя идеальная работа и не нужна. Зато результат в итоге получился именно такой, какой мне нужен на данный момент.
Ссылка на конечный проект: https://v0-video-to-svg-animation.vercel.app/
Видео на ютюбе https://youtu.be/__Is1YJA3rg
🙊1
Развитие ИИ движется семимильными шагами, но все еще это хаотические потуги для многих компаний. В прошлом году я пробовал сформулировать принципы, которые бы могли помочь сфокусировать усилия по внедрению ИИ инструментов и которые бы помогли выстроить дорожную карту для этого процесса.
После некоторых исследований я в итоге остановился на формулировке простого фреймворка.
Фреймворк построен как дорожная карта развития ИИ, которая помогает двигаться от ситуации низкой зрелости компании и фрагментарного подхода к внедрению ИИ к ситуации глубокой интеграции ИИ в процессы. Через определение приоритетов можно выстроить реалистичный путь движения от краткосрочных улучшений к стратегическим изменениям.
First STAIR: Время, Стоимость, Эффективность
На первом этапе ИИ применяется к существующим процессам, чтобы достичь ощутимого эффекта в операционной эффективности.
Речь идет о сокращении времени выполнения задач, оптимизации затрат и устранении узких мест, мешающих масштабированию. Этот шаг нацелен на быстрый возврат инвестиций и создание внутренней уверенности в ценности ИИ.
В качестве простой цели можно поставить экономию времени.
Минимальная цель - это 4 часа в неделю на сотрудника, но в качестве оптимальной цели - 10 часов в неделю на сотрудника (см. The AI Proficiency Report).
Second STAIR: Качество, Улучшение отдачи
На второй ступени компании переходят от повышения производительности к повышению качества результатов. ИИ помогает принимать более точные решения, персонализировать клиентский опыт и улучшать бизнес-метрики — будь то конверсия, удержание или маржинальность.
На этом уровне ИИ способен стать фактором конкурентного преимущества.
Сейчас все больше появляется стартапов, которые обещают новый качественный результат, например, от автоматизации поддержки (decagon.ai) до предиктивной аналитики оттока (churned.io) и т.д.. И большая четверка активно продвигает именно этот нарратив, там во многом ставка делается на AI агентов.
Third STAIR: Новая система
Третья ступень — это стратегическая трансформация.
Компания начинает не просто использовать ИИ, а строить бизнес-модель вокруг него. Это означает создание новых продуктов, переопределение цепочек создания ценности и формирование экосистем, где данные и алгоритмы становятся ядром бизнеса, а автономные агенты ключевыми элементами ее работы.
Пока еще нет ни одной такой компании, но именно здесь будут рождаться новые лидеры рынка.
Мне нравятся эти три шага, потому что они дают простой фокус для приложения усилий и помогают выстроить стратегию внедрения ИИ. А моя практика показывает, что когда есть правильный фокус, то достижение результата более вероятно.
Если у вас в компании уже есть стратегия, связанная с ИИ, то может, поделитесь ее тезисами и ориентирами?
После некоторых исследований я в итоге остановился на формулировке простого фреймворка.
Фреймворк построен как дорожная карта развития ИИ, которая помогает двигаться от ситуации низкой зрелости компании и фрагментарного подхода к внедрению ИИ к ситуации глубокой интеграции ИИ в процессы. Через определение приоритетов можно выстроить реалистичный путь движения от краткосрочных улучшений к стратегическим изменениям.
First STAIR: Время, Стоимость, Эффективность
На первом этапе ИИ применяется к существующим процессам, чтобы достичь ощутимого эффекта в операционной эффективности.
Речь идет о сокращении времени выполнения задач, оптимизации затрат и устранении узких мест, мешающих масштабированию. Этот шаг нацелен на быстрый возврат инвестиций и создание внутренней уверенности в ценности ИИ.
В качестве простой цели можно поставить экономию времени.
Минимальная цель - это 4 часа в неделю на сотрудника, но в качестве оптимальной цели - 10 часов в неделю на сотрудника (см. The AI Proficiency Report).
Second STAIR: Качество, Улучшение отдачи
На второй ступени компании переходят от повышения производительности к повышению качества результатов. ИИ помогает принимать более точные решения, персонализировать клиентский опыт и улучшать бизнес-метрики — будь то конверсия, удержание или маржинальность.
На этом уровне ИИ способен стать фактором конкурентного преимущества.
Сейчас все больше появляется стартапов, которые обещают новый качественный результат, например, от автоматизации поддержки (decagon.ai) до предиктивной аналитики оттока (churned.io) и т.д.. И большая четверка активно продвигает именно этот нарратив, там во многом ставка делается на AI агентов.
Third STAIR: Новая система
Третья ступень — это стратегическая трансформация.
Компания начинает не просто использовать ИИ, а строить бизнес-модель вокруг него. Это означает создание новых продуктов, переопределение цепочек создания ценности и формирование экосистем, где данные и алгоритмы становятся ядром бизнеса, а автономные агенты ключевыми элементами ее работы.
Пока еще нет ни одной такой компании, но именно здесь будут рождаться новые лидеры рынка.
Мне нравятся эти три шага, потому что они дают простой фокус для приложения усилий и помогают выстроить стратегию внедрения ИИ. А моя практика показывает, что когда есть правильный фокус, то достижение результата более вероятно.
Если у вас в компании уже есть стратегия, связанная с ИИ, то может, поделитесь ее тезисами и ориентирами?
👍1👀1
Новые ИИ сейчас затрагивают не только генерацию картинок и бесконечные мемы, но они привносят что-то новое и в то, что, казалось бы, не должно меняться.
В блоге Vercel вышла статья «Making agent-friendly pages with content negotiation» с довольно актуальной темой. Они пишут, что начали выдавать на запрос
Типичная страница занимает 500 KB с учетом HTML, CSS и JavaScript. Однако в формате Markdown сам контент страницы весит всего 2 KB. Значительное сокращение объема загрузки и сильное упрощение для ИИ при анализе содержания. С учетом того, что на запрос тратятся токены, более компактный контент с большей вероятностью не столкнется с ограничениями при его обработке.
Зная, что российские компании отличаются инновационностью, я пошел проверить, реализовано ли у них это. И, конечно, зашел на сайт самой большой и богатой ИТ-компании России — на сайт Сбербанка. И, конечно, там запрос под Markdown не обрабатывается. Потом зашел на сайты Tinkoff, Ozon, Wildberries — и там то же самое.
В общем, пока это не стало распространенным явлением. Хотя роль ИИ-поиска все выше, и все компании, в принципе, должны быть заинтересованы в том, чтобы ИИ эффективно обрабатывал их контент.
Но есть шанс, что, сидя за своим монитором, я просто чего-то не замечаю.
Может у вас уже внедряют выдачу
В блоге Vercel вышла статья «Making agent-friendly pages with content negotiation» с довольно актуальной темой. Они пишут, что начали выдавать на запрос
Accept: text/markdown, text/html, */* не код страниц, а ответ в формате Markdown. И для объяснения этого есть хороший аргумент.Типичная страница занимает 500 KB с учетом HTML, CSS и JavaScript. Однако в формате Markdown сам контент страницы весит всего 2 KB. Значительное сокращение объема загрузки и сильное упрощение для ИИ при анализе содержания. С учетом того, что на запрос тратятся токены, более компактный контент с большей вероятностью не столкнется с ограничениями при его обработке.
Зная, что российские компании отличаются инновационностью, я пошел проверить, реализовано ли у них это. И, конечно, зашел на сайт самой большой и богатой ИТ-компании России — на сайт Сбербанка. И, конечно, там запрос под Markdown не обрабатывается. Потом зашел на сайты Tinkoff, Ozon, Wildberries — и там то же самое.
В общем, пока это не стало распространенным явлением. Хотя роль ИИ-поиска все выше, и все компании, в принципе, должны быть заинтересованы в том, чтобы ИИ эффективно обрабатывал их контент.
Но есть шанс, что, сидя за своим монитором, я просто чего-то не замечаю.
Может у вас уже внедряют выдачу
text/markdown?Vercel
Making agent-friendly pages with content negotiation
Learn how Vercel uses HTTP content negotiation to serve markdown to agents and HTML to humans from the same URL, reducing response sizes by 90% while keeping both versions synchronized.
🔥1🤔1
This media is not supported in your browser
VIEW IN TELEGRAM
Работая с ИИ над анимацией для блога, пришлось вспомнить законы Мерфи: «Если что-то может пойти не так, оно пойдет не так». И я думаю, что это теперь базовый принцип вайб-кодинга.
Задача довольно простая, я хотел, чтобы шарики летали по кривой, а пользователь мог их хватать и толкать. Я экспортировал кривую в SVG из Figma и пошел в ChatGPT с промтом, в котором указал «использовать популярную и современную JS-библиотеку». Это важный момент, потому что по опыту вижу, что часто ИИ пишет код с нуля, и такой результат менее стабилен, чем при использовании готовых библиотек.
Но вот что интересно, любое необъявленное поведение может быть реализовано как угодно. В промте я не сказал, откуда появляются шарики и они стали возникать в случайном месте кривой. Не уточнил, что делать с достигшими конца пути и они зависали и накапливались там. А первоначальный промт, использовать пятисекундный интервал для появления шариков, проигнорировали. Пришлось итеративно уточнять поведение системы несколько раз.
В итоге получил блок, который работает на 95% от моих ожиданий. И это нормальный результат. Даже хороший.
И это ситуация регулярного компромисса при работе с ИИ, когда ты все время приближаясь к целевому результату, но должен быть готовым согласиться на компромиссный вариант или немного иное решение. Иначе есть шанс зациклиться в бесконечных попытках исправить код.
Потому что я все чаще думаю: а где теперь граница моей компетенции как дизайнера? Раньше я бы не взялся за такую задачу или потратил неделю на изучение GSAP. Сейчас сделал за час, но с осознанием, что контролирую процесс лишь частично. Я научился формулировать намерение, корректировать курс и принимать 95% как достаточный результат.
Кстати, тут как раз вспоминается статья «The Design Vibeshift» про изменение парадигмы дизайн-подхода вместе с переключение дизайнеров от работы с хостом в Figma к кодированию результата через ИИ. Там есть много интересных мыслей, не хочу их пересказывать, но одну цитату от Hardik Pandya (Head of Design at Atlassian, это они делают Jira) приведу: «Figma очень быстро становится огромным узким местом в создании продуктов.»
Не думаю, что это приговор традиционному дизайну, но, возможно, это повод задуматься и начать делать что-то через вайб-код.
А то, что получилось у меня, в рамках текущего вайб-код эксперимента, можно посмотреть здесь.
Задача довольно простая, я хотел, чтобы шарики летали по кривой, а пользователь мог их хватать и толкать. Я экспортировал кривую в SVG из Figma и пошел в ChatGPT с промтом, в котором указал «использовать популярную и современную JS-библиотеку». Это важный момент, потому что по опыту вижу, что часто ИИ пишет код с нуля, и такой результат менее стабилен, чем при использовании готовых библиотек.
Но вот что интересно, любое необъявленное поведение может быть реализовано как угодно. В промте я не сказал, откуда появляются шарики и они стали возникать в случайном месте кривой. Не уточнил, что делать с достигшими конца пути и они зависали и накапливались там. А первоначальный промт, использовать пятисекундный интервал для появления шариков, проигнорировали. Пришлось итеративно уточнять поведение системы несколько раз.
В итоге получил блок, который работает на 95% от моих ожиданий. И это нормальный результат. Даже хороший.
И это ситуация регулярного компромисса при работе с ИИ, когда ты все время приближаясь к целевому результату, но должен быть готовым согласиться на компромиссный вариант или немного иное решение. Иначе есть шанс зациклиться в бесконечных попытках исправить код.
Потому что я все чаще думаю: а где теперь граница моей компетенции как дизайнера? Раньше я бы не взялся за такую задачу или потратил неделю на изучение GSAP. Сейчас сделал за час, но с осознанием, что контролирую процесс лишь частично. Я научился формулировать намерение, корректировать курс и принимать 95% как достаточный результат.
Кстати, тут как раз вспоминается статья «The Design Vibeshift» про изменение парадигмы дизайн-подхода вместе с переключение дизайнеров от работы с хостом в Figma к кодированию результата через ИИ. Там есть много интересных мыслей, не хочу их пересказывать, но одну цитату от Hardik Pandya (Head of Design at Atlassian, это они делают Jira) приведу: «Figma очень быстро становится огромным узким местом в создании продуктов.»
Не думаю, что это приговор традиционному дизайну, но, возможно, это повод задуматься и начать делать что-то через вайб-код.
А то, что получилось у меня, в рамках текущего вайб-код эксперимента, можно посмотреть здесь.
👾1
Просматривал старые публикации и наткнулся на незаслуженно забытый вариант схемы стратегического плана, который я создавал для редизайна «Комсомольской правды». Он мне до сих пор нравится, потому что отражает необходимые усилия для достижения комплексного результата и помогает фокусироваться на самом результате, а не соскальзывать в текучку промежуточных задач.
Это визуализация из статьи про редизайн сайта газеты у меня в блоге.
Подход к созданию этого стратегического плана проходил через несколько этапов:
— Приоритизировать цели: преобразовать хаотичное облако целей в упорядоченный список, чтобы ответить на вопрос «что важнее».
— Выразить цели через метрики: сформулировать метрики для каждой цели, указать, как их считать, и выявить факторы влияния.
— Измерять метрики в динамике: убедиться, что метрики можно рассчитывать для сравнения изменений; использовать гипотезы для неопределенных факторов.
— Определить зависимости: выявить ключевые влияния факторов на метрики, упростив картину до основных сил.
— Создать стратегический план: объединить цели, метрики, факторы и действия (промежуточные задачи) в единое пространство, фокусируясь на главной цели для достижения остальных побочно.
Обо всем этом я подробнее писал в статье на Medium , кажется, это моя самая залайканная статья там.
Это визуализация из статьи про редизайн сайта газеты у меня в блоге.
Подход к созданию этого стратегического плана проходил через несколько этапов:
— Приоритизировать цели: преобразовать хаотичное облако целей в упорядоченный список, чтобы ответить на вопрос «что важнее».
— Выразить цели через метрики: сформулировать метрики для каждой цели, указать, как их считать, и выявить факторы влияния.
— Измерять метрики в динамике: убедиться, что метрики можно рассчитывать для сравнения изменений; использовать гипотезы для неопределенных факторов.
— Определить зависимости: выявить ключевые влияния факторов на метрики, упростив картину до основных сил.
— Создать стратегический план: объединить цели, метрики, факторы и действия (промежуточные задачи) в единое пространство, фокусируясь на главной цели для достижения остальных побочно.
Обо всем этом я подробнее писал в статье на Medium , кажется, это моя самая залайканная статья там.
✍2
ИИ все больше используется в разработке, и не прекращается разговор о его эффективности. Недавно вышла статья по результатам исследования Anthropic «Исследование Anthropic опровергло идею сверхэффективности ИИ-ассистентов для программистов».
В статье ссылка на свежее исследование, которое показывает, что решение новых задач в области программирования с использованием ИИ не дает значительного прироста производительности. То есть не получается существенно выиграть в скорости. Но при этом возможна сильная потеря в качестве.
Исследователи не отрицают полезность ИИ, но указывают на то, что в эксперименте качество зависело в том числе от подхода, который использовали люди. Те, кто полагался только на ИИ, с одной стороны получали результат быстрее всего, но их результат не был высокого качества.
При этом, когда испытуемый начинал задавать дополнительные вопросы ИИ, делать уточнения, время выполнения задания увеличивалось. Составление промптов и предоставление точного контекста для выполнения задачи занимало столько же времени, сколько и ручное написание кода у некоторых участников.
Исследователи показали шесть паттернов поведения в отношении ИИ, и в тех ситуациях, когда люди задавали концептуальные вопросы и запрашивали объяснения результата, качество было выше, чем в случаях отсутствия вовлеченности.
Вот как исследователи описали паттерны поведения:
AI Delegation (Делегирование ИИ): полностью полагались на ИИ при написании. Эта группа выполнила задания быстро и с небольшим количество ошибок или вообще без них.
Progressive AI Reliance (Постепенная зависимость от ИИ): начали с 1–2 вопросов и в конечном итоге делегировали написание всего кода ИИ. Эта группа показала низкие результаты в тесте, в основном из-за того, что не смогла понять концепции для одного из заданий.
Iterative AI Debugging (Итеративная отладка ИИ): полагались на ИИ для отладки или проверки своего кода. Эта группа делала больше запросов к ИИ-помощнику, но использовала его для решения проблем, а не для уточнения собственного понимания.
Generation-Then-Comprehension (Генерация — понимание): сначала генерировали код, а затем вручную копировали или вставляли его в свою работу. После генерации кода задавали ИИ уточняющие вопросы для улучшения понимания. Эти участники не отличались высокой скоростью, но продемонстрировали высокий уровень понимания в тесте.
Hybrid Code-Explanation (Гибридный код — объяснение): участники составляли гибридные запросы, в которых просили сгенерировать код вместе с его объяснением. Чтение и понимание объяснений занимало больше времени, но обеспечивало более высокое качество.
Conceptual Inquiry (Концептуальное исследование): задавали только концептуальные вопросы. Хотя эта группа столкнулась со многими ошибками, они самостоятельно их исправляли. В среднем этот режим оказался самым быстрым среди высокоэффективных и вторым по скорости после режима делегирования ИИ.
Но есть пара мест и для критики исследования.
Я бы отметил, что в исследовании использовалась модель GPT-4o, которая на сегодняшний день не является лучшей для решения задач в области программирования. Если была бы модель Gemini-3-Pro (сейчас она на первом месте в https://openlm.ai/chatbot-arena/ ), то быть может результаты были бы другими.
Кроме того, программисты работали с новой для себя библиотекой, и модель, соответственно, тоже имела дело с новым кодом. Таких задач в обычной практике немного. Большинство разработчиков сталкиваются с типичными для себя и отрасли задачами. Подозреваю, что для них качество ответов используемого ИИ было бы значительно выше. И в этой ситуации AI Delegation получил бы более значительную оценку.
Но в любом случае стоит обратить внимание на то, что изменение самого подхода к использованию ИИ влияет на результаты. Поэтому разумно, когда компании проводят внутри себя программы по распространению эффективного использования ИИ в работе и находят возможность фокусироваться на методологии работы с ИИ, потому что, как кажется, именно здесь проходит водораздел между «немного облегчает жизнь» и «это просто космос».
В статье ссылка на свежее исследование, которое показывает, что решение новых задач в области программирования с использованием ИИ не дает значительного прироста производительности. То есть не получается существенно выиграть в скорости. Но при этом возможна сильная потеря в качестве.
Исследователи не отрицают полезность ИИ, но указывают на то, что в эксперименте качество зависело в том числе от подхода, который использовали люди. Те, кто полагался только на ИИ, с одной стороны получали результат быстрее всего, но их результат не был высокого качества.
При этом, когда испытуемый начинал задавать дополнительные вопросы ИИ, делать уточнения, время выполнения задания увеличивалось. Составление промптов и предоставление точного контекста для выполнения задачи занимало столько же времени, сколько и ручное написание кода у некоторых участников.
Исследователи показали шесть паттернов поведения в отношении ИИ, и в тех ситуациях, когда люди задавали концептуальные вопросы и запрашивали объяснения результата, качество было выше, чем в случаях отсутствия вовлеченности.
Вот как исследователи описали паттерны поведения:
AI Delegation (Делегирование ИИ): полностью полагались на ИИ при написании. Эта группа выполнила задания быстро и с небольшим количество ошибок или вообще без них.
Progressive AI Reliance (Постепенная зависимость от ИИ): начали с 1–2 вопросов и в конечном итоге делегировали написание всего кода ИИ. Эта группа показала низкие результаты в тесте, в основном из-за того, что не смогла понять концепции для одного из заданий.
Iterative AI Debugging (Итеративная отладка ИИ): полагались на ИИ для отладки или проверки своего кода. Эта группа делала больше запросов к ИИ-помощнику, но использовала его для решения проблем, а не для уточнения собственного понимания.
Generation-Then-Comprehension (Генерация — понимание): сначала генерировали код, а затем вручную копировали или вставляли его в свою работу. После генерации кода задавали ИИ уточняющие вопросы для улучшения понимания. Эти участники не отличались высокой скоростью, но продемонстрировали высокий уровень понимания в тесте.
Hybrid Code-Explanation (Гибридный код — объяснение): участники составляли гибридные запросы, в которых просили сгенерировать код вместе с его объяснением. Чтение и понимание объяснений занимало больше времени, но обеспечивало более высокое качество.
Conceptual Inquiry (Концептуальное исследование): задавали только концептуальные вопросы. Хотя эта группа столкнулась со многими ошибками, они самостоятельно их исправляли. В среднем этот режим оказался самым быстрым среди высокоэффективных и вторым по скорости после режима делегирования ИИ.
Но есть пара мест и для критики исследования.
Я бы отметил, что в исследовании использовалась модель GPT-4o, которая на сегодняшний день не является лучшей для решения задач в области программирования. Если была бы модель Gemini-3-Pro (сейчас она на первом месте в https://openlm.ai/chatbot-arena/ ), то быть может результаты были бы другими.
Кроме того, программисты работали с новой для себя библиотекой, и модель, соответственно, тоже имела дело с новым кодом. Таких задач в обычной практике немного. Большинство разработчиков сталкиваются с типичными для себя и отрасли задачами. Подозреваю, что для них качество ответов используемого ИИ было бы значительно выше. И в этой ситуации AI Delegation получил бы более значительную оценку.
Но в любом случае стоит обратить внимание на то, что изменение самого подхода к использованию ИИ влияет на результаты. Поэтому разумно, когда компании проводят внутри себя программы по распространению эффективного использования ИИ в работе и находят возможность фокусироваться на методологии работы с ИИ, потому что, как кажется, именно здесь проходит водораздел между «немного облегчает жизнь» и «это просто космос».