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

Полина Вострикова написала об особенностях процесса дизайна b2b- и b2c-продуктов

— В b2c релизный цикл короче. Можно быстро выпускать новые фичи, собирать отклики и дорабатывать их. Бизнес не обновляет используемые программные продукты так же часто;
— Из-за этого цена ошибки выше, и тестирование длится дольше;
— Простые на первый взгляд задачи могут оказаться довольно сложными. Например, переключение протокола шифрования из одной кнопки превращается в целый сценарий из-за того, что протоколом пользуется сеть подчинённых друг другу и сгруппированных устройств и их серверов;
— В b2b часто приходится создавать что-то с нуля и не обойтись без исследований. Но искать респондентов сложнее и проблематично тестировать прототипы на друзьях и коллегах;
— Больше объём задач (они запланированы на полгода или хотя бы квартал, см. первый пункт), поэтому особенно актуальны навыки планирования и оценки времени на выполнение задач. «Нет, мы не будем это пилить, потому что не успеем».

Дмитрий Ваницкий написал введение в веб-аналитику для дизайнеров

— Веб-аналитики заняты анализом бизнес-моделей клиентов, разработкой стратегии измерения, её внедрением, настройкой и поддержкой. Это необходимо для принятия решений и точной оценки изменений в процессах. Настольная книга: «Веб-аналитика 2.0 на практике» Авинаша Кошика;
— Что, как и зачем измерять, остаётся загадкой. Появляются фреймворки вроде HEART, но начинают сбоить или не подходят бизнес-модели, и всё откатывается к стандартным настройкам;
— Часто дизайнеры меряют, чтобы измерить. Дальше констатации фактов дело не идёт;
— Метрики, доступные из коробки: посещения и посетители, время на сайте и на странице, отказы, выходы, коэффициент конверсии;
— Чтобы понимать суть значений любого показателя, нужно смотреть на них в динамике;
— Примитивные показатели приводят к выводам о работе всей системы. Если с новым релизом увеличилось время пребывания на странице, сложно сделать вывод о причинах. И это не повод откатывать релиз;
— Воронки помогают увидеть показатели по каждому перевалочному пункту пользователей;
— Аналитики обычно не доверяют тепловым картам. Они вешают триггеры на каждый интерактивный элемент, чтобы точно знать, куда пользователь нажал, без оглядки на ширину экрана, устройство и так далее;
— Воронки могут не работать: а) важно понимать, кто именно отваливается и что с ними в принципе происходит, б) это анализ количества кликов, а не намерений, в) анализ данных в статике — плохая затея;
— Коэффициент конверсии скажет неправду, если не учесть посещения, предшествовавшие целевому действию. Иногда люди не готовы купить товар сразу;
— Усреднённый показатель конверсии или отказов тоже ничего не скажет. Надо сегментировать аудиторию, например, по источникам трафика. Может оказаться, что высокий процент отказов возник из-за плохой рекламы, создающей неадекватные ожидания;
— Сегментация — основная стратегия анализа данных, если надо докопаться до сути;
— Важно чистить данные перед анализом, например, не принимать в расчёт сессии длиной в 0 секунд;
— KPI (key performance indicator) — любая метрика, отображающая успешность работы сервиса или его части. У разных продуктов они разные;
— При выборе KPI можно скатиться к «покупкам», но стоит поискать менее тривиальные варианты вроде: процент выполнения задачи, распределение трафика, лояльность и недавность, продолжительность и глубина посещения, альтернативные каналы потребления, процент важных выходов;
— В электронной коммерции это отказы от корзины или оплаты, время и посещения до целевого действия, объём заказа, основная цель пользователя;
— Есть основные цели, критичные для бизнеса (макроконверсии, например, покупка или подписка), и вспомогательные, направленные в основном на увеличение лояльности (микроконверсии, например, получение помощи или чтение статей).

Вячеслав Лазарев написал о правилах хорошего дизайна

— Теория близости: любые объекты, расположенные рядом, воспринимаются связанно. При вёрстке текстовой страницы заголовок ставят к тексту, к которому он относится;
— Правило внутреннего и внешнего: внутреннее ≤ внешнее. Например, расстояние между словами должно быть меньше межстрочного расстояния или равно ему. Оно в свою очередь должно быть ≤ абзацного отступа, который должен быть ≤ полей вокруг блока с текстом;
— Правило якорных объектов: объекты, которые сразу бросаются в глаза читателю (иллюстрации, заголовки, пиктограммы), должны тяготеть к якорным точкам модуля, расположенным в его углах или центре;
— Закон Фиттса: чем больше расстояние от курсора до цели и чем меньше размер цели, тем сложнее в неё попасть. Поэтому кнопки делают больше, увеличивают область нажатия вокруг иконок и не ставят кнопки «Ок» и «Отмена» слишком близко друг к другу;
— Правило тинктур: нельзя накладывать эмаль на эмаль и металл на металл. Любопытное правило из геральдики о соблюдении контраста при сочетании цветов.

Энтони Ценг написал об адаптации таблиц под маленькие экраны

— Чтобы найти подходящее решение, надо понять назначение таблицы и разобраться в её структуре;
— Таблица помогает сравнивать объекты по параметрам. Первый столбец — идентификаторы объектов. Остальные столбцы — значения параметров этих объектов;
— Можно зафиксировать первый столбец на экране и дать возможность прокручивать или переключать столбцы с параметрами. Шапка таблицы тоже должна быть зафиксирована;
— Все параметры объекта (для комплексного анализа) можно показывать по нажатию на строку с этим объектом. Энтони предлагает модальное окно, но аккордеон тоже подойдёт;
— На возможность нажатия на строку может указывать иконка глаза (или шеврон, если там аккордеон);
— Если параметров немного и пользователям надо сопоставлять несколько параметров одновременно, вместо таблицы можно использовать карточки. Минусы: 1) названия параметров повторяются во всех карточках, 2) карточки занимают больше места по вертикали.

Гонсалу Диас написал об иллюзии свечения

— Это эффект, когда светлый объект кажется больше тёмного объекта такого же размера;
— На сетчатке глаза размеры объектов не отличаются, дело в первичной зрительной коре. Нейроны, которые реагируют на светлые объекты на тёмном фоне, откликаются интенсивнее нейронов, реагирующих на тёмные объекты на светлом фоне. Даже если контраст одинаковый;
— Возможно, причина в том, что светлые объекты отражают больше фотонов, чем тёмные;
— Чтобы это учесть, при создании тёмной темы можно: 1) уменьшить толщину шрифтов, 2) не использовать полностью чёрный цвет и снизить контрастность в пределах рекомендаций по доступности;
— При создании белой версии логотипа можно скорректировать толщину линий.

Егор Камелев поделился чеклистом и серией видео о проектировании регистрации

— Чеклист — список вопросов, которые можно задать при проектировании формы регистрации пользователей. Среди них:
— Будет ли регистрация отличаться для разных пользовательских ролей?
— Что делаем в сценариях, когда пользователь всё-таки ввёл свои данные неверно (например, ввёл адрес электронной почты с опечаткой или вообще чужой)?
— Нужна ли верификация аккаунта при регистрации? Будет ли набор функций в системе отличаться для верифицированных и неверифицированных пользователей?
— Помешает ли регистрация целевому действию? Не окажется ли пользователь далеко от своей цели после всех процедур? Нужно ли ему авторизоваться после регистрации или это произойдёт автоматически?

Антон Григорьев написал о функциональной спецификации интерфейса

— Это один из артефактов, который полезно создавать при проектировании интерфейсов. Она уточняет показанные в прототипе решения и отвечает на будущие вопросы разработчиков;
— В ней можно описать то, что трудозатратно или невозможно визуализировать в прототипе, и то, что на картинках человек скорее всего не заметит;
— Также она: 1) может стать частью договора, 2) помогает перепроверить и доработать свои решения;
— Во второй половине статьи я рассказал, как её писать: когда приступать, что в неё включать и как это структурировать, что писать об отдельных элементах интерфейса и что уже выходит за рамки подобного документа;
— Это, конечно, не подробное руководство с детальными чеклистами, но неплохой материал для старта.

В Kode поделились итогами митапа о голосовых интерфейсах

— Надо исследовать пользователей, чтобы: 1) найти задачи, для решения которых подойдёт голосовой интерфейс, 2) спроектировать органичное голосовое взаимодействие;
— Личностью помощника и креативностью ответов можно пожертвовать, когда нужны конкретные ответы и быстрые действия. Скорее всего, такими будут специализированные помощники;
— Для мультифункциональных помощников вроде Алисы характер важнее, так как с ними пользователи общаются чаще;
— Люди лучше воспринимают женский голос;
— Паттерны голосового взаимодействия основываются на опыте общения с другими людьми. Графический интерфейс ограничивает конкретным набором кнопок на экране. В разговоре такого ограничения нет, он может быть нелинейным, и это ключевая сложность;
— Если есть конкретный сценарий диалога (банковский перевод или заказ пиццы), пользователю придётся подстроиться, чтобы достичь цели;
— Голос — однопоточный канал взаимодействия, на который пользователь должен направлять весь фокус внимания;
— Создание уместных и естественных подсказок о возможностях помощника (вроде того, что он может подбрасывать кубик) — вызов для дизайнера;
— Важно научиться информировать о состоянии системы (слушает или нет, что-то загружает, произошла ошибка) с помощью графики, звуков и речи;
— Важна консистентность. Например, если в сценарии есть персонаж со своим характером, Маруся сначала его представляет. Или поддержка команды «повтори» в навыках, созданных разными разработчиками;
— У пользователя должна быть возможность безболезненной отмены действия без повтора диалога.

Виталий Фридман написал о форме подписки на рассылку во всплывающем окне на главной странице

— Внедрение таких форм действительно повышает количество подписчиков, но не приводит к увеличению доходов. Это плохие, случайные подписчики;
— Даже такие подписчики стоят компании денег, так как всплывающие окна отталкивают часть посетителей;
— Окно появляется не вовремя и прерывает выполнение текущей задачи пользователя;
— Такие сообщения надо отображать вовремя: на страницах с пустыми состояниями и ошибками, на продуктовых страницах и в публикациях в блоге;
— На страницах, где пользователь завершает текущую задачу или достигает определённой вехи;
— Где оказывается после отправки письма для подтверждения адреса электронной почты. Здесь можно предложить указать больше информации о себе или установить пароль в обмен на скидку;
— Рядом с ценой товара, побуждая подписаться и получить скидку на первую покупку;
— Также всплывающие окна можно сделать немодальными и сворачиваемыми, чтобы к ним можно было вернуться позднее.

Александра Савельева написала о подтверждении пользовательского действия в модальном окне

— Проблема в том, что пользователи подтверждают свои действия не задумываясь и, например, иногда удаляют не то, что хотели;
— Можно реализовать отмену действия в течение 10 секунд и отображать уведомление об этом. Так делает Gmail после отправки письма. Фактически, действие происходит на 10 секунд позднее, если пользователь не решает его отменить;
— Если разработчики не готовы так делать, можно доработать модальное окно: описать, что происходит (человек подтверждает выход именно из профиля Ozon), к чему приведёт подтверждение (перестанут отображаться персональные рекомендации). Окно станет чуть менее стандартным, повысится вероятность, что пользователь в него вчитается;
— К кнопке подтверждения можно добавить кнопку отказа от действия и сделать её акцентной. Кнопки с разрушительными действиями стоит делать красными;
— Для подтверждения самых разрушительных и редких действий (удаление проекта или профиля) можно попросить ввести в текстовое поле какую-нибудь фразу, например, название удаляемого проекта.

Игорь Штанг написал о современной русской пунктуации на примере упаковки умной розетки Яндекса

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

Тимофей Контанистов (в фамилии опечаток нет) написал об использовании Яндекс Толоки для тестирования интерфейсов

— Когда дизайнер несколько недель подряд работает над одним и тем же макетом, у него замыливается глаз;
— Иногда сложно выбрать один вариант дизайна, а проводить всё через AБ-тестирование — долго и дорого;
— Практически нет инструментов для анализа результатов Толоки, сортировать и оценивать ответы приходится вручную. Нужны навыки работы с таблицам;
— С другой стороны, нет ограничения по типу заданий. Пользователям можно предложить всё: от сравнения двух текстов до похода в магазин и проведения контрольной закупки;
— Не подходит для тестов в узких сферах. У сервиса широкая целевая аудитория, на которой удобно проверять массовые продукты и сервисы;
— Можно сочетать с другими сервисами. UsabilityHub даёт классные возможности по аналитике, но аудитория там англоязычная, а тесты — дорогие. Можно создать тест в бесплатной версии UsabilityHub, а через Толоку привести туда пользователей;
— Четыре вида тестов на Толоке: 1) side-by-side, сравнение двух вариантов, 2) first click, 3) five second test, что пользователь успевает увидеть и понять за несколько секунд, 4) тест на понятность;
— Перед запуском на большую аудиторию проверяйте понятность вопросов на небольшой аудитории;
— Есть пользователи, которые не вникают в задания. Для борьбы с ними можно: 1) использовать ловушки для читеров, 2) добавлять вопросы, на которые нельзя ответить не подумав, 3) собирать базу проверенных респондентов, 4) увеличивать количество респондентов;
— Проведение тестов прокачивает дизайнера: развивает критическое мышление, учит задавать больше вопросов и не принимать первое решение как единственно верное.

----

Автор заметок UX-дизайнера (телеграм-канал UX notes) — Антон Григорьев — опытный проектировщик информационных систем, преподаватель и автор статей. Он каждый месяц прочитывает десятки публикаций, отбирает из них самые достойные, выписывает основные тезисы и публикует в своём канале.

Дайджест заметок UX-дизайнера за июнь 2022