UX Notes

Анастасия Ефанова написала, как сокращение количества пушей в 2,5 раза повысило конверсию из пушей в 3 раза и снизило отписки на 38,5%. — Ключевая метрика — конверсия в завершённую смену, то есть работник согласился на подработку и отработал смену; — Пуши использовались для онбординга, вывода на смену, информирования об акциях; — Новые пользователи получали 8–10 пушей в день. Важно конвертировать их в первую смену в течение месяца, иначе такой пользователь отваливается; — Начали с изучения сценариев отправки пушей. Выяснили, что информируют о закончившихся акциях или работают в соответствии с устаревшей бизнес-логикой (напоминают о чекине в течение часа после выхода на смену, хотя такого требования уже нет); — По конверсии и адекватности количества пушей все сценарии разделили на худшие (надо отключать), средние (улучшать), лучшие (масштабировать); — Например, пуш о подработках в радиусе 20 км был бесполезен в Москве и Петербурге, так как местные работники не готовы ездить так далеко; — Сократили интервалы между онбординговыми пушами, чтобы отправить их за 2 недели вместо месяца и во вторые 2 недели сфокусироваться на конверсии в смену; — Большинство всё равно загружает документы и выполняет прочие действия сразу, и пушей с напоминаниями не получает; — Ввели ограничения на пуши о подработке в радиусе 10 км, если работник уже на смене или выйдет в ближайшие дни. Плюс отправляют их не чаще одного раза в день; — Понизили приоритет пушей об акциях: если уже отправлен пуш о подработке, пуш об акции не отправится; — Добавили ограничения на уровне сценариев. Триггерный сценарий срабатывает не чаще одного раза в 2 часа. У отдельных сценариев (вроде возвращения доступных подработок) — раз в 2 дня. #push

Татьяна Бублик поделилась своей системой организации файлов в Фигме. — Все макеты продукта могут находиться в одном файле; — Из-за этого он может тормозить и даже перестать открываться, обновления дизайн-системы будут применяться ко всем макетам, даже архивным, команде сложно находить нужные макеты; — В Фигме есть бранчи, но недоработки этого инструмента и ошибки дизайнеров могут принести больше проблем; — Заведите папки: для файлов дизайн-системы (сюда можно отнести редполитику и любые вспомогательные материалы), для текущих задач (и шаблонов для новой задачи и мастер-файла), для каждой фичи или микросервиса; — Макеты по отдельной задаче создаются в отдельном файле, в названии которого есть номер тикета, чтобы легко его находить; — Появляется такой файл в папке для текущих задач. Дизайнер подключает к нему нужные файлы дизайн-системы; — При передаче макетов в разработку размещает их на странице For dev; — После успешного дизайн-ревью и завершения разработки перемещает файл в папку фичи; — А макеты из файла задачи копирует в мастер-файл фичи, в котором отображаются макеты всех флоу фичи; — Статусы задачных файлов отличаются от статусов задач в таск-трекере: In progress, Ready for dev, Design review, Freeze, Closed (закрыта, но ещё не перенесена в папку фичи), Archive (перенесена в папку); — В архивных файлах дизайнер не принимает обновлений ДС, макеты выглядят так, как должны были быть разработаны, что важно разработчикам и тестировщикам; — Мастер-файлы фич содержат макеты всех флоу, что позволяет команде быстро понимать актуальное состояние фичи; — Система требует времени для поддержания порядка (час каждого дизайнера в спринт). Плюс команде требуется время, чтобы привыкнуть. #figma #management

Стас Мельников написал, как с помощью CSS-свойств улучшить дизайн веб-страниц. — Чтобы, например, на последней строке заголовка не оставалось одного слова, можно использовать свойство text-wrap: balance; — Свойство padding задаёт внутренние отступы. У интерактивных элементов оно позволяет увеличить область нажатия и облегчить пользователям попадание по таким элементам; — Если на новость ведёт ссылка и в заголовке, и в картинке, пользователи скринридеров услышат о ссылке дважды. С помощью псевдоэлемента ::before можно убрать вторую ссылку и при этом сохранить интерактивность картинки; — В разметке попапа код кнопки закрытия часто идёт первым. В этом случае пользователи скринридера, открыв попап, сразу же слышат о кнопке закрытия попапа; — Можно расположить код кнопки в конце разметки попапа, но с помощью свойства position: absolute сохранить её визуальное расположение в верхней части попапа; — Для выделенного текста голубой цвет фона можно заменить на любой другой. При этом цвет текста можно автоматически делать контрастным по отношению к цвету фона с помощью функции contrast-color(). #accessibility #css

Кейт Каплан написала о контекстном меню. — Контекстное меню включает набор действий, связанных с конкретным элементом или областью интерфейса. Оно помогает уменьшить визуальный шум и скрыть второстепенные действия; — На десктопе оно может отображаться по нажатию правой кнопки мыши, но чаще всего используют иконку с тремя горизонтальными (митбол) или вертикальными (кебаб) кружками; — Пользователи нормально их воспринимают. Но не используйте иконку бургера: она ассоциируется с основной навигацией; — Минусы: по его внешнему виду не догадаться, какие действия доступны внутри. Если иконка мелкая, малоконтрастная и находится далеко от связанного объекта, её могут не заметить; — Поэтому не размещайте в этом меню важные действия; — Три кружка могут принять за индикатор прогресса или карусели (если они расположены рядом с картинкой, как в примере из статьи); — Кнопку меню отображайте всегда, а не только при наведении курсора на связанный с ним элемент. Размещайте её рядом с этим элементом; — Рядом можно разместить другие кнопки управления элементом, чтобы намекнуть пользователю на содержимое контекстного меню; — Будьте последовательны: используйте иконку митбола или кебаба в своём интерфейсе только для контекстного меню. Даже для контрола раскрытия скрытой части текста не используйте «…»; — Добавьте тултип, например с текстом «Действия с публикацией» или перечнем действий, как в Ноушене: «Style, export, and more…»; — Если в меню мало действий (или вообще одно), попробуйте обойтись без контекстного меню. In English. #menu

UX Feedback запускает «Разговоры» — новый формат встреч онлайн. Несколько команд коротко рассказывают свои реальные кейсы, а остальное время обсуждаем их вместе — что сработало, что нет и почему у соседней команды в похожей ситуации получилось иначе. У каждого продукта своя специфика, поэтому всё не сводится к общим советам под конец. В ближайшем выпуске — про то, сколько на самом деле стоит искать респондентов среди своих же пользователей. Нужные люди уже внутри продукта — значит, на рекруте точно можно сэкономить? Не всегда. На деле в процесс включаются скринер, нужный сегмент, приглашения, переписка, назначенные и сорванные слоты. И экономия почти никогда не значит быстро или просто. 17 сентября в 16:00 разберём это на реальных примерах вместе с экспертами из Циан, Hoff, S7 и T2: — что именно компании экономят: деньги, дни или часы сотрудников; — как находить пользователей с нужным продуктовым опытом; — где чаще всего ломается путь от приглашения до интервью; — когда стоит продолжать рекрут среди своей аудитории, а когда разумнее выбрать другой канал. ➡️ Регистрация здесь Реклама ООО «Фидбек». ИНН: 5030094661, erid: 2VtzqwpLukp

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

Снежана Чепа написала об ошибках в работе с персональными данными на российских сайтах, которые могут привести к штрафам. Суммы можно посмотреть в статье. — Использование Гугл Форм. Данные должны попадать в базы, находящиеся на территории России. Гугл Формы можно заменить на Яндекс Формы; — Нет предупреждения о куках. Куки у вас точно используются, если подключены сервисы веб-аналитики; — Под формами нет согласий на обработку персональных данных (ПД) или они не соответствуют требованиям закона. Политика конфиденциальности ≠ согласие на обработку ПД; — В согласии должна быть цель обработки данных, их полный список, срок, в течение которого действует согласие; — Нет чекбокса «Я соглашаюсь на обработку персональных данных в соответствии с политикой конфиденциальности». Слово «соглашаюсь» можно сделать ссылкой на согласие, «политикой конфиденциальности» — на политику; — Отзывы размещены без получения согласия на распространение ПД. Если размещаете отзывы, лучше получить отдельное согласие по специальной форме (есть в статье); — Нет политики конфиденциальности или она не соответствует требованиям. В ней должны быть сведения о каждой цели обработки данных; — Не уведомили Роскомнадзор об обработке ПД; — Нет соглашения о поручении обработки данных третьим лицам, например, сервисам рассылок. Такое поручение можно сделать разделом заключаемого с клиентами договора; — Нет документа с перечнем всех мест хранения ПД на бумажных носителях, если в вашем бизнес-процессе используются такие носители; — Важно реагировать на обращения, например вопросы о том, на каком основании человек получает от вас письма, запросы на удаление ПД из ваших баз данных. #laws

Русалина Ушакова написала о том, когда удобный интерфейс мешает обучению. — Десятилетия исследований памяти показывают: что даётся легко — запоминается хуже; — Условия, в которых ученик показывает высокую производительность в моменте, часто приводят к слабому долгосрочному запоминанию, и наоборот; — Метрики вовлечённости измеряют производительность. Нужны отдельные метрики запоминания, например, как ученик справляется с заданием через неделю без подсказок, а не сразу после урока; — Запоминанию способствуют усилия при обучении: чем сложнее задание (при условии, что оно остаётся посильным), тем лучше; — Если часть урока потратить на вспоминание материала вместо его перечитывания, долговременное запоминание резко растёт; — Предложите сначала вспомнить ответ, прежде чем появится возможность выбрать из предложенных вариантов; — Также лучше запоминается то, что ученик создал сам: ввод вместо выбора, достраивание вместо чтения, объяснение своими словами; — Полезно смешивать разные типы задач, а не давать их однотипными блоками. Мозг учится каждый раз определять, какой приём применить. И это ближе к реальной жизни; — Слегка отложенная обратная связь при ответе на вопрос лучше моментальной. У мозга есть время «додумать» и удержать усилие, что закрепляет эффект; — Когда ученик был уверен в ответе, но ошибся, запоминается лучше, чем когда ученик сомневался. Уверенность можно определить по скорости и решительности ответа; — Важно это использовать и при уверенных ошибках давать более заметную обратную связь, которая подчеркнёт контраст: думал так — вот как на самом деле. #learning #principles

😎 Авито ищет UX-редакторов: присоединяйся к оплачиваемой программе Design Bootcamp и развивай продукт для миллионов пользователей. Что тебя ждёт: —12 месяцев работы над реальными задачами; — поддержка наставника и рост от стажёра до мидла; — шанс продолжить карьеру в Авито. Ты будешь: — в паре с дизайнером создавать логичные и дружелюбные интерфейсы; — участвовать в дискавери-синках и обсуждать развитие продукта; — работать над лендингами и рассылками; — придумывать что-нибудь новое, например, название новой фичи. 📌 Откликайся на программу здесь!

Помните шутку «почини принтер, ты ж программист»? А бывало у вас такое же с дизайном? Типа «нарисуй дракона, ты ж дизайнер» или «подскажи, какие обои лучше поклеить, ты ж дизайнер». И смех смехом, но я помню времечко, когда неважно, какой ты дизайнер — ты и полиграфию делал, и фотки ретушировал, и иллюстрашки валил, и юзер-флоу, и упаковку… Почему помню? Потому что вчера это было. Я делал визитки. Очень, должен сказать, интересно было потрясти стариной. Но это заставило меня задуматься, о скольких вещах нам нужно помнить, чтобы собрать правильный пользовательский опыт. Даже о таких, казалось бы, незначительных, как буквы в адресной строке. Типа: https://www.example.com:8080/store/catalog/item.php?category=shoes&size=42#reviews А с ними всё совсем не просто. Если почитаете оригинал вот этой статьи, то вам станет понятно, что URL состоит из многих частей, которые нужно упаковывать консистентно, сродни токенам дизайн-библиотеки, чтобы сделать его читабельным и продуцирующим меньше ошибок. Вот несколько советов по работе с урлами, которые вы можете положить к себе в DoD или DESIGN.md для проверки: — Путь (это домен и всякие слэши) должен указывать на постоянный ресурс или понятную иерархию. Все части пути пишем маленькими буквами и разделяем в едином стиле (например, всегда через дефис, иначе тётушка Клава задолбается переводить пробельчики в %20 и вводить адрес своими большими пальчиками) 💅. — Если структура сайта поменялась, со старых публичных ссылок нужно обязательно настроить редиректы на новые адреса, иначе мы рискуем терять людей, которые заложили себе старый URL. 🔖 — Для идентификаторов (ID) и понятных названий в ссылках (slugs) стоит продумать логику, чтобы они не менялись со временем. Это про то, что https://www.megaman.com/blog/4533 (на конце ID) и https://www.megaman.com/blog/fight-for-juice (на конце slug) могут вести на одну и ту же страницу. Да и должны бы всегда это делать, даже если статью переименуют: slug изменится, а ID останется. 🔓 — Для дополнительных фильтров и настроек отображения используйте понятные и задокументированные параметры запроса (всё, что идёт после [?] ). Массивы в параметрах всегда передаются одним, чётко задокументированным способом. Все значения из параметров нужно аккуратно раскодировать, проверять на корректность и задавать для них разумные ограничения. 👩‍💻 — Фрагменты (с решёткой #) лучше оставить исключительно для навигации внутри страницы или работы с состоянием на стороне клиента. 🚫 — Ну и капитанское: В ссылках не должно быть никаких паролей, секретных токенов или личных данных — безопасность превыше всего. 🇺🇸 В общем, принимайте во внимание даже такие мелочи, чтобы сделать взаимодействие максимально приятным! И да пребудет с вами дизайнерская сила.