Интерфейсы *

Почему современные интерфейсы иногда усложняют жизнь

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

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

1️⃣ Как изменилось взаимодействие человека с интерфейсами?

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

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

2️⃣ Почему даже современный интерфейс может утомлять пользователя?

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

3️⃣ Получается, «проще» не всегда означает «лучше»?

Именно. Иногда в погоне за минимализмом или новыми трендами мы убираем то, что было интуитивно понятно. 

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

4️⃣ Можно ли создать интерфейс, который будет удобен для всех?

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

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

5️⃣ Как понять, что новое решение действительно улучшает интерфейс?

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

→ Подробнее своим опытом Динара поделилась в статье.

Новая экранизация «Одиссеи» в очередной раз привлекла внимание к стандарту IMAX, точнее, к его плёночной разновидности. В прокат картина вышла в том числе на плёнке 15/70, кадр которой, в зависимости от разновидности использованной апертуры, в 7–11 больше обычного.

По названию стандарта нетрудно догадаться, о чём идёт речь: на плёнке шириной 70 мм каждый кадр занимает 15 шагов перфораций. Плёнка при этом движется горизонтально, а не привычным для нас вертикальным образом. При скорости в 24 к/с через проектор в секунду проходит около 1,7 м плёнки — это 6,1 км/ч, скорость быстрого шага. В результате полнометражка в 15/70 — это физический объект огромных размеров.

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

Подсчёт кадров остановился на отметке 255 315. Как пишет киномеханик, общая протяжённость собранной программы достигает 18,2 км, масса — около 286 кг. Здесь, правда, склеены и несколько минут пролога третьей части «Дюны» Дени Вильнёва, которые в залах IMAX эксклюзивно демонстрируют в качестве бонуса к «Одиссее» Нолана. Попутно Палмер опроверг слухи о том, что «Одиссея» в IMAX 15/70 весит больше 800 фунтов (362 кг).

Любопытно поглазеть на другие детали этого интерфейса. Дело в том, что машина во многом уникальная: больше плёночных проекторов не производят, а сохранившиеся экземпляры достают со складов, ремонтируют и повторно вводят в эксплуатацию. В мире подобных плёночных проекторов на ходу осталось очень мало — «Одиссея» в IMAX 15/70 вышла всего на 41 экране.

Современные лазерные проекторы IMAX выпускаются, стандарт живёт. Старые плёночные машины нужны лишь для редких событийных спецрелизов с претензией на высокое кино. Типичный пример: кинотеатр IMAX в Мельбурне в 2015 году после установки двойной лазерной системы плёночный проектор демонтировал, но уже в 2017 аппарат 15/70 пришлось доставать со склада ради спецпроката «Дюнкерка». С тех пор и до наших дней в этом австралийском кинотеатре плёночный и цифровой проекторы стоя́т рядом.

Интерфейс промышленной операторской панели проектора 15/70 походит на что-то со станции «Севастополь» из игры Alien: Isolation. Разве что в данном случае это не стилизация, а просто старый HMI, human-machine interface — период производства машины Палмер расплывчато определяет между восьмидесятыми годами прошлого века и нулевыми этого.

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

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

Киномеханик развеял миф, что проектором управляет КПК PalmPilot 2002 года. Три года назад при прокате «Оппенгеймера» прошёл слух, будто древние проекторы управляются наладонниками Palm m130. На деле для киномеханика это в большей степени элемент индикации состояния платтеров — горизонтальных дисков, с которых плёнка подаётся на проектор.

В комментариях также спрашивали, почему в одном случае фрагмент из третьей части «Дюны» не показали. Как предположил Джесси, в аппаратной почему-то решили выдать бэкап в виде цифровой копии. По данным Палмера, все залы IMAX для копий «Одиссеи» в 15/70 получили плёночный бонус в виде фрагмента фильма «Дюна: Часть третья».

Подчеркивать индивидуальность или быть удобным?

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

Звучит - круто! Стимулирующе.

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

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

Очевидно - большинству непривычно пользоваться сервисом с настолько “выраженной индивидуальностью” :) Очевидно...

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

Как думаете, на что лучше сделать ставку по умолчанию?

На "незабываемую индивидуальность", на банальность светлого или на молодежность тёмного?

Эгегей!
Я продолжаю заморачиваться версиями и вот еще одна отличная новость, kui увеличился до версии 1.0000000000000000000000000000000000000000001! Довольно длинный получился. Номер версии. А вы что подумали? По случаю добавил полезную функцию debase64 для работы с сертификатами (secrets). Сертификаты в формате kubernetes.io/tls кодируются base64. Debase64 декодирует информацию из секретов, теперь можно без труда сравнивать сертификаты из секретов кубера с сертификатами где-то, где вы их храните.

Творите, выдумывайте, пробуйте!)

Рекрутинг респондентов: что сломалось и что делать?

Разбирались на круглом столе UX Feedback про рекрутинг респондентов для UX-исследований вместе с Кириллом Малыком из команды пользовательского опыта РТЛабс

Главное, что прозвучало:
— пользователи стали меньше доверять исследованиям
— старые способы рекрутинга работают всё хуже
— стоимость привлечения продолжает расти
— всё больше команд строят собственные базы и сообщества
— бережное отношение к респондентам — уже не преимущество, а необходимость

👉 Смотреть в записи

Юху!
Смотрите sshto обновилось до версии 1.01! В новой версии по многочисленным (2) просьбам добавил поддержку множественных значений Host. Теперь вот такой конфиг:

Host     homyak home house
HostName localhost
User     root

Будет обработан вот так:

Творите, выдумывайте, пробуйте!)

Личный бренд и бренд продукта – странная и не всегда простая связка.

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

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

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

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

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

Наверное, самый здоровый вариант –  где-то посередине. Хотя я не уверена, что уже до конца понимаю, где именно проходит эта середина.

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

Это тонкий баланс, и, кажется, его невозможно найти теоретически. Только на практике: через свои неловкие посты, сомнения, эксперименты и постепенное понимание, что звучит честно, а что уже похоже на forced marketing.

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

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

Туц-туц-туц. Слышите?

Это звуки Техно-Квартирника, нашей регулярной неформальной встречи сообщества A?.Frontend. В этот раз встречаемся в Москве, в нашем ИТ-офисе на Технопарке, и онлайн — из любой точки мира.

27 мая (среда) в 19:00 переходим в режим «техно», чтобы разобрать примеры, как использовать ИИ-агенты в разработке интерфейсов:

Чистая архитектура frontend-приложений и при чём здесь ИИ-агенты?

Илья Агапов, технический лидер разработки, Данила Звягин, ведущий разработчик, Альфа-Банк

Как я поднял ИИ-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина

Роман Троицкий, старший разработчик интерфейсов (frontend), Сбер

Как ИИ ломают привычную модель веб-безопасности?

Анастасия Егорова, разработчик интерфейсов (frontend), CozyFrontend

После каждого доклада устроим дискуссию по самым трендовым темам, а в завершении вечера проведём:

• Консультации по ИИ-агентам

• Диджей-сет

• Нетворкинг

Регистрируйтесь

ИИ: Гонки на лафетах

Всего лишь иллюстрация. Примерно год-полтора назад решил я выбрать - deepseek или chatgpt. И выбрал deepseek. Однако через некоторое время стал обращать внимание не его лютый подхалимаж, что, кстати, не раз уже обыграли в различных мемах. Не в отношении deepseek, а относительно AI в общем.
Проблему обсудил и с deepseek, и с windows copilot (chatgpt был благополучно забыт). Deepseek стал подхалимски юлить, мол да, copilot хорош и все такое. Copilot же оправдал Deepseek - мол это такая технология поддержки энтузиазма в клиенте. Между прочим тонко намекнув, что сам-то он лучше и глубже. Но это присказка, сказка впереди.
В процессе завершения разработки обертки над EntityFramework попросил оценить проект сразу четверых: deepseek, copilot, chatgpt и grok. Результат ожидаем - сыровато, но в продакшн годно, оценки 4.5/5 и 7/10.
Претензии разные, существенных практически не было, но в одно они уперлись хором - "тяжелые" интерфейсы. Подробности опущу, это было семейство generic-интерфейсов со многими типами. Что-то вроде IInterface(T1), IInterface(T1,T2) и так далее, пока не надоест.
Несколько итераций я эти наезды игнорировал, но AI не унимались. Уже и оценки до 9/10 дошли, но проблема-то осталась.
Вспылил и написал письмо на полстраницы, начинавшееся фразой "Господа AI !". Концептуальное. Гневное. Циркулярное И получил ответы:
- ООО! Мы все поняли. Гениально, единственно верное решение.
Это deepseek 5/5 и copilot 10/10.
- Нуу... Проблема решена, но способ так себе... в общем 9/10 и есть гораздо лучшие альтернативы, рассмотрим?
Это chatcpt и grok. И что характерно, альтернативы предлагают разные, по паре штук каждый. Рассмотрим, конечно.

Это просто зарисовка не о разработке обертки, а о различных системах AI.

UPD: Забыл добавить - deepseek еще и извинился за необоснованные оценки :)))

Rust GUI: поверхностный обзор и шпаргалка

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

Перед выбором любого фреймворка — откройте areweguiyet.com. Там видно зрелость, лицензию, платформы и число скачиваний. Лучшая страховка от «библиотека умерла через месяц».

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

Immediate Mode (пересобирается каждый кадр). Суть: «Опиши, что должно быть на экране прямо сейчас». Не «создай кнопку и запомни её», а линейная пересборка каждый кадр: «если сейчас здесь нажали — сделай действие, и в любом случае нарисуй кнопку вот здесь».

— egui, Ply, Rust bindings dear imgui

Retained Mode (дерево виджетов в памяти). Суть: «Измени то, что уже есть». Один раз описывается структуру UI (создал кнопку, положил в layout), а потом меняются её свойства: текст, цвет, видимость. Кнопка «живёт» в памяти как объект.

— GTK и FLTK.

Reactive (реактивный режим). Суть: «UI — это функция от состояния». UI описывается как отображение некоторого состояния. Когда состояние меняется, фреймворк сам пересчитывает, что именно в UI нужно обновить.

— Azul, Cushy, Floem, Ribir, Yew, Xilem, Dioxus (использует Virtual DOM), Leptos.

Hybrid Mode (декларативный API + оптимизированный retained‑рендеринг)

— GPUI(Zed)

Теперь — к конкретным фреймворкам, которые сейчас на слуху.

Tauri. Аналог Electron. Бэкенд пишется на Rust, фронтенд — с помощью JS фреймворков (React, Vue, Svelte). Но архитектура платформы не ограничивается этим стеком. Благодаря поддержке WebAssembly можно использовать и полностью Rust-решения. Например, фреймворк Leptos компилируется в WASM-модуль и запускается во встроенном WebView Tauri.

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

Iced. Кроссплатформенная библиотека, вдохновленная Elm Architecture (TEA). Типобезопасность и простота использования заявляются как ключевые принципы.Проект находится в активной разработке.

Dioxus. Фреймворк, похожий на React. Использует собственный Virtual DOM и макрос rsx!, позволяя писать HTML‑подобный код прямо внутри Rust. Dioxus Native: экспериментальный рендерер на базе WGPU, отрисовывает дерево компонентов напрямую, без использования WebView или CSS‑движка. UI‑логика и бэкенд выполняются в одном процессе, в отличие от Tauri, где фронтенд и бэкенд разделены.

Slint. Фреймворк, нацеленный на легковесность, вплоть до использования на встраиваемых устройствах. Для описания интерфейса используется собственный язык разметки (.slint), для кода доступны биндинги к Rust, C++ и JavaScript. Предлагает инструмент Live‑Preview для визуальной разработки.

Xilem. Экспериментальный фреймворк от команды Linebender на основе оригинальной архитектуры (Xilem architecture), вдохновленной Elm, SwiftUI и Flutter. Разрабатывается как преемник библиотеки Druid, работа над которой была прекращена.

Следующий шаг.

Выбор фреймворка по документации и отзывам — это половина дела. Вторая половина — попробовать его руками на минимальном примере.

Многие Rust‑фреймворки требуют системных библиотек для графики и оконных систем. Настройка «на голой» машине может занять ощутимое время и зависеть от ОС. Чтобы не разворачивать отдельное окружение под каждый вариант, удобно использовать dev‑контейнеры в VS Code. Контейнер фиксирует эту настройку один раз, и она работает одинаково на Windows, macOS и Linux (с учётом специфики Docker).

Преимущества контейнеров:

• Изолированное, воспроизводимое окружение для каждого фреймворка.

• Отсутствие конфликтов версий и зависимостей на основной машине.

• Возможность переключаться между фреймворками параллельно, не теряя контекст.

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

Что такое magicgui и зачем он нам?

magicgui — это Python‑библиотека для быстрой разработки простых интерфейсов. Если нужен сложный интерфейс с кастомной вёрсткой и нестандартным поведением — лучше взять PyQt‑Pyside. Когда задача обернуть функцию в окошко за 5 минут — magicgui справится.

В настоящее время magicgui поддерживает следующие бэкэнды:

• Qt (через PySide2 / PySide6 или PyQt5 / PyQt6 )

• Виджеты Jupyter

API организовано на двух уровнях:

Верхний уровень — магия типов. Декораторы @magicgui, @guiclass, автоопределение виджетов по аннотациям.

Нижний уровень — ручная сборка из готовых виджетов (SpinBox, Slider, PushButton).

Примеры работы: https://pyapp‑kit.github.io/magicgui/generated_examples/

Github: https://github.com/pyapp‑kit/magicgui

Нативная коммуникация: новый термин для DHAIE и человеко-ориентированного AI

Это вторая заметка в серии о терминологии DHAIE. Первая была посвящена понятию Эмулякр. DHAIE — методология коэволюции человека и AI

Почему потребовался новый термин

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

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

Для второго случая у нас не было точного слова.

В маркетинге есть «нативная реклама» — она про незаметность коммерческого сообщения. В UX есть «интуитивный интерфейс» — он про эргономику формы. В HCI есть affordance, контекстность, semantic communication. Но ни один из этих терминов не описывает то, что происходит именно в диалоге между субъектом и AI-агентом, когда взаимодействие перестаёт ощущаться как взаимодействие.

Мы вводим термин нативная коммуникация.

Определение

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

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

Якорная формула: нативная коммуникация — это когда не замечаешь границу между своим и чужим мышлением.

Три уровня нативности

Термин не бинарный. Нативность существует как спектр:

Уровень 1 — синтаксическая нативность Понятный язык, уместный регистр, правильная структура ответа. Это уровень UX и интерфейсного дизайна. Необходимое условие, но недостаточное.

Уровень 2 — когнитивная нативность Соответствие внутренней модели мышления субъекта: темп, логика, способ структурирования проблемы. Агент «думает» в той же системе координат, что и человек. Это уровень персонализации глубокого порядка — не форма, а структура.

Уровень 3 — динамическая нативность Взаимная настройка в процессе взаимодействия: агент адаптирует не только форму, но и режим — исследование, синтез, верификация — в ответ на состояние субъекта. Например: пользователь набрасывает идеи нелинейно, с незаконченными фразами и прыжками между темами. Агент распознаёт режим брейншторма и не пытается структурировать и уточнять — он подхватывает, разворачивает, предлагает неожиданные связи. Тот же агент в режиме финальной проверки ведёт себя иначе: медленнее, точнее, с вопросами. Переключение происходит без явной инструкции. Это уровень, к которому движется DHAIE как методология.

Признак ненативной коммуникации

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

Чем это не является

Нативная коммуникация — это не то же самое, что:

• Персонализация — персонализация подстраивает форму сообщения. Нативная коммуникация согласует структуру мышления.

• Интуитивный интерфейс — интуитивность описывает эргономику продукта. Нативность описывает качество диалога между субъектами.

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

Зачем продукту исследования

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

Поговорили с Илоной, продуктовым дизайнером Project Ruler, о том, как команда использует исследования в работе и какие выводы из этого делает.

• конкурентный анализ

• глубинные интервью

• древовидное тестирование

• опросы

• юзабилити-тестирование

3️⃣ Как выглядел конкурентный анализ?

Мы использовали его как основу для гипотез. Смотрели не просто интерфейсы конкурентов, а конкретные сценарии: как пользователь выполняет задачу → куда идет → что видит.

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

4️⃣ Какую пользу получили от глубинных интервью?

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

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

5️⃣ Зачем понадобилось древовидное тестирование?

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

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

6️⃣ Что оказалось самым неожиданным?

Вот несколько ключевых мыслей:

• Уведомления раздражают — 8 из 10 пользователей их просто выключают и потом переживают, что что-то пропустили.

• Пользователям нужно меньше, чем кажется — основные сценарии: список или доска задач, карточка задачи и смена статуса.

• 8 из 10 пользователей не списывают трудозатраты — это стало поводом пересмотреть приоритеты и не перегружать продукт лишним функционалом.

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

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

• Блок «Недавние» очень востребован — пользователи прямо просили его добавить.

7️⃣ Был момент, когда исследования помогли не продукту, а вашей команде?

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

8️⃣ Какой главный вывод из всего этого опыта?

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

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

Если до вас дошло обновление Firefox 149 и вы в ужасе от сломанного мультипоиска, то пока его ещё можно вернуть:

browser.search.widget.new → false

Самое печальное тут — стоящая за исчезновением история. Оказывается, команда юзабилистов из Мозиллы не смогла сделать мультипоиск аксессибильным («доступным», т.е. совместимым со скринридерами и управлением строго с клавиатуры). Решение было гениальным: нет мультипоиска — нет проблемы.

Основные ошибки при запуске UX-опросов

1. Неправильный контекст показа

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

2. Неправильная формулировка вопросов

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

3. Отсутствие сегментации, или «Ошибка средней температуры по больнице»

Средние показатели по вообще всем пользователям скрывают важные различия между сегментами. Например, 90% пользователей пользуются мобильной версией: оценка удобства 4.8. 10% пользователей — на десктопе: оценка 2.0. Средний балл: 4.42. Вывод «В целом всё ок» будет ошибочным, ведь данные говорят, что на десктопе точно есть заметные проблемы.

4. Слишком много вопросов

Бывает так, что опросы пытаются замерить всё сразу и состоят из 15–20 вопросов. Но дело в том, что длинные опросы утомляют пользователей, они бросают их на полпути или просто кликают любые варианты, чтобы закрыть форму. Оптимальное решение — 8–10 вопросов. Этого достаточно, чтобы оценить нужные параметры.

Подробнее о UX-исследованиях рассказываем на примере сайта «Халвы» в нашем блоге.

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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

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

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

• навести курсор на элемент и посмотреть, где он находится на странице

• быстро найти нужный блок через селектор

• посмотреть размеры, фон и отступы

А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

Там собраны все итоговые стили элемента — включая те, что пришли через наследование или заданы браузером. Можно быстро найти нужное свойство, например, border-radius, и понять, какое значение реально применяется.

4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

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

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

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

• выбрать готовые профили — 3G, 4G

• настроить собственную скорость сети

• протестировать поведение приложения в режиме офлайн

8️⃣ Как работать с локальными данными

Во вкладке Приложение можно посмотреть данные, которые браузер сохраняет на стороне пользователя:

1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.

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

🔟 Как записывать пользовательские сценарии

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

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

Годовалый ребёнок без присмотра решил понажимать на кнопки на коробочке и случайно удалил 32 ТБ данных на NAS‑сервере. Зачем вообще было производителю добавлять функцию «Удалить весь RAID» в меню «Быстрая настройка», родитель не понял.

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

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

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

В общем, пока потыкать в кнопки кажется быстрее и привычнее, особенно с учетом перспективы давать доступ к микрофону каждому встречному лендингу и вслух выяснять подробности)

Автоматизация без сборки с нуля: n8n теперь в Рег.облаке

В Рег.облаке появился готовый облачный образ n8n — open-source платформы для автоматизации процессов и интеграции сервисов.

n8n позволяет в визуальном интерфейсе связать API, CRM, базы данных, SaaS-сервисы и AI-инструменты без разработки с нуля. Образ разворачивается автоматически при создании сервера: Ubuntu 24.04 LTS, зависимости, SSL и домен уже настроены. После запуска можно сразу работать через web-интерфейс по HTTPS.

Сценарии использования — от обработки заявок и создания задач в CRM до CI/CD-триггеров, уведомлений о сбоях и AI-автоматизации с LLM и RAG. Можно подключить PostgreSQL и MySQL, в том числе через DBaaS.

Образ бесплатный — оплачиваются только ресурсы сервера по почасовой модели. Масштабирование доступно без переустановки.

Подробнее о доступных конфигурациях — на сайте Рег.облака.

Навеяно сегодняшней статьёй «История: как Microsoft шесть раз отказывалась от виджетов, но потом возвращала их».

Понятно, что Майкрософт просто хочет содрать с бедолаги, купившего (тем более, скачавшего) винды, 33 шкуры. И поэтому делает как бы виджеты, но они все должны вести туда, куда хочет Майкрософт. В Copilot, MSN и тому подобные места. Но давайте помечтаем, что могла бы сделать Майкрософт, если бы по-настоящему хотела сделать своим юзерам удобно.

1. Виджет это приложение, точка Приложения бывают хорошие, годные и злые, вредные. Любое приложение может сломать ваш компьютер, украсть данные и деньги. Ответственность делится так: автор приложения прилагает все усилия, чтобы приложение не делало ничего плохого. Юзер прилагает все усилия, чтобы не ставить подозрительные приложения хрен пойми откуда. Если вам кажется, что это наивно, вспомните, что именно эта схема действует на PC прямо сейчас. На Github'е @dartraiden выложил драйвер (даже не простое приложение!), который позволяет использовать недорогие карты для майнинга вместо видеокарт (за 10-15% от цены последних) и написал: «Если вы мне не доверяете, вот инструкция, как собрать драйвер самому». Спасибо, но что-то не хочется )). Собирать драйвер самому. Я доверяю автору проекта! А ещё — авторам редактора Notepad++, браузера Firefox, файлового менеджера FAR (который почти в каждой сессии просит права админа, потому что я захожу им в системные папки) и многим другим авторам приложений.

2. Любое приложение может зарегистрировать себя в качестве виджета. Такая технология у Майкрософт уже есть, и называется ActiveX. Она до сих прекрасно работает (в день, когда сломается ActiveX, я перейду на Линукс, потому что только старые приложения меня под виндой и держат).

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

   Этот файл просто создаёт маленькое окошко (говоря техническим языком, window handle), может быть написан на C или Rust, занимать килобайты и работать со скоростью света.

   Всё, что вам нужно — дополнительно записывать при регистрации идентификатор своего ActiveX-компонента в ветку реестра с виджетами.

   Чтобы было проще создавать виджеты на HTML/CSS/JS, Майкрософт мог бы добавить новый тип проекта в Visual Studio: HTML Widget. Он брал бы файлы .html/.css/.js, метаданные и запаковывал бы в ActiveX-компонент вместе с WebView2 (браузерным окном). И ваш виджет отображался бы при помощи Chromium, как это делает приложение (не виджет) Steam, но весил бы, в отличие от Steam, ровно столько, сколько весят картинки и текст.

   Разумеется, ничто не мешало бы создать виджет на C#, Qt, Delphi, на базе своей версии Chromium (как это делает Steam), на базе Gecko, на базе чего угодно.

3. Будучи хозяйкой бала, Windows предлагала бы юзеру зарегистрированные виджеты перетаскивать из палитры виджетов в следующие места: а) рабочий стол, б) панель задач, в) меню «Пуск». Разумеется, любой виджет обязан был бы имплементировать помимо стандартных интерфейсов ActiveX-компонента специальный интерфейс IAmWidget и через него рассказывать о своих требованиях. Так что виджет, которому нужна минимальная площадь 512x512 пикселей, можно было бы создать только на рабочем столе.

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