UX Notes

Дмитрий Якушин написал о дизайн-токенах. — Набор дизайн-токенов позволяет сделать визуально согласованный и при этом гибкий дизайн (легко поменять один оттенок на другой); — Дизайн-токен — псевдоним определённого значения той или иной переменной: цвета, шрифта, размера элемента, тени, отступа, скругления; — Цвет #677178 можно назвать color-grey-600 и использовать в макетах так, а можно создать токены color-text-secondary и color-component-badge-bg-neutral, которые будут ссылаться на color-grey-600; — В тёмной теме color-text-secondary может ссылаться на другой цвет, что упрощает создание макетов для других тем; — Говорящие названия упрощают их использование, особенно новыми участниками команды; — Есть черновая версия стандарта дизайн-токенов от W3C; — В составном токене (миксине) может быть больше одной переменной. Например, в токене типографики: название шрифта, кегль, высота строки, межбуквенный интервал; — color-green-600 — глобальная переменная (примитив, палитра, референсный токен) с абстрактным названием без контекста. Число обычно отражает количество света в цвете; — color-text-success — дизайн-токен, который ссылается на переменную color-green-600 и имеет контекст использования: для текстовых сообщений об успехе; — Есть компонентные токены, которые относятся к конкретным компонентам, например, color-component-badge-bg-info для фона информационного бейджика; — Распространены стили названия: color_text_primary для веба, сolorToken.textPrimary для мобильных платформ; — Полная структура названия: префикс, группа (color), тип (text, component), элемент (badge), модификатор (background), вариант (info), состояние (hover); — Некоторых частей может не быть: если токен не относится к компоненту, если к проекту не подключено нескольких библиотек с токенами (прификс их идентифицирует); — В именах токенов размеров лучше не использовать цифры, чтобы не было путаницы с фактическими значениями: xx-small, x-small, small, medium, large, x-large, xx-large; — Категории: colors, font family, font size, line height, border color, grid, border radius, spacing, box shadow, duration/transition, shadows, z-index, size.

Аврора Харли написала о принципе общей области. — Это один из гештальт-принципов, согласно которому элементы внутри границы воспринимаются как группа и имеют общие характеристики и функции; — Границу формируют рамкой или фоном; — Помогает быстро понять структуру интерфейса, какие элементы связаны между собой; — Контрастным фоном на сайтах часто выделяют закреплённое сверху меню и большой футер со ссылками; — Общую область часто используют в аккордеонах, чтобы сгруппировать содержимое раскрытой секции; — Это более сильный способ группировки, чем близость или сходство. Подходит, когда надо сгруппировать разные типы элементов и нельзя регулировать отступы. Или когда уже задействованы другие способы, например, в таблице близостью группируются столбцы; — Чрезмерное использование фонов и рамок создаёт визуальный шум. Иногда полезно убрать лишние рамки и подложки; — Блоки с контрастным фоном во всю ширину окна могут вызывать ложное ощущение футера на странице, из-за чего пользователи могут закончить прокручивать страницу; — Прежде, чем добавить рамки и фон, подумайте, необходимы ли они для понимания группировки элементов?

В RetailRocket написали об а/б-тестировании. — Хороший источник — книга «Доверительное а/б-тестирование»; — Большая проблема — отсутствие а/а-тестов, когда оба сегмента пользователей видят один и тот же контент; — Значимые различия между сегментами в таком тесте показывают, что есть проблемы с делением трафика, недостаточностью данных (мало пользователей) или аномалиями. В этом случае а/б-тест запускать бессмысленно; — Пример аномалии с метрикой «средняя выручка на пользователя» — покупатели с суммой заказа, в разы превышающей остальные заказы. Можно использовать метрики, менее чувствительные к аномалиям; — Важная процедура — оценка мощности метрики, вероятности, что она значимо изменится в ответ на тестируемое изменение (достаточно 80%); — Например, метрика «средняя выручка на пользователя» показывает пользу от блока с рекомендациями в денежном выражении, но её мощность ниже, чем у «среднее количество просмотренных карточек товаров» или «конверсия в пользователя с корзиной»; — При краткосрочном тестировании пользу в деньгах можно не увидеть, если клиент добавит товар в корзину, а вернётся к покупке уже после окончания теста; — Мощность также зависит от окружения. Чтобы проверить влияние блока с рекомендациями, лучше убрать с этой страницы другие инструменты, решающие ту же задачу. Также если блок находится на странице слишком низко, его влияние тоже будет ниже; — Важно понимать, на что влияет тестируемая функциональность. Блок рекомендаций может увеличить количество покупателей, но ARPPU при этом может даже уменьшиться, если часть из них купит что-то по мелочи; — Влияние на разные группы пользователей может отличаться. Блок рекомендаций для новых пользователей может влиять на конверсию, а для старых — на средний чек; — Чаще всего не получится обойтись одним тестом; — Оценить полезность инструмента можно и без а/б-теста. Можно проанализировать количество товаров с атрибутом «найдено с помощью системы рекомендаций».

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

Вика Шаханина написала о проектировании настройки повторяющегося события в календаре. — Чтобы не изобретать велосипед, можно изучить существующие решения. Настройка повторяющихся событий есть в нативных календарях в iOS и Android; — Прежде, чем слепо копировать аналог (если решения разные, надо ещё разобраться, какое достойно копирования), полезно протестировать его на респондентах; — Тестировать iOS и Android-календарь стоит как на пользователях соответствующей системы (календарь им привычен), так и на пользователях альтернативной; — Трудности с созданием события, повторяющегося каждые 3 месяца, возникли в Андроиде; — Чтобы задать характер повтора, надо было нажать на поле «Не повторяется» с двумя стрелками по кругу. Не все догадались на него нажать для настройки повторения (проблема индикатора состояния и команды); — В самой настройке повтора был заголовок «Повторяется раз в», поле для ввода цифры и селектор с несклоняемыми «день, неделя, месяц, год». Последнее затруднило понимание. Один респондент поставил повтор каждые 4 года, думая, что повтор будет 4 раза в год; — В итоге выбрали решение из iOS с добавлением склоняемой подсказкой о текущей настройке: «Каждые 2 недели», «Каждые 3 месяца».

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

Артур Валиуллин написал о дизайнерских синках. — Ежедневные синки помогают синхронизировать команду, следить за качеством, растить дизайнеров и чаще проводить ревью; — Обратная связь, взгляд со стороны нужны постоянно, а не только тогда, когда их попросили; — Синки оперативнее канбан-доски показывают сдвигающиеся сроки и ситуации, когда продакт решил изменить ранее согласованный сценарий; — Все знают, над чем работают коллеги; — Дизайнеры учатся друг у друга; — Виден текущий уровень дизайнеров: кто готов переходить на новый грейд, обучать новичков, кому не хватает компетенций; — Достаточно одного часа, если в команде 7–10 человек; — Если недельные спринты с началом в понедельник, проверять статусы задач можно во вторник и четверг; — Это скорее групповой менторинг, когда команда помогает находить решения; — Не все активно вовлекаются. Точечно спрашивайте мнения тех, кто не участвует; — Вопрос «Если ли вопросы или темы для обсуждения?» в конце формирует доверие в команде. Плюс иногда вопросы появляются; — Придумывайте ритуалы, например, в понедельник спросить «Как ваши выходные?».

Владимир Гайдадей написал об управлении интерфейсом одним пальцем. — Существующие решения: режим одной руки (активируется свайпом вниз в нижней части экрана), когда верхняя часть интерфейса смещается в центр экрана. Так можно дотянуться до кнопки «Назад» в левом верхнем углу; — Режим одной руки на экранной клавиатуре уменьшает её, позволяя дотянуться до всех букв большим пальцем; — Кажется, они не особо популярны, так как проще перехватить телефон или использовать вторую руку. И они не учитывают, что палец может находиться не у нижней части телефона; — Samsung, Xiaomi умеют уменьшить весь интерфейс под диагональ в 4 дюйма (можно настроить) и расположить в правом нижнем углу экрана; — Обычно скрол останавливается, когда нижняя часть прокручиваемого контента достигает нижней стороны экрана или верхняя часть — верхней стороны; — Можно реализовать длинный скрол — останавливать его, когда нижняя часть контента достигает верхней стороны экрана или верхняя часть — нижней. Так элемент, на который пользователь хочет нажать, можно проскролить в любую часть экрана, где бы ни находился палец; — С одним пальцем пользователю остаются свайпы и тапы (одинарные, двойные и так далее); — Свайп вправо можно оставить под возвращение назад, кроме главного экрана, где с ним может быть связано другое действие; — Свайп влево в этой концепции подойдёт для вызова меню с действиями, которое также обладает длинным скролом.

Елена Сеченых написала о тёмной теме в письмах. — Нет единых правил инвертирования в разных почтовых сервисах и даже разных приложениях одного и того же сервиса; — 4 варианта поведения: ничего не делать (большинство десктопных клиентов, веб-версии Gmail и Яндекс Почты); инвертировать светлые письма и не трогать тёмные; инвертировать и туда и обратно (Gmail на iOS); позволять управлять отображением с помощью медиазапросов (Apple Mail на macOS и iOS, Mail Ru на мобильных и в веб-интерфейсе); — Подбирайте палитру, чтобы автоматически выбираемые почтовиками инверсные версии цветов оставались контрастными. Лучше не использовать жёлтый — по факту остаётся светлым и становится чуть более грязным; — Изображения автоматически не инвертируются. Можно использовать картинки с прозрачным фоном. В этом случае может понадобиться светлая обводка, которой не будет видно в светлой теме, но которая выделит графику в тёмной (например, чёрный логотип, если брендбук не запрещает); — Не забудьте про фоновые изображения. Они не инвертируются и находящийся поверх них текст может потерять контраст; — Если почтовик умеет обрабатывать медиазапросы, можно просто подготовить отдельное изображение; — Обязательно проверьте отображение письма в андроид-приложениях Яндекса, Mail Ru, Gmail, а также в Gmail на iOS; — Есть сервисы для тестирования писем: Email on Acid, Litmus, но они не работают с Яндексом. Фреймворк для вёрстки Ampier показывает и классическую инверсию, и вариацию Gmail на iOS.

Александр Мачуговский написал, как сообщать пользователю о пустых обязательных полях формы. — Правило хорошего UX — дать пользователю возможность вернуться в предыдущий режим, к изначальному состоянию; — Пользователь нажимает на кнопку отправки формы, все пустые поля переходят в состояние Error, в нормальное состояние они возвращаются по очереди по мере заполнения. По сути форма переходит в режим отладки; — Нажатие на кнопку приводит к изменению состояния полей, но объект взаимодействия — кнопка, с ней связан локус внимания пользователя. Но не она говорит с пользователем, а поля (которые вместо полей ввода стали полями вывода); — Если автоматически фокусироваться на первом пустом поле, на мобильных это приведёт к отображению клавиатуры и затруднит изучение формы в целом. Можно прокручивать страницу к этому полю, но тогда пользователю придётся нажимать на поле, чтобы его заполнить; — Стоит разделять ошибки данных (не хватает @ в адресе электронной почты) и ошибки процесса (пришёл ответ сервера о несуществующем адресе); — Пустое поле — не ошибка данных, а приглашение к взаимодействию; — Принцип «один экран — одно действие» сокращает количество вариантов для выбора и повышает его скорость; — Если на экране одновременно одно поле, поднимающаяся при фокусе клавиатура не мешает. Если оставить его пустым, нажатие на «Продолжить» вернёт фокус в поле и отобразит клавиатуру, приглашая к взаимодействию без сообщения об ошибке; — Если на экране полей много, можно реализовать их последовательное заполнение, переходя между полями кнопкой Next на экранной клавиатуре и прокручивая страницу так, чтобы заполняемое поле было ровно над клавиатурой; — При попытке отправить форму можно вернуть пользователя к первому неправильно заполненному полю (с сообщением об ошибке), не помечая все остальные.

Юля Кондратьева поделилась исследованиями тёмных паттернов из научных статей (компании таким делятся редко). — 95% исследованных приложений и 97% популярных сайтов содержали тёмные паттерны. Правда, к ним относят и довольно вегетарианские приёмы вроде проставленной по умолчанию галочки; — Если рядом расположить одинаковые кнопки «Подписаться» и «Отказаться», конверсия будет 16,7%. Если «Подписаться» сделать акцентной — 18,1%. Если под «Подписаться» написать «Рекомендовано» — 20,1%. Если «Отказаться» заменить на ссылку «Другие опции» — 23,6%; — Если информацию о стоимости после истечения бесплатного месяца написать мелким серым цветом в сноске, конверсия становится 30,1% (без этого — 14,8%). Если добавить социальные доказательства — 22,1%. Если использовать манипулятивную формулировку на кнопке отказа — 19,6%. Если ограничивать время и создавать ажиотаж — 14,3%; — Тёмные паттерны сильнее влияли на респондентов с худшим образованием; — Удлинение флоу отказа повысило конверсию с 11,7% до 25,8% (+2 шага) и 41,9% (+6 шагов, похожий был в Яндекс Плюсе). При этом оценка готовности повторить опыт снизилась всего с 4,46 баллов до 4,11 и 3,97 из 7; — Пользователи посчитали интернет-магазин с целым набором тёмных паттернов более надоедливым по сравнению с магазином без них: 3,44 балла против 2,34 из 5. А также хуже соблюдающим свои обещания (3,26 против 3,55, −5,8%) и менее вызывающим доверия (3,07 против 3,42, −7,5%); — В одном исследовании дизайнеры опознали меньше половины тёмных паттернов. Не разбираясь, можно неосознанно использовать их в своей работе; — Многие научные работы посвящены автоматическому отслеживанию тёмных паттернов. Возможно, когда-нибудь браузеры станут предупреждать о них при посещении сайтов или поисковые системы учитывать их наличие при ранжировании сайтов.

Катя Тюхай рассказала о конфликтах в продуктовой команде. — Самый распространённый — борьба за ресурс, когда дизайнеров или исследователей мало, а продуктовых команд и задач много. Можно перевести их в формат студии, без привязки к продуктовым командам, или чётко разделить, сколько времени можно тратить на задачи конкретной команды; — Если дизайнеров достаточно, надо легализовать теневые работы вроде дизайн-ревью, которые часто не учитывают при планировании; — Руководитель не должен выносить конфликты на уровень команды; — Конфликты могут возникать из-за культурной разницы. Минимизировать их помогает неформальное общение с коллегами (например, в формате Random Coffee), один день поработать рядом с человеком на его рабочем месте, сессии совместной работы; — Когда сотрудник хочет, но ещё не готов стать лидом, предложите взять какой-нибудь спецпроект, стать лидером компетенции, составить чеклисты или методички, менторить стажёра; — У команд противоположные KPI (продавцы хотят быстрее совершать сделки, риск-менеджеры — тщательнее их проверять). Надо встретиться, обменяться цифрами и целями на полгода-год и найти точки соприкосновения. Они есть всегда; — Нет ресурсов на достижение KPI. Ищите команды со схожими целями и KPI. Например, если занимаетесь дизайн-системой, вовлекайте тех, кто получит от её внедрения максимальный буст; — Непрозрачные процессы. Создавайте чеклисты, шаблоны задач, автоматизируйте прохождение задачи в Jira, внедряйте синки, например, большие горизонтальные демо раз в одну-две недели.