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 месяца».